NanoVNA Custom Software

[joeqsmith]

However wider spans with the same number of points take larger frequency steps. I wonder if the Si chip needs a longer time to settle when making larger frequency jumps? Maybe simply increasing the wait time prior to sampling will improve things in wide spans?

I wonder if this is part of the problem I saw with that last test.  I would assume most noticed that that data was always corrupt in the area leading up to 900MHz.  Once it reached 900, the data was stable.   Hopefully the people putting the firmware together are aware of these problems and are able to solve them.     

Possible explanation in nanovna-users@groups.io post:

hugen@...Aug 5   #719 
The si5351 manual shows that the internal VCO operates at a maximum of 900MHz and a 4-divide-frequency output with a maximum frequency of 225MHz. In order to output a frequency of 300MHz, the internal VCO needs to be overclocked to 1200MHz. Not every si5351 can be stably overclocked to 1200MHz. As the temperature increases, the internal VCO operating limit frequency of the si5351 will decrease. If you notice a significant spike(>0dB) in your nanoVNA at 300 MHz or 900 MHz, I recommend that you use the 800MHz firmware.

If you look at the data it's not a spike at 300/900 as this person describes.    It appears more like random noise leading up to 900MHz, then it clears up once it goes beyond 900MHz.  Considering the amount of time I ran below 900MHz without a problem,  I suspect it has something to do with the frequency range being swept  but I haven't had time to look into it further.   

I made an attempt to get the Windows tools setup, unsuccessfully. 

[OwO]

They mostly use flange mount connectors for internal modules, yet performance of those do not differ from edge-mount/edge-launch SMA connectors when latter are properly shielded. Manufacturers obviously just pick right connector and do not invent shielding transition for connector which is not made for such. Whatever. - Why don't use angled trough hole mount connectors then?

Yes so that is my point too; with these common edge mount connectors there is NO way to fully shield it, but all low cost VNAs (under $500) on the market uses these. The through hole SMA connectors have a worse problem - the center pin is long and sticks out which creates an antenna.
Be realistic and don't suggest milled enclosures. You know that is a no-go at this price point. We have to work with commodity parts with reasonable cost, so specialized connectors designed for shielding are also a no-go. If you think you can do a better job then go design and sell your own VNA.

That picture you posted is not the full two port version; the only pictures that exist of it are in a few kickstarter updates. You can see the shielding that covers the two SMA connectors, but even that's insufficient entirely because of that tiny slot between the connector body and the shield can. That is where they added a blob of solder in production.

[OwO]

The V2 PCB is 4 layers. The schematics will be posted soon, at the same time as the launch on taobao, but you can DM me if you want to see it right now.

[OwO]

Indeed. It is clear that he missed to put (legs of) connectors in the shield. Port1 and port2 have connector center legs, some components and quite a transmission line length in common cavity which is main enclosure. That is "no no". I will say it last time - shielding can of particular channel shall cover everything including legs of the connector.

How exactly do you put those things inside a shield? As I said earlier simply putting the shield over the connector legs is not sufficient (found experimentally), and you actually have to form a connection between the connector body and shield can body. It's easy to say "you must achieve this" but have you actually tried designing a fully shielded VNA while keeping BOM cost below $100 and have it be manufacturable? Point me to a VNA below $500 that does it correctly as you say. Or are you saying all low cost network analyzers on the market are crap?

Edit: so we are arguing the same point, which is that leakage from the SMA connector center pin trace is significant (assuming the PCB is designed correctly and everything else is shielded). Where I disagree is I think none of the edge mount SMA connectors on the market are actually fully shieldable, and that is why high end test equipment do not use edge mount connectors. If you can find me a picture of a shielded edge mount connector on a PCB that would be great.

[ogden]

Indeed. It is clear that he missed to put (legs of) connectors in the shield. Port1 and port2 have connector center legs, some components and quite a transmission line length in common cavity which is main enclosure. That is "no no". I will say it last time - shielding can of particular channel shall cover everything including legs of the connector.

How exactly do you put those things inside a shield?

For example - by using trough-hole mount angled connector (attach), mounting it from bottom side so legs can be fully covered by shield lid. If angled SMA for any reason cannot be used and you want to use ultracheap edge mount by all means - order shielding can lid with cutout for connector legs (read below).

The through hole SMA connectors have a worse problem - the center pin is long and sticks out which creates an antenna.

It is no concern considering that you put it's legs under shield. That 1mm does not do much for planned frequencies anyway, owner or naked nude virgins can cut it if any concerns. Siglent did not care about it in front connector board of VNA (picture you posted).

As I said earlier simply putting the shield over the connector legs is not sufficient (found experimentally), and you actually have to form a connection between the connector body and shield can body. It's easy to say "you must achieve this" but have you actually tried designing a fully shielded VNA while keeping BOM cost below $100 and have it be manufacturable? Point me to a VNA below $500 that does it correctly as you say.

NanoVNA-F. Only thing to improve - add EMI shielding braid between connector shield and can, or just generous amount of solder.

[hwalker]

OWO,
I haven't seen any info about what screen size the NanoVNA 2 will be using. Hugen has posted in the past about prototyping with a 3.5-inch LCD and I would expect something that size or larger to keep up with the nanoVNA-F that is now being sold.  Do you have any information you can share?

TKs, Herb

[radiolistener]

ISOLN --> what do I have to do here?

connect two 50 ohm terminators on both connectors.
If you don't have two, then connect one to CH1 and leave CH0 open.

THRU --> my guess is I straight connect CH1 to CH0?

yes

Why do I have to do a RESET first?

To clear old calibration and avoid mistake.

Am I correct that CAL should be performed using the same cables that will be used for measurement? Makes sense, because the length will/can determine phase shifts, right?

yes

[joeqsmith]

I had some time to play with the tool chain again.   I was able to rebuild Hugen79's source and program the image into the Nano using both a Windows 7 and Windows 10 system.  The VNA reports the same version and as expected has the same problems as the image I downloaded.   I was concerned about having a header with exposed pins hanging off the side and used these lower profile pins.   I thought about running it vertical and notching the case but decided to go this route instead.   

I spent some time reading the GNU license a few times along with the FAQ because I am sure that will come up at some point.   

[joeqsmith]

I tried several tests and it seems with my particular Nano,  it will always fail at the frequencies leading to 900MHz.  When sweeping below 900M, it seems to be VERY stable.   When sweeping above 900M, it appears I can change the start to any value and the data will become corrupt.   It seems to have nothing to do with my software (will happen stand alone).  It tried to straddle 300M, 600M and 800M with a 100M span and saw no problems.  It appears unique to 900M.   

It will be difficult to understand how they derived some of their code with the sparse comments.   It's also impossible for me to know if anyone else is seeing this problem.   I randomly tried a few things and it appears that the problem could be improved.   Shown with the original code (about 200 sweeps, several corrupt data sets) and last mods (roughly 1000 sweeps, first data set corrupt only.).     Note that I had replaced the filter with a thru and I am not using any sort of calibration.   Everything is set to the defaults with an 850 start and 950 stop.  If your's has this same problem it is easy to reproduce.  Just watch the screen for a few minutes.   

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.   

[radiolistener]

joeqsmith, I can suggest you to try the original NanoVNA firmware written by edy555:
https://github.com/ttrftech/NanoVNA

It works different. It seems that hugen79 removed some part of calibration calculations for some unknown reason. Also it uses different gain and frequency modes.

At a glance, original firmware from edy555 works with a much less noise. Also it seems more stable and has no flickering.

[ogden]

Just looked at (original) nanovna PCB to find out that decoupling capacitor is way too far from power pin, connecting trace is thin. This is popular decoupling error of many hobby projects using particular chip. In this application it may be critical. I suggest to add decoupling capacitor (sideways standing) between two red dots marked in attachment pic. I can't promise any performance improvements, yet you can try - who knows. There are few more improvements regarding si5351 which I would rather tell only in PM.

[edit] In case you are soldering sharpshooter, you can try to put decoupling cap directly between power and ground pins, they are pin7 & pin8.

[ogden]

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.

[Bicurico]

https://e2e.ti.com/blogs_/b/analogwire/archive/2019/08/23/so-what-is-a-vna-anyway?eloquaCampaignId=2522&utm_campaign=asc-dc-hsc-adc12dj5200RF-articleseries-wwe&utm_medium=email&utm_source=Eloqua#

[radioactive]

FWIW,  I just compiled the latest state of this repository  https://github.com/ttrftech/NanoVNA  .   I had to get rid of 32 bytes of "info" text to prevent overflow when compiling.  After installing the calibration was messed up.  I did a cal.   Looks great now.  No glitches.  I think the dynamic range @ 900 MHz might have improved.

[edit]  I've attached a binary if someone else wants to test this build.

[edit]  Forgot to mention a couple of other changes I made to compile the attached image:

Changed this:

Code: [Select]

static const I2SConfig i2sconfig = {
  NULL, // TX Buffer
  rx_buffer, // RX Buffer
  AUDIO_BUFFER_LEN * 2,
  NULL, // tx callback
  i2s_end_callback, // rx callback
  0, // i2scfgr
  2 // i2spr
};
To This:

Code: [Select]

static const I2SConfig i2sconfig = {
  NULL, // TX Buffer
  rx_buffer, // RX Buffer
  AUDIO_BUFFER_LEN * 2,
  i2s_end_callback, // rx callback
  0, // i2scfgr
  2 // i2spr
};
Also, in the Makefile:

Changed from:
USE_OPT = -O2 -ggdb -fomit-frame-pointer -falign-functions=16 --specs=nano.specs -fstack-usage
To This:
USE_OPT = -O2 -ggdb -fomit-frame-pointer -falign-functions=16

And from:
USE_PROCESS_STACKSIZE = 0x200
To This:
USE_PROCESS_STACKSIZE = 0x1a0

[edit]   I found that I needed to add D2 diode to get the new battery status indicator (added to repository on Sept 9th)  in this firmware working.   

[radiolistener]

radioactive, there is no need to make any changes in order to compile it with gcc. Probably you're using incorrect ChibiOS config

[radioactive]

radioactive, there is no need to make any changes in order to compile it with gcc. Probably you're using incorrect ChibiOS config

That may be true.  I was just documenting what I did.  The firmware image I attached is definitely better on my device.  I haven't seen any glitchy traces with this image.   That could just be all the new changes that are in the repository.  Once thing I could not get to compile was the I2SConfig struct as is.   

Here is the error:
main.c:448:3: note: (near initialization for 'i2sconfig.i2scfgr')
main.c:448:3: error: initializer element is not computable at load time
main.c:448:3: note: (near initialization for 'i2sconfig.i2scfgr')
main.c:450:3: warning: excess elements in struct initializer

I'm using 'gcc-arm-none-eabi-7-2018-q2-update' toolchain.

[edit]
The change I made to the struct was based on looking at the definition for that struct.   I'm not saying it definitely makes a difference or fixed any issues or even that it is correct.  I needed to change it to get it to compile though.

[joeqsmith]

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 believe this is the case.  There is a lock flag but they do not appear to use it.  Instead they appear to sprinkle delays in the code.  How these delays were calculated does not appear in the comments.   My simple view is that they should leverage that status bit but they may have some reason not to use it.  With the code not being well documented,  it's just a pure guess.

Looking  at the data I show where the unit starts to settle down, I am playing with the delays.

radioactive, there is no need to make any changes in order to compile it with gcc. Probably you're using incorrect ChibiOS config

This seems to be the case.  I just downloaded and it appears to build as is.  I have it running in the Nano now with no changes.   

[radioactive]

From:  ChibiOS/os/hal/templates/hal_i2s_lld.h

Code: [Select]

/**
 * @brief   Driver configuration structure.
 * @note    It could be empty on some architectures.
 */
typedef struct {
  /**
   * @brief   Transmission buffer pointer.
   * @note    Can be @p NULL if TX is not required.
   */
  const void                *tx_buffer;
  /**
   * @brief   Receive buffer pointer.
   * @note    Can be @p NULL if RX is not required.
   */
  void                      *rx_buffer;
  /**
   * @brief   TX and RX buffers size as number of samples.
   */
  size_t                    size;
  /**
   * @brief   Callback function called during streaming.
   */
  i2scallback_t             end_cb;
  /* End of the mandatory fields.*/
} I2SConfig;

Code in the main.c  in the repository:

static const I2SConfig i2sconfig = {
  NULL, // TX Buffer
  rx_buffer, // RX Buffer
  AUDIO_BUFFER_LEN * 2,
  NULL, // tx callback    This appears to be wrong to me
  i2s_end_callback, // rx callback
  0, // i2scfgr
  2 // i2spr
};

Again, it may not make any difference.  My thinking is that the version of gcc I'm using might be catching an error here.   What versions of gcc are you guys compiling with?

[joeqsmith]

Lastest firmware from edy555, showing 1700 sweeps, not a single glitch.     I have no idea if the software has other problems or improvements as I am only looking at this one test case.    I'll play around with this version of code as time permits.   

From the change log:

### v8.2.1-1.7.1 (2019-05-24)


 

[radioactive]

The reason I reverted back to using gcc-arm-none-eabi-7-2018-q2-update:
https://community.arm.com/developer/tools-software/oss-platforms/f/gnu-toolchain-forum/13503/gcc-g-version-8-very-slow-to-compile

Version 8 was painfully slow for a project I'm working on.  They say it will be fixed in the next release.

[radiolistener]

The change I made to the struct was based on looking at the definition for that struct.   I'm not saying it definitely makes a difference or fixed any issues or even that it is correct.  I needed to change it to get it to compile though.

it seems that you're used SPIv1 instead of SPIv2

[radiolistener]

From:  ChibiOS/os/hal/templates/hal_i2s_lld.h

you're needs to use ChibiOS\os\hal\ports\STM32\LLD\SPIv2\hal_i2s_lld.h

[ogden]

Lastest firmware from edy555, showing 1700 sweeps, not a single glitch.     I have no idea if the software has other problems or improvements as I am only looking at this one test case.    I'll play around with this version of code as time permits.   

Is it possible to rotate graph such a way to properly read vertical scale? Seems like it is more than 0dB at around 880MHz.. What is this? Measurement of bandpass filter or just noise floor? If noise floor then I'll pass on such VNA

[radioactive]

From:  ChibiOS/os/hal/templates/hal_i2s_lld.h

you're needs to use ChibiOS\os\hal\ports\STM32\LLD\SPIv2\hal_i2s_lld.h

Sorry,  the file I posted before was not the one I was using.  I am using ChibiOS\os\hal\ports\STM32\LLD\SPIv2\hal_i2s_lld.h,   but the problem I'm describing is still the same:

Trying to fit this from main.c :

Code: [Select]

static const I2SConfig i2sconfig = {
  NULL, // TX Buffer                  //(1)    tx pointer
  rx_buffer, // RX Buffer            //(2)    rx pointer
  AUDIO_BUFFER_LEN * 2,        //(3)    size_t
  NULL, // tx callback                //(4)    tx pointer   (this looks wrong)
  i2s_end_callback, // i2s callback    //(5)    i2s_end_callback pointer
  0, // i2scfgr                 //(6)      int16
  2 // i2spr                    //(7)         int16
};
Into this:  (original comments removed to make it easier to see the types)
ChibiOS\os\hal\ports\STM32\LLD\SPIv2\hal_i2s_lld.h

typedef struct {
  const void                *tx_buffer;       //(1)    tx pointer
  void                      *rx_buffer;          //(2)     rx pointer
  size_t                    size;                   //(3)      size_t
  i2scallback_t             end_cb;      //(4)      i2scallback   end_cb  pointer
  int16_t                   i2scfgr;             //(5)      i2scfgr  int16
  int16_t                   i2spr;               //(6)       i2spr   int16
} I2SConfig;

It might work anyway.  Or it might compile, but not be what was intended being stuffed in there.  I haven't tried to analyze it much more than that.   This is why I got the compiler error.   There are 7 elements in the initializer,  but the struct definition only has 6 elements.   Am I missing something here?

Anyway,  I'll leave it at that.   I reverted all the changes I made from previous versions of the repository (when I first got the device).   Everything from the current repository state compiles (I haven't tested an image this way yet) with gcc 7.xx, but not this error.

[Bicurico]

How do I flash these BIN files?

It should be a DFY file...

When I compiled the sources I got the BIN myself, but was not able to flash it?

Thanks,
Vitor