开云体育

Please remember that with rapid S/W development, there will always be some kind of niggling issues somewhere in the code. To be safe, you can stick with releases from either edy555 or hugen. Erik also

When I heard there was the ability to extent the range to 2.5 GHz, I got over exited. Because I'm not forking out $800 bucks for a Analyzer. So which build do you recommend?

IMO, most danger comes from potential static discharge when jumpering DFU contacts. Firmware bugs may leave nanoVNA in hung state at power on, so forcing hardware DFU is an ongoing requirement. I and

Please DO NOT use that firmware - it was purely experimental and was indicated as such when Erik talked about it.There will be no support if you have any issues. However, it you DO want to play with

TRANSFORM submenu https://oristopo.github.io/nVhelp/html/Vnano.htm

37 : The [LeastVNA] @Gary O'Neil - 6 October 2019 : /g/nanovna-users/message/4194 35 : Straight In The Heart of The Matter - 6 October 2019

Sorry for the stupid question. But a recently saw a firmware update with the ability to go up to 2.5GHz freq. But I can't seem to find a solid wait to upgrade on windows. How would I go about

Ciao Roberto, I wish I had the time to look at the code but my 'real' job keeps me very busy. :-( The developer of the firmware you are using might be reading this group... or might not. It's good to

Hi aa_talaat, Your smith plot, using linear sample points, is similar to expected results using a Simsmith model. First straight line caused by very wide sample points. SimSmith model is shown in:

FWIW, I don't think DMR-CLEAR_MEMORY_DFU.dfu helps unless some desired firmware otherwise fails to load.

Hi Bryan Thank you for your comment. I see you have not fully under my trick, so I will take some small steps to explain what is going on. Consider we have calibrated at the female SMA calibration

Link added to /g/nanovna-users/wiki/Application-Notes

If you are modelling the terminal SOLT elements correctly you should have the same number of equations as elements. The correct calibration procedure should therefore be extended to beyond, 12, 16 or

Hi David, I will try sending you an experimental version at some point, and if it works, I could include that code in the future releases. Whether it keeps working is a different matter altogether.

IMHO, we really need a way of *properly* defining a calibration kit in *firmware*. That means as a minimum a delay, (which can be negative), and at least fixed capacitance C0 to support *professional*

Hi David, I will try sending you an experimental version at some point, and if it works, I could include that code in the future releases. Whether it keeps working is a different matter altogether. --

I will be glad to see remark in the about window that TDR code in C# was developed by alex_m :) You can also add window type selection option. In most case Blackman window provides best result for

The only discrepancy - which is fatal to the software working - that I have seen thus far, is that the developers have changed the prompt line, which I use to detect when output from the device has

Kurt, Good points for more precise calibration. It would certainly be more precise than my suggestion. I certainly agree with you that it is a good idea to calibrate as close to the measurement plane

Hi Bryan You are forgetting that the female female adaptor has a delay which when removed shift the measurement plane away form the calibration plane. I have a suggestion which work with good