your comparison is invalid, just because you're trying to compare different loads with different electronic delay and didn't apply correction for this electronic delay difference.
But ogen trying to compare it with terminator which has much longer visual size. I think it's delay is about 20-30 picoseconds higher than NanoVNA cal-kit load.
Comparison was to demonstrate exactly that - "original terminator" have (longer) parasitic transmission line inside, yet you say that I shall compensate for it and basically void whole idea of demonstration
Attached R+jX
Problem 1
Setting the Center frequency to 750MHz, then set the Span to 1500MHz. Request the Frequency. The firmware returns only 100 data points rather than 101. I would expect the Nano to always send 101 data points. This problem is reproducible.
Problem 2
Setting the Start frequency to 0MHz, the Stop to 1MHz. Request the Frequency. The firmware returns a starting frequency of 10KHz rather than the expected 50KHz. The number of data points is correct. I would expect the Nano to limit the lower frequency to 50KHz, or there should be a document explaining that the lower limit is now 10KHz. This problem is reproducible.
Problem 3
Screen still leaving random artifacts from previous scan when using the Smith Chart. This problem is reproducible and appeared in the firmware that was supplied with my Nano. I have yet to see firmware that does not have this problem.
Problem 4
After programming the new firmware into the Nano and running a calibration, the calibration appeared corrupt. An open was on the left side of the screen and a short was on the right. Applying any load would be unstable when looking at the display. The frequency range was set to 0.05 to 900MHz prior to calibration. A reset was ran prior to calibration. Attempting to repeat the calibration corrected the problem. I have not attempted to repeat this condition.
clearconfig
Problem 5
Programming a start of 50KHz and an stop frequency of 1500MHz. Request the Frequency. The firmware returns the correct frequency for the first data point. Looking at higher frequencies, there is an error between various firmware. For example, some will report 1500 for the last data point where others report 1499.99995. For a given version of firmware, it will return predictable values. This problem is easy to reproduce.
R+jX measurement is very sensitive to electronic delay. Especially on high frequency. Before R+jX measurements, you're needs to setup proper electronic delay in the menu DISPLAY => SCALE => ELECTRICAL DELAY
Try this version, it solves your issues, allows to enter negative electronic delay and also improves precision for data transfer from NanoVNA to PC.
Just downloaded from your GH area and tried to build but once again get errors that it will not fit. I assume that the image was not built from what is uploaded.
There is one thing I notice with your code that seems unique that I find strange. I run a speed test where I make requests to the Nano and measure the response times. I start with the Frequencies command, sending it several times. I then switch to data 0. At the time I make this switch, with your code I will see the response time increase (about double) for the very first read.
I tried installing your couple of files. I placed cstartup.s in the compilers/IAR directory and the hal_i2s_lld.c in both SPIV1&2. It still errors out.
If you don't change start/stop/center/span frequencies, there is no need to repeat "frequencies" command. You can exectute "frequencies" command just once after start/stop/center/span frequency change. After that you can execute just data command in a loop.
I tried installing your couple of files. I placed cstartup.s in the compilers/IAR directory and the hal_i2s_lld.c in both SPIV1&2. It still errors out.
hal_i2s_lld.c needs to be replaced just in the folder ChibiOS\os\hal\ports\STM32\LLD\SPIv2\hal_i2s_lld.c
But actually, these are minor changes, and they should not affect build.
The error depends on tool chain
I could send more than one command while waiting for the Nano to respond. I could not do this with the data commands. At the time, it would not crash the Nano but it appeared to just not receive the commands.
/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/8.2.1-1.7.1/.content/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: region `flash0' overflowed by 584 bytes
collect2.exe: error: ld returned 1 exit status
make: *** [ChibiOS/os/common/startup/ARMCMx/compilers/GCC/rules.mk:243: build/ch.elf] Error 1
I had asked you about your regression tests that you mention but you chose not to discuss for what ever reason. I am still open to discussing and plan to continue to add to the complexity of my scripts.
/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/8.2.1-1.7.1/.content/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: region `flash0' overflowed by 584 bytes
collect2.exe: error: ld returned 1 exit status
make: *** [ChibiOS/os/common/startup/ARMCMx/compilers/GCC/rules.mk:243: build/ch.elf] Error 1
it seems that the code doesn't fit into STM32F072CB. First check that your tool chain uses 128 kB flash for this chip. The second you can play with optimization options. If it doesn't help, you can remove some commands. For example scan command duplicating sweep functionality, so you can comment it with #if 0 directive. Also remove it from the command list array.
This is known issue. The controller STM32F072CB has too small flash memory - just 128 kB. And you can find that other people also fighting with this limitation for NanoVNA.
This is why NanoVNA V2 uses more powerful controller, it has more memory, so it can handle more things
An odd side effect is that I no longer see the delay when the commands are switched like I show in the earlier plots.
One of the test cases I added was to set the start frequency to 1500 and the stop to 0. My old analog VNA has no way to scan backwards. Looking at my old HP3589A, it behaves similar to the Nano which basically reports it will scan from 10KHz to 10KHz with 101 samples. With my Signal Hound, when trying to set the stop lower than the stop, it will coerce the it to the maximum value. Any thought on if you will change how this works?
how PC USB scan data is made? It is separate scan which is not displayed on nanovna display? If so - is it possible to just readout buffer of completed scan?
how PC USB scan data is made? It is separate scan which is not displayed on nanovna display? If so - is it possible to just readout buffer of completed scan?The device performs sweep and render in a loop. The PC can request the current data of the sweep through USB and NanoVNA will send the last sweep data to PC.