NanoVNA Custom Software

[radiolistener]

How should it work then?

scanraw 0 10000 1 1000000 1 works in the following way:

- measure frequency 10000 Hz
- send measured data to PC
- measure frequency 10001 Hz
- send measured data to PC
- measure frequency 10002 Hz
- send measured data to PC
...

if you requested 1000000 points it can take long time

[joeqsmith]

How should it work then?

scanraw 0 10000 1 1000000 1 works in the following way:

- measure frequency 10000 Hz
- send measured data to PC
- measure frequency 10001 Hz
- send measured data to PC
- measure frequency 10002 Hz
- send measured data to PC
...

if you requested 1000000 points it can take long time

Is there a reason you don't want to discuss the average?   Or am I not being clear when I am asking how the average works? 

And, is there a way to abort it? 

[radiolistener]

Is there a reason you don't want to discuss the average?

Average works in usual way. For example average 3x is specified.
Then it performs 3 measurements: a1, a2, a3.

each measurement is complex, it includes real and imag part.

the result will be calculated in the following way:
real part = ( real(a1) + real(a2) + real(a3) ) / 3
imag part = ( imag(a1) + imag(a2) + imag(a3) ) / 3

And, is there a way to abort it?

yes, you can abort it with power off NanoVNA 

[joeqsmith]

Is there a reason you don't want to discuss the average?

Average works in usual way. For example average 3x is specified.
Then it performs 3 measurements: a1, a2, a3.

each measurement is complex, it includes real and imag part.

the result will be calculated in the following way:
real part = ( real(a1) + real(a2) + real(a3) ) / 3
imag part = ( imag(a1) + imag(a2) + imag(a3) ) / 3

And, is there a way to abort it?

yes, you can abort it with power off NanoVNA 

Hang in there.  It's slowly sinking in.   

After some trial and error, it seems you limit the number of accumulations to 1000.  1001 errors out.   For a single sample with averages set to 1000,  scanraw 0 10000 1 1 1000, it seems as though you can read at about 1KHz.  So, for 100 samples, can it sweep at 10Hz without averaging?    At least running it with the Tera Term and sending scanraw 0 10000 1 101 1,   it doesn't appear so.    I wonder is the poor update rate really the time it takes to sweep (perhaps limited by the loss of lock)  or is it the data rate. 

[radiolistener]

sweep requires change frequency. Change frequency needs for wait PLL lock, etc.

Average don't needs to change frequency. It just needs to get more samples. This is why it works much more faster than usual sweep.

scanraw works pretty fast for usual measurements. If you want realtime fast sweep several times per second, I think NanoVNA cannot do that, because there is needs some time for pll lock, for channel switch, for gain stabilization, etc.

Average don't needs to switch channel, don't needs to change gain, don't needs to change frequency and don't needs to wait for PLL lock. This is why it can measure several samples more fast.

[joeqsmith]

Thank you for all the information. 

Does your new firmware wait for the lock status?   

Have you looked into the purpose of the other two commands (threshold & transform) you added?   If so, could you provide a brief description?   

[radiolistener]

Does your new firmware wait for the lock status?   

yes, it check hardware status of PLL lock. In, comparison original edy555 firmware just use some delay with no actual check for hardware PLL status. The idea to check PLL status was introduced on this thread by user radioactive.

Have you looked into the purpose of the other two commands (threshold & transform) you added?   If so, could you provide a brief description?

These commands were added by edy555 in original firmware it will be available in the next edy555 firmware release. It just merged to NanoVNA-Q.

"threshold" command allows to change frequency threshold for 1-st harmonic. By default it uses 300 MHz threshold. Bad quality si5351 chips cannot work at 300 MHz. In such case you can decrease threshold.

"transform" command just a console command for DISPLAY => TRANSFORM menu. It enables TDR mode on NanoVNA.

[joeqsmith]

Your lock check routine appears to only be used when changing ranges.  Others appear to use a fixed delay time. 

I tried to download your latest files and now see this error:

./NANOVNA_STM32_F072/board.h:49:8: error: unknown type name 'uint32_t'
 extern uint32_t dfu_reset_to_bootloader_magic;
        ^~~~~~~~

Looks like you have been busy.   Lot's of changes.....

[radiolistener]

I tried to download your latest files and now see this error:

./NANOVNA_STM32_F072/board.h:49:8: error: unknown type name 'uint32_t'
 extern uint32_t dfu_reset_to_bootloader_magic;
        ^~~~~~~~

interesting. I don't have such error, some compiler dependent issue.
You can solve it by adding this line at the top of board.h file:

Code: [Select]

#include <stdint.h>


[joeqsmith]

I tried to download your latest files and now see this error:

./NANOVNA_STM32_F072/board.h:49:8: error: unknown type name 'uint32_t'
 extern uint32_t dfu_reset_to_bootloader_magic;
        ^~~~~~~~

interesting. I don't have such error, some compiler dependent issue.
You can solve it by adding this line at the top of board.h file:

Code: [Select]

#include <stdint.h>


Thanks.  After adding, it builds without any other changes.   It's running the regression now. 

*****

Passes.   

[joeqsmith]

I connected my home made GaAs transfer relay to the nano with two different loads.  I then toggle between the two, collecting and plotting the data while in each state.   The firmware I am using is the one I mentioned in the previous post, so I assume it will have whatever fix was specifically added to try and address the out of sync problem.   

You can see there are two discrete lines for the two states.  If the firmware or my software were to fall out of sync, these two lines are going to swap positions.

This is using my normal method of start, stop, data0, toggle and repeat.   Again, I have never had this be a problem when I use my segmented sweep and am not expecting to find anything.  I'll let it run overnight. 

It's possible that something else was wrong but because of how I talk with the nano, I never run into it. 


**** 

I had the wrong data being plotted, but caught it before calling it a day.   It ran all night and never fell out of sync.   

[joeqsmith]

Showing test setup and data from the toggle test.   I am not sure what was going on with the 500 ohm being bimodal towards the end.  It gets a bit of an offset and higher noise.  Maybe something being coupled in from the PC. 

[radiolistener]

Showing test setup and data from the toggle test.   I am not sure what was going on with the 500 ohm being bimodal towards the end.  It gets a bit of an offset and higher noise.  Maybe something being coupled in from the PC.

probably this is charge controller from NanoVNA. It is a little noisy and you can notice significant offset when usb charger is connected to NanoVNA.

[joeqsmith]

I would expect with it plugged into the USB while running it, if it was low we would have seen it charge early on in the data set, not towards the end.  Still, it's certainly possible. 

What is the thread safe display about? 

[radiolistener]

it allows to use display from different threads of NanoVNA firmware. Technically it allows to get screenshot from almost any device state, for example now you can get screenshot with numpad, or version screen. Old firmware doesn't allow that.

In addition, these issues related with data modification from different threads are fixed. Now it will not get you garbage if two threads trying to modify the same memory simultaneously. Unfortunately, not all issues are fixed. Actually, original firmware was overcrowded with these thread collision issues. Fix of some issues may leads to slow down PC data transfer due to poor data transfer protocol. I cannot change it, because it will break backward compatibility. So, I leave some issues unfixed in order to support backward compatibility and fast data transfer.

In overall, I feel the whole code needs to be rewritten. Because there are whole black holes full of bugs. For example, try to press joystick for long time on START/STOP menu in the STIMULUS. It will open numerical editor, which currently don't works properly. I have fix, but it pulls a buch of another changes. So, I just shelved these fixes. It will take a lot of time and I'm not sure that I want to spend time on that

I feel that I want just to fix major issues and the rest of issues leave as is. Because it already works good enough

PS: forgot to say, numpad frequency rounding error is fixed. Now you can enter 123456789 Hz on NanoVNA numpad and it will be exactly 123456789. In old versions it was rounded to 123456792. Annoying bug. But now it works as expected

[joeqsmith]

Thanks for the description.  I'm not understanding what you mean by a screen shot.   Are you suggesting there is a way to do screen captures of the Nano from the PC? 

Personally, I think you've done a great job getting it as stable as it is.   My software is fairly simple and doesn't take advantage of most of the new features.  Combined with seldom running it standalone,  this may be why I'm not finding problems with your later versions.       

I would still like to see the Nano scan faster but I don't see it as a major issue.   If you decided to go after it, I would attempt to support it.   

It's funny to hear your concerned with few Hz error.   Having used my old HP VNA, I can't control it anywhere near that.  There's no way to control the start, stop, center or span from the software.  Even from the panel, it's not accurate.   The only thing I can do with the PC is download the data from it.   The Nano being 40 years newer, is far more advanced. 

"transform" command just a console command for DISPLAY => TRANSFORM menu. It enables TDR mode on NanoVNA.

Could you please walk though the steps on how to use it?   

I was missing that real needs to be selected.   

[ted572]

Hello  'radiolistener':
A little over a month ago I installed newer firmware in my NanoVLA per your instructions here -> https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2701026/#msg2701026
First of all I would like to thank you again for all the assistance you provided, and I was able to successfully install version 0.1.1.9 firmware, also others below this level.  Although this is where it has stopped for me, as I'm not able to fully install any 0.2.x or 0.3.x versions.  It seems to install, and it reports that it was installed, although when I select the menu, and them select a individual menu item, the whole menu just disappears.  Gonski!  So I'm unable to Cal. the unit, see version info, or do anything else with it.  Although earlier versions, and 0.1.1.9 does works Ok (with a few miner bugs) and of course up to 1.5 GHz.  By the way I had some other issues here that has taken all my time until now, and I have been re-visiting this with no results to date.  I'm still able to go back and reinstall ver. 0.1.1.9 after several failed attempts with newer firmware. 

Do you (or anyone else please) have any thoughts on what could cause this inability to install more recent firmware?  Any suggestions to try wold be appreciated.   Thank you in advance, Ted
Edit - PS: I have been using your method '2) ST-LINK update', and have also tried '1) DFO update'.  Neither works for me with the newer FW.

[xrunner]

Try the attached file which clears all memory, then try the latest firmware. Hope it helps.

[ted572]

Hello xrunner:
Wow! That did it for me.  Thank you so very much.  I had supposedly previously cleared the firmware area a couple of times thinking that would have possibly helped.  Any way your file did the job.   Thanks, Ted

[xrunner]

Cool!

[radiolistener]

Do you (or anyone else please) have any thoughts on what could cause this inability to install more recent firmware?  Any suggestions to try wold be appreciated.   Thank you in advance, Ted

it looks like you're forgot to clean up settings after update. You can do it with console command

Code: [Select]

clearconfig 1234
Just run PuTTY, select Serial connection and enter COM port name with NanoVNA. Connect and execute this command. It will clean all settings. After that do power off and power on. That's it.

Some peoples doing clean memory with CLEAR.DFU file. But this way is not reliable. Execute clearconfig is more reliable way.

After cleanup, you're needs to do touch calibration, enter to CONFIG menu and select TOUCH CAL. Then check your touch calibration with TOUCH TEST menu. If it works ok, then save this touch calibration with menu SAVE.

After that, just setup frequency range in STIMULUS menu and do usual calibration.

[ogden]

it looks like you're forgot to clean up settings after update. You can do it with console command

Code: [Select]

clearconfig 1234

*Manual* reset of data which is made invalid by data-related changes in firmware can be easily avoided. Usually it is done by saving firmware data format version along with data (settings/calibration), comparing it upon startup. When no match - reset automagically, just notify user, or maybe not.

[radiolistener]

*Manual* reset of data which is made invalid by data-related changes in firmware can be easily avoided. Usually it is done by saving firmware data format version along with data

it's already present. But it seems that some old firmware had different data structure, but the same version code. I think you're right it will be better to change version for different firmware, even if it uses the same data structure.

[ogden]

it seems that some old firmware had different data structure, but the same version code

You may avoid that mistake by simply introducing new version code disregarding fact that structure is not changed. [edit] Data contents (compatibility) change also shall be versioned, not only structure change.

[battlecoder]

Thanks radiolistener! I've been following this thread for a while, waiting for my nanoVNA to arrive.
I finally got mine a couple of weeks ago, and thanks to all the information you've shared here I was able to update my nanoVNA to a more recent firmware version!

I was also able to fix the battery indicator by soldering D2 on the board. I have to admit I didn't have the diode specified in the schematics, so I used a thru-hole 5817 that I managed to solder on the pads by clipping and bending the diode legs against its body, similar to a DO-214 package. I figured the only important spec was low Vf, and that's the diode with the lowest forward voltage I had. I'm not 100% sure if it's a good choice for that application, but for the time being it seems to work.