NanoVNA Custom Software

[radioactive]

Those frequencies makes sense because they are at the beginning of each (VCO) range:

I noticed that.  I think the reason the current firmware in the repository works good is because there is a "delay" parameter returned from the set_frequency() function.  The delay is incremented by 10 on vco band changes.  That delay value determines the number of adc samples to skip over.   So on a band change,  it skips over samples that might otherwise be glitchy due to pll unlock.

[radiolistener]

I tested si5351 for sweep generator. With no PLL change it allows to change frequency very fast and with no breaks. But when you change PLL and make PLL reset, the output will be disabled for a short period of time. For about 1 us or something like that (don't remember exactly). It prevents to use si5351 for continuous sweep above 150 MHz.

[radiolistener]

I think the reason the current firmware in the repository works good is because there is a "delay" parameter returned from the set_frequency() function.  The delay is incremented by 10 on vco band changes.

yes, I think this approach is more stable than continuous check for pll lock. Because pll reset requires fixed time in average, so proper delay will works good. But continuous read of status may lead to si5351 hung up, especially if you're I2C at high speed 400 kHz.

I have such issue with si5351. If you're using overclocked I2C for communication at extreme high speed, sometimes it may leads to hung up. After that si5351 is responsive for I2C requests, but it's output is stuck and cannot be changed with any register write. After that you can fix it with power off and power on.

[radioactive]

One last attachment for now.   The zip has a binary image and the changes I made to the source from  https://github.com/ttrftech/NanoVNA   (edy555 commit 30d33571fa3929ff697bf410d3b7f25145cc6e45)

I added another command 'adc_samples' and got rid of the delay+10 in returned on vco changes because of the pll lock polling.   adc_samples N,  where N is a value between 3 and 255.  This is the value that the set_frequency() function will return.  Instead of I/Q skipping samples,  it now averages them.  It looks like averaging samples has a good effect on the measurement range for frequencies below 100 MHz.   Of course, the higher N,  the longer it takes to sweep.

Anyway,  hope this gives someone else something to mess around with.   I'm going to get back to work on the sdr project now.

[radioactive]

I think the reason the current firmware in the repository works good is because there is a "delay" parameter returned from the set_frequency() function.  The delay is incremented by 10 on vco band changes.

yes, I think this approach is more stable than continuous check for pll lock. Because pll reset requires fixed time in average, so proper delay will works good. But continuous read of status may lead to si5351 hung up, especially if you're I2C at high speed 400 kHz.

I have such issue with si5351. If you're using overclocked I2C for communication at extreme high speed, sometimes it may leads to hung up. After that si5351 is responsive for I2C requests, but it's output is stuck and cannot be changed with any register write. After that you can fix it with power off and power on.

It does seem to work fine just skipping some adc samples, so no big deal if your device looks like it is working ok.  Your argument about I2C doesn't make much sense to me.  The device is constantly using I2C @ 400kHz for programming the tlvxxx and si5351 part on every sweep.  I know I mentioned before, but when you are dealing with PLL that has the ability to check lock  (pretty much all of them),  then it is a good idea to take advantage of that in general.  In this case, it would be good to at least have warnings on unlock in my opinion.  If you don't check, how will you know? 

[radiolistener]

If you don't check, how will you know?

just use delay for some period of time which is needed for stable pll lock

You're needs to make this delay when you send PLL reset command to si5351.

[radioactive]

If you don't check, how will you know?

just use delay for some period of time which is needed for stable pll lock

You're needs to make this delay when you send PLL reset command to si5351.

Might work almost all the time.   Wonder what could be causing these issues:  https://github.com/ttrftech/NanoVNA/issues/59

[radiolistener]

Wonder what could be causing these issues

I think he forgot to perform calibration after firmware update

[bob91343]

I don't see a link to the video.

[joeqsmith]

After having the newer firmware lockup on me a few times, I shelved the Nano.   I looked a few days ago and saw there was a newer release but I have not tried it.   I did see that they had uncommented the new command allowing for a variable number of samples.   

[Mike G]

Hi Joe, just in case it might help, the latest, 7th October 2019, version of edy555's firmware seems to have cured the "white screen" when performing segmented scanning, I am not sure if this is connected to your problem?  Hope you don't hang up your nano for good as I have learnt a lot from your you-tube videos and the posts on this forum, although I admit a fair bit of your later work is above my head. Regards Mike

[joeqsmith]

Hi Joe, just in case it might help, the latest, 7th October 2019, version of edy555's firmware seems to have cured the "white screen" when performing segmented scanning, I am not sure if this is connected to your problem?  Hope you don't hang up your nano for good as I have learnt a lot from your you-tube videos and the posts on this forum, although I admit a fair bit of your later work is above my head. Regards Mike

Thanks and I'm glad you found them useful.     

With the latest firmware, the screen doesn't go white like it used to but the Nano locks up.  It will not accept USB commands and requires a power cycle to recover.   

I had put together a longer stage for my TDR experiments and was running some fairly long tests and the Nano would lockup while running them.  This was with the last stock firmware from edy555 that I downloaded.  I did not reload the later hugen firmware as it was having other problems sending corrupt data.   

With them cranking out what appears to be untested versions so fast, it's not worth manually checking them all looking for stable version.

[radiolistener]

With the latest firmware, the screen doesn't go white like it used to but the Nano locks up.  It will not accept USB commands and requires a power cycle to recover.   

Try this version

[joeqsmith]

With the latest firmware, the screen doesn't go white like it used to but the Nano locks up.  It will not accept USB commands and requires a power cycle to recover.   

Try this version

I would have no way of knowing what this version is.  That's been part of the problem I see with the edy555 and hugen79 code, they do not document. As a user,  I can waste time running a diff and try to sort of what they changed and why.  A bit odd they don't keep a detailed log of the changes.

It looks like hugen79 also released something new in the last couple of days.  Like the latest edy555 release, they also enabled the scan command. 

It may be worth spending some time putting together some sort of automated regression tests for the Nano. 

[ogden]

I had put together a longer stage for my TDR experiments and was running some fairly long tests

While doing that did you remember what you say some time ago? Just saying.

[joeqsmith]

I had put together a longer stage for my TDR experiments and was running some fairly long tests

While doing that did you remember what you say some time ago? Just saying.

Sure I remember.  What about it?

[ogden]

I had put together a longer stage for my TDR experiments and was running some fairly long tests

While doing that did you remember what you say some time ago? Just saying.

Sure I remember.  What about it?

Well...  Rebuild of delay contraption removed most of obstacles you mentioned back then. So @rhb could get info he looked for.

[radiolistener]

Try this version

I would have no way of knowing what this version is.  That's been part of the problem I see with the edy555 and hugen79 code

This is the most fresh version which includes edy555 changes + hugen79 improvements + improved stability + scanraw command. It also excludes these changes which didn't passed QA due to regression.

scanraw command allows to read raw S11 or S21 (with no calibration apply) and averaging. You can use it to apply your own calibration.

For example:

Code: [Select]

scanraw 0 1000000 1000000 900 10
will read 900 points from 1 MHz to 900 MHz with 1 MHz step and averaging by 10 points for CH0.

You're needs to apply your own calibration to the result.

[joeqsmith]

Try this version

I would have no way of knowing what this version is.  That's been part of the problem I see with the edy555 and hugen79 code

This is the most fresh version which includes edy555 changes + hugen79 improvements + improved stability + scanraw command. It also excludes these changes which didn't passed QA due to regression.

scanraw command allows to read raw S11 or S21 (with no calibration apply) and averaging. You can use it to apply your own calibration.

For example:

Code: [Select]

scanraw 0 1000000 1000000 900 10
will read 900 points from 1 MHz to 900 MHz with 1 MHz step and averaging by 10 points for CH0.

You're needs to apply your own calibration to the result.

Please fill me in on this regression testing you mention.     

Do you have a link to where the source is being stored for the image you uploaded? 

[radiolistener]

Do you have a link to where the source is being stored for the image you uploaded?

https://github.com/qrp73/NanoVNA

[joeqsmith]

Do you have a link to where the source is being stored for the image you uploaded?

https://github.com/qrp73/NanoVNA

Thanks for the link.

In order to evaluate all of these various versions efficiently, I would really need to consider setting up some sort auto or semi-auto regression test.   I am very interesting in knowing more about the regression testing you mentioned.   Mainly, what tests you perform?  Is it possible to use your test scripts on other flavors?   What hardware you require?  Do you create any sort of reports that could be posted?   

If your regression tests could be shared with the other developers, that may be helpful. 

Currently I have no way of running a decent test outside of just manually going through the paces.   This takes a fair amount of time.

[ogden]

Got nanovna by shopping spree accident, black clone. Why it's not "original" - don't ask. Perhaps for greater good. Port2 mixer IC (sa612) was dead, reflection mixer seems to be "factory-repaired" as well. After quick fix it seems to perform well for a price.

Supplied cables and short are surprisingly good. Open is good by definition because it's joke at those frequencies anyway. Terminator/load is utter piece of crap. Every owner of nanovna shall consider getting quality 50ohm terminator. Those who can afford some more may get 2nd terminator and 10dB, 20dB, 40dB 6dB attenuators.

I did calibrate repaired and fully functioning nanovna using supplied accessories + mini-circuits terminator. Measured S11 of mini-circuits terminator, then supplied terminator. Files attached.

[radioactive]

Terminator/load is utter piece of crap. Every owner of nanovna shall consider getting quality 50ohm terminator.

I guess results may vary.  The 50-ohm terminator I was supplied results in S11 measurement range very close to your mini-circuits terminator measurements.

[ogden]

Terminator/load is utter piece of crap. Every owner of nanovna shall consider getting quality 50ohm terminator.

I guess results may vary.  The 50-ohm terminator I was supplied results in S11 measurement range very close to your mini-circuits terminator measurements.

Be careful before you jump with conclusions. You can't judge about quality of your terminator unless you have one reference to calibrate & compare with. With just one terminator you don't know. You may see amazing return loss picture like attached S11 and do not even know that it is actually worst 50ohm'ish crap ever:

[radioactive]

Terminator/load is utter piece of crap. Every owner of nanovna shall consider getting quality 50ohm terminator.

I guess results may vary.  The 50-ohm terminator I was supplied results in S11 measurement range very close to your mini-circuits terminator measurements.

Be careful before you jump with conclusions. You can't judge about quality of your terminator unless you have one reference to calibrate & compare with. With just one terminator you don't know. You may see amazing return loss picture like attached S11 and do not even know that it is actually worst 50ohm'ish crap ever:

The supplied terminator I received with nanoVNA also looks very close to a Weinschel 50 ohm terminator of mine.