As of 2022 there are many badly performing clones on the market. V2/3GHz NanoVNA uses parts like ADF4350 and AD8342 which are costly and clones have been cutting costs by using salvaged or reject parts.
See official store and look for V2 Plus4/V2 Plus4 Pro versions only to avoid getting a bad clone. We have stopped selling V2.2 versions since October 2020, so all V2 hardware that are not Plus or Plus4 are not made by us and we can not guarantee performance.
Interesting quick comparison between a calibrated H4 and an uncalibrated V2.2 (through a large 145MHz helical filter) ..
Not sure but I believe the point bandwidth/RBW of the V2 is around 500Hz ?
Hello,
I don't understand the point of comparing a calibrated trace on a given
devicz with an uncalibrated one on another device. I don't understand what
this picture is trying to say.
Regards
Peter
On Wed, 4 Nov 2020, 07:24 OneOfEleven, <cmoss296@gmail.com> wrote:
Er, a more basic question....
Which trace is which device? Obviously the blue trace looks more like the real response, but is it the H4 or Saa2?
maybe there was a label on the screenshot, but I could not see it on my Iphone, on which I am writing this.
I have to confess that at the lower frequencies (below 500mhz), I find the Saa2 performs quite well without calibration for quick setups.
Steve L G7PSZ
They're both real traces ;)
I did not mean they were not real traces, ** but which real trace is closer to the true response of the DUT? I am now on the Ipad and can see no trace identification.
Which trace is which vna?
Nice looking program, by the way.
Steve L
oh right, sorry.
The blue trace is the best match, the one without the two larger peaks on the right hand side of the filter passband.
Which Firmware do we have to load to use this soft on the SAA-v2 ?
Or am I wrong , can it work with the SAA-V2 ?
Hello Jempi
for saa2 (or v2_2) ... (means all versions with small screen and no
"plus" version)
https://nanorfe.com/downloads/20201013/nanovna-v2-20201013-v2_2.bin
(guessing you do not have a plus or plus4)
hth
greetz sigi dg9bfc
Am 04.11.2020 um 19:31 schrieb Jempi ( ON7MA ):
Hi Sigi
I have 2 of them.. 2_2 's.., one with 2.8" and one orig 2.8, where I changed to 4" ST7796
I flashed the 2.85 with 20201013, but still have to flash the 4".. I best use then the 2.74 I presume...
NanoVNA works now on the 2.8" , unfortunate that calibration can not be done from the software...
Tnx for info
JP
On Wed, Nov 4, 2020 at 09:08 PM, Jempi ( ON7MA ) wrote:
>
> NanoVNA works now on the 2.8" , unfortunate that calibration can not be
> done from the software...
No calibration routines yet, but their will be.
The V2 firmware unfortunately seems to be a bit buggy at times when sending points to the PC, it's is forcing me to limit the number of points per scan (the firmware skips sending some frequency points at times), but anyway I'll deal with that in another thread ..
On Wed, Nov 4, 2020 at 01:37 PM, OneOfEleven wrote:
>
>
> The V2 firmware unfortunately seems to be a bit buggy at times when
> sending points to the PC, it's is forcing me to limit the number of points
> per scan (the firmware skips sending some frequency points at times), but
> anyway I'll deal with that in another thread ..
>
>
OneOfEleven,
VNA-QT is also excruciatingly slow when a large number of points are selected, although I have not noticed it dropping data points during recurrent sweeps. Maybe the program adjusts on the fly for any lost data points.
If NanoVNA-App is at least as fast (slow??) as VNA-QT that should probably your base for comparison. Anyone requiring faster performance should probably look into purchasing the new V2 Plus models.
- Herb
you can use nanovna saver ... that works with v2/saa2/whatsoeverclone
... with calibration!!
kurt poulsen also made calibration files for the cal kits (sma and n
version) for saver
the nanovna soft also supports saa2 but not with calibration (wait a few
days ... grin)
greetz sigi dg9bfc
Am 04.11.2020 um 21:08 schrieb Jempi ( ON7MA ):
Reading the datapoints has to be done continuously in a dedicated thread
or else the FIFO will overflow and you will miss points. The sweep can
not be paused so any time you aren't reading from the FIFO datapoints
are accumulating.
Dear Gabriel,
Sorry if I am being a bit thick, but, if datapoints are missed because of FIFO overflow, surely a device which scans faster will produce more points more quickly, and the PC program is going to drop even more datapoints from a v2plus or v4.
To everyone else, does the data drop occur on old, slower PCs? Or PCs loaded with many paralell tasks running in the background?
Steve L
On Thu, Nov 5, 2020 at 04:46 AM, OwO wrote:
>
> Reading the datapoints has to be done continuously in a dedicated thread
> or else the FIFO will overflow and you will miss points. The sweep can
> not be paused so any time you aren't reading from the FIFO datapoints
> are accumulating.
I already am doing, but I'll change things round a little and move some other non-priority routines out.
If your fifo sending loop could send the fifo blocks continuously as it scans without having to poll the VNA for up to 255 of them at a time would help things out (maybe allow the full number of points instead of up to the 255 limit).
If I did say a READFIFO with the number of points/values set to '0' then just send all the points of a scan in one go without having to poll your VNA - no need for any protocol changes then.
Have to remember that even with so called 'real time' threads on a PC doing nothing but one simple thing their is no guarantee that the thread will be processed within the next millisecond, the PC has 100's of other messages to process in lots of other stuff going on, a typical PC is a multi tasking OS, it never has meant to have been a real time OS, allowing for that fact in all firmware should always be done (within limits yes).
I saw that single byte place holder for the size and questioned it as well.
"You have a ReadFIFO command that accepts an address and one byte for the number of values. However SweepPoints is a uint16. So, to pull down the entire sweep could require several reads which are all out of sync?"
The whole idea that you may want to synchronize the sweeps seems lost. While I would have preferred to send it a trigger then download the entire data set, it seems they are trying to make it more flexible.
I haven't started to write any code for the V2P outside of reading the document and trying a few commands. Would like to get a better understanding before I start to design my own software for it but may have to just sort it out by trial and error.
I posted my other questions here.
NanoVNA Custom Software - Page 29
|
|
| |
NanoVNA Custom Software - Page 29
NanoVNA Custom Software - Page 29
|
|
|
What effective baud rate is being used by the firmware, over the USB to PC
connection?
On Wed, Nov 4, 2020, 11:30 PM Stephen Laurence <Gaslaurence@gmail.com>
wrote:
On Thu, Nov 5, 2020 at 02:50 PM, Joe Smith wrote:
>
> I saw that single byte place holder for the size and questioned it as
> well.
>
Hi Joe
Talking with the V2 is a headache I know that much!
I could solve some problems about the V2 by fixing the source (easy enough) and recompiling, so basically start doing new firmware, but I don't want to be helping them out like that.
Anyway, I've learnt a few things that might help you when you're ready to tackle writing your own software to talk with the V2 ..
You have to think ahead, ie, you have to put your request to the V2 for more points ahead of time, waiting till the very end will at some point result in lost sample points (the V2 will not send them). So try to ask for the next block of samples say 10 or more points before the current lot are finished, or do similar to what I'm doing and send all of your 255 point (or how ever many you want) block requests at the start of the sweep in one go (the V2 has a small input serial buffer to allow for that), ie if you want 401 points then immediately send it two block request, one 255 point followed by a 146 point.
You also have to do this when starting the next full scan, but, DO NOT resend the start, step, number of sweep points or the number of values per frequency again, if you resend them then the V2 sweep will be very slow - again.
The initial sweep it does is very slow (around 42 points/sec), but subsequent sweeps are just over twice as fast (around 94 points/sec), I don't yet know why this is as I've not gone into depth with the source code - yet, but the V2 is doing something more on the initial first sweep that it doesn't do on subsequent sweeps. So, to keep the speed up, on subsequent full sweeps just continue to request your blocks of points (ahead of time) without resending the start, step, number of sweep points or the number of values per frequency again.
Thinking ahead like this is a real pain, but it's the only real solution I've found due to the PC not being a real time system (due to it's multi tasking setup), you only have to miss your request for the next block of samples by a few milliseconds and that's it, you'll be loosing samples left right and center, the V2 just will not send them.
I hope that makes sense? .. let me know if you want any more frustrated learnings ;)
On Thu, Nov 5, 2020 at 08:35 PM, Neal Pollack wrote:
>
> What effective baud rate is being used by the firmware, over the USB to PC
> connection?
>
The baud rate is totally ignored in USB VCP as their are no hardware serial ports in the link (set it to whatever you want), the data rate the V2 sends at is not limited by the USB 12Mbit/sec speed (not on the V2 and V2Plus anyway), it's limited by the scan speed of the V2 (max 95 points/sec'ish on the V2.2, faster for the V2plus and V2plus4).
So on the V2.2 I have I get 94 points/sec, each frequency point is sent in a 32-byte block, so that's 94*32*8 = 24064 bits/sec, so basically 24kBaud. I use USB VCP at over 1 MByte/sec in other STM32 projects so the USB speed is certainly not the limiting factor here.
There is already a FIFO on the device to deal with PC latency, but this
limited by the amount of memory on the device and there isn't much that
can be improved. The sweep can not be paused, so if the PC is unable to
read data for a long time there will be lost points. NanoVNA-QT in all
environments I've tested does not drop any points with the plus4, so I
don't think this is a problem.
Thanks for the added details. I have a Signal Hound SA that requires USB3. I've written some software for it and it seems when I was first reading about it, their manual made a comment to the effect that once you tell it to send data, you better be ready because it's sending a lot, very fast. The Nano seems fairly slow and shouldn't pose a problem.
Having to split the data into two sets is what I was thinking. Most likely I will have a receiver thread that runs full out, always pulling down data of some fixed length. I am thinking it would look for the start frequency as a start of frame. It would look for a second start frequency to know the end and it knows the number of samples so at least these should match. Then transfer that frame to the next layer. So the next layer would always be getting a full frames. If that last byte is a checksum, it would be really good to know as it seems they assume the transfers are perfect and nothing ever goes wrong.
Their averaging does throw a bit of a wrench into this.
I want to keep my code generic enough to handle what ever frame sizes I want with or without averages. It's too bad they don't just accumulate and do a final divide. I am thinking the next layer would handle the average and output a final fixed length frame to the next layer. Doesn't seem too bad just thinking about it.
I assume the 32-bit integers are just basically raw data and the software is required to scale them. So, they are not really a 32-bit float of something like that?
As mentioned, I did try a few commands just to make sure the Nano did something. I noticed that the output is not very flat. It looks like mine is about a -10 dBm at 100MHz and -20 at 4GHz. Any idea what the compression is at the two extremes? Do you know if there is any way to adjust the level? For a wideband power device, I would like to keep it's input at a constant level. I could characterize the Nano as part of the calibration and change the level based on the frequency. Do you know if it supports something like this?
It appears I can program the frequency up to about 4.6GHz I assume I could run it up this high with a very reduced performance as long at I use this as the stop frequency, or is there something that would prevent it?
Looking forward to starting this fun project. I really like the original Nano and this V2+4 seems like a big improvement.
On Fri, Nov 6, 2020 at 02:10 PM, Joe Smith wrote:
>
> Having to split the data into two sets is what I was thinking. Most
> likely I will have a receiver thread that runs full out, always pulling
> down data of some fixed length. I am thinking it would look for the
> start frequency as a start of frame. It would look for a second start
> frequency to know the end and it knows the number of samples so at least
> these should match. Then transfer that frame to the next layer. So the
> next layer would always be getting a full frames. If that last byte is a
> checksum, it would be really good to know as it seems they assume the
> transfers are perfect and nothing ever goes wrong.
>
> Their averaging does throw a bit of a wrench into this.
>
> I assume the 32-bit integers are just basically raw data and the software
> is required to scale them. So, they are not really a 32-bit float of
> something like that?
>
Sounds like the best way re the threads.
Yes the checksum is easy to use (c code I use in my software) ..
uint8_t checksum = 0x46;
for (unsigned int i = 0; i < sizeof(fifo) - 1; i++)
checksum = (checksum ^ ((checksum << 1) | 1u)) ^ fifo[k + i];
const bool checksum_ok = (checksum == fifo[sizeof(fifo) - 1]) ? true : false;
I'd forget about the pointsPerFrequency averaging, set it to one and do your own averaging (as I do). You just want to get those points into your software as quickly as possible to do your thing with them.
Each fifo 32-byte block has 6 points (as you know), each point is a 32-bit signed integer, the first two points are the scaling value for the following 4 points (S21/S21 real/imag). You take first real/imag pair (1st two 32-bit points) and divide the following S11/S21 real./imag 32-bit int pairs by them to produce the final S11/S21 floating point real/imag's.
Very easy serial protocol/format, just not the best due to the inherent timing problems that can happen.
I was guessing that the reason for the strange averaging was they could read the same frequency many times without having to wait for it to settle. The over all sweep time will change as it reads each location multiple times and because of how it works, it will smear the data over time. Just seems like a really odd way to implement it. I wonder what the gains are speed wise and if it's worth the added effort. Say you want to tune some network for example and the smearing is no big deal. You just want faster feedback from your adjustments. Still, would you want the average on. I guess just something to ponder before jumping in.
Thanks on the info on the checksum and 32int. Your comments will save me some time. I wasn't even sure if that was even a checksum as their document shows registers 1A - 1F as reserved. Odd they wouldn't define it. It sounds like you are using it and not seeing any problems.
I tried collecting some metrics on how the average would improve the overall throughput compared with setting the ValuesPerFreq to 1. It does not appear to improve it. It would be good to know why this was added, if it wasn't to improve the speed.
Your comments on the checksum and scaling were correct. I made a quick test using the three threads and two FIFOs as mentioned and it seems robust enough.
I have not spent any time looking at the hardware but noticed in the documents that they have an ecal built in. What does the firmware do with this? Does it perform some sort of alignment on power up? When you run headless (USB) does the ecal still come into play? I noticed that when running headless, with no calibration, the values are much closer than I was expecting.
Anyway, its a good start. Thanks for the help.
NanoVNA Custom Software - Page 29
|
|
| |
NanoVNA Custom Software - Page 29
NanoVNA Custom Software - Page 29
|
|
|
I'm not sure who decided on the details of the protocol they use.
Someone asked why would you ever want to average the VNA scans/sweeps/points. Well, it can help a lot when making static measurements of things like filters.
Here's a quick example I just did with the NanoVNA V2 and adjusting the averaging over time (time domain moving average filter). You can see how when increasing the amount of averaging (over time) causes the noise floor to drop somewhat beyond it's normal level and so increase viewable dynamic range ..
https://youtu.be/GGBY6QfptTo
Joe,
The V2 firmware does a sort of electronic calibration or normalization using the internal open(RF3) and load(RF3) pins of the SW_ECAL switch (U551). This does not provide a full calibration out to the external connector, but it its pretty close (except for phase) up through VHF. The full firmware calibration is then built on top of that basic normalization. I think that the normalization is periodically updated to adjust for internal circuit changes over temperature. I think the data reported over the USB connection is the normalized (but not calibrated) data.
--John Gord
On Sun, Nov 8, 2020 at 08:00 AM, Joe Smith wrote:
oops. The "load" connected pin of U551 is RF2.
On Sun, Nov 8, 2020 at 09:12 PM, John Gord wrote:
To reply to this topic, join https://groups.io/g/NanoVNAV2
