开云体育

On Tue, 1 Oct 2019 at 14:29, John AE5X <ae5x@...> wrote:

Is the main (only?) difference in the -F that it has a 100 MHz higher
upper frequency limit?

I am unsure if you made a typo or an error, but on the link to alliexpress,
it shows a marker at over 400 MHz. Did you mean 1000 MHz rather than 100
MHz?

Dave
--
Dr. David Kirkby,
Kirkby Microwave Ltd,
drkirkby@...

Telephone 01621-680100./ +44 1621 680100

Registered in England & Wales, company number 08914892.
Registered office:
Stokes Hall Lodge, Burnham Rd, Althorne, Chelmsford, Essex, CM3 6DT, United
Kingdom

Email direct, please, for the alpha testing :-)

--
Rune / 5Q5R

Rune, do you want feedback here or via email?

Fair questions.

My use will be 99% lab use.
This means that form factor is not important. A display is nice but not critical, and if the display is less than 7" it is more or less useless to me. I have not seen the 4,5" NanoVNA. I have an OK sight for my age. I am actually contemplating taking a v.2 apart, and build it into a desktop solution e.g. with a 7" display, if possible. Adding some more optional buttons could be nice, e.g. for faster selection of certain measurements/features, up/down and select functionality.

For antenna measurement use I will probably pre-configure a palm size unit, since I find it cumbersome to operate. The toggle-switch is flimsy and the touch screen can be difficult to operate with dirty or cold fingers. Thus both are tough and risky to operate in a tower or on the roof.

If the component target cost is 100 USD making a modular design may not add a lot to the basic model. A modular design may in fact reduce the cost of the basic unit, since it may be nothing but the RF and processor modules. Then users may add a display of different size, provided the resolution is supported, battery and enclosure. I.e. a bit like the Yaesu FT-817 when it comes to the myriad of accessories (tuner, stands, back-pack, power supply etc.)

Calibration standards and TDR functionality apply in both cases.

Bo

David,
It would interesting if you gave a review of the NanoVNA and NanoVNA-F since you own both devices. Especially interested in whether Rune's nanovna-saver app works out of the box with the NanoVNA-F.

Herb

You need to be connected to the Internet in order to use the Web interface because you need to access cho45's webpage.That means mobile data or WiFi.
All I did was to connect my nano to the tablet's USB host port and run cho45's webpage through Chrome and it worked.This was 3 weeks ago and the UI was flakey but cho45 has updated it since then so YMMV.
Regards,Larry

Normally, you really don't need to upgrade if the device is working well for you.
Typically, one would upgrade for two main reasons:
1. New functionality
2. Bug fixes

The latest edy555 release fixed 3 bugs per the github release notes, so you should probably upgrade to that version.
You don't need to use the extended frequency if you don't want to.
The device will still work normally for your needs after it is calibrated.

Cheers,
Larry

Do it the ISO 8000 way = spaces

I am presently running the 300_ch (9-11-19) version of the firmware because I use the NanoVNA primarily for HF. I see that the latest version is edy555_bugfix (10-1-19). Would it be a good idea to install the latest version even though I don't need the UHF function? In general, how does one decide which version to install?

I would like to try the software.

Rick LU4FDV

Hi Nigel,
looks like the driver was the culprit! If nothing is shown in the box where
it probably says "COM17" by now, it means the software hasn't detected the
NanoVNA. I guess that could be clearer ;-)

I hope you have good use out of it!

--
Rune / 5Q5R

Hi Nigel -

I have updated with the newer version based on the file name (en.stsw-stm 32080 vs en.stsw-stm 32102)
and after a re-boot and changing device driver from ChibOS/RT Virtual Com port
to the one from st.com, the nanovna now has a port number

It's good when a plan works. I have little Windows 7 experience.
(I found Vista so awful that I pretty much stuck with XP SP2 until 8.1)

Firmware updates almost certainly require STM's driver, if you ever attempt.

From: Dr. David Kirkby from Kirkby Microwave Ltd

Rune's NanoVNA-Saver looks a lovely bit of software, but it is not much
good unless you work outside, unless willing to take a PC worth you.
===================================

I've used a Windows tablet PC for demonstration purposes, and something like this /might/ suit you:



I run nanoVNA-saver on a 10-inch earlier model (the one where 1/3 of the 64 GB of storage is eaten by an unused Android partition).

73,
David GM8ARV
--
SatSignal Software - Quality software for you
Web:
Email: david-taylor@...
Twitter: @gm8arv

Up until now, I have used my $450 AIM-4170D for measurements made inside the shack and it is capable of being calibrated to make remote measurements from the shack. Calibrating for those remote measurements is a pain plus the AIM-4170D requires a 12v supply and a PC or laptop for it to function. My decisions have been (1) run back and forth between remote measurement point and shack in order to do the calibration or (2) Lug a 12v battery and laptop to the remote measurement point (sometimes on the roof or up a tree). Up until now, I have relied on my $120 Autek VA1 for those vest pocket difficult remote measurements but the Alpha-Numeric+ display is clumsy. Except for a couple of nagging problems, e.g. bright sunshine, the NanoVNA solves those problems. One idea I have had is to marry the NanoVNA to a portable RPi system (larger display) running NanoVNA-Saver. Some hams are already running WSJT-X and FLDigi on such portable battery-powered systems.

Hi Bryan,
sweeping currently works as follows:
1) The requested frequency range is set (start and stop frequency)
2) A delay of 300 ms
3) The frequencies are read back by sending the text "frequencies", waiting
50 ms, and then reading them
4) The S11 data is read (again, 50 ms delay included)
5) The S21 data is read

I decided on 300 ms after testing a few times, and figuring that it was
"probably fine". Setting no delay sometimes let to errors, and more than
250 ms seemed to be fine, so I set it to 300. Maybe it's too low? But
then I was using Hugen's firmware.

If you can make a non-continuous sweep that produces a noticeable error,
you can try exporting the S1P/S2P Touchstone file, and looking at the
frequencies. The Touchstone export reads the exact frequencies reported
back by the NanoVNA, so it should tell you what frequencies it thinks it's
reporting data for.

Sadly I don't think it's something I can really address in the application
- I believe it has to be accounted for in the firmware.

Thanks for the work you're doing on this issue, though! Good luck with it!

--
Rune / 5Q5R

On Tue, 1 Oct 2019 at 16:40, bryburns via Groups.Io <bryburns=
[email protected]> wrote:

Rune,

Thanks for taking a look at this thread!

My biggest concern is that with the firmware 0.2.2 from edy555 I always
see incorrect data in the second scan when using 2 scans between 80 and 120
MHz. With a single scan there are no errors over the same frequency
range. The incorrect data is always wrong in the same way. I.E. it is
actual measurements but they are from the wrong frequencies. If I do 5
scans, it appears that the first part of scans 2 through 5 is almost always
incorrect data. If it were occasional errors, I could work with it;
however, it is repeated with my nanoVNA and this firmware. When I request
a single scan over the exact same frequencies as the 2nd or 3rd or 4th or
5th scan, I very rarely, if ever, see an error in the nanoVNA-Saver data,
even in continuous sweep mode. What is different about continuous sweep
mode? Is there a pause between the scans?

I very rarely, if ever, see it with firmware from hugen dated August 2,
2019 using the exact same scan settings 2 or 3 or 4 or 5... Yes, I will
occasionally see errors with the hugen firmware but they are quite rare and
usually pretty obvious. Repeating a sweep or measurement will clear the
errant data.

I don't know much about the transfer protocol between the nanoVNA and the
PC. From your comment above, I would have to assume that you do not get
the frequency information in the same message as the data so there is no
way to throw out data based on the fact that the frequencies you requested
are not the frequencies sent from the nanoVNA. Is that correct?

A few questions, mostly thinking out loud. :>) I wonder if data is being
sent from the firmware before the hardware has actually stabilized at the
new frequencies you have requested? Would it help to pause a bit after
requesting a new set of frequencies?

I will continue looking for more clues to this issue.

--
Bryan, WA5VAH

Good afternoon from sunny South Africa :-)

Updates:

Rune - Copy of log file(s) created below FYI but not much to analyze... Also a screen shot of the command window and log file from a USB 'trace' in case of interest / value) that may assist your development(s) in some way(?).

Oristo - Thanks for the link to another driver, although was already on system I have updated with the newer version based on the file name (en.stsw-stm 32080 vs en.stsw-stm 32102) and after a re-boot and changing device driver from ChibOS/RT Virtual Com port to the one from st.com, the nanovna now has a port number - PROGRESS!

Running NanoVNA-Saver now shows the associated port number AND connection is possible <BIG Smile>.

Now I have additional (fun) stuff to learn which will hopefully keep my cerebral cells busy...

Gyula - Thank you for taking time to reply, thankfully a change of driver was the 'simple' fix.

Thank you all again for your interest and support, it really is a FANTASTIC community to be a party of :-)

Best regards

Nigel R

Content below this line probably only of interest if similar issues encountered by others and / or for reference.
Sorry for consuming bandwidth / space if inappropriate.
-----------------------------------------------------------------------------------------------------------------------------
LogFile 1
2019-10-01 15:20:03,761 - NanoVNASaver - INFO - Startup...
2019-10-01 15:20:04,412 - NanoVNASaver.SweepWorker - INFO - Initializing SweepWorker
2019-10-01 15:20:04,512 - NanoVNASaver.NanoVNASaver - DEBUG - Building user interface
2019-10-01 15:20:05,303 - NanoVNASaver.NanoVNASaver - DEBUG - Finished building interface
2019-10-01 15:22:35,569 - NanoVNASaver - INFO - Startup...
2019-10-01 15:22:36,100 - NanoVNASaver.SweepWorker - INFO - Initializing SweepWorker
2019-10-01 15:22:36,190 - NanoVNASaver.NanoVNASaver - DEBUG - Building user interface
2019-10-01 15:22:36,981 - NanoVNASaver.NanoVNASaver - DEBUG - Finished building interface

LogFile 2 after change of driver
2019-10-01 15:38:26,009 - NanoVNASaver - INFO - Startup...
2019-10-01 15:38:26,620 - NanoVNASaver.SweepWorker - INFO - Initializing SweepWorker
2019-10-01 15:38:26,730 - NanoVNASaver.NanoVNASaver - INFO - Found NanoVNA (0483 5740) on port COM17
2019-10-01 15:38:26,730 - NanoVNASaver.NanoVNASaver - DEBUG - Building user interface
2019-10-01 15:38:31,918 - NanoVNASaver.NanoVNASaver - DEBUG - Finished building interface
2019-10-01 15:38:36,845 - NanoVNASaver.NanoVNASaver - INFO - Opening serial port COM17

Screenshot is console with non working driver.

Error message below reported after initial attempt to use with new driver but as reported all well second and subsequent times.

\\?\usb#vid_0483&pid_5740#400#{a5dcbf10-6530-11d2-901f-00c04fb951ed}

Description:
A problem caused this program to stop interacting with Windows.
Problem signature:
Problem Event Name: AppHangB1
Application Name: nanovna-saver.v0.0.12.exe
Application Version: 0.0.0.0
Application Timestamp: 5d24a31b
Hang Signature: c143
Hang Type: 0
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 7177
Additional Hang Signature 1: c143197821453067c6fca61d7dec776f
Additional Hang Signature 2: ef39
Additional Hang Signature 3: ef3942ff81a6672d8bee95d6e5eccc0c
Additional Hang Signature 4: c143
Additional Hang Signature 5: c143197821453067c6fca61d7dec776f
Additional Hang Signature 6: ef39
Additional Hang Signature 7: ef3942ff81a6672d8bee95d6e5eccc0c

USB Tree (non working driver)
======================== USB Device ========================

+++++++++++++++++ Device Information ++++++++++++++++++
Device Description : ChibiOS/RT Virtual COM Port
Device Path : \\?\usb#vid_0483&pid_5740#400#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
Device ID : USB\VID_0483&PID_5740\400
Hardware IDs : USB\VID_0483&PID_5740&REV_0200 USB\VID_0483&PID_5740
Driver KeyName : {88bae032-5a81-49f0-bc3d-a4ff138216d6}\0000 ({88BAE032-5A81-49F0-BC3D-A4FF138216D6})
Driver : system32\DRIVERS\WinUsb.sys (Version: 6.1.7601.17514 Date: 2010-11-20)
Driver Inf : C:\Windows\inf\oem40.inf
Legacy BusType : PNPBus
Class : USBDevice
Class GUID : {88bae032-5a81-49f0-bc3d-a4ff138216d6}
Interface GUID : {a5dcbf10-6530-11d2-901f-00c04fb951ed} (GUID_DEVINTERFACE_USB_DEVICE)
Service : WinUSB
Enumerator : USB
Location Info : Port_#0002.Hub_#0005
Location IDs : PCIROOT(0)#PCI(1E00)#PCI(0400)#PCI(0000)#USBROOT(0)#USB(2)
Container ID : {760c3622-4a59-596d-bacb-13523c1ebcfe}
Manufacturer Info : STMicroelectronics
Capabilities : 0x14 (Removable, UniqueID)
Status : 0x0180600A (DN_DRIVER_LOADED, DN_STARTED, DN_DISABLEABLE, DN_REMOVABLE, DN_NT_ENUMERATOR, DN_NT_DRIVER)
Problem Code : 0
Power State : D0 (supported: D0, D2, D3, wake from D0, wake from D2)

---------------- Connection Information ---------------
Connection Index : 0x02 (2)
Connection Status : 0x01 (DeviceConnected)
Current Config Value : 0x01
Device Address : 0x01 (1)
Is Hub : 0x00 (no)
Device Bus Speed : 0x01 (Full-Speed)
Number Of Open Pipes : 0x03 (3 pipes to data endpoints)
Pipe[0] : EndpointID=2 Direction=IN ScheduleOffset=0 Type=Interrupt
Pipe[1] : EndpointID=1 Direction=OUT ScheduleOffset=0 Type=Bulk
Pipe[2] : EndpointID=1 Direction=IN ScheduleOffset=0 Type=Bulk
Data (HexDump) : 02 00 00 00 12 01 10 01 02 00 00 40 83 04 40 57 ...........@..@W
00 02 01 02 03 01 01 01 00 01 00 03 00 00 00 01 ................
00 00 00 07 05 82 03 08 00 FF 00 00 00 00 07 05 ................
01 02 40 00 00 00 00 00 00 07 05 81 02 40 00 00 ..@..........@..
00 00 00 00 ....

---------------------- Device Descriptor ----------------------
bLength : 0x12 (18 bytes)
bDescriptorType : 0x01 (Device Descriptor)
bcdUSB : 0x110 (USB Version 1.10)
bDeviceClass : 0x02 (Communications and CDC Control)
bDeviceSubClass : 0x00
bDeviceProtocol : 0x00 (No class specific protocol required)
bMaxPacketSize0 : 0x40 (64 bytes)
idVendor : 0x0483 (STMicroelectronics)
idProduct : 0x5740
bcdDevice : 0x0200
iManufacturer : 0x01 (String Descriptor 1)
Language 0x0409 : "STMicroelectronics"
iProduct : 0x02 (String Descriptor 2)
Language 0x0409 : "ChibiOS/RT Virtual COM Port"
iSerialNumber : 0x03 (String Descriptor 3)
Language 0x0409 : "400"
bNumConfigurations : 0x01 (1 Configuration)
Data (HexDump) : 12 01 10 01 02 00 00 40 83 04 40 57 00 02 01 02 .......@..@W....
03 01 ..

------------------ Configuration Descriptor -------------------
bLength : 0x09 (9 bytes)
bDescriptorType : 0x02 (Configuration Descriptor)
wTotalLength : 0x0043 (67 bytes)
bNumInterfaces : 0x02 (2 Interfaces)
bConfigurationValue : 0x01 (Configuration 1)
iConfiguration : 0x00 (No String Descriptor)
bmAttributes : 0xC0
D7: Reserved, set 1 : 0x01
D6: Self Powered : 0x01 (yes)
D5: Remote Wakeup : 0x00 (no)
D4..0: Reserved, set 0 : 0x00
MaxPower : 0x32 (100 mA)
Data (HexDump) : 09 02 43 00 02 01 00 C0 32 09 04 00 00 01 02 02 ..C.....2.......
01 00 05 24 00 10 01 05 24 01 00 01 04 24 02 02 ...$....$....$..
05 24 06 00 01 07 05 82 03 08 00 FF 09 04 01 00 .$..............
02 0A 00 00 00 07 05 01 02 40 00 00 07 05 81 02 .........@......
40 00 00 @..

---------------- Interface Descriptor -----------------
bLength : 0x09 (9 bytes)
bDescriptorType : 0x04 (Interface Descriptor)
bInterfaceNumber : 0x00
bAlternateSetting : 0x00
bNumEndpoints : 0x01 (1 Endpoint)
bInterfaceClass : 0x02 (Communications and CDC Control)
bInterfaceSubClass : 0x02 (Abstract Control Model)
bInterfaceProtocol : 0x01 (AT Commands defined by ITU-T V.250 etc)
iInterface : 0x00 (No String Descriptor)
Data (HexDump) : 09 04 00 00 01 02 02 01 00 .........

-------------- CDC Interface Descriptor ---------------
bFunctionLength : 0x05 (5 bytes)
bDescriptorType : 0x24 (Interface)
bDescriptorSubType : 0x00 (Header Functional Descriptor)
bcdCDC : 0x110 (CDC Version 1.10)
Data (HexDump) : 05 24 00 10 01 .$...

-------------- CDC Interface Descriptor ---------------
bFunctionLength : 0x05 (5 bytes)
bDescriptorType : 0x24 (Interface)
bDescriptorSubType : 0x01 (Call Management Functional Descriptor)
bmCapabilities : 0x00
D7..2: : 0x00 (Reserved)
D1 : : 0x00 (sends/receives call management information only over the Communication Class interface)
D0 : : 0x00 (does not handle call management itself)
bDataInterface : 0x01
Data (HexDump) : 05 24 01 00 01 .$...

-------------- CDC Interface Descriptor ---------------
bFunctionLength : 0x04 (4 bytes)
bDescriptorType : 0x24 (Interface)
bDescriptorSubType : 0x02 (Abstract Control Management Functional Descriptor)
bmCapabilities : 0x02
D7..4: : 0x00 (Reserved)
D3 : : 0x00 (not supports the notification Network_Connection)
D2 : : 0x00 (not supports the request Send_Break)
D1 : : 0x01 (supports the request combination of Set_Line_Coding, Set_Control_Line_State, Get_Line_Coding, and the notification Serial_State)
D0 : : 0x00 (not supports the request combination of Set_Comm_Feature, Clear_Comm_Feature, and Get_Comm_Feature)
Data (HexDump) : 04 24 02 02 .$..

-------------- CDC Interface Descriptor ---------------
bFunctionLength : 0x05 (5 bytes)
bDescriptorType : 0x24 (Interface)
bDescriptorSubType : 0x06 (Union Functional Descriptor)
bControlInterface : 0x00
bSubordinateInterface[0] : 0x01
Data (HexDump) : 05 24 06 00 01 .$...

----------------- Endpoint Descriptor -----------------
bLength : 0x07 (7 bytes)
bDescriptorType : 0x05 (Endpoint Descriptor)
bEndpointAddress : 0x82 (Direction=IN EndpointID=2)
bmAttributes : 0x03 (TransferType=Interrupt)
wMaxPacketSize : 0x0008 (8 bytes)
bInterval : 0xFF (255 ms)
Data (HexDump) : 07 05 82 03 08 00 FF .......

---------------- Interface Descriptor -----------------
bLength : 0x09 (9 bytes)
bDescriptorType : 0x04 (Interface Descriptor)
bInterfaceNumber : 0x01
bAlternateSetting : 0x00
bNumEndpoints : 0x02 (2 Endpoints)
bInterfaceClass : 0x0A (CDC-Data)
bInterfaceSubClass : 0x00
bInterfaceProtocol : 0x00
iInterface : 0x00 (No String Descriptor)
Data (HexDump) : 09 04 01 00 02 0A 00 00 00 .........

----------------- Endpoint Descriptor -----------------
bLength : 0x07 (7 bytes)
bDescriptorType : 0x05 (Endpoint Descriptor)
bEndpointAddress : 0x01 (Direction=OUT EndpointID=1)
bmAttributes : 0x02 (TransferType=Bulk)
wMaxPacketSize : 0x0040 (64 bytes)
bInterval : 0x00 (ignored)
Data (HexDump) : 07 05 01 02 40 00 00 ....@..

----------------- Endpoint Descriptor -----------------
bLength : 0x07 (7 bytes)
bDescriptorType : 0x05 (Endpoint Descriptor)
bEndpointAddress : 0x81 (Direction=IN EndpointID=1)
bmAttributes : 0x02 (TransferType=Bulk)
wMaxPacketSize : 0x0040 (64 bytes)
bInterval : 0x00 (ignored)
Data (HexDump) : 07 05 81 02 40 00 00 ....@..

-------------------- String Descriptors -------------------
------ String Descriptor 0 ------
bLength : 0x04 (4 bytes)
bDescriptorType : 0x03 (String Descriptor)
Language ID[0] : 0x0409 (English - United States)
Data (HexDump) : 04 03 09 04 ....
------ String Descriptor 1 ------
bLength : 0x26 (38 bytes)
bDescriptorType : 0x03 (String Descriptor)
Language 0x0409 : "STMicroelectronics"
Data (HexDump) : 26 03 53 00 54 00 4D 00 69 00 63 00 72 00 6F 00 &.S.T.M.i.c.r.o.
65 00 6C 00 65 00 63 00 74 00 72 00 6F 00 6E 00 e.l.e.c.t.r.o.n.
69 00 63 00 73 00 i.c.s.
------ String Descriptor 2 ------
bLength : 0x38 (56 bytes)
bDescriptorType : 0x03 (String Descriptor)
Language 0x0409 : "ChibiOS/RT Virtual COM Port"
Data (HexDump) : 38 03 43 00 68 00 69 00 62 00 69 00 4F 00 53 00 8.C.h.i.b.i.O.S.
2F 00 52 00 54 00 20 00 56 00 69 00 72 00 74 00 /.R.T. .V.i.r.t.
75 00 61 00 6C 00 20 00 43 00 4F 00 4D 00 20 00 u.a.l. .C.O.M. .
50 00 6F 00 72 00 74 00 P.o.r.t.
------ String Descriptor 3 ------
bLength : 0x08 (8 bytes)
bDescriptorType : 0x03 (String Descriptor)
Language 0x0409 : "400"
Data (HexDump) : 08 03 34 00 30 00 30 00 ..4.0.0.

I agree.
How about a soft-switch to enable external communication either through the USB port OR a serial port that could be connected to a Bluetooth Dongle?

My 0.02

...Larry

25 : The concept of Quantity today

Hello,

Our Objective World adopted * p a r t s * of the following:

VIM - International Vocabulary of Metrology



JCGM_200_2012.pdf - 4,024,384 bytes

Author : BIPM
Title: JCGM 200:2012 - International vocabulary of metrology -
Basic and general concepts and associated terms (VIM)
PDF Version : 1.6
Pages Count : 108

p.viii:

The present Vocabulary pertains to metrology, the “science of
measurement and its application”.

p.18 - Left Column

1.1 (1.1)
quantity
property of a phenomenon, body, or substance, where the property
has a magnitude that can be expressed as a number and a
reference

NOTE 2
A reference can be a measurement unit, a measurement procedure,
a reference material, or a combination of such.

After that, we put parentheses "( )" around the undefined terms
and square brackets around the defined terms in the above entries
of this very version of VIM, to get the following:

[quantity]
(property) of a : (phenomenon), (body), or (substance), where
the (property) has a (magnitude) that can be expressed as a
number and a [reference]

A [reference] can be a [measurement unit], a [measurement
procedure], a [reference (material)], or a combination of such.

Sincerely,

gin&pez@arg

25

Rune,

Thanks for taking a look at this thread!

My biggest concern is that with the firmware 0.2.2 from edy555 I always see incorrect data in the second scan when using 2 scans between 80 and 120 MHz. With a single scan there are no errors over the same frequency range. The incorrect data is always wrong in the same way. I.E. it is actual measurements but they are from the wrong frequencies. If I do 5 scans, it appears that the first part of scans 2 through 5 is almost always incorrect data. If it were occasional errors, I could work with it; however, it is repeated with my nanoVNA and this firmware. When I request a single scan over the exact same frequencies as the 2nd or 3rd or 4th or 5th scan, I very rarely, if ever, see an error in the nanoVNA-Saver data, even in continuous sweep mode. What is different about continuous sweep mode? Is there a pause between the scans?

I very rarely, if ever, see it with firmware from hugen dated August 2, 2019 using the exact same scan settings 2 or 3 or 4 or 5... Yes, I will occasionally see errors with the hugen firmware but they are quite rare and usually pretty obvious. Repeating a sweep or measurement will clear the errant data.

I don't know much about the transfer protocol between the nanoVNA and the PC. From your comment above, I would have to assume that you do not get the frequency information in the same message as the data so there is no way to throw out data based on the fact that the frequencies you requested are not the frequencies sent from the nanoVNA. Is that correct?

A few questions, mostly thinking out loud. :>) I wonder if data is being sent from the firmware before the hardware has actually stabilized at the new frequencies you have requested? Would it help to pause a bit after requesting a new set of frequencies?

I will continue looking for more clues to this issue.

--
Bryan, WA5VAH

It is clear from some of the comments I have seen here, that different
people have different uses for the NanoVNA. I'm just trying to get some
idea of what percentage of people have such uses, as it dictates whether
internal firmware or external programs like Nano-Sharp are of primary
importance to them. It is also likely to affect the screen size they want.

1) Some, like myself, want to use the NanoVNA away from a laboratory or
radio shack - most likely outside working on feeders, antennas or similar,
but maybe with antennas in loft spaces or similar.

Such people are likely to want at least some of the following.
* Bigger better screens readable in bright light.
* Support in the *firmware* for decent calibration standards
* Support in the *firmware* for other features like time domain
reflectometry (TDR)
* Such people are less likely to be interested in the capabilities of
external software such as VNA-Savert.
* Rugged device, suitable for outside use.

Rune's NanoVNA-Saver looks a lovely bit of software, but it is not much
good unless you work outside, unless willing to take a PC worth you.

*Please understand, I'm not getting at Rune here. In fact, I've been
thinking about the possibilites of using his sofware with HP VNAs. I'm sure
virtually any data that can be taken from the NanoVNA, could probably be
taken from the HP VNAs. Anything that could not be obtained from the HP
VNAs, could probably be ignored. Of course, all the command would be
different, but I don't see that as a major problem. Most of the work is in
the GUI I believe. *

2) Others are likely to use the instrument mainly inside a shack or
laboratory. For them
* The capabilities of external software, like NanoVNA-Saver, will be *very*
important.
* Facilities like TDR, or good calibration facilities in the firmware are
lunikely to be important, as external software can do this on a large
screen.
* NanoVNA screen size is possibly less importance, as being able to read
the screen outside clearly is no that imporant.

3) Some might be a mix of the two. In what case, what percentage of time do
you consider using the NanoVNA in such of the environments?

--
Dr David Kirkby Ph.D C.Eng MIET
Kirkby Microwave Ltd
Registered office: Stokes Hall Lodge, Burnham Rd, Althorne, CHELMSFORD,
Essex, CM3 6DT, United Kingdom.
Registered in England and Wales as company number 08914892

Tel 01621-680100 / +44 1621-680100