开云体育

On the Google drive here -



The firmware is now in folders (I do not think this was the case last week when I got the 900 version date 9/24). But, the old .dfu version of NanoVNA-H__900_ch_ was 129 kB, and now the new version is only 96 kB. Does this seem strange to anyone - is this correct that the size was decreased? What changed to cause that?

NanoVNA-H__900_ch_20190924.dfu Size: 129 kB


NanoVNA-H__900_ch_20191003.dfu Size: 96 kB

Hi Rune,
thanks for the hint! I tried it out right away and it works very well!
I have attached the plot of a 200MHz BP-Filter. The calibration is done with full span and 8 segments. Now I can figure out the bandwidth manually.
One thing I would like to mention. For good reason the professional VNAs have "number of point" settings of i.e. 101, 201, 301, 401, 801 and so on. Could that feature be implemented in your software as well?

Kind regards
Norbert, DG1KPN

28 : DERDEI : Use of Standalone [gnuplot] Instead of [maxima]

Hello,

Allow us, please, to confirm the interested Common User,
who already observed that is indeed redundant in this case,
since the use of [maxima], which is still buggy, after thirty-seven
37 years of development:
(software)

is limited to calls of [gnuplot], that is of tool, which is under
development and extremely fruitful in results, for thirty-three
33 years:


Hence, the direct use of [gnuplot] instead of [maxima] is
strongly possible, e.g. in the way we already use it in our work:

[tlnomiva] : Transmission Line Nominal Values without
Tolerance - from Cable Specifications and Technical
Data Sheets : /F/L/O/S/S/ for MS Windows:


Sincerely,

gin&pez@arg

28

I agree; with decent screen calibration
and an old Samsung Galaxy Note stylus,
I find device menus faster and easier
than any VNA software UI,
so use software mostly for data capture or TDR.

Probably not long.
I am sure there are much more robust connection options available but <$30 for a set of possible uses doesn't exactly seem that expensive (you could make your own of course) but I guess if want to check functionality might be an idea.
You got a nice smith chart blank on one side to photocopy and own use etc :-)

72
Dom
M1KTA

Hi Jim -

Oristo, reference your inductor measurement above, Could you explain how you conducted this test?

I will try!

Did you recal the NanoVNA at each of your measurement ranges?

Yes.

Your test fixture set up isn't really a broad range test fixture.

Exactly, but I am not about to build a pcb with BNC connectors for
each component to measure,
and it is IMO not necessary for use below 150 MHz.

Did you lock down the position of your test clips and leads?

Not really, but did not rearrange things between CAL and measurements

I don't remember reading if the Nano firmware stores one single point/frequency calibration value, several over the specified frequency range or 101 points.

I don't recall reading that explicitly, but suppose that SPAN CALs
are @ 101 points;
don't know what happens with CW stimuli..?

What did your 51 ohm resistor look like over the 0.1-900 Mhz range after the calibration?

It had not occurred to me to measure (since I never use that range),
but since you ask, it is easily done...

... and the answer is: messy and unstable for reactance:

* with usual 34cm SMA-BNC pigtail, 49.9-50.0 Ohms, but 500 uF to 5nH (??)
- hard to read, with values rapidly changing drastically

perhaps a video would be better...

* replacing 34cm with 3m LMR195 and recalibrating yields
the same 49.9-50.0 Ohms, but 800uF to 63nH


I suppose that 3m LMR195 Smith plot is cleaner
because 3m separation between nanoVNA and DUT
reduces stray signal pickup by untrimmed axial resistor leads.

FWIW, at lower (and more reasonable) frequencies,
measurements are more stable for moderate SPAN than CW stimuli.

Thanks for the segment suggestion Rune and those off line too, I don't think it was the segment issue. It seems the callibration data had somehow been borked and nothing was correct, once did the 'cal reset' over serial it came back to life again. Will, have to redo the calibration again obviously and see if it can hold the information.

The actual device on all traces without even connecting a pc was seeing the 2 billion value.

72

Dom
M1KTA

Hi Norbert,
For calibration within NanoVNA-Saver, setup the sweep first to be the span
you want calibrated - for example, 50k to 1500M. Then in the box labeled
"segments", enter how many segments (of 101 points each) you want - so
entering 50 would give you 5050 points (and take about a minute per sweep).

This is how more points than 101 are acquired for normal sweeps as well.

--
Rune / 5Q5R

Hi Rune,
thank you very much for your quick answer!
Please tell me the trick where I can change the number of points prior to calibration. I didn't find that yet.

I think the following measurements are relevant:

Band pass -3dB, -6dB, and -60dB bandwidth.

The same for bandstop.

To measure a low pass or a high pass filter: -3dB right down and -3dB left down.

Kind regards
Norbert, DG1KPN

Hi Norbert,
the application can run calibrations at far more than 401 points - I have
certainly done 5050 points at one point. ;-) But it does this in the
application, and not on the device, due to the hardware limitations.

I agree that a function to find cut-off frequencies for filters etc. would
be interesting, and I've put it on the list of features I would like to
implement for the next version, ie. for next week. I don't make any
promises though :-)

What measurements would be relevant to provide? Cut-off frequency, span for
band-pass, dB/octave and dB/decade fall-off, pass-band ripple?

--
Rune / 5Q5R

Hi Rune,
thank you for fixing this issue!
I have a question for you in respect to the required number of data points to measure a band pass filter. With 101 points it is most likely not possible to find the -3 dB points because the sample point is way off from -3 dB on both sides of the band pass. With 401 points it would work. An automatic feature of measuring the bandwidth would be absolutely cool! The TAPR software is able to perform a calibration at 401 points or even more than that, so I am certain that you could do that as well. I have no glue on how difficult that would be, but more data points for calibration would be a huge improvement.

Kind regards
Norbert, DG1KPN

Thanks Rune,

I'll try both options. BTW this is running Linux & Python 3.74 version at home, work is much earlier so will have to wait I guess until later. I get the same output with the previous versions.

Using putty I can get into it and it seems to be functioning. Used the putty/cli command to reset the calibration data 'cal reset' and it seems to function again, I get odd 2 billion results in the 4 traces though every now and then if try to alter frequency again.

72

Dom
M1KTA

Glad you got yours. Obviously I'm not worthy.
I have got one now from elsewhere on eBay.
And when my sma to n adapters come I may even use it!

Nice idea. I wonder how long those little u.fl connectors will last though.

27 : Reproduction of (REGION , DEREDEI) Results and Graphics

@Jose Luu : /g/nanovna-users/message/3812

Hello Jose,

Thank you very much for your proved interest on our work.

Your message contents are really Great News for our Objective World !

Now, regarding the restricted - up to 6 characters long, with capital
letters only - names of our variables, we can assure that we tried hard
to conform ourselves with the requirements of FORTRAN IV without
any extension, in order to make possible for our REGION program
to be compiled and run under as much environments as is possible

Nevertheless, from what you report we conclude that it may worth to
look again into the current state of progress of openwatcom V2 fork.
Thank you.

And by the way, a word of clarification regarding our instructions at:

26 : Correction of Maxima Version and "Unpacked" DERDEI Code
/g/nanovna-users/message/3770

Because of the existing restrictions in [maxima] GUI, it is not possible
at all for the interested reader to Copy-and-Paste using his mouse all
the way, so he has to use the key-combinations: [Ctrl][C]-and-[Ctrl][V].

Finally, allow us, please, to motivate you, as well as, any other interested
reader, to try our /F/L/O/S/S/ on your measurements. One, of the many,
possible use is to construct your real standard load with Nominal Value
and Core Uncertainty depending in an * e x p l i c i t l y * k n o w n * way
on the frequency - that is as we have already done with our ref2007box:

22 : AnyVNA From The Common User's Point Of View :
A Practical Application of the Core Uncertainty Strips
/g/nanovna-users/message/3340

Who can ask more than that ?

Best regards,

Nikolitsa OE3ZGN|SV7DMC and Petros OE3ZZP|SV7BAX

27

You tried sweep 50kHz span with 101*10 sweep.
I don't think NanoVNA capable below 50Hz RBW...
How about give more span with default 101 sweep?

Oh, a different issue: You set the segment count far, far too high (1000).
Try a value of 1 first, and see if that helps :-)

--
Rune / 5Q5R

On Thu, 3 Oct 2019, 09:19 Rune Broberg via Groups.Io, <mihtjel=
[email protected]> wrote:

Hi Dom,
The application is receiving some weird data from you device - a value of
about 2 billion, which is supposed to be in the range -1 to +1. ?

Try doing a full calibration on the nanovna, including resetting the
calibration first and saving it to save slot 0. If it still fails after
that, there will have to be further investigation.

I hope this helps!

--
Rune / 5Q5R

On Thu, 3 Oct 2019, 08:35 Dom Baines M1KTA via Groups.Io, <dombaines=
[email protected]> wrote:

I cannot get this to work on startup using nanosaver and I get in the
logfile ...

2019-10-03 07:33:37,745 - NanoVNASaver - INFO - Startup...
2019-10-03 07:33:37,829 - NanoVNASaver.SweepWorker - INFO - Initializing
SweepWorker
2019-10-03 07:33:37,869 - NanoVNASaver.NanoVNASaver - INFO - Found

NanoVNA

(0483 5740) on port /dev/ttyACM0
2019-10-03 07:33:37,869 - NanoVNASaver.NanoVNASaver - DEBUG - Building
user interface
2019-10-03 07:33:37,973 - NanoVNASaver.NanoVNASaver - DEBUG - Finished
building interface
2019-10-03 07:33:51,682 - NanoVNASaver.NanoVNASaver - INFO - Opening
serial port /dev/ttyACM0
2019-10-03 07:33:52,100 - NanoVNASaver.NanoVNASaver - INFO - info
Kernel: 4.0.0
Compiler: GCC 5.4.1 20160919
Architecture: ARMv6-M
Core Variant: Cortex-M0
Port Info: Preemption through NMI
Platform: STM32F072xB Entry Level Medium Density devices
Board: NanoVNA
Build time: Aug 2 2019 - 16:40:01
ch>
2019-10-03 07:33:52,265 - NanoVNASaver.NanoVNASaver - INFO - Read

starting

frequency 100000 and end frequency 150000
2019-10-03 07:33:52,265 - NanoVNASaver.NanoVNASaver - DEBUG - Starting
initial sweep
2019-10-03 07:33:52,266 - NanoVNASaver.SweepWorker - INFO - Initializing
SweepWorker
2019-10-03 07:33:52,266 - NanoVNASaver.SweepWorker - INFO - 1000 sweeps
2019-10-03 07:33:52,266 - NanoVNASaver.SweepWorker - DEBUG - Parsed sweep
range as 100000 to 150000
2019-10-03 07:33:52,266 - NanoVNASaver.SweepWorker - DEBUG - Sweep

segment

no 0
2019-10-03 07:33:52,267 - NanoVNASaver.SweepWorker - DEBUG - Setting

sweep

range to 100000 to 100000
2019-10-03 07:33:52,568 - NanoVNASaver.SweepWorker - DEBUG - Reading
frequencies
2019-10-03 07:33:52,784 - NanoVNASaver.SweepWorker - DEBUG - Reading

data 0

2019-10-03 07:33:52,994 - NanoVNASaver.SweepWorker - DEBUG - Read 101
values
2019-10-03 07:33:52,995 - NanoVNASaver.SweepWorker - WARNING - Got a
non-float data value: 2147483647.147483647 2147483647.147483647
(2147483647.147483647)
2019-10-03 07:33:52,995 - NanoVNASaver.SweepWorker - DEBUG - Re-reading
data 0
repeats until
2019-10-03 07:34:06,245 - NanoVNASaver.SweepWorker - CRITICAL - Tried and
failed to read data 0 20 times. Giving up.
2019-10-03 07:34:06,245 - NanoVNASaver.SweepWorker - DEBUG - Sweep

segment

no 1
2019-10-03 07:34:06,251 - NanoVNASaver.SweepWorker - DEBUG - Stopping
sweeping as signalled
2019-10-03 07:34:06,258 - NanoVNASaver.SweepWorker - DEBUG - Resetting
NanoVNA sweep to full range: 100000 to 150000
2019-10-03 07:34:06,260 - NanoVNASaver.SweepWorker - DEBUG - Sending
"finished" signal

Anyone?

No RF squirted into it, default as delivered. Cannot see more than one
trace.

Hi Dom,
The application is receiving some weird data from you device - a value of
about 2 billion, which is supposed to be in the range -1 to +1. ?

Try doing a full calibration on the nanovna, including resetting the
calibration first and saving it to save slot 0. If it still fails after
that, there will have to be further investigation.

I hope this helps!

--
Rune / 5Q5R

On Thu, 3 Oct 2019, 08:35 Dom Baines M1KTA via Groups.Io, <dombaines=
[email protected]> wrote:

I cannot get this to work on startup using nanosaver and I get in the
logfile ...

2019-10-03 07:33:37,745 - NanoVNASaver - INFO - Startup...
2019-10-03 07:33:37,829 - NanoVNASaver.SweepWorker - INFO - Initializing
SweepWorker
2019-10-03 07:33:37,869 - NanoVNASaver.NanoVNASaver - INFO - Found NanoVNA
(0483 5740) on port /dev/ttyACM0
2019-10-03 07:33:37,869 - NanoVNASaver.NanoVNASaver - DEBUG - Building
user interface
2019-10-03 07:33:37,973 - NanoVNASaver.NanoVNASaver - DEBUG - Finished
building interface
2019-10-03 07:33:51,682 - NanoVNASaver.NanoVNASaver - INFO - Opening
serial port /dev/ttyACM0
2019-10-03 07:33:52,100 - NanoVNASaver.NanoVNASaver - INFO - info
Kernel: 4.0.0
Compiler: GCC 5.4.1 20160919
Architecture: ARMv6-M
Core Variant: Cortex-M0
Port Info: Preemption through NMI
Platform: STM32F072xB Entry Level Medium Density devices
Board: NanoVNA
Build time: Aug 2 2019 - 16:40:01
ch>
2019-10-03 07:33:52,265 - NanoVNASaver.NanoVNASaver - INFO - Read starting
frequency 100000 and end frequency 150000
2019-10-03 07:33:52,265 - NanoVNASaver.NanoVNASaver - DEBUG - Starting
initial sweep
2019-10-03 07:33:52,266 - NanoVNASaver.SweepWorker - INFO - Initializing
SweepWorker
2019-10-03 07:33:52,266 - NanoVNASaver.SweepWorker - INFO - 1000 sweeps
2019-10-03 07:33:52,266 - NanoVNASaver.SweepWorker - DEBUG - Parsed sweep
range as 100000 to 150000
2019-10-03 07:33:52,266 - NanoVNASaver.SweepWorker - DEBUG - Sweep segment
no 0
2019-10-03 07:33:52,267 - NanoVNASaver.SweepWorker - DEBUG - Setting sweep
range to 100000 to 100000
2019-10-03 07:33:52,568 - NanoVNASaver.SweepWorker - DEBUG - Reading
frequencies
2019-10-03 07:33:52,784 - NanoVNASaver.SweepWorker - DEBUG - Reading data 0
2019-10-03 07:33:52,994 - NanoVNASaver.SweepWorker - DEBUG - Read 101
values
2019-10-03 07:33:52,995 - NanoVNASaver.SweepWorker - WARNING - Got a
non-float data value: 2147483647.147483647 2147483647.147483647
(2147483647.147483647)
2019-10-03 07:33:52,995 - NanoVNASaver.SweepWorker - DEBUG - Re-reading
data 0
repeats until
2019-10-03 07:34:06,245 - NanoVNASaver.SweepWorker - CRITICAL - Tried and
failed to read data 0 20 times. Giving up.
2019-10-03 07:34:06,245 - NanoVNASaver.SweepWorker - DEBUG - Sweep segment
no 1
2019-10-03 07:34:06,251 - NanoVNASaver.SweepWorker - DEBUG - Stopping
sweeping as signalled
2019-10-03 07:34:06,258 - NanoVNASaver.SweepWorker - DEBUG - Resetting
NanoVNA sweep to full range: 100000 to 150000
2019-10-03 07:34:06,260 - NanoVNASaver.SweepWorker - DEBUG - Sending
"finished" signal

Anyone?

No RF squirted into it, default as delivered. Cannot see more than one
trace.

Of course Larry, you've been a great help thus far! :-)

I'll be doing alpha testing for each new version from here on.

--
Rune / 5Q5R

Chinese holiday now