This is a firmware based on the original Edy555 firmware with some small changes
- Upper frequency limit is increased to 1500MHz. Be aware accuracy decreases rapidly above 900MHz
- A "scan" console command is added to allow arbitrary sweeps with arbitrary number of points
- The stack sizes of the two main threads have been adjusted for increased robustness.(thanks to david mugridge )

https://groups.io/g/nanovna-users/files/NanoVNA%20PC%20Software/TAPR%20VNA/NanoVNA%20with%20scan%20and%201500MHz.zip

Hello erik,
Thank you for the firmware extension.
I have tried to flash your firmware under MacOS:

$ dfu-util -v -d 0483:df11 --alt 0 -D NanoVNA_with_scan-and_1500MHz.dfu
But I got the error:
dfu-util: Error: File ID 0483:0000 does not match device (0483:df11 or 0483:df11)

What can I do to fix it?
73, Rudi DL5FA

the id in Erik's firmware is 0483:0000, so you can convert it, or try to pgm with -d 0483:0000, or take the attached version

Hello tinhead,
Thank you very much for the file with the original USB ID 0483:df11.
The flashing now works.

Just a question, how can you convert the USB ID in a .dfu file?

73, Rudi DL5FA

i'm on windows, so have different tools (DfuFileMgr.exe), for you "dfu-tool set-product somefirmware.dfu df11" should work

Hello erik, Rune and tinhead,

Thank you very much for the quick help.

I could calibrate (hopefully) the nanoVNA-1500 board.
See the attached photo nanoVNA-1500_Through_LCD_DSC08128.jpg

The python3 program nanoVNA-saver 0.0.9 from Rune also works with the 1500 firmware,
see the screen shot nanoVNA-saver-1500-Through.png

Now it needs further testing.

i'm on windows, so have different tools (DfuFileMgr.exe), for you "dfu-tool set-product somefirmware.dfu df11" should work

Hello tinhead,
Thank you for the hint.

I found the following web page:
https://github.com/myriadrf/LMS8001-Companion/tree/master/drivers/STM32_DFU/tools/DfuSe%20v3.0.5/Bin
I could download "DFUFileMgr.exe" and the accompanied DLL files.
Also needed are "MFC120-dll" and "MSVCR120.dll" which I found in the internet.

Running "DFUFileMgr.exe" under windows 10 I could read in the DFU file from erik "NanoVNA_with_scan-and_1500MHz_erik.dfu"
and export as a binary file. Then I read in the binary file, added the USB product ID "DF11" and saved as a .dfu file.
Unfortunately the header in the exported file was changed, so the CRC at the file end does not match your file "NanoVNA_with_scan_and_1500MHz_tinhead.dfu"

How did you manage to change the USB product ID only and update the CRC without changing the file header?

73, Rudi DL5FA

convert to hex, save it, open hex and convert to dfu

Hello tinhead,

Thank you very much for the hint.
When you convert with DfuFileMgr.exe intermediate to HEX you avoid to enter a start address in case of the BIN format.
That makes it easier to add the USB device ID "DF11" to file "NanoVNA with scan and 1500MHz.dfu" from erik.

Because of the different file path, the CRC is different.
But if the byte length is equal, then it should be OK.

73, Rudi DL5FA

Hi Erik,

Thanks for the firmware update.
Have tested it a bit, and seems to be working fine, of course with reduced
accuracy in the high end.. (would be nice with some averaging now, but
guess there might not be enough memory for that)

But I think there is a bug using the jog-switch, when I move the cursor
with it, first time is ok, but second or third or fourth time using it, the
NanoVNA locks up. Only power off/on restores it. Also tried to use
NanoVNA-Saver when it was frozen, and as expected it did not manage to do
anything.


BR,
Askild

I did an update yesterday because I made an error in the stack setting. Build time (as you can see in the info screen) 15-9-2019, 10:13
For me the cursor is working now
When did you download?
Inside the config menu there is a dfu command to boot the nanoVNA in boot load mode. No need for jumper setting

It would be really nice if NanoVNA firmware had an identifier in the "info"
text that identified the software, not just the build time - for example to
be able to set reasonable start/stop frequency limits, as well as whether
to use the "scan" command or not.

--
Rune / 5Q5R

Ok, thanks for the update, I will check it out.. I used anolder version..

Erik where is the 1500 Mhz code?

Thx
Dana

Hi Eric;

Nice job with the extended range, plus the other added features. It mostly works OK, and as stated earlier; it interfaces nicely with NanoVNA Saver. Kudos to Rune also on his "beyond the call" value added effort.

There appears to be a bug in the calibration... at least in my case... While attempting to perform a 2-port 50 kHz to 30 MHz local cal (not via one of the Windows GUIs), The corrected S21 data plots consistently in excess of -6 dB after several cal attempts, and I'm unable to toggle the correction on and off. I've checked my cables, and this wasn't an issue with my original firmware install, so I'm pretty certain it's something in the firmware. I'm going to reflash the firmware tomorrow, but I don't suspect a bad install would do something wrong consistently and not eventually crash. :-)

Has anybody else been putting this extended range firmware through its paces and observed something similar?


--
72/73

Gary, N3GO

On Tue, Sep 17, 2019 at 03:44 PM, Dana Shtun wrote:

Erik where is the 1500 Mhz code?

https://github.com/erikkaashoek/NanoVNA

Hi again Erik;

My apologies for misspelling your name on my earlier post. :-O

I re-flashed the 1500 MHz firmware this morning, and have observed no change in behavior. To ensure I'm not on a different page, the firmware build date I'm working with is Sep 14, 2019 - 10:38:20.

The re-flash also confirmed that the DFU software switch works fine, so the update was effortless. I also like that you implemented it as a two step process. I seem to have a propensity to accidentally touch something I shouldn't touch and send the device chasing its tail to places unknown. I often experience many restarts before I get to where I need to be. LOL! The Touch screen cal routine seems to work OK also.

I've been trying to get a better handle on the errors I'm seeing here, so it might be useful if I share what I think I have found that might help with debug... or maybe inspire some definitions to ensure my measurements are valid.

I reduced the display to a single trace... Only to keep my wits about me and not lead me off onto a tangent.... I stepped through each of the display formats in both cal and uncal modes and for both channels to verify expected results.

In channel O, LogMag and phase look fine. CH1 LogMag looks like indeterminate reflection data rather than gain (i.e. S22 vs S21).
Delay is not functional at all (in either CH0 or CH1 and the display is fixed at 1.0 seconds in both channels .
Smith, SWR, Polar, and linear all look OK.

I began to get inconsistent data when I began investigating the Real and Imag displays, so I tried a number of things to establish a starting point and baseline. Too much variability in those results to attempt mapping the process and incremental results here. The net of what I think is contributing to this is that the data is somehow getting corrupted when making display changes. I also discovered that Recall/Save now supports Recall only. Save is no longer an option perhaps? I am able to navigate to the Cal setup menu to initiate a Save when I wish to move stored data positions (Store 3 to Store 0 for example). This works OK so far, and as long as I don't modify the recalled data display in any manner prior to initiating the re-save. Since all results are computed from the corrected set of reflected and transfer coefficient data, I assumed that changing the saved display configuration would have no impact on the calculated results. Is this assumption incorrect? Are there post measurement display changes that invalidate the measurement results?

--
73

Gary, N3GO

I just downloaded V 0.1.1 and verified that I'm getting identical invalid results. Since nobody else seems to have any issues with this, firmware; am I remiss in my thinking that this version of NanoVNA firmware is backward compatible with previous versions? Is this firmware only intended for desktop use of the NanoVNA, and more specifically as a bundled package with NanoVNA Saver?

--
73

Gary, N3GO

Hi Gary,
There's no firmware made specifically for NanoVNA-Saver - the software does
not use any features beyond the default, built in ones.

--
Rune / 5Q5R

Gary,

Edy555 increased the stack size of one of the threads and as my firmware is tracking his changes (as it is identical except scan command and 1500MHz upper limit) I will be releasing a new firmware soon
But it might be a good idea to also test edy55 his firmware to eliminate possible causes

https://github.com/ttrftech/NanoVNA/releases