Into this: (original comments removed to make it easier to see the types)
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;
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
};
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.hQuotetypedef 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.
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
Your .h file and the .h file I have are not the same or I am looking at the wrong file, which is possible.
QuoteYour .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.
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.
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
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.
This area was always at the 900MHz switch point.
Now, if others including yourself are having similar problems in other ranges
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.QuoteNow, if others including yourself are having similar problems in other rangesThing is I do not have nanovna. Not yet. It is up-to you guys
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.
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)QuoteIf 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.
It seems you are unable to understand that I had ran tests at 300MHz before your posting about it.
QuoteIt 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.
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.QuoteQuoteIt 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?
I am not interested in wasting my time investigating your wild guesses of what you feel may be a problem.
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)QuoteIf 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.
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.
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)QuoteIf 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.
joeqsmith, there is fixed bug with S21 calibration in edy555 firmware, I recommend to update.