NanoVNA Custom Software

[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.

[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.

[ogden]

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.

Comparison was to demonstrate exactly that - "original terminator" have (longer) parasitic transmission line inside, yet you say that I shall compensate for it and basically void whole idea of demonstration 

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.

How many times I shall repeat that I do not compare hugens calkit because I do not have one! I just demonstrate that clones have crap calkits, especially terminators, reference planes of short and load for my supplied cal kit are kinda far from each other.

[edit] Geez, you guys seems are here only to have argument no matter what 
[edit1] Attached R+jX minicircuits terminator in the end of 10cm quality semirigid. As you see impedance does not wander off as in case of crap terminator. Explain that.

[radiolistener]

Comparison was to demonstrate exactly that - "original terminator" have (longer) parasitic transmission line inside, yet you say that I shall compensate for it and basically void whole idea of demonstration 

you cannot make conclusions from your measurements, because your NanoVNA was calibrated with incompatible loads. It means that your NanoVNA calibration is invalid and you cannot believe to it's measurements.

Your cal-lit L load can be really bad, but you're needs to use proper calibration in order to check that. Proper calibration means that all your cal-kit loads - L, O and S should be exactly the same physical length. O load should have 50 fF. If you you can satisfy these conditions for calibration, then you can believe measurements results.


I can help you to determine if your load is really bad and what happens exactly.
In order to do that, please provide me with S1P files taken in the following way:

1) open CAL menu and press RESET
2) open CLIBRATE menu and perform calibration with NanoVNA cal-kit (with using NanoVNA L load). Press OPEN/SHORT/LOAD just once. If you press it twice, go to step 1 (reset cal and repeat).
3) Check if calibration success (check that O, S, L loads shows proper point on Smith chart)
4) Measure S1P file for NanoVNA cal-kit L load
5) Measure S1P file for Minicircuits terminator
6) Provide me with these two S1P files

Provide me with these two S1P files and I will check what is going on with your loads.

[radiolistener]

Attached R+jX

R+jX measurement is very sensitive to electronic delay. Especially on high frequency. Before R+jX measurements, you're needs to setup proper electronic delay in the menu DISPLAY => SCALE => ELECTRICAL DELAY

[radiolistener]

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.   

fixed

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.   

this is not a problem. This is feature of this firmware. It allows to use 10 kHz - 1500 MHz frequency range

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.

this is known issue of all NanoVNA firmware versions, but there is still no fix for that.

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. 

Different firmware may use incompatible calibration settings. In order to avoid such issues, it is recommended to perform clear of configuration and perform full calibration after firmware update. You can clear configuration with the following console command:

Code: [Select]

clearconfig

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.

fixed

Try this version, it solves your issues, allows to enter negative electronic delay and also improves precision for data transfer from NanoVNA to PC.

[ogden]

R+jX measurement is very sensitive to electronic delay. Especially on high frequency. Before R+jX measurements, you're needs to setup proper electronic delay in the menu DISPLAY => SCALE => ELECTRICAL DELAY

Again you do not get what I am actually showing you and/or you do not understand what causes impedance increase @high frequencies in case of crap load. I just give up. Have a nice day. Meanwhile think why hi-end (Keysight, R&S, Anritsu) cal kits have length specifications only for open and shorts, never for broadband loads.

[joeqsmith]

Try this version, it solves your issues, allows to enter negative electronic delay and also improves precision for data transfer from NanoVNA to PC.

There's no link. 

[radiolistener]

There's no link.

Here:

[joeqsmith]

Just downloaded from your GH area and tried to build but once again get errors that it will not fit.  I assume that the image was not built from what is uploaded.

[radiolistener]

Just downloaded from your GH area and tried to build but once again get errors that it will not fit.  I assume that the image was not built from what is uploaded.

there is needs fix for ChibiOS, and it depends on environment. The image has version stamp, it is linked to github version.

[joeqsmith]

With the image you linked, it does appear to correct the rounding, span  and range problems.  Nice job.   I have updated my regression tests to look for the 10KHz lower limit. 

I also want to mention that I ran that last image for several hours and not once did I see the screen go white, or had the firmware lockup where it required a power cycle to reset.   

I am building under Windows 10, with the same tools I previously listed.  What will need to change in the ChiOS to support this tool chain?

There is one thing I notice with your code that seems unique that I find strange.  I run a speed test where I make requests to the Nano and measure the response times.  I start with the Frequencies command, sending it several times.   I then switch to data 0.  At the time I make this switch, with your code I will see the response time increase (about double) for the very first read.  It then settles down.    It also appears to be quicker then some of the older images I was trying to use.   This delay does appear to be repeatable. 

The reason I am asking about this delay is that when I was looking at the PC software they provided for the Nano, they always read the frequency and both data sets.   I suspect as they scan through the commands, this delay would effect the overall speed.  I have not tried to run a cycle test like this yet but may add it to my scripts.

[radiolistener]

There is one thing I notice with your code that seems unique that I find strange.  I run a speed test where I make requests to the Nano and measure the response times.  I start with the Frequencies command, sending it several times.   I then switch to data 0.  At the time I make this switch, with your code I will see the response time increase (about double) for the very first read.

data command needs to wait until NanoVNA will complete sweep. You can monitor sweep state by LED state on the NanoVNA board. When sweep is active, the LED is off, at this moment data command will needs to wait.

Since NanoVNA performs sweep in the loop. The delay of data command will depends on current sweep state. Because data command needs to wait when sweep will be completed.


If you don't change start/stop/center/span frequencies, there is no need to repeat "frequencies" command. You can exectute "frequencies" command just once after start/stop/center/span frequency change. After that you can execute just data command in a loop.

[joeqsmith]

I tried installing your couple of files.  I placed cstartup.s in the compilers/IAR directory and the hal_i2s_lld.c in both SPIV1&2.   It still errors out. 

On the plus side, your latest version just finished running through my simple regression tests and had no errors.   Of course I am not suggesting the code is bug free, just that it passed my simple test.  Good job.

My software waits for each command to have a response before sending the next or it times out.   I had ran some tests early on where I would stack them up, but it seems unpredictable if the Nano would keep up or not.   Basically, in some cases where I would say, make a parameter change, I could send more than one command while waiting for the Nano to respond.   I could not do this with the data commands.    At the time, it would not crash the Nano but it appeared to just not receive the commands.

[radiolistener]

I tried installing your couple of files.  I placed cstartup.s in the compilers/IAR directory and the hal_i2s_lld.c in both SPIV1&2.   It still errors out.

hal_i2s_lld.c needs to be replaced just in the folder ChibiOS\os\hal\ports\STM32\LLD\SPIv2\hal_i2s_lld.c

But actually, these are minor changes, and they should not affect build.

The error depends on tool chain

[joeqsmith]

If you don't change start/stop/center/span frequencies, there is no need to repeat "frequencies" command. You can exectute "frequencies" command just once after start/stop/center/span frequency change. After that you can execute just data command in a loop.

Again, this is a regression test, not normal operation.  I am collecting metrics on the firmware.  One of the metrics is the response time.   When I run this test, I will send the commands over and over (50 times) and then calculate my standard deviation and mean from that.     I run these various odd tests to get some insight as to how the firmware behaves. 

It's similar to setting the center to 750MHz and setting the span to 1500, pushing the low end to 0.  A fringe case but none the less showed some unexpected behavior.   Not something I would normally do if I were just using the Nano.   

Some of the tests seem to cause the white screen in certain firmware versions.   One of the main reasons I am creating these tests is to try and find a stable version of firmware.   

I had asked you about your regression tests that you mention but you chose not to discuss for what ever reason.  I am still open to discussing and plan to continue to add to the complexity of my scripts.