NanoVNA Custom Software

[MagicSmoker]

I read every last message in this thread - can't claim I remember all of them  - and promptly ordered a nanovna as a result. I'm more of a power electronics guy than RF but jeez... only $50? Why the hell not?

Actually, I do have a use in mind that I'm not sure can be done but again, only $50; I want to better characterize transformers used in resonant converters. It would be nice if the minimum frequency could be dropped to say, 10kHz (is that a hardware [unlikely] or firmware limit?) but the immediate task at hand is a converter operating at 250kHz which I suspect has an unintended parallel resonance somewhere north of 4MHz (hence why I need a VNA).

And who knows, maybe I'll learn to love the Smith chart...

[radiolistener]

only $50

now you can find it for 30 USD from some sellers

[radioactive]

I'll see if I can narrow the problem down further so maybe the real firmware guys can correct it.  Then again, if it's just this one unit, it's hardly worth going after.

It seems like hardware problem (that may be fixable in software or not). Noticeably there are many traces w/o glitch. Then suddenly one or more traces have huge noise. We see that problem occur above 800MHz only when there are huge VCO tuning jumps. Seems like PLL is struggling to lock for some reasons in overclocking freq range or software do not wait long enough for PLL to lock, continue with measurement disregarding unlocked PLL. I have not seen source code - are there any PLL lock checks at all? I say that huge VCO freq jumps shall be followed by direct PLL lock status polling and only small steps shall be done using timeouts.

I'm trying to get PLL lock check added just to see what happens, but something is not working right here.   This returns fail about every other call to set_freq function.  Anyone see what is wrong here?  I've tried quite a few variations on this, but not sure that I'm calling the ChibiOS i2c functions correctly.   Things I've already tried:

-  i2cMasterTransmitTimeout()  only with the receive parameters filled in
-  longer timeouts
-  setting bit 0 for addr on the the read function

Ideas?

Also FYI,  @ogden,  I took a look at the decoupling on pin 7 and pin 1 of the si5351A.  On the board I have,  both pins appear to be decoupled correctly.

Code: [Select]

int si5351_wait_for_pll_lock(void) {

  int addr = SI5351_I2C_ADDR>>1;
  #define STATUS_REG 0x00
  uint8_t reg[] = { STATUS_REG};
  uint8_t data[1];
  int retry=6;

  i2cAcquireBus(&I2CD1);

lock_retry:

  retry--;
  (void)i2cMasterTransmitTimeout(&I2CD1, addr, reg, 1, NULL, 0, 10);
  (void)i2cMasterReceiveTimeout(&I2CD1, addr , data, 1, 10);

  //A and B
  //if( (data[0]&0x60) != 0x00 && --retry>0) goto lock_retry;

  //A only
  //if( (data[0]&0x20) != 0x00 && --retry>0) goto lock_retry;

  //B only
  if( (data[0]&0x40) != 0x00 && retry>0) goto lock_retry;


  i2cReleaseBus(&I2CD1);

  if(retry==0) return 0;
    else return 1;  //PLL locked
}


[edit]  I should point out that I'm quite happy with the current state of the firmware in the github repository.   Just experimenting with it here...

[ogden]

I'm trying to get PLL lock check added just to see what happens, but something is not working right here.   This returns fail about every other call to set_freq function.

Just two cents, no pressure to do anything about what I going to say next (grin): Usually after PLL freq change there shall be some delay before continuing with PLL state check. After initial delay, PLL lock status shall be checked during defined and *limited* time. So do you know how long it takes to execute PLL lock check loop 6 times? Also such (indicator) class of instrument better not halt with "hard error" on PLL unlock, it shall continue measurements no matter what - as it does now. It may be just some "PLL unlock" warning indicator on screen which lights up for 0.5sec or so and maybe output some diagnostics info in serial output as well (w/o breaking PC s/w backwards compatibility!). As datasheet is very obscure about PLL timings, PLL minimum/maximum delay shall be determined somehow. One is clear that maximum delay do not need to be longer than 10ms which is whole chip power-up time (max). Anyway if it is not locked during significant time say 10ms, most likely it will never lock in current conditions and some change is needed to "fix" situation. BTW that also could be the case why you see errors no matter what.

Also FYI,  @ogden,  I took a look at the decoupling on pin 7 and pin 1 of the si5351A.  On the board I have,  both pins appear to be decoupled correctly.

Great. Which version do you have? Any chance of PCB close-up picture so potential buyers have better decision making chances?

[hwalker]

Over on nanovna-users@groups.io, hugen gave some clarifications about his anticipated October product release.

1. It will be called NanoVNA-H per his agreement with edy555 to help differentiate clone branches.
2. He provided a pre-release photo of the  anticipated October product release (see attachment).
3. The release is a repackaging of the current nanoVNA and not the STM32F303CCT6 modification currently in development.

hugen's additional comments on 9-29-2019:

"I don't have a plan to compete with NanoVNA-F. The NanoVNA-F is too big. I can't put it in my trouser pocket. I don't even think he should be called NanoVNA. If you need a larger screen, connecting your smartphone with cho45's NanoVNA-Web-Client (https://github.com/cho45/NanoVNA-Web-Client) is a great solution. Regarding the new nanoVNA-H plan, I am trying to move to STM32F303CCT6 with AA6KL. Maybe I will try 3.5-inch LCD later. If you are interested, you can follow this project https://github.com/AA6KL/NanoVNA, if You want to participate in development and you can contact me to get the hardware. Thank you!"

[radioactive]

I'm trying to get PLL lock check added just to see what happens, but something is not working right here.   This returns fail about every other call to set_freq function.

Just two cents, no pressure to do anything about what I going to say next (grin): Usually after PLL freq change there shall be some delay before continuing with PLL state check. After initial delay, PLL lock status shall be checked during defined and *limited* time. So do you know how long it takes to execute PLL lock check loop 6 times? Also such (indicator) class of instrument better not halt with "hard error" on PLL unlock, it shall continue measurements no matter what - as it does now. It may be just some "PLL unlock" warning indicator on screen which lights up for 0.5sec or so and maybe output some diagnostics info in serial output as well (w/o breaking PC s/w backwards compatibility!). As datasheet is very obscure about PLL timings, PLL minimum/maximum delay shall be determined somehow. One is clear that maximum delay do not need to be longer than 10ms which is whole chip power-up time (max). Anyway if it is not locked during significant time say 10ms, most likely it will never lock in current conditions and some change is needed to "fix" situation. BTW that also could be the case why you see errors no matter what.

Also FYI,  @ogden,  I took a look at the decoupling on pin 7 and pin 1 of the si5351A.  On the board I have,  both pins appear to be decoupled correctly.

Great. Which version do you have? Any chance of PCB close-up picture so potential buyers have better decision making chances?

Success! 

The main problem I was having getting it to work was needing to turn off DMA for I2C communications in mcuconf.h

Code: [Select]

#define STM32_I2C_USE_DMA                   FALSE
beginning of sweep function in main.c looks like this now:

Code: [Select]

// main loop for measurement
bool sweep(bool break_on_operation)
{
  int i;
  int delay;

  for (i = 0; i < sweep_points; i++) {

retry_lock:

    #if 1
      delay = set_frequency(frequencies[i]);

      if( si5351_wait_for_pll_lock()==0) {
        chprintf((BaseSequentialStream *)&SDU1, "freq: %d not locking\r\n", frequencies[i]);
        frequencies[i] += 1;  //see if we can lock on 1Hz greater freq
        goto retry_lock;
      }
      tlv320aic3204_select_in3(); // CH0:REFLECT
      wait_dsp(delay);
    #else
      tlv320aic3204_select_in3(); // CH0:REFLECT
      wait_dsp(delay);
    #endif

new function in si5351.c

Code: [Select]

int si5351_wait_for_pll_lock(void) {

  int addr = SI5351_I2C_ADDR>>1;
  #define STATUS_REG 0x00
  uint8_t reg[] = { STATUS_REG};
  uint8_t data[1];
  int retry=99;

  i2cAcquireBus(&I2CD1);

lock_retry:

  retry--;
  (void)i2cMasterTransmitTimeout(&I2CD1, addr, reg, 1, data, 1, 1000);

  //A and B
  if( (data[0]&0x60) != 0x00 && --retry>0) goto lock_retry;

  i2cReleaseBus(&I2CD1);

  if(retry==0) return 0;
    else return 1;
}
With retry=6 in wait_for_lock function,  I see errors locking like this during sweeps:

freq: 50024 not locking
freq: 108044024 not locking
freq: 153041524 not locking
freq: 306033024 not locking
freq: 450025024 not locking
freq: 50025 not locking
freq: 108044025 not locking
freq: 153041525 not locking
freq: 306033025 not locking
freq: 450025025 not locking
freq: 50026 not locking
freq: 108044026 not locking
freq: 153041526 not locking
freq: 306033026 not locking
freq: 450025026 not locking
freq: 50027 not locking
freq: 108044027 not locking
freq: 153041527 not locking
freq: 306033027 not locking
freq: 450025027 not locking
freq: 50028 not locking
freq: 108044028 not locking
freq: 153041528 not locking
freq: 306033028 not locking
freq: 450025028 not locking

With retry=99  in wait_for_lock function,  I see no errors locking.

@ogden,  I can post an image later, but you can just take a look at the image of pcb and schematic at hugen's sales site here:  https://www.alibaba.com/product-detail/Original-2-8-Touchscreen-50KHz-900MHz_62232701280.html

[radioactive]

Forgot to mention that the lock errors shown in previous post were for the standard 101 point sweep from 50kHz to 900MHz.   Still no errors showing up with retry=99.  I may stick the thing in freezer and oven later to see if anything different happens.

[radioactive]

If anyone wants to compare their results with mine, but doesn't want to make changes to source and compile,  I'm attaching a binary.  This differs in one way from the results that I posted in previous 2 posts.  This binary will not increment the frequency by 1 Hz if the wait_for_lock function fails to lock.  If there is no lock, it will just print the frequency that did not lock in the USB serial console and continue to retry.  Note that you would need to handle this in your external software application if there is actually some lock errors during the sweep.  This firmware image has the retry=99 in the wait_for_lock function.  I can also post an image for retry=6 (or whatever) if anyone wants to compare results for that.   Aside from the changes I posted above, this firmware image is based on the latest source from here:   https://github.com/ttrftech/NanoVNA   ,  from edy555 commit 30d33571fa3929ff697bf410d3b7f25145cc6e45

[edit]
If you do try this out,  it would probably be a good idea to do a re-cal just in case this might improve calibration coefficients for a few frequencies that were off from the previous cal due to unlock.

[edit]

I tested after putting it in the freezer for 10 minutes and the oven, low temp,  for 10 minutes (measured 105F when I pulled it out).  No pll lock errors reported with retry=99 in lock function for either temperature extreme.   I did see 3-4 glitches in the display for the first 30 seconds or so after the cold temperatures.  Not sure what that would be.

I would say this is something that probably should be added to the code base.  Based on experience with frequency synthesizers,  I have found that you *must* check for lock and have some sort of retry mechanism.  It might only affect one unit out of a batch.  It might only happen in temperatures extremes, but sooner or later you will find unlock happening in certain circumstances.  It needs to be handled by checking lock status, retries, etc.

[ogden]

Success!

Congrats! 

        frequencies += 1;  //see if we can lock on 1Hz greater freq

Better do not touch frequency like that unless you are absolutely sure. Even slightest shift of IF or LO freq which is unexpected for VNA math, may lead to significant errors.

With retry=99  in wait_for_lock function,  I see no errors locking.

Good. You may narrow down retry number in just few test runs by using "binary search" approach.

@ogden,  I can post an image later, but you can just take a look at the image of pcb and schematic at hugen's sales site here

No need. Knowing that it is hugen's original version, we just take picture from the web (attach). BTW from appearance it seems like @joeqsmith have such as well. Yes, this version have decoupling capacitor for pin7 which is kinda improvement compared to edy555 PCB, yet there's still rookie errors: both traces going to (C10) capacitor forms loop antenna close to nearby signal trace. Influence may be minimal, yet anyway... There was room for everything - few ground plane stiches along signal line *and* closer pin7 capacitor placement. It becomes clear when we look at audio codec decoupling capacitor (C34, C36, C37) placements which are strange as well: they all are at distance away from the chip. Seems like strange "minimum distance to IC" rule applied  and absent ground via next to cap.

[radioactive]

Better do not touch frequency like that unless you are absolutely sure. Even slightest shift of IF or LO freq which is unexpected for VNA math, may lead to significant errors.

As I already mentioned,  I took that out before posting the binary image.  It was just a bit of test code.   I left it in the first post output,  so it made it clear that the synth was locking on second call to set_freq after wait_for_lock function failed.

I agree with your assessment that the layout could be improved, but it works fine.  I suspect there are some via-in-pads for some of those caps, so grounds may be closer than they look.  C9 should only bypass the chip (and be moved closer) and another separate cap  should be added for the ref osc.    Anyway,  it is close enough.  Obviously, it works great.

Still no lock errors.

[ogden]

I suspect there are some via-in-pads for some of those caps, so grounds may be closer than they look.

Very unlikely, unless those vias under caps are epoxy-filled. I bet they are not because $$$. Via-in-pad is bad idea on cheap PCB, unless used for thermal pads of big components (TO-252, D-PAK). Otherwise you may get tombstone or open joint (pic below).

[edit] Briefly looked into source code. Seems like both, PLL-A and PLL-B used for VNA functions. It means that MCLK is derived from either one. Well, well, well...  VCO tuning, PLL locking takes time. During that time clock output is either disabled or whatever VCO is doing at the moment - sweeping or just wandering around. It does happen to MCLK as well!! That in result can and will upset audio codec and USB operation, cause various artefacts of sample or USB data corruption. During operation you shall never re-tune VCO+PLL that feeds either audio or serial interface (USB, Ethernet). Possible fix: run si5351 and MCU from 24MHz XO and use si5351 exclusively and only for VNA frequency generation.

[radioactive]

I'm attaching an update to the firmware image I posted last night with the pll lock check.   I've added a command to change the number of loops in the wait_for_lock function before it returns lock status to the main loop.  If the lock fails after reading the si5351 status register n times, it will will call the set_freq() function again until lock.
usage:  lock_wait n,  where n=99 by default.

While running a trace from 50kHz to 1500MHz,  I see no errors in the USB serial console.  If I set lock_wait to a value of 25,  still no errors.   

ch> lock_wait 20

ch> freq: 50000 not locking
freq: 300039984 not locking
freq: 50000 not locking
freq: 50000 not locking
freq: 300039984 not locking
freq: 300039984 not locking
freq: 50000 not locking
freq: 300039984 not locking
freq: 50000 not locking
freq: 300039984 not locking
freq: 900019984 not locking
freq: 50000 not locking
freq: 300039984 not locking
freq: 50000 not locking

ch> lock_wait 10

ch> freq: 50000 not locking
freq: 108044000 not locking
freq: 153041504 not locking
freq: 306033008 not locking
freq: 450025008 not locking
freq: 900000016 not locking
freq: 50000 not locking
freq: 108044000 not locking
freq: 153041504 not locking
freq: 306033008 not locking
freq: 450025008 not locking
freq: 900000016 not locking
freq: 50000 not locking
freq: 108044000 not locking
freq: 153041504 not locking
freq: 306033008 not locking
freq: 450025008 not locking

see the post above for more info on what the code looks like:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2715592/#msg2715592

[ogden]

freq: 50000 not locking
freq: 108044000 not locking
freq: 153041504 not locking
freq: 306033008 not locking
freq: 450025008 not locking
freq: 900000016 not locking

Those frequencies makes sense because they are at the beginning of each (VCO) range:
 * 1~100MHz fixed PLL 900MHz, fractional divider
 * 100~150MHz fractional PLL 600-900MHz, fixed divider 6
 * 150~300MHz fractional PLL 600-900MHz, fixed divider 4
Then there are two transitions of harmonics mode, 450MHz and 900MHz.
BTW 50KHz-100MHz is done using fixed PLL config, no need to test that.

BTW due to your PLL lock polling, code following comment "// Set PLL twice on changing from band ___" is superflous.

[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.