NanoVNA Custom Software

[radiolistener]

With the latest firmware, the screen doesn't go white like it used to but the Nano locks up.  It will not accept USB commands and requires a power cycle to recover.   

Try this version

[joeqsmith]

With the latest firmware, the screen doesn't go white like it used to but the Nano locks up.  It will not accept USB commands and requires a power cycle to recover.   

Try this version

I would have no way of knowing what this version is.  That's been part of the problem I see with the edy555 and hugen79 code, they do not document. As a user,  I can waste time running a diff and try to sort of what they changed and why.  A bit odd they don't keep a detailed log of the changes.

It looks like hugen79 also released something new in the last couple of days.  Like the latest edy555 release, they also enabled the scan command. 

It may be worth spending some time putting together some sort of automated regression tests for the Nano. 

[ogden]

I had put together a longer stage for my TDR experiments and was running some fairly long tests

While doing that did you remember what you say some time ago? Just saying.

[joeqsmith]

I had put together a longer stage for my TDR experiments and was running some fairly long tests

While doing that did you remember what you say some time ago? Just saying.

Sure I remember.  What about it?

[ogden]

I had put together a longer stage for my TDR experiments and was running some fairly long tests

While doing that did you remember what you say some time ago? Just saying.

Sure I remember.  What about it?

Well...  Rebuild of delay contraption removed most of obstacles you mentioned back then. So @rhb could get info he looked for.

[radiolistener]

Try this version

I would have no way of knowing what this version is.  That's been part of the problem I see with the edy555 and hugen79 code

This is the most fresh version which includes edy555 changes + hugen79 improvements + improved stability + scanraw command. It also excludes these changes which didn't passed QA due to regression.

scanraw command allows to read raw S11 or S21 (with no calibration apply) and averaging. You can use it to apply your own calibration.

For example:

Code: [Select]

scanraw 0 1000000 1000000 900 10
will read 900 points from 1 MHz to 900 MHz with 1 MHz step and averaging by 10 points for CH0.

You're needs to apply your own calibration to the result.

[joeqsmith]

Try this version

I would have no way of knowing what this version is.  That's been part of the problem I see with the edy555 and hugen79 code

This is the most fresh version which includes edy555 changes + hugen79 improvements + improved stability + scanraw command. It also excludes these changes which didn't passed QA due to regression.

scanraw command allows to read raw S11 or S21 (with no calibration apply) and averaging. You can use it to apply your own calibration.

For example:

Code: [Select]

scanraw 0 1000000 1000000 900 10
will read 900 points from 1 MHz to 900 MHz with 1 MHz step and averaging by 10 points for CH0.

You're needs to apply your own calibration to the result.

Please fill me in on this regression testing you mention.     

Do you have a link to where the source is being stored for the image you uploaded? 

[radiolistener]

Do you have a link to where the source is being stored for the image you uploaded?

https://github.com/qrp73/NanoVNA

[joeqsmith]

Do you have a link to where the source is being stored for the image you uploaded?

https://github.com/qrp73/NanoVNA

Thanks for the link.

In order to evaluate all of these various versions efficiently, I would really need to consider setting up some sort auto or semi-auto regression test.   I am very interesting in knowing more about the regression testing you mentioned.   Mainly, what tests you perform?  Is it possible to use your test scripts on other flavors?   What hardware you require?  Do you create any sort of reports that could be posted?   

If your regression tests could be shared with the other developers, that may be helpful. 

Currently I have no way of running a decent test outside of just manually going through the paces.   This takes a fair amount of time.

[ogden]

Got nanovna by shopping spree accident, black clone. Why it's not "original" - don't ask. Perhaps for greater good. Port2 mixer IC (sa612) was dead, reflection mixer seems to be "factory-repaired" as well. After quick fix it seems to perform well for a price.

Supplied cables and short are surprisingly good. Open is good by definition because it's joke at those frequencies anyway. Terminator/load is utter piece of crap. Every owner of nanovna shall consider getting quality 50ohm terminator. Those who can afford some more may get 2nd terminator and 10dB, 20dB, 40dB 6dB attenuators.

I did calibrate repaired and fully functioning nanovna using supplied accessories + mini-circuits terminator. Measured S11 of mini-circuits terminator, then supplied terminator. Files attached.

[radioactive]

Terminator/load is utter piece of crap. Every owner of nanovna shall consider getting quality 50ohm terminator.

I guess results may vary.  The 50-ohm terminator I was supplied results in S11 measurement range very close to your mini-circuits terminator measurements.

[ogden]

Terminator/load is utter piece of crap. Every owner of nanovna shall consider getting quality 50ohm terminator.

I guess results may vary.  The 50-ohm terminator I was supplied results in S11 measurement range very close to your mini-circuits terminator measurements.

Be careful before you jump with conclusions. You can't judge about quality of your terminator unless you have one reference to calibrate & compare with. With just one terminator you don't know. You may see amazing return loss picture like attached S11 and do not even know that it is actually worst 50ohm'ish crap ever:

[radioactive]

Terminator/load is utter piece of crap. Every owner of nanovna shall consider getting quality 50ohm terminator.

I guess results may vary.  The 50-ohm terminator I was supplied results in S11 measurement range very close to your mini-circuits terminator measurements.

Be careful before you jump with conclusions. You can't judge about quality of your terminator unless you have one reference to calibrate & compare with. With just one terminator you don't know. You may see amazing return loss picture like attached S11 and do not even know that it is actually worst 50ohm'ish crap ever:

The supplied terminator I received with nanoVNA also looks very close to a Weinschel 50 ohm terminator of mine.

[radiolistener]

Terminator/load is utter piece of crap. Every owner of nanovna shall consider getting quality 50ohm terminator.

Don't rush to draw conclusions. There is big probability, that your minicircuit is much worse. At least on 1-900 MHz frequency range. I'm pretty sure about that. Because this is not cal-kit load. This is usual 50R terminator.

At least my NanoVNA cal-kit L load is very good. It has 49.95 Ohm and works much better than all Chinese terminators that I have.

Your minicircuit may be very good above 6 GHz but it cannot be good within entire 12 GHz range, so there is very high probability that it is not so good below 1 GHz

First, try to measure your minicircuit load terminator with precise DMM. And compare it with cal-kit L load.

The second issue, is that all cal-kit loads needs to have the same delay. Do you have O and S loads for your minicircuit? I guess not. And it means that you cannot use it with O and S loads from NanoVNA kit, because they have different delay. And according to picture, significantly different. I think the difference is about 20-30 picoseconds. Such delay is too high for NanoVNA.


Regarding to your request for screenshot, here it is:

CH0 and CH1 are open:


CH0 and CH1 both connected with 50R load:

[ogden]

Your minicircuit may be very good above 6 GHz but it cannot be good within entire 12 GHz range, so there is very high probability that it is not so good below 1 GHz

No. You are wrong. https://ww2.minicircuits.com/pages/s-params/ANNE-50+_GRAPHS.pdf

The second issue, is that all cal-kit loads needs to have the same delay. Do you have O and S loads for your minicircuit?

Purist You better check presence of pin in your Open "standard" first.

And according to picture, significantly different. I think the difference is about 20-30 picoseconds.

Where did you get 20-30 picoseconds from?

[edit] Thank you for screens! Speaking of insanely good return loss indication - again we see that you can't estimate precision of the ruler using same exact ruler

[joeqsmith]

I have started working on my own regression test.   

I had thought about using the SA, tied to the PC to aid with some of the tests but decided to keep the required hardware to a minimum for now and just do what I can with a thru installed.   

It needs more work but can at least catch the basic problems I have been seeing with some of the firmware with the added bonus, I don't have do anything outside of pressing go.  Considering it takes a few hours to run through all the tests so far, this is a big time saver.   

[joeqsmith]

With the latest firmware, the screen doesn't go white like it used to but the Nano locks up.  It will not accept USB commands and requires a power cycle to recover.   

Try this version

I was planning to use this version while I work through my regression tests.   I have started adding a report generator and increasing some of the tests I run.   I will report the problems as I find them.  If you want to try to correct them as I find problems, I would be willing to work with you to run your changes through my regression tests. 
 

Problem 1
Setting the Center frequency to 750MHz, then set the Span to 1500MHz.   Request the Frequency.   The firmware returns only 100 data points rather than 101.  I would expect the Nano to always send 101 data points.    This problem is reproducible.   

Problem 2
Setting the Start frequency to 0MHz, the Stop to 1MHz.   Request the Frequency.   The firmware returns a starting frequency of 10KHz rather than the expected 50KHz.  The number of data points is correct.   I would expect the Nano to limit the lower frequency to 50KHz, or there should be a document explaining that the lower limit is now 10KHz.   This problem is reproducible.   

Problem 3
Screen still leaving random artifacts from previous scan when using the Smith Chart.  This problem is reproducible and appeared in the firmware that was supplied with my Nano.   I have yet to see firmware that does not have this problem.

Problem 4
After programming the new firmware into the Nano and running a calibration, the calibration appeared corrupt.  An open was on the left side of the screen and a short was on the right.  Applying any load would be unstable when looking at the display.   The frequency range was set to 0.05 to 900MHz prior to calibration.  A reset was ran prior to calibration.    Attempting to repeat the calibration corrected the problem.  I have not attempted to repeat this condition. 

Problem 5
Programming a start of 50KHz and an stop frequency of 1500MHz.   Request the Frequency.   The firmware returns the correct frequency for the first data point.   Looking at higher frequencies, there is an error between various firmware.  For example, some will report 1500 for the last data point where others report 1499.99995.   For a given version of firmware, it will return predictable values.    This problem is easy to reproduce. 

[ogden]

View at the terminators from another angle. Attached R+jX plots for minicircuits anne-50+ (18GHz) terminator, original terminator and original terminator with 40dB 18GHz hi-end attenuator attached. That atten BTW is worth more than nanovna. It is clear that supplied terminator have "parasits" inside. To be clear - that minicircuits terminator is more than good as minivna cal standard. Any claim that it's performance at minivna frequencies is poor - utter BS.

[edit] note that "original terminator" means: originally supplied with nanovna *clone*, black version

[erikka]

The nanoVNA internal calibration assumes a 50fF C0 parasitic for the load. Would that match your measurement?

[ogden]

The nanoVNA internal calibration assumes a 50fF C0 parasitic for the load. Would that match your measurement?

For "good terminator" - kind of. It's capacitance and inductance indication is noisy as it should be measuring return loss noise floor, yet averages around zero. Not so good terminator "averaged" around 1nH, attach.

[radioactive]

Anyone else think that the need for better than 40dB for an S11 measurement might be a post for the Metrology thread?   The description could be changed from "This is where the Voltnuts hang out."   to  "This is where the Voltnuts and S11nuts hang out".   

[hendorog]

The nanoVNA internal calibration assumes a 50fF C0 parasitic for the load. Would that match your measurement?

That's not correct, unless something has changed recently. The 50fF is for the open. The Load and Short standards are assumed perfect.

[joeqsmith]

I have added a few more findings to my list as I continue to expand my test scripts:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2736580/#msg2736580

I decided to try and build the last edy555 code from 10112019 and run the regression test on it.    This was right from Git.   

build/ch.elf section `.data' will not fit in region `flash0'
none-eabi/bin/ld.exe: region `flash0' overflowed by 296 bytes

Odd anyone would commit something that won't even build.    It's the first time I have ran into a problem like this with the Nano firmware.   

I tried a version from hugen that I had downloaded on 10102019.  While this version builds just fine, it will send corrupt data at other switch points, not just 900MHz like I was seeing with the older version.     

It appears that most of the firmware I have looked at will send back a frequency of 1500.000000 rather than being off.   I would expect if I program 1500, I would get 1500, not 1499.99995.

[radiolistener]

Attached R+jX plots for minicircuits anne-50+ (18GHz) terminator, original terminator and original terminator with 40dB 18GHz hi-end attenuator attached

your comparison is invalid, just because you're trying to compare different loads with different electronic delay and didn't apply correction for this electronic delay difference.

Such comparison just doesn't make sense, because you're trying to compare measurement taken with significantly different conditions.

[radiolistener]

The nanoVNA internal calibration assumes a 50fF C0 parasitic for the load. Would that match your measurement?

No, the NanoVNA error-adapter assumes 50 fF for open load and also it assumes zero electronic delay (like ideal loads).

Supplied cal-kit is close to that assumption. Some guys reported that supplied open load has 22 fF. That's the only complaint I've heard about cal-kit supplied with NanoVNA.

But ogen trying to compare it with terminator which has much longer visual size. I think it's delay is about 20-30 picoseconds higher than NanoVNA cal-kit load.