NanoVNA Custom Software

[radiolistener]

That means that scan is not bottleneck. Excellent. USB have enough bandwidth

that's not the case, it uses old USB peripherals which can work in USB FS mode and the speed is limited with small amount of buffer memory and MCU speed. But it is good enough for communication. I didn't measured the maximum performance, but think it is about 50-100 kB/s.

MCU have bandwidth as well - because it does update it's screen fast during PC software scan.
It means PC SW update speed *can* be improved. Somebody just have to look at it because it is important while using average, especially knowing that it can be *twice* as fast.

Do you release hex and/or dfu releases as well? Please.

MCU cannot communicate with PC during sweep, because it will affect measurement.

Communication speed really can be improved, but I'm not sure that this is really needed.

There are several ways to improve performance:
1) optimize communication from PC side (don't send extra requests, don't do long delays, etc)
2) use binary format communications, but it will break compatibility with existing software (NanoVNASharp, Saver, etc)

As for average, it is better to perform it on MCU side. For example you can use scanraw command from NanoVNA-Q firmware. It allows to setup average from 1x to 1000x and it will be performed on MCU side. But it returns raw gamma data with no correction (with no calibration apply, the same as you see with reset calibration), so you're needs to apply your own calibration.

[ogden]

That means that scan is not bottleneck. Excellent. USB have enough bandwidth

that's not the case, it uses old USB peripherals which can work in USB FS mode

Yes, I did mean exactly that - USB FS of stm32 which is running at 72MHz(?) have enough bandwidth for this application.

MCU cannot communicate with PC during sweep, because it will affect measurement.

Well, it does not need to show scan on it's display two times faster than PC is getting scan data as well. While connected to PC, display can be off. That would also fall into "will not affect measurement", if not then "waste less time" definitely.

For example you can use scanraw command from NanoVNA-Q firmware.

No. I can do many things but what i Want to do is - *use* nanovna, not modify or develop it. What I see - PC software is slow, slower than onboard firmware and I know that hardware is more than capable.

[5q5r]

Hello Ogden,
there were some changes to the official firmware which necessitated a slowdown be put in to all data reads. As of firmware 0.2.0 and newer, and NanoVNA-Saver 0.1.2 and newer (but use 0.1.3, it's just out now), the new "scan" command is used. This disables the screen, runs a single sweep of the requested range, waits for it to complete, and then the application fetches the data.

I still think it feels slow, also compared to early experiments. But it's how I'm told by the maker of the firmware that I should request data via serial, and thus it's what I make the application do. I would be very happy if someone were to try to optimize the code on the NanoVNA ;-)

[ogden]

Thanx, tried 0.1.3 and do not see any improvements in areas that IMHO are actually important. Same weird behavior - nanovna makes two scans but on PC only one is displayed. That does not makes sense because cooms interface is CDC! As soon as nano is finished scan, it can PUSH out data. Application shall jus sit and wait for next scan data to come in. Firmware and software guys shall start to talk each other. Also seems like averaging did not work in 0.1.1 and still does not in 0.1.3. Noise peak-peak amplitude does not go down . Anybody else think so?

[5q5r]

Hello Ogden,
I can confirm that averaging certainly does work. Whether it gives you the results you expect, or whether it works with your particular firmware I can't promise, of course :-) What firmware revision are you running?

On the "shall start to talk to each other": I certainly have had conversations with edy555 about the device and interaction with NanoVNA-Saver, and he has specified using this particularly interface, ie. using the "scan" command in newer firmware. What speed it goes at isn't something I can affect :-)

[ogden]

I can confirm that averaging certainly does work.

Firmware mentioned in this post:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2739418/#msg2739418

Tested using s11 noise floor which is most "noisy". Look at the picture. Those dips can't be there after 20x average. No way. Not to mention that picture does not look any different than single sweep w/o average. If you are further interested - let's go PM. I can give input as long as it does not take big chunk out of my spare time.

[5q5r]

Whether those dips can be there or not depends on your calibration, I would say. If there were opposite peaks at the time of calibrating the NanoVNA itself, it would over-compensate on those particular frequencies, and consistently produce such dips.

Attached are two sweeps of 900-1500MHz (lots of noise!) - one without and one with 20x averaging. I would say it looks like it's working.




The levels you're looking at when looking at the noise floor are quite small. Even a tiny variation in the magnitude of S11 causes a large jump in measured return loss.

[ogden]

Even a tiny variation in the magnitude of S11 causes a large jump in measured return loss.

Agreed. Large jump will trash all the average and spike will stay. Yet I marked *dips*. Whatever. If you say it works - fine.

If there were opposite peaks at the time of calibrating the NanoVNA itself, it would over-compensate on those particular frequencies, and consistently produce such dips.

Oh, ok. It means that I did find problem with firmware/calibration, not PC software

[5q5r]

Possibly - though to confirm, you should probably do multiple sweeps with high averaging. If the dips (or peaks) stay in place, it's a "true" error, if they move around, maybe the averaging isn't good enough to catch it, or you have indeed found a bug that I just haven't recognized ;-)

I generally run 10 segments and 25x averaging (using truncated mean, so 25 averages dropping 5 readings per average) when doing calibration. It takes a few minutes per sweep at that point, but it does give a very nice and stable in-application calibration which I can save afterwards. Then again, if I change any cables or connectors, I have to start over ... 

[ogden]

Possibly - though to confirm, you should probably do multiple sweeps with high averaging. If the dips (or peaks) stay in place, it's a "true" error, if they move around, maybe the averaging isn't good enough to catch it, or you have indeed found a bug that I just haven't recognized ;-)

Everything is fine, there is no bugs. Phew. Three 20x averages of 20dB reflection, they all look basically the same. Conclusion: to get meaningful averaging results, same level of averaging for calibration data is necessary. Now averaging just reveals calibration noise.

[joeqsmith]

....

I didn't measured the maximum performance, but think it is about 50-100 kB/s.

....
Communication speed really can be improved, but I'm not sure that this is really needed.

There are several ways to improve performance:
1) optimize communication from PC side (don't send extra requests, don't do long delays, etc)
2) use binary format communications, but it will break compatibility with existing software (NanoVNASharp, Saver, etc)

Oddly, I'm seeing no where close to 50-100 kB/s (400kbs-800kbs) but then again, it could be something I am doing wrong.    I don't think this is the problem with why it's so slow.   Without the Nano connected to the PC and just watching it, it will scan about once a second.   This is using the last image you uploaded.     

On the PC I am seeing 325467 Bytes in 14.04 seconds or 185kbs.  This is plenty fast to keep up with how slow the Nano scans.   If I really push the data rates, basically asking for the next data set right after is finished sending a data set, without giving it some delay, the performance suffers.   

Attached, I am showing the data rate portion of my regression test.   I send out 50 frequencies commands which are very fast to respond as the payload is so small.  This is followed by 50 data  0 and 50 data 1 packets.      I will wait up to 2 seconds for the Nano to respond with a valid packet before timing out.   I had tried to disable the LCD at one time but it had no effect on the speed.  Maybe this has changed. 

I've posted this a few times and mentioned it during my video but as long as we are on the topic of speed,  unlike the software that was supplied with the Nano, I only request the frequencies when I have changed them.   I also only collect data 0 for S11.   Their software will collect data 0, data 1 and the frequencies for each sweep.   I suspect they need a slightly longer delay  for their Auto (1.2 seconds).   It's a very small difference and IMO, both are very slow.   

But hey, it's $50.  I am just happy to see how stable this image you uploaded is!   I have been running a fair number of tests on it over the last few days and not once has it white screened, locked up, or sent bad data.   

I have not added any support for your averaged scan or the normal scan.  I did try sending the commands just to get a feel how they would work.

[ogden]

If I really push the data rates, basically asking for the next data set right after is finished sending a data set, without giving it some delay, the performance suffers.

Problem even have a name: multitasking race condition. PC software have to request data but time window while it is available, is very small. As we see, PC manages to miss each other scan data set. Needed change is quite "simple" - leave existing "polling" approach alone and introduce new command for continuous scan and "push" for nano. In short nano while said mode is initiated: 1) performs scan 2) optionally displays it on the built-in LCD 3) sends scan data to PC unconditionally and only when USB transfer fully done, continue with next scan.

But hey, it's $50.

Yes, you can say so when you are talking about tiny screen and fonts, awkward and fragile input "thingie", lack of proper case but such excuse is not OK in case of poor software *design* that clearly can be improved.

[radiolistener]

Problem even have a name: multitasking race condition. PC software have to request data but time window while it is available, is very small.

No, there is no race condition. There is just delay while NanoVNA is busy. It cannot respond immediately, because it may be busy. If PC request performed when NanoVNA is busy, it will needs to wait. NanoVNA may perform sweep or rendering. PC command cannot interrupt this operation, so it needs to wait until current operation will be completed.

NanoVNA cannot respond in parallel, because data command needs to access to measurement data, which is under update by sweep. It needs to share the same memory with measurement data, because there is not enough memory to store a copy. Measurement data for single channel requires 101*4 = 404 bytes. There is no memory even for stack margins, so you're needs just to share the same memory for different task.

Since data is modified by sweep task and modification is not complete yet, the data command needs to wait when the sweep will be completed. This is the reason for delay.

[ogden]

Problem even have a name: multitasking race condition. PC software have to request data but time window while it is available, is very small.

No, there is no race condition. There is just delay while NanoVNA is busy. It cannot respond immediately, because it may be busy. If PC request performed when NanoVNA is busy, it will needs to wait.

You do not make any sense. Why PC does get only each 2nd scan then? I am afraid that you need to update your knowledge about "race condition". Meaning is quite broad BTW.

Since data is modified by sweep task and modification is not complete yet, the data command needs to wait when the sweep will be completed. This is the reason for delay.

Yes. It means that PC have small time window. I said it already.  Yet you somehow manage to reply "no you are wrong, let me say the same just using another words"  

[edit] Why don't you comment my suggestion of PC communications redesign? Two PC software guys are reading, they can potentially change software side accordingly, seems you are more than capable to make such seemingly small firmware change.

[joeqsmith]

If I really push the data rates, basically asking for the next data set right after is finished sending a data set, without giving it some delay, the performance suffers.

Problem even have a name: multitasking race condition. PC software have to request data but time window while it is available, is very small. As we see, PC manages to miss each other scan data set. Needed change is quite "simple" - leave existing "polling" approach alone and introduce new command for continuous scan and "push" for nano. In short nano while said mode is initiated: 1) performs scan 2) optionally displays it on the built-in LCD 3) sends scan data to PC unconditionally and only when USB transfer fully done, continue with next scan.

But hey, it's $50.

Yes, you can say so when you are talking about tiny screen and fonts, awkward and fragile input "thingie", lack of proper case but such excuse is not OK in case of poor software *design* that clearly can be improved.

Sadly you seem to have ignored:

I don't think this is the problem with why it's so slow.   Without the Nano connected to the PC and just watching it, it will scan about once a second.   This is using the last image you uploaded.     On the PC I am seeing 325467 Bytes in 14.04 seconds or 185kbs.  This is plenty fast to keep up with how slow the Nano scans.

I have no race condition.  My software is synchronized to the Nano by the completion of the first request.   

As we see, PC manages to miss each other scan data set.

As "you" see, not "we".   What I see with the software I am writing, using Radiolistern's image is that my PC easily keeps pace with how slow the Nano sweeps.   

In case you would like to see what I am seeing, I made a short video showing my software plotting data.  The Nano is hung next to the screen so you can watch its' LED compared with the scan indicator of my software.  If you have firmware for the Nano that will sweep faster than this, post details about it and I will see if my PC can somehow manage to keep pace with it. 

https://youtu.be/N77my69u_b8

[radiolistener]

Why PC does get only each 2nd scan then?

Because NanoVNA Saver sends two data requests. First for S11 and second for S21. Each request requires one sweep cycle. So, two request needs two sweep cycles.

That's behavior is specific for NanoVNA Saver. You can request just S11 and it will take single sweep time. But NanoVNA Saver sends two data requests and this is why it takes two sweeps.

I am afraid that you need to update your knowledge about "race condition". Meaning is quite broad BTW.

There is no race condition for data command, because operations are synchronized with mutex.

Why don't you comment my suggestion of PC communications redesign?

I don't see reason to redesign something. Yes, transfer speed can be improved, but I'm too lazy to do something with no real needs. It already works good enough

[5q5r]

That's behavior is specific for NanoVNA Saver.

I don't know that there would be another way to do it if reading both S11 and S21?

[joeqsmith]

Why PC does get only each 2nd scan then?

Because NanoVNA Saver sends two data requests. First for S11 and second for S21. Each request requires one sweep cycle. So, two request needs two sweep cycles.

That's behavior is specific for NanoVNA Saver. You can request just S11 and it will take single sweep time. But NanoVNA Saver sends two data requests and this is why it takes two sweeps.

When I use both data0 & data1, I plot while alternating between the two data sets.  So my screen always updates once per request.   I guess I could have shown that as well.  It would have been just as exciting to watch. 

 

That's totally wrong with my current software.  I plot once after both data sets have been collected.

 

Wrong again....  It's actually the way I originally described.     Time for some wake up juice. 

[joeqsmith]

As a totally off subject, I happened to listen to the last Amp hour podcast.  Anytime they mention RF in the subject with both Dave and Chris, I'll have a listen.    Oddly, they are talking about VNAs.  Chris talks about getting the new Siglent one and they discuss the merits of the old 8753ES vs the new Siglent.  (I almost pulled the trigger on a 6Ghz ES to replace my old 8754A).    Anyway, to my surprise, even with it being as popular as it is, there wasn't a single mention of the NanoVNA.   

If I were buying my first ever VNA and was just getting started with RF, I would hands down spend the $50 on the Nano to at least learn some of the basics.   I wouldn't be surprised to find out that it wasn't the most sold VNA ever! 

[5q5r]

I don't know that I would say it's off-topic.

My guess is that there are two main reasons: The NanoVNA isn't being marketed, but only spreading via word of mouth, mainly among enthusiasts in the amateur radio community. And there is a preference, approaching a fetish at times, for expensive test gear from the big name brands among some parts of the electronics community

The NanoVNA is my first VNA, and I have no desire to buy anything more expensive than it, given the (limited) uses I have for it.

[xrunner]

If I were buying my first ever VNA and was just getting started with RF, I would hands down spend the $50 on the Nano to at least learn some of the basics.   I wouldn't be at all surprised to find out that it wasn't the highest sold VNA ever!

It's selling like hotcakes in my town as far as the local hams. A few of us got them and started talking about the NanoVNA. Most people didn't have a clue what a "vector network analyzer" did. But after an explanation and some in-person demos it's caught on Big Time. Companies like MFJ who sell antenna analyzers for hams here -

MFJ Analyzers

are in trouble because they will not be able to compete with something like the Nano for < $50.

[ogden]

As "you" see, not "we".

It's "you", not me/we I talk about NanoVNA Saver and it was clearly said BTW.

Because NanoVNA Saver sends two data requests. First for S11 and second for S21. Each request requires one sweep cycle. So, two request needs two sweep cycles.

Well, I did not know that. It makes sense then indeed. So how does NanoVNA Saver and other PC software can get Both - S11 and S21 using single request? - If there is no command then perhaps you can make one? 

[joeqsmith]

It's selling like hotcakes in my town as far as the local hams. A few of us got them and started talking about the NanoVNA. Most people didn't have a clue what a "vector network analyzer" did. But after an explanation and some in-person demos it's caught on Big Time. Companies like MFJ who sell antenna analyzers for hams here -

MFJ Analyzers

are in trouble because they will not be able to compete with something like the Nano for < $50.

That doesn't surprise me at all.   If anything, I would have expected him to plug his own site.  I find it hard to believe Dave's not aware of this threads' popularity. 

[ogden]

Companies like MFJ who sell antenna analyzers for hams here -
MFJ Analyzers
are in trouble because they will not be able to compete with something like the Nano for < $50.

Right, they should be worried Is it even legal to use square wave signal for antenna tuning? - Harmonics violate out-of band radiation regulations for sure. It's kinda "spread spectrum" unless CW mode used, but anyway. Many of you are HAMs, right? Perhaps you can comment? - Just curious.

[xrunner]

Right, they should be worried Is it even legal to use square wave signal for antenna tuning? - Harmonics violate out-of band radiation regulations for sure. It's kinda "spread spectrum" unless CW mode used, but anyway. Many of you are HAMs, right? Perhaps you can comment? - Just curious.

What does it output - something like -10 dBm, which is 100 uW? Maybe even less.

I just connected the NanoVNA to a 30m dipole outside, which is just under another fan dipole with the same band included (I have a lot of antennas ). I set the Nano to sweep from 10.1 to 10.150 MHz. I listened to the sweeps on an Icom IC-7300 and you can indeed hear the sweeping (and see it on the waterfall). I then connected the radio to my other main fan dipole which is about 30 feet away - the amplitude is already falling off considerably in that range.

However - I tuned through other ham bands (and other ranges in the shortwave bands) and could not hear any sweeping at all outside of the set sweep range. So, even though there may be sidebands out there, they are too low to detect with a shortwave radio