NanoVNA Custom Software

[gf]

One problem with Electrical Delay in the v2 firmware is that it subtracts the SAME delay from S11 and S21. But S11 is round trip, while S21 is one way. So if you set an electrical delay in order to extend port1, then it can be either correct for S11, or for S21, but not for both at the same time.

[gf]

Imo it were better if I could set separate port extension delays for ports 1 and 2, where the former is subtracted 2x from S11 and 1x from S21, and the latter is subtracted 1x from S21.

[Mechatrommer]

afaik the term is de-embedding, and its a math intensive procedure and requires full 2-port VNA, which i believe you havent demonstrated it. neither did i.

A noteworthy trivial special case of de-embedding is "port extension" which assumes that the network to be de-embedded is a piece of ideal 50 Ohm transmission line. This can serve as a good enough approximation for things like (say) a short female-female adapter between calibration plane and DUT, or similar.

only that (bolded line), but can we get ideal 50ohm TL at cheap? are we sure the hunglow pigtail M or F connectors/through are really ideal? its ok if we can only "assume" thats fine with me , but in academic world i dont find it that simple. and characterized/ideal port extender can cost 10x of LiteVNA i guess, unless china manufacturing and QC has figured out something. if only want to extend port/plane for insertable dut.. i can only think of, why we dont just recalibrate at new extended plane? if we have both female and male cal kit? (i have ), so we can let the internal math of VNA FW do the job. the difficult part of extending plane is because the DUT is not insertable such as on PCB. i'm not sure though what the reason we want to test an open coaxial cable with reflections everywhere along the line as dislord did and then get into hassle try to extend (or even backward) the ref plane as we like. ymmv.

[joeqsmith]

One problem with Electrical Delay in the v2 firmware is that it subtracts the SAME delay from S11 and S21. But S11 is round trip, while S21 is one way. So if you set an electrical delay in order to extend port1, then it can be either correct for S11, or for S21, but not for both at the same time.
 
Imo it were better if I could set separate port extension delays for ports 1 and 2, where the former is subtracted 2x from S11 and 1x from S21, and the latter is subtracted 1x from S21.

My released software only trims the delay for S11/S22.  The newer version supports S11/S21 (/2 for S21) but currently does not support the transfer relay.   That section of code is the main reason for the change and is still work in progress.   

[realfran]

The software average work fantastic fast, this for the tuning filter is important.
I get a little confused with the TDR I tray to test my LINE stretcher, I need to learn to use it (not a lot of information for coax line stretcher)
When I did 2 port calibrations with the Transfer relay on, I get the same image for both ports works very good.

[joeqsmith]

It's a round robin average.  While you are always getting the averaged data at what ever rate the VNA is sending it, if it's 10 deep and the Nano sends data once a second, it will take 10 seconds to rifle through (think step response).  If you are tuning a filter (or anything else with trimmers) I would imagine you want instant feedback.  You may be able to reduce the number of data points to obtain acceptable feedback but I doubt it.  You may also be able to give up the average features but if you are working with communications, again I doubt it.  Even with average, I doubt they are good enough for this kind of work.   I think its a case where you would need something better than the Nano.  This is something the CB and amateur radio hobbyist would need to chime in on. 

I do not understand what you are trying to do with these delay lines you keep mentioning which is why I had asked you once to explain it.  It should be obvious that the more you extend them, TDR would show a longer time of flight.   Maybe just post a short video clip of your setup and what it is doing.  Then explain in text what you feel it should be doing.   

[joeqsmith]

DH7DN had posted an article about using the V2Plus4 with my software. 
https://physik.co-i60.com/2022/01/new-addition-to-the-lab-nanovna-v2-plus4/

First steps

Buy NanoVNA, plug in the USB cable and turn it on. If you’re using Windows 10, the device should be recognized as USB CDC (Communications Device Class) on a virtual serial port (e. g. COM6). Next steps will be a little bit annoying: create an account on the National Instruments (NI) homepage, download and install the NI LabVIEW Runtime Engine (Version 2011 SP1 32-bit, size ca. 215 MB) and NI VISA. I have installed VISA v17.0 which is a 750 MB chonker.  It contains drivers for USB/Serial communications any many others (also some important drivers for my obsolete GPIB test equipment which aren’t supported in the newer versions anymore). Install VISA and the Runtime Engine and spend your precious life with many reboots. I highly recommend to read Joe Smith’s User Manual, otherwise you may run into problems.

Word of advice, take the time to read the README file.  I'm impressed that they were able to get it all working. 

[joeqsmith]

Dislord,

I am planning to add the ability to reprogram the VNA from my software.  Looked simple enough... 

What are the userArguments e8..eb that passed to the program upon soft reset?
When programming the device, what is the flashwritestart set to? 

I attempted to program the device using a start address of 0.  F0 - F4 appear correct. Minor revision reports 0.   I see the ASCII 2 for the indicate commands and am able to jump after the file has been loaded.   However, when I check the version in the menu it has not been updated.   

[joeqsmith]

Sniffing the bus, the address doesn't appear to be 0 as I guessed.   I changed my start address to match but still no luck. 

***
Sniffing when their software is sending the programming file,  they appear to always append the array with 0x0d.  None of these basics appear to be covered in the documentation.   I don't see any other problems with my software and suspect this is the last problem. 
***
After some sleep, the 0x0d is the Indicate command...

[realfran]

This will be great!!! Especially the reset if it's possible to change de firmware from the PC without pushing the jog button on it.
This is for the people using Nano/Lite with the PC is very useful (for people with sigth problem like me great).
There is a possibility to enlarge the screen size to fit on the monitor?
Thank you for all your improvement on the software. 

[DiSlord]

Firmware start address (uint32_t register 0xe0):  V2/Lite = 0x8004000, for V2Plus4 = 0x800C000 !! this value changed in Bootloader!! need write as for V2 = 0x8004000 (bootloader ignore less values for prevent write in it, this allow reduce chance erase bootloader code)

At device startup bootloader check pressed button (Right for V2 or Center on Lite) if pressed enter to firmware upload mode

In fw upload mode set this settings in Version registers:
   // set version registers (accessed through usb serial)
   registers[0xf0] = 2;   // device variant (NanoVNA V2)
   registers[0xf1] = 1;   // protocol version
   registers[0xf2] = 0;   // board revision (always 0 in bootload mode)
   registers[0xf3] = 0xff;   // firmware major version (0xff in bootload mode)
   registers[0xf4] = 0;   // firmware minor version

So you can read it and detect V2/Lite in firmware upload mode.

Write in 0xE4 register - write in flash

For exit booload mode (reset devide) need write in registers[0xef] = 0x5e

[joeqsmith]

Dislord,

Thanks for saving me some time.  I wouldn't have guessed these would all require a different address.  Why doesn't the boot loader handle it?  Is there a way to query the address to make it more generic?  I have no idea what the V2 is.  Does it use the same protocol as the Lite and V2Plus4?

As realfran asked, is there a command in the application to drop to boot?  It would make sense to automate the whole process. 
 
Programmer is now working well (I tried 10 reloads, toggling versions with no errors). 

***
Wait... are you telling me I have to run the application first to determine what hardware is installed, then drop to the boot?   It sure looks like the Lite and V2Plus4 manuals are showing the same values for F0-F4 when the bootloader is running.  Surely with 5 locations we could sort that out. 

[realfran]

thank you. 

[DiSlord]

V2 - any NanoVNA V2.2 devices:
https://nanorfe.com/nanovna-versions.html

V2Plus4 bootloader contain all close source part for measure and DSP processing, this need more bigger size for it 48k for V2Plus4, and 16k For other), but for allow write by old software use 0x8004000 address. I can`t detail answer about V2Plus/Plus4 bootloader structure.

Rewrite bootloader - more difficult part, need use STLink. Used in V2/V2Plus/V2Plus4 GD32F303 MCU not contain DFU mode (not allow easy programm it over USB). So change bootloader/fix it more difficult.
Additional V2Plus/Plus4 boorloaders depend from MCU serial number - used for protect it from copy.

In LiteVNA used AT32F403
https://www.arterychip.com/en/product/AT32F403.jsp
Allow use DFU mode, but need ATlink software
https://www.arterychip.com/download/AT_Link_EN_20210427.zip
For enter in DFU mode need connect bootpins on board and power on.

You can`t detect hardware version in bootloader mode (all devices answer as i write)

I can add command for enter in booloaded mode in next version firmware, example write in registers[0xef] = 0x5e, but only on next firmware version.

[joeqsmith]

There is a possibility to enlarge the screen size to fit on the monitor?

Using the search in the upper right of the screen and leaving the topic set to "This topic", I used "resolution" and got the following hits:

https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3617154/?topicseen#msg3617154
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3813608/?topicseen#msg3813608
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3621361/?topicseen#msg3621361
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3616560/?topicseen#msg3616560

[joeqsmith]

Thank you for providing these details.   That's too bad about the system architecture.  I'll just add a selection for the target device.   

I used the QT software to load your application code and every time, I cringe.      I think it's safe now to get rid of it.

If you do decide to provide a unique ID within those 5 fields, let me know.  I still have that ST-link for programming the original NanoVNA.   

***
If you have any concerns about adding the drop to boot command, don't.   It would be nice to have but the V2Plus4 doesn't support it and I can imagine that it may be too confusing for the users. 

[joeqsmith]

FYI: a discussion about VNA calibration  error models goes here:
https://groups.io/g/nanovna-users/topic/34237712

This paper seems directly related to the Unknown Through Calibration error model, as I understand:
https://www.researchgate.net/publication/358164808_Measurement_Uncertainty_in_Network_Analyzers_Differential_Error_Analysis_of_Error_Models_Part_4_Non-Zero_Length_Through_in_Full_Two-Port_SLOT_Calibration

Thanks.  I had read that email chain and was talking with a friend about it the other day.  The translation makes it difficult for me to follow.   It will require I spend a lot of time to try and make sense of it. I did not download the tools and source code to try and replicate their tests.   I also didn't read their final report.  There were some other nuggets I found in that mail chain but again, it takes time to research.   Did you read it and attempt to follow? Were you able to rebuild their code as well?

I've read up to where they had started to post their BASIC programs.  I attempted to run some of what they have shown but I have not tried to feed in my own data.   So far, everything is a one port but I skipped to the end and see they also discuss a 2-port system.  While they mention the NanoVNA throughout the thread,  I have not seen where they added their algorithms to the open source software.   

Dislord, have you tried to port any of their work into the firmware?   

[Alextsu]

I've read up to where they had started to post their BASIC programs.  I attempted to run some of what they have shown but I have not tried to feed in my own data.   So far, everything is a one port but I skipped to the end and see they also discuss a 2-port system.  While they mention the NanoVNA throughout the thread,  I have not seen where they added their algorithms to the open source software.   

It appears to be more a theoretical work, as far as they had published several scientific papers on the topic. I doubt it may have any practical implementation in low-cost VNA FW code.
Their last paper about 2-port systems analysis might trigger some discussion on the topic, but the subject seems too complicated to dive deep into details

[DiSlord]

I use this as base for calibrations.

Also add calibration standard suport, for this part i use various sources.
I had to deduce some formulas myself and optimize the calculations. Since initially they were very cumbersome for calculations (a large number of calculations in complex numbers is quite resource-intensive for the microcontroller, especially since hardware support for floating point numbers is disabled in V2/V2Plus/V2Plus4, since not all GD32F303 processors have this module. The processor in Lite is faster and there support is always on).

For thru calibtaiton most good result show ISOLN/THRU calibration as on H/H4. It allow good remove leakage from measured data.

[joeqsmith]

It appears to be more a theoretical work, as far as they had published several scientific papers on the topic. I doubt it may have any practical implementation in low-cost VNA FW code.
Their last paper about 2-port systems analysis might trigger some discussion on the topic, but the subject seems too complicated to dive deep into details

I tend to agree with some of the comments posted in that chain.  It would have been very helpful had they started with a clear description of the problem they are trying to solve.  This should have been able to be boiled down to a paragraph.   

Minimize the errors introduced by existing  known models.  Provide an approach that allows the error model to run more efficiently.   Decouple the error model from the hardware used.    As an example.  I'm not suggesting these align with their goals.

One person was attempting to follow along which has helped me.  Several pages into it, they still seem unsure what the goals are, which is my take when reading it. 

With their emphasis on the NanoVNA,  I would assume the are suggesting their models offer some benefits.  At least for the single port error model they presented, it would be easy enough to experiment with.   

I use this as base for calibrations.

Also add calibration standard suport, for this part i use various sources.
I had to deduce some formulas myself and optimize the calculations. Since initially they were very cumbersome for calculations (a large number of calculations in complex numbers is quite resource-intensive for the microcontroller, especially since hardware support for floating point numbers is disabled in V2/V2Plus/V2Plus4, since not all GD32F303 processors have this module. The processor in Lite is faster and there support is always on).

For thru calibtaiton most good result show ISOLN/THRU calibration as on H/H4. It allow good remove leakage from measured data.

Thanks for the post.  Did you choose to follow their work because of it requiring less resources (memory, CPU...), or did it provide a more accurate result?   Both?   If you tried other methods when making the choice what model to use,  I would be very interested in seeing any metrics you collected along the way.   

[joeqsmith]

I am curious if anyone else with the Lite had noticed a random shift problem?   It seems to be bimodal, or always recovers.  I've seen it when running various tests but it's been rare. 

***
Looking at other times I have seen it, the amount it shifts may be constant.

[DiSlord]

S11 or S21 measures? Frequency?

I never see phase shifts, on device or on NanoVNA-App.
I see amplitude shift on my test AGC variant (The problem is that the gain depends slightly on the frequency and it is difficult to correctly connect different levels, it runs up to 0.1dB of error)

PS i possibly know source of problem, but not sure. You see this on device stanalone?

[joeqsmith]

That was S21, 100MHz.  I don't normally use these devices standalone and have not seen it.  Again, it's rare and appears random.   After that post, I let it run that same configuration for about a half hour and never saw it. 

Anytime I have noticed it, it was a downward shift.  I think it is always the same width and height but am not sure.  I've been ignoring it. 

Of course, it is very possible it's my software but I am not sure what the cause would be.  My software checks each packet and it seem fine. This last example was without any calibration or normalization.  It's about as close as I can get to the raw data from the Lite.   

If there is something you would like me to try in order to isolate the problem, let me know.   

***
Also, this was with firmware LiteVNA64-220127.   I had tried the touchscreen test before and after this install and indeed, it works MUCH better now near the edges.   

[DiSlord]

On 100MHz device switch generator mode, so i think know source of problem.

In V2.2 / V2Plus / V2Plus4 used 2 generators

Si5351 - cover 2 bands:
< 100MHz use fixed PLL and variable multiplier for set frequency
>= 100MHz and < 140MHz use fixed divider and various PLL
On switch generator mode possible unstable work.
For >= 140MHz used ADF4350 (or MAX2871 in Lite)

In future for Lite i move switch to MAX generator to 100MHz (ADF not allow work on less 140MHz, MAX allow work from 26MHz)

[joeqsmith]

I tried several tests at 900MHz and could not reproduce the step.   Over the last few weeks, for the most part I have been testing below 100MHz.  I can believe it is somehow related to that.