Author Topic: NanoVNA Custom Software  (Read 468965 times)

0 Members and 1 Guest are viewing this topic.

Online radiolistener

  • Super Contributor
  • ***
  • Posts: 3430
  • Country: ua
Re: NanoVNA Custom Software
« Reply #450 on: September 26, 2019, 08:11:50 pm »
How do I flash these BIN files?

with ST-LINK
 

Online radiolistener

  • Super Contributor
  • ***
  • Posts: 3430
  • Country: ua
Re: NanoVNA Custom Software
« Reply #451 on: September 26, 2019, 08:19:22 pm »
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.
 

Offline joeqsmithTopic starter

  • Super Contributor
  • ***
  • Posts: 11780
  • Country: us
Re: NanoVNA Custom Software
« Reply #452 on: September 26, 2019, 08:35:49 pm »

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

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

Offline radioactive

  • Regular Contributor
  • *
  • Posts: 173
  • Country: us
Re: NanoVNA Custom Software
« Reply #453 on: September 26, 2019, 09:35:51 pm »
Quote
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. 
« Last Edit: September 26, 2019, 10:27:35 pm by radioactive »
 

Offline hwalker

  • Contributor
  • Posts: 45
  • Country: us
Re: NanoVNA Custom Software
« Reply #454 on: September 26, 2019, 11:17:26 pm »
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
 

Offline joeqsmithTopic starter

  • Super Contributor
  • ***
  • Posts: 11780
  • Country: us
Re: NanoVNA Custom Software
« Reply #455 on: September 26, 2019, 11:53:58 pm »
Quote
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.   

Offline radioactive

  • Regular Contributor
  • *
  • Posts: 173
  • Country: us
Re: NanoVNA Custom Software
« Reply #456 on: September 27, 2019, 05:28:24 am »
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)

Quote
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.
« Last Edit: September 27, 2019, 06:43:22 am by radioactive »
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: NanoVNA Custom Software
« Reply #457 on: September 27, 2019, 09:24:39 am »
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.
 

Offline Bicurico

  • Super Contributor
  • ***
  • Posts: 1716
  • Country: pt
    • VMA's Satellite Blog
Re: NanoVNA Custom Software
« Reply #458 on: September 27, 2019, 10:00:07 am »
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

Offline joeqsmithTopic starter

  • Super Contributor
  • ***
  • Posts: 11780
  • Country: us
Re: NanoVNA Custom Software
« Reply #459 on: September 27, 2019, 11:08:37 am »
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.   

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: NanoVNA Custom Software
« Reply #460 on: September 27, 2019, 11:41:31 am »
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.

Quote
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 ::)
« Last Edit: September 27, 2019, 11:43:34 am by ogden »
 

Offline joeqsmithTopic starter

  • Super Contributor
  • ***
  • Posts: 11780
  • Country: us
Re: NanoVNA Custom Software
« Reply #461 on: September 27, 2019, 12:01:32 pm »
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.

Quote
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. 
Quote
It tried to straddle 300M, 600M and 800M with a 100M span and saw no problems.  It appears unique to 900M.   

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

Offline joeqsmithTopic starter

  • Super Contributor
  • ***
  • Posts: 11780
  • Country: us
Re: NanoVNA Custom Software
« Reply #462 on: September 27, 2019, 12:09:51 pm »
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)

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

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: NanoVNA Custom Software
« Reply #463 on: September 27, 2019, 12:43:10 pm »
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.

Quote
Quote
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.  :palm:     
Since when owning one became criteria to post in this thread?  :-DD
« Last Edit: September 27, 2019, 01:11:18 pm by ogden »
 

Offline joeqsmithTopic starter

  • Super Contributor
  • ***
  • Posts: 11780
  • Country: us
Re: NanoVNA Custom Software
« Reply #464 on: September 27, 2019, 01:37:43 pm »
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.

Quote
Quote
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.  :palm:     
Since when owning one became criteria to post in this thread?  :-DD

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.   

Offline Bicurico

  • Super Contributor
  • ***
  • Posts: 1716
  • Country: pt
    • VMA's Satellite Blog
Re: NanoVNA Custom Software
« Reply #465 on: September 27, 2019, 02:18:07 pm »
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

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: NanoVNA Custom Software
« Reply #466 on: September 27, 2019, 02:33:16 pm »
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.  :blah: :blah:  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.
« Last Edit: September 27, 2019, 03:35:57 pm by ogden »
 

Offline radioactive

  • Regular Contributor
  • *
  • Posts: 173
  • Country: us
Re: NanoVNA Custom Software
« Reply #467 on: September 27, 2019, 03:08:23 pm »
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)

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

Offline hwalker

  • Contributor
  • Posts: 45
  • Country: us
Re: NanoVNA Custom Software
« Reply #468 on: September 27, 2019, 03:36:00 pm »
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
 
The following users thanked this post: joh, ogden

Offline joeqsmithTopic starter

  • Super Contributor
  • ***
  • Posts: 11780
  • Country: us
Re: NanoVNA Custom Software
« Reply #469 on: September 27, 2019, 10:02:45 pm »
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.  :blah: :blah:  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.

Offline joeqsmithTopic starter

  • Super Contributor
  • ***
  • Posts: 11780
  • Country: us
Re: NanoVNA Custom Software
« Reply #470 on: September 27, 2019, 10:08:06 pm »
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)

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


Online radiolistener

  • Super Contributor
  • ***
  • Posts: 3430
  • Country: ua
Re: NanoVNA Custom Software
« Reply #471 on: September 28, 2019, 04:32:19 am »
joeqsmith, there is fixed bug with S21 calibration in edy555 firmware, I recommend to update.
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2328
  • Country: 00
Re: NanoVNA Custom Software
« Reply #472 on: September 28, 2019, 07:51:58 am »
Do anybody have experience with this unit ?



 

Offline joeqsmithTopic starter

  • Super Contributor
  • ***
  • Posts: 11780
  • Country: us
Re: NanoVNA Custom Software
« Reply #473 on: September 28, 2019, 04:27:45 pm »
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.

Online xrunner

  • Super Contributor
  • ***
  • Posts: 7526
  • Country: us
  • hp>Agilent>Keysight>???
Re: NanoVNA Custom Software
« Reply #474 on: September 28, 2019, 04:41:19 pm »
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
I told my friends I could teach them to be funny, but they all just laughed at me.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf