NanoVNA Custom Software

[DiSlord]

You can increase sweep rate by use my debug registers.

0xE0 - for Si5351 (< 140MHz range)
0xE1 - for MAX (>140MHz)

This regisers by default = 15, set IF periods count for one measure
This mean for one point measure use 300 samples (for frequency > 400Hz, in this case one period = 20 samples, for less frequency one period 100 samples)
Average multiplie this value, so on 2xavg use 2x300 = 600 samples and so on

You can use any non zero value. !!! this registers i use for debug, so not check for 0)!!!

Use 1 allow get high sweep rate, but more noise (in this case sweep time limit only USB bus speed and wait/sync delays)

PS try use USB 2.0 port on CPU, as i see it allow get more sample rate then USB3.0

[joeqsmith]

Thanks.  I will add the ability to change this setting and let you know how it works. 

My newer software supports sending the demodulated signals to the sound card.   Maybe we can do some audio. 

***
spelling

[joeqsmith]

I added manual control to these two registers.   Changing from 1 to 15 seems to have no effect on the data rate to the PC.   I tried both synthesizers at 10MHz and 200MHz.  No change (except the slower sweep rate for the lower frequency). 

I still have LiteVNA64-220127.bin firmware installed.   Does the released code support it?   Do I need to be in a certain state before changing the registers for them to take effect?   

[DiSlord]

Hmm, i write to E0 (send 0x20 0xE0 0x01)

And get ~660 samples/sec sweep on 1xavg in < 400k range

Here is my last beta, in it i rewrite DSP part, now for all measures select best gain (before only for thru).
Also  must get little less noise floor and more linear thru measure on hi frequency, but this still beta, i want add more fixes.

[joeqsmith]

It's very possible it's on our side.    At 10MHz, I was seeing an update rate of 1000ms for 401 data points, 1 avg at 10MHz.   Writing a one to E0, I still see 1000ms.   I'll try your current firmware. 

[joeqsmith]

With the new firmware installed, it seems to speed it up about 100ms.   

If you turn off S11 and only send the S21 data, could you then skip all the delays?   Do you have have another debug register to select what data comes back? 

[DiSlord]

Yes, this is one of the features that I would like to add (for version H / H4 this feature is available), this allow near x1.5 faster sweep.

[joeqsmith]

That would be a worthwhile change.   50% increase but half the data, hard to believe any of the existing software would have a problem.   Let me know if you want to try it. 

[joeqsmith]

This is as fast as the Lite will run with your test code and my software seems to have no problem keeping up.   It seems there is a bit of phase error in the sampling as well.   

[DiSlord]

I see onboard speed increase (visually) but max speed i can get in CPU software ~800 points/sec (in theory by timings i must get near 2000-3000).

I see x1.5 increase on one data measure (S11 or S21), but as before limit near 700-800 (not depend from internal measure speed, limits in current USB exchange format).

You can try this:
write in 0x44 register 1 allow get only S11 data (exchange protocol not change, S21 data conatain garbage)
write in 0x44 register 2 allow get only S21 data (exchange protocol not change, S11 data conatain garbage)

Current settings (not need use debug registers 0xE0 and 0xE1) allow get max speed in only S11 or S21 measure on 1xAVG, as i can see near 800 points/sec (1.2ms for one point in your software)

[joeqsmith]

Thanks for the update.  I tried it and it seems to work as suggested.  Not stated but setting to 0 will reset the mode to S11 and S21 data.   I tried comparing USB 3 and 2 ports but saw no difference.  My PC seems a fair bit slower than yours so I suspect there is a way I could further speed up my software by using the read FIFO command (0x18,AA,NN).   Since getting the V2+4, I have always set NN to 1.  Each call the index will increment as expected.   Setting NN to 2 for example,  I will get the two packets but they are identical.   Not just the same index but the same payload.   I always assumed this was a bug and just ignored it but suspect if this were to work, I could reduce the overhead a fair amount. 

I send 0x18, 0x30, 0x01 for every data point.  I would expect I could send 0x18, 0x30, 0x02  and receive two data points but it doesn't appear to work this way.   

***
That was a problem on my end.  I forgot to index the array...   

Anyway, seems to work fine but sadly, no gains.   With USB 3.1, 800 points, 200MHz CW, 1 Avg, S21 only, it takes about 1.23 seconds (1.53ms/point or 650Hz sample rate).     Sending both S21 and S11 requires 1.36 seconds.   I can disable all the features except the showing the raw data and the time is not improved.   Sending both with USB 2.0  requires 1.46 seconds.   

It's only 167kbps sustained.    In your case, a couple hundred kbps, but I am not sure why.   You have a faster Lite?  Hardly seems like the PC is the bottleneck.   

***
Using NN > 1 does seem to deduce the phase error.   Shown is about an hour of data.

***
If I throttle the PC read thread.  This is the thread sending the read FIFO commands, the index will start to skip.   So, if the software can't keep up, we will not see incrementing indexes.   
(not true, always seems to increment regardless.  Breakpoint in wrong spot)

At these low data rates, I could use a couple of USB / TTL or RS232 adaptors and write a simple Lite simulator.   Maybe send test patterns.  From this we could sort out at what speed LabView can't not keep up. 

On the firmware side, you could also try making a simple debug version that just sends up a pattern.   Even a simple counter with checksum should be good enough.  If the problem is getting the data out of the Lite,  what do you think about only sending the data that is being requested? 

I'm only considering CW.   
 

[joeqsmith]

Looking at the USB comm port adapters I have, none are very fast.   I could achieve maybe 5X faster but I suspect not enough to stress the software.

It's not really an apples to apples compare but I own a Signal Hound BB60C spectrum analyzer that uses USB 3.   They offer an API that allows access to the IQ data.    I made a demo video where I used LabView to collect the signal from a 900MHz radio (a DMM I own) and convert it to the meter's readings. 

https://signalhound.com/products/bb60c/




I don't own any other equipment that uses USB but I have used LabView to interface with some Ethernet devices also at much higher data rates without any problems.   

[DiSlord]

Found problem, now you can get max speed (i can get ~2600 points/sec if use E0/E1 = 1, avg = 1, and get only S11 data 0x44 = 1, this speed close to current limit)

Also now on device calibrate i use only one channel measure (S11 for SOL, and S21 for ISOLN/THRU) - so calibrate sweep ~x1.5 faster.

But need understand use E0/E1 change measure RBW - so use less value increase noise, increase this value reduce it.
Final RBW depend from E0/E1 * AVG, bigger value reduce RBW and decrease noise, but increase sweep speed.

PS i see only 1000 points/sec on USB3 port and 2600 points/sec on USB2, look like USB3 ask for data only every 1ms

[joeqsmith]

 

That's fast!  800 data points is about 160ms or roughly 5KHz on USB3.x port.    Screen shot showing me running Flippers Lite a couple thousand miles away.  Their PC only has 3.x ports.   I tried enabling both VNA ports and it made little difference on the data rates.   

I'll play around with it using my setup but this is very much what I was expecting.   Thanks for taking the time to look into this.

[joeqsmith]

0xE0 - for Si5351 (< 140MHz range)
0xE1 - for MAX (>140MHz)

This regisers by default = 15, set IF periods count for one measure
This mean for one point measure use 300 samples (for frequency > 400Hz, in this case one period = 20 samples, for less frequency one period 100 samples)
Average multiplie this value, so on 2xavg use 2x300 = 600 samples and so on

Can you maybe reword the above or provide more details about where these number come from and what they mean? 

[DiSlord]

This related to DSP processing

VNA measure IF data after mixer
Use ADC for this, on LiteVNA used 600k sample rate (V2Plus/V2Plus4 use 1.5M sample rate, but after decimate?)
After used sin/cos table for calculate signal I/Q data
Table period depend from used IF
For signal >400k used 60k IF and 10 samples for one period table (if use 60k on less frequency you start see artefacts on IF harmoincs)
For signals > 20k and less 400k used 12k IF, but use bigger table - and this reduce sweep speed (you can see artefacts on 24k, 36k and so on)
For signals < 20k used 6k IF, and this more slowdown

More IF periods pass in DSP - result less RBW in measure, less noise, but need more time.

E0 - periods count for Si generator ( < 100MHz) for one measure, after this multiplie by AVG settings
E1 for MAX generator ( > 100 MHz)

You can see how this work, connect generator to CH1, set 30MHz output, and measure S21 logmag in 30MHz and span 30k, change AVG or E0 settings and see filter width

E0 = 6 and AVG = 1 give RBW = 10k (60k IF / (6 * 1))
E0 = 60 and AVG = 1 give RBW = 1k (60k IF / (60 * 1))
And so on

Default E0/E1 = 15, this give on 1xAVG RBW = 60k/15 = 4k

[joeqsmith]

Here's Dislord's latest rocket powered firmware in action .... so fast!!   



It will be interesting to see if any of it makes it into the release code.   If it does, I will go ahead and clean up my software to support it. 

Thanks for all your help.     

[realfran]

I sed before Joe; you can make with your software one gadget to one  instrument:-+
Thank you Dislord@ to share your precious information from your great work on this firmware.
I hope to get the V.3 I'm very anxious about it.

[joeqsmith]

I hope to get the V.3 I'm very anxious about it.

You're not alone.  Its been a while since I've received any colorful emails but an radio hobbyist PMed the other day.  They felt the need to need to let me know they are upset about my not releasing it.   They did make me aware of how important their time was.     Apparently they didn't like the "tone" of my responses.      

[realfran]

I don't flatter person but appreciate your work and when you release the software version I go to use,  for the ""tone" of your response same time luck sarcastic or dray but is your character possible is your sense of humour this not change the fact I appreciate your labour and the experience of it. 

[joeqsmith]

While one viewed may have droned on about my choice of music, failing to see notice the forest for the trees,  I have been playing with the new firmware a fair bit and its impressive.   I believe I hung the firmware once and had to power cycle it but for a test version of code it's proven to be very stable.

If you were to add this to the release, would you keep the same register address or add new ones?   Would the manual be updated to include the new map?     

I have not dug into the hardware at all but another question I have is about the narrow band.   It seems I had used the CW mode to see how fine I could control the frequency, using a counter to monitor the frequency.   It seems that it had the resolution but something was amuck with the receiver not being able to resolve to the same resolution.    I'll repeat this test and give you some numbers but like the limited sample rates, I wonder if this isn't also a limitation of the newer firmware rather than the hardware.   

[DiSlord]

I leave this registers (E0 and E1 exist in official firmware, i use this for debug), added 0x44 register, i set use it only for USB connection (at this moment set 0x44 register also apply on device internal measure)

If set CW mode over USB you not see CW output on CH0 port (i not complete this part, CW mode work only if set on device), if i made this - then get more faster sampling (~1.5-2x more, not need measure reference for every point, but can get USB bus limit, as i can see on my CPU new limit ~6k samples in CW mode, you can get it if set CW mode on device and after ask CW mode over USB at this moment)

I hope complete code on next 1-2 week, as i can see new DSP processing more fast, and stable (also allow do more things).

[joeqsmith]

Take your time.   I'm in no rush and more just curious if the register mapping will remain the same. 

On the narrow band, I setup the same experiment.   Using my scope's counter to monitor port1 and triggering on the dead time, then stepping the VNAs frequency it seems the resolution isn't a problem.

Connecting my RF generator to a series 4MHz crystal then trimming the frequency for peak and applying on port2.   Basically, I want to simulate running the crystal without the effects of port 1 dropping out.   With a span of 500kHz, I would expect to see a very narrow peak at 4MHz but instead see two peaks. 

Setting E0 to 1 to try and remove some of the filtering, the shape changes but we clearly see the two peaks with a 120kHz separation. 

Can you explain the cause?

[DiSlord]

You connect external generator to ch1 port?

You see 60k IF mirror (at 4MHz - 2*60k = 3.88M).

[gf]

Can you explain the cause?

The receiver/mixer has of course no image rejection. Unlike a SA, a network analyzer does not need that, since the stimulus is not wide-band, but only a single freqency at a time (as long it is granted that no foreign signal is present). It is important, though, that the IF filter rejects harmonics of the IF significantly¹⁾, since both, stimulus and LO are suqare waves, therefore harmonics of the IF are expected at the mixer output, but we are only interested at the IF fundamental (or alternatively only in a single particular harmonic, when harmonic mode is used at high frequencies).

It were also interesting how well f+540kHz (9th IF harmonic) is suppressed, since 540kHz folds (aliases) back to 60kHz when sampled @600kSa/s, and 60kHz is exactly the IF frequency. So it cannot (must not) be eliminated by the digital filter, but already the analog lowpass in front of the ADC needs to do that. How well does it do its job? The same applies to the 11th, 19th, 21th,... IF harmonics as well, but the 9th is the first (and strongest) one folding back to 60kHz.

¹⁾ Either it notches them out, or alternatively it generally needs a high stop band rejection.

EDIT: The bizarre shape in the first image is the (expected) result of averaging. Since the window function of the coherent detector spans only a fraction of the measured samples, it effectively get repeated over the total measurement window, which leads to the depiced frequency response then. In the second image, the window function obviously spans all measured samples.