NanoVNA Custom Software

[ogden]

It seems you are unable to understand that I had ran tests at 300MHz before your posting about it. 

Speaking of ability to understand: had you let VCO jump from < 900MHz frequency to >= 1100 MHz in those tests "at 300MHz"? Hint: you did not. So if you don't want to verify what I say - fine. What is not fine - passive aggressive insults.

It is obviously for you to decide - you want to waste your precious time checking something that comes from random d00d in the forum or not.

You don't have one to test and this is the comment you come up with.       

Since when owning one became criteria to post in this thread? 

[joeqsmith]

It seems you are unable to understand that I had ran tests at 300MHz before your posting about it. 

Speaking of ability to understand: had you let VCO jump from < 900MHz frequency to >= 1100 MHz in those tests "at 300MHz"? Hint: you did not. So if you don't want to verify what I say - fine. What is not fine - passive aggressive insults.

It is obviously for you to decide - you want to waste your precious time checking something that comes from random d00d in the forum or not.

You don't have one to test and this is the comment you come up with.       

Since when owning one became criteria to post in this thread? 

What I have presented was the test case where I was able to replicate the problem.  I expect it's obvious to most people that this would not include all test cases ran.   

If you had a Nano, and a specific test case that was causing you problems, I would invest the time to try and replicate it.   I am not interested in wasting my time investigating your wild guesses of what you feel may be a problem.   

[Bicurico]

https://www.aliexpress.com/item/33010508546.html?spm=a2g0o.productlist.0.0.41987b1ff0XwgM

Is this the new device?

Does it have a spectrum analyzer mode, too?

Regards,
Vitor

[ogden]

I am not interested in wasting my time investigating your wild guesses of what you feel may be a problem.

Right. It is so incredibly hard to set other start/stop frequencies, run test again.    Oh and BTW instability of some overclocked si5351 is widely known, hold your horses naming it as my guess. Dont even bother to waste your time answering.

[radioactive]

joeqsmith,

Would you mind comparing the results from this firmware image to the plots you just posted?
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2709596/#msg2709596   (latest edy555 source with older ChibiOS)

If I compare the hugen firmware with the edy555, I do see a difference in the data.   The edy firmware appears to be less stable overall with more noise.  The transition over the 900MHz crossover point it not as smooth.    However, it doesn't seem to send corrupt data like the hugen firmware. 

I would describe what I've observed about the same.  The image with the older ChibiOS (above link) appears to have cleared up the glitchy traces as seen in the hugen image (I assume was shipped with my device), but looks like it is better data than either the current edy555 image (latest ChibiOS) or image that shipped with the unit I'm testing as it was shipped.  Unfortunately, I accidentally deleted the firmware image that it shipped with even though I had backed it up.  I have no idea what version, etc it was now.

[edit]
After more testing, no doubt about it for me now.  The latest edy555 firmware, but with old ChibiOS (master branch) is definitely the way to go on my device.  That was a nice accident.

Using your build, I ran a few more sweeps than the edy555 with the same test setup.   It appears very similar to the image I had just built from Git.  It did not glitch, has the same harsh transition and roughly the same noise.   I may have to add some metric tracking to my software.   

What is really odd, is obviously this is a new day with a whole new install.  Note how that same pattern immerges at roughly the same sweep.   Chances of that happening by chance would be zero.  I wonder if there is something happening in the firmware at these times that causes the pattern. It would be roughly synced up with the power on, or reset. 

Thanks for testing that.  I may have been on the wrong track with older/newer ChibiOS.   I loaded up the latest  edy555 + latest ChibiOS this morning again and it looks great.  I'm just visually comparing sweeps on a bandpass filter over time.  Yesterday, it seemed there was a clear difference.  This morning,  they look the same.  I may start logging sweeps as well so I can do a better comparison.

[hwalker]

Vitor wrote ...
"Is this the new device?"
---------------------------------------------

Vitor,

The device you linked to is not the V2 design.  V2 will come from Hugen who first retailed the nanoVNA device based on the edy555 open source project.  I gleaned the following information from earlier posts in this user group regarding nanoVNA version 2.

1. The nanoVNA will eventually reach 3GHz (and at a similar price to version 1).
2. It's going to be based on the adf4350 + si5351.
3. The 3 mixers are replaced with one higher spec mixer (ad8342) that is switched between the 3 channels.
4. A variable gain amplifier is added at baseband using one opamp and switched feedback resistors for improved dynamic range.
5. The Audio codec is removed and the stm32 built in ADC is used instead.
6. The performance should be comparable or better to V1.
7. Info about the baseband VGA design:  A RFIC switch is used to switch the shunt resistor in the feedback path. The switch is basically "transparent" because the off state capacitance is in the femtofarad range (it is an RF switch) which is negligible at the IF frequency. The on state resistance is small compared to the resistors being switched in. Since the amplifier gain is mainly dictated by the feedback network, and the switch is "transparent", there is nothing other than the tempco of the physical resistors that can cause a temperature dependence. The RFIC used is the same as for the receiver RF switch, and it turns out all the maxscend switches do not have the shunt diode problem (most RF switch ICs have parasitic diodes from RF input to ground which will start to conduct at lower frequencies), so it has no theoretical lower frequency limit and can be applied at the IF frequency. This is a big improvement over using normal analog switch ICs which have capacitance in the pF range.
8. Info about linearity: The code will perform a calibration of each VGA step on boot up. Since there is no temperature dependence the calibration only needs to happen once.
9. The V2 PCB is 4 layers.
10. The schematics will be posted to GitHub, at the same time as the launch on taobao,
11. Design objectives include keeping BOM cost below $100 and compatibility with current software base.

A member of this forum, located in China, indicated that the schematics are available now but only via private request.  I haven't seen any leaked info regarding screen size, but Hugen has posted in the past about prototyping with a 3.5-inch LCD.  I would expect something that size or larger to keep pace with the nanoVNA-F that is already being marketed.  To distinguish itself from the nanoVNA-F, it will most likely be marketed as the nanoVNA-H or nanoVNA-H V2.

Herb

[joeqsmith]

I am not interested in wasting my time investigating your wild guesses of what you feel may be a problem.

Right. It is so incredibly hard to set other start/stop frequencies, run test again.    Oh and BTW instability of some overclocked si5351 is widely known, hold your horses naming it as my guess. Dont even bother to waste your time answering.

It's not hard at all to setup these tests and run them, but once they have been ran, there is no reason to waste time repeating them.

[joeqsmith]

joeqsmith,

Would you mind comparing the results from this firmware image to the plots you just posted?
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2709596/#msg2709596   (latest edy555 source with older ChibiOS)

If I compare the hugen firmware with the edy555, I do see a difference in the data.   The edy firmware appears to be less stable overall with more noise.  The transition over the 900MHz crossover point it not as smooth.    However, it doesn't seem to send corrupt data like the hugen firmware. 

I would describe what I've observed about the same.  The image with the older ChibiOS (above link) appears to have cleared up the glitchy traces as seen in the hugen image (I assume was shipped with my device), but looks like it is better data than either the current edy555 image (latest ChibiOS) or image that shipped with the unit I'm testing as it was shipped.  Unfortunately, I accidentally deleted the firmware image that it shipped with even though I had backed it up.  I have no idea what version, etc it was now.

[edit]
After more testing, no doubt about it for me now.  The latest edy555 firmware, but with old ChibiOS (master branch) is definitely the way to go on my device.  That was a nice accident.

Using your build, I ran a few more sweeps than the edy555 with the same test setup.   It appears very similar to the image I had just built from Git.  It did not glitch, has the same harsh transition and roughly the same noise.   I may have to add some metric tracking to my software.   

What is really odd, is obviously this is a new day with a whole new install.  Note how that same pattern immerges at roughly the same sweep.   Chances of that happening by chance would be zero.  I wonder if there is something happening in the firmware at these times that causes the pattern. It would be roughly synced up with the power on, or reset. 

Thanks for testing that.  I may have been on the wrong track with older/newer ChibiOS.   I loaded up the latest  edy555 + latest ChibiOS this morning again and it looks great.  I'm just visually comparing sweeps on a bandpass filter over time.  Yesterday, it seemed there was a clear difference.  This morning,  they look the same.  I may start logging sweeps as well so I can do a better comparison.

No problem.   I would need to add software to try and characterize the differences as I can't tell from just visually looking at the data that there is any difference.   Of course, there could be other differences if we start to run other test cases.    Good to hear that you are seeing the same thing.   I have wondered how temperature effects it.  This time of the year, our house stays fairly stable.  Maybe something like this caused your results to change.   

[radiolistener]

joeqsmith, there is fixed bug with S21 calibration in edy555 firmware, I recommend to update.

[ebclr]

Do anybody have experience with this unit ?

[joeqsmith]

joeqsmith, there is fixed bug with S21 calibration in edy555 firmware, I recommend to update.

I had seen that release and was going to download it just now but saw they had updated it again a couple of hours ago.  Doing a diff on Main.c, it appears they may be trying to fix the artifact problems I was seeing with the graphics.   

Looking at the hugen area, there appears to be no new changes.   Depending how you use the Nano, it may be worth it to wait a few weeks and see if it becomes more stable.   I wonder if they perform some sort of automated regression test before releasing the code to the public or if they rely on the users to test their code for them.

[xrunner]

Been following this thread - thanks for the info. I just got a NanoVNA yesterday, so far it's pretty impressive. Matches the return loss plot of my ham bands fan dipole using a Rigol DSA815-TG.

I did use the dfu utility to update the firmware and it went well - I used this file -

NanoVNA-H__900_ch_20190924.dfu

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