NanoVNA Custom Software

[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

[radiolistener]

How do I flash these BIN files?

with ST-LINK

[radiolistener]

Into this:  (original comments removed to make it easier to see the types)

you're looking wrong file. Here is struct definition from ChibiOS\os\hal\ports\STM32\LLD\SPIv2\hal_i2s_lld.h
(I removed comments):

Code: [Select]

typedef struct {
  const void                *tx_buffer;
  void                      *rx_buffer;
  size_t                    size;
  i2scallback_t             tx_end_cb;
  i2scallback_t             rx_end_cb;
  int16_t                   i2scfgr;
  int16_t                   i2spr;
} I2SConfig;

here is init in the main.c:

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
};

This is original code with no changes and initialization fit with struct declaration.

[joeqsmith]

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

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.

Your .h file and the .h file I have are not the same or I am looking at the wrong file, which is possible. 

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 of TX.
   */
  i2scallback_t             tx_end_cb;
  /**
   * @brief   Callback function called during streaming of RX.
   */
  i2scallback_t             rx_end_cb;
  /* End of the mandatory fields.*/
  /**
   * @brief   Configuration of the I2SCFGR register.
   * @details See the STM32 reference manual, this register is used for
   *          the I2S configuration, the following bits must not be
   *          specified because handled directly by the driver:
   *          - I2SMOD
   *          - I2SE
   *          - I2SCFG
   *          .
   */
  int16_t                   i2scfgr;
  /**
   * @brief   Configuration of the I2SPR register.
   * @details See the STM32 reference manual, this register is used for
   *          the I2S clock setup.
   */
  int16_t                   i2spr;
} I2SConfig;

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

Sure I can rotate to show the scale.   You are correct, this is indeed a BP filter.  I'm really just looking for the Nano to send up some corrupt data.   I'll try running a few other tests with it.   This version does appear a little slower (I am not currently measuring the Nano's response time)  which I guess would make some sense if they are slowing down the scan to make it more stable.     

[radioactive]

Your .h file and the .h file I have are not the same or I am looking at the wrong file, which is possible. 

I see what is going on.  I'm using the master branch for ChibiOS sub-module.
https://github.com/edy555/ChibiOS/blob/master/os/hal/ports/STM32/LLD/SPIv2/hal_i2s_lld.h

You are probably using this one:
https://github.com/edy555/ChibiOS/blob/669d4bbc8da1ee0e4ccdf93a472b06d183922320/os/hal/ports/STM32/LLD/SPIv2/hal_i2s_lld.h

Thanks.  That explains that.   I'll try that out.    When I pulled the NanoVNA --recursive for the submodules,  I got an error.  I just cloned the referred ChibiOS manually.


[edit]
That was it.  I can compile the latest source without any issues now.  I've attached a binary of that.   However,  after testing it for a bit,  I noticed that the traces did not look near as good as the binary I created from the older ChibiOS source earlier today.   I'll do some more testing, but if someone else can compare the two images, it would be appreciated. 

[hwalker]

Bicurico,
If you are using the DfuSeDemo program on Windows to change firmware, then you have to first convert the "BIN" file to a "DFU" file.  The "BIN" format is useable on LINUX and Apple systems  using a command-line utility.  Both formats are released together by some Moders as a convenience.  I believe the DfuFileMgr program can be used to perform the conversion but I'm not certain.

Herb

[joeqsmith]

Your .h file and the .h file I have are not the same or I am looking at the wrong file, which is possible. 

I see what is going on.  I'm using the master branch for ChibiOS sub-module.
https://github.com/edy555/ChibiOS/blob/master/os/hal/ports/STM32/LLD/SPIv2/hal_i2s_lld.h

You are probably using this one:
https://github.com/edy555/ChibiOS/blob/669d4bbc8da1ee0e4ccdf93a472b06d183922320/os/hal/ports/STM32/LLD/SPIv2/hal_i2s_lld.h

Thanks.  That explains that.   I'll try that out.    When I pulled the NanoVNA --recursive for the submodules,  I got an error.  I just cloned the referred ChibiOS manually.


[edit]
That was it.  I can compile the latest source without any issues now.  I've attached a binary of that.   However,  after testing it for a bit,  I noticed that the traces did not look near as good as the binary I created from the older ChibiOS source earlier today.   I'll do some more testing, but if someone else can compare the two images, it would be appreciated.

Good to hear we are now on the same page. 

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. 

Both firmware shown with latest build.  Both are stock, just clean builds from Git.   Both are shown with the same 10dB attenuator being swept from 850 - 950MHz.   Note that I only ran about half as many sweeps with the hugen firmware.  You can also see the hugen firmware glitching as before as the frequency is be swept to the 900MHz switch point and then recovering.   You can also see that the edy firmware once again is glitch free.   

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

[ogden]

Someone shall try to contact hugen, huh?

BTW you guys are testing same range again and again, 850-950. It's deep into "out of spec" range. I wonder how glitchty firmware performs in 570-950 range. Exact numbers are important because "roll over" frequency is within specs (<=225Mhz), 570/3=190, 950/5=190.

[Bicurico]

Bicurico,
If you are using the DfuSeDemo program on Windows to change firmware, then you have to first convert the "BIN" file to a "DFU" file.  The "BIN" format is useable on LINUX and Apple systems  using a command-line utility.  Both formats are released together by some Moders as a convenience.  I believe the DfuFileMgr program can be used to perform the conversion but I'm not certain.

Herb

That was it!

I did not notice there was a separate DfuFileMgr. It allows to convert from BIN to DFU, which is much more convenient than using STLink.

Regards,
Vitor

[joeqsmith]

Someone shall try to contact hugen, huh?

BTW you guys are testing same range again and again, 850-950. It's deep into "out of spec" range. I wonder how glitchty firmware performs in 570-950 range. Exact numbers are important because "roll over" frequency is within specs (<=225Mhz), 570/3=190, 950/5=190.

I thought I was clear about the reason I was using this particular range:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2703604/#msg2703604
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2708874/#msg2708874

If not, I'll try to consolidate my findings into this single post for you. 

Running older versions of firmware (I would have no idea what version as they are not clearly marked), the Nano would send up corrupt data at seemingly random times.   Slowing down how fast my software requests data from the Nano improved this.   The corrupt data was not correlated with any specific frequency ranges.   Also, making requests too fast could cause the Nano to white screen which required a power cycle to recover.   I saw the same corrupt data when using their included software.

I then installed some later version of the hugen firmware.  This appeared to completely solve the corrupt data.   I ran several tests over a few days and never saw a single corrupt packet, however, I limited my frequency range to 900MHz.      I then started to run some tests above 900M and discovered it would once again send corrupt packets.  This was independent from how fast I requested the data, or for that matter, it would happen without using any software.   This area was always at the 900MHz switch point.   

Current testing with the latest edy555 firmware is being ran in that same frequency range as that is the only place I have seen a problem. 

Now, if others including yourself are having similar problems in other ranges, I would have no way of knowing unless you posted about it.  If you are having problems at specific ranges, you should post the ranges, the version of firmware you are using and maybe screen shots of your results.   I could then attempt to replicate your findings.   As I said, I only have the one Nano and it's very possible that this one is unique in how it behaves. 

I have not tried to contact anyone outside of this forum.  The main reason is again, I only have one test point (one Nano) and as I said, if the problem in unique to this one unit, it's hardly worth going after.   

[ogden]

This area was always at the 900MHz switch point.   

To reiterate, 300 and 900MHz crossing points are critical. When crossing 900MHz mark, internal VCO is stepping from (899/3)*4 = 1198.66 MHz to (900/5)*4= 720MHz. Note that max specified freq of internal VCO is 900MHz. Jumping into 850MHz (of your choice) shall be considered for PLL as "tricky to lock" because it is still deep into overclock range. That's why I asked about "safe" 570-950Mhz range. 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.

Now, if others including yourself are having similar problems in other ranges

Thing is I do not have nanovna. Not yet. It is up-to you guys

[joeqsmith]

This area was always at the 900MHz switch point.   

To reiterate, 300 and 900MHz crossing points are critical. When crossing 900MHz mark, internal VCO is stepping from (899/3)*4 = 1198.66 MHz to (900/5)*4= 720MHz. Note that max specified freq of internal VCO is 900MHz. Jumping into 850MHz (of your choice) shall be considered for PLL as "tricky to lock" because it is still deep into overclock range. That's why I asked about "safe" 570-950Mhz range. 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.

Now, if others including yourself are having similar problems in other ranges

Thing is I do not have nanovna. Not yet. It is up-to you guys

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

It tried to straddle 300M, 600M and 800M with a 100M span and saw no problems.  It appears unique to 900M.   

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.       

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