开云体育

On Mon, Oct 21, 2019 at 12:30 PM, Rune Broberg wrote:

Hi Bryan,
I know it's the easy way out to claim that it's the other guy's fault, but
I really don't treat 0.3.0 any differently than I did 0.2.3. The fact that
it's at a specific frequency might point towards it being related to your
calibration at that particular frequency. I assume, though, that you have
tried re-calibrating your device, and that it remained in place at the same
frequency?

Rune,

Yes, I tried recalibrating but I still had an intermittent problem on the first sample of some segments.

I switched to another version of firmware, NanoVNA-0.3.0m from QRP RX that was included in the post at /g/nanovna-users/message/5445 and I did a full recalibration after installing the new firmware. It is my observation that every other version of firmware I have tried has produced something like a few bad samples. I don't know what that means. The new firmware from QRP RX cured all of the problems with reference to intermittent issues in the first sample of some segments. I really don't know what might be different. Clearly this means that the issue I was observing with intermittent bad values is not anything in nanoVNA-Saver. I don't observe any bad samples even though I have tried conditions that repeatedly caused them before switching firmware.

For now, I am using this version from QRP RX and all is well.

I also observed that you made some changes to the TDR function. It looks like it is working as it should. Good job!

Now, all I want is the low-pass TDR function that is in the nanoVNA firmware to be in nanoVNA-Saver so that I can test longer cables at high resolution. Maybe someday?

--
Bryan, WA5VAH

Hi Bryan,
Good to hear that 0.3.0m works better - I tried it out as well, and it
seems to work fine! :-)

What does that low-pass TDR function entail?

--
Rune / 5Q5R

On Wed, 23 Oct 2019 at 02:43, bryburns via Groups.Io <bryburns=
[email protected]> wrote:

On Mon, Oct 21, 2019 at 12:30 PM, Rune Broberg wrote:

Hi Bryan,
I know it's the easy way out to claim that it's the other guy's fault,

but

I really don't treat 0.3.0 any differently than I did 0.2.3. The fact

that

it's at a specific frequency might point towards it being related to your
calibration at that particular frequency. I assume, though, that you have
tried re-calibrating your device, and that it remained in place at the

same

frequency?

Rune,

Yes, I tried recalibrating but I still had an intermittent problem on the
first sample of some segments.

I switched to another version of firmware, NanoVNA-0.3.0m from QRP RX that
was included in the post at /g/nanovna-users/message/5445
and I did a full recalibration after installing the new firmware. It is my
observation that every other version of firmware I have tried has produced
something like a few bad samples. I don't know what that means. The new
firmware from QRP RX cured all of the problems with reference to
intermittent issues in the first sample of some segments. I really don't
know what might be different. Clearly this means that the issue I was
observing with intermittent bad values is not anything in nanoVNA-Saver. I
don't observe any bad samples even though I have tried conditions that
repeatedly caused them before switching firmware.

For now, I am using this version from QRP RX and all is well.

I also observed that you made some changes to the TDR function. It looks
like it is working as it should. Good job!

Now, all I want is the low-pass TDR function that is in the nanoVNA
firmware to be in nanoVNA-Saver so that I can test longer cables at high
resolution. Maybe someday?

--
Bryan, WA5VAH

Eric,
thank you very much for the diff files. There's one small issue though -
speed.

Looking at the TDR response with 2**16 FFT points, and 101 data points, I
get the following:
IFFT 6 milliseconds
"convolve" operation 3634 milliseconds

I don't know what "convolve" does, but I assume it's something quite
complicated?

Is there a better (= faster) way of doing this calculation?

--
Rune / 5Q5R

I don't know what "convolve" does,
but I assume it's something quite complicated?

"convolve" is a rolling sum.



For this special case of convolving with constant one,
it can be speeded by dropping the oldest value and adding the newest to the sum
for all ones in e.g. self.step

This is AKA 1-D box filter or summed area table

It looks like it's significantly faster (13 milliseconds) if using
scipy.signal.convolve - even though that adds another dependency to the
application, I'm considering allowing it this time.

--
Rune / 5Q5R

Hi Rune,

I am sorry to hear that the convolve math caused so much delay and that I didn't notice it. Not sure how to measure this. Running python 3.7.4 under OSX does not seam to have a lot of delay. Could there be a difference in python versions? Another member also mentioned in a PM to me that he experienced higher CPU load.
Fortunately Oristo was able to help us out!
I will try to write down the theoretical background of these routines as to explain the physical background.

Regards,

Eric

Hi Eric,
no problem - the calculations seem to be *correct* which is the major
hurdle ;-) As I posted, scipy.signal.convole seems a lot faster, and is
probably a good way to do it. The test also revealed that the TDR response
was being re-calculated whenever a marker was moved, which, as it turns
out, was completely unnecessary. So that won't be the case for the next
release :-)

Thanks for your efforts,
--
Rune / 5Q5R

Hi. Has the Save/Reteive Settings feature ever been implemented? Seems like I have seen a post that said it was but can't find it in the program. Thanks all.

Ken

On Fri, Jan 17, 2020 at 06:30 AM, Ken Kayser wrote:

Hi. Has the Save/Reteive Settings feature ever been implemented? Seems like I have seen a post that said it was but can't find it in the program. Thanks all.
=================================================

Ken,
The NanoVNA does not allow the settings you save in memory locations 0-4 to be saved externally and restored to the unit. Rune's NanoVNA-saver program allows you the save and retrieve calibration settings that you perform within his program; however, these are only for use within his program.

If you are asking if NanoVNA-saver allows you save and restore configuration information, such as its current operating state, that is not a feature Rune has implemented but is probably on his to do list.

- Herb