开云体育

Herb,

I think I have the edy555 version 0.2.3 firmware working well with nanoVNA-Saver 0.1.2, now. I no longer see weird data errors on the nanoVNA display or in the nanoVNA-Saver 0.1.2 displays.

I downloaded a different copy of the edy555 firmware. The one I used today was included in the post by reuterr at the link below.

/g/nanovna-users/topic/34428581#4280

The one I used previously was from and I had to convert ch.hex in the .zip file to a .dfu file using the software that comes with DfuSeDemo called "Dfu file manager". Prior to loading that version into the nanoVNA I loaded "DMR-CLEAR_MEMORY_DFU.dfu" which is not what I have been doing. I had previously been loading "DMR_FILL Flash with FF DFU.dfu". I don't know what the difference is between these .dfu files. Perhaps someone else knows. Does the "DMR-CLEAR_MEMORY_DFU.dfu" file write zeros to all locations?

So, this time I loaded "DMR_FILL Flash with FF DFU.dfu" and then the file from post 4280 in this user group called "nanoVNA_0.2.3-ch.dfu" included by reuterr in post #4280. After loading the firmware I asked the DfuSeDemo software to verify the download by using the available checkbox. There were no indications of any errors anywhere in this process. But, I did not see any errors in my first attempt either.

After installing the firmware, I cycled power on the nanoVNA, carefully set the screen calibration by gently using a wooden toothpick, and saved it. Then I immediately went to the calibration page, pressed "RESET" and initiated a cal. I noticed that the yellow line was about 3 divisions below the top of the display. Normally with a good cal and an open or short attached it 1 division below the top of the display. And, the device did not have a black background behind "CORRECTION". I then clicked on "RESET" followed by "CALIBRATE" and then went through the calibration procedure with "OPEN", "SHORT", "LOAD", "ISOLATION", and "THROUGH". I then saved this calibration in calibration memory 0. I also recalled calibration 0. I am not sure this is necessary, but... I immediately went to check the status of "CORRECTION" and it had that word highlighted by a black background. I am pretty sure that means that the "CORRECTION" from memory 0 is being used. I also confirmed that on the left side of the nanoVNA screen there was a "C0" in the first line, not "c0" which means that the calibration frequency range in memory zero matches the frequency range in use and nothing has been changed. I immediately went to check the calibration using an open, short, load, and through. Everything looks much better than before.

There seems to be a few possible changes that made the difference in the outcome.
1) I converted the .hex file to a .dfu file using the software "Dfu file manager" instead of using a .dfu file created by someone else.
2) I used a different .dfu file. A binary comparison does not show what I think is a difference in the part of the .dfu file that gets loaded; however, I could be wrong. The only difference I see is something about the path of the file that is stored in the .dfu file.
3) I cleared the memory of the nanoVNA with "DMR_FILL Flash with FF DFU.dfu" NOT "DMR-CLEAR_MEMORY_DFU.dfu."
4) I verified that what was loaded in the nanoVNA was the same as the file I was trying to load. I seriously doubt this is made a difference; however, I did not do that before.

#2 above may be a significant difference. Does anyone know what that might mean for operation of the nanoVNA? I certainly have no idea.

And, now when I use nanoVNA-Saver 0.1.2, things are working as I would expect.

By-the-way, when creating a calibration in nanoVNA-Saver, I set it up to average a minimum of 3 complete scans. I have considered doing many more (say 10). This will help reduce noise in the calibration itself. I think this has to be good for everything done with nanoVNA-Saver, especially above 300 MHz. Reducing the noise in calibration should be a good thing. I suggest everyone do this. I haven't seen this suggestion anywhere, but I haven't looked for it either.

I hope all of this is very clear and easy to understand.

--
Bryan, WA5VAH