So Christian - you're telling the forum members that Nano's firmware is not accurate (in one area) and that you've fixed it in you own private repo, but you're not willing to share the changes with others in this forum that are able to compile the code themselves?
"Pissing off coders" as only one member had opined is a lame excuse and that you >might consider< a pull request???
That's quite brash for someone new to the forum where everyone else shares their ideas and solutions quite freely.??
Think about it.
toggle quoted message
Show quoted text
On Thursday, September 24, 2020, 5:56:30 a.m. EDT, Christian Zietz <czietz@...> wrote:
Thank you, everyone, for your comments.
However, imho, the fact that the NanoVNA is an inexpensive device is no excuse for not correcting a systematic error and not making the NanoVNA an even better device. In particular, if these systematic errors are easily correctable with only minor impact on code size / flash memory usage. (It's just a multiplication that needs to be done.)
In any case, I have meanwhile changed/fixed this in a private version of the firmware. Now the peaks of my DUT (open-ended cable) show up as ¡Ö 0 dB in time-domain, regardless of mode and window settings - same as they would do on any other VNA. See attached screenshots.
I might consider a Github pull request (with eddy555?) for my FW change. But if the prevalent opinion is that this would be "pissing off coders", I'll keep my change and all further improvements/bug-fixes to my private fork of the firmware.
Regards
Christian
