开云体育

On Tue, Oct 22, 2019 at 04:16 PM, Raymond Domp Frank wrote:

A new version is never a mature version. Old bugs may have been killed but new
(buggy?) features and behaviour will have been introduced.
It may be powerful and feature-rich, but it's not mature.

That doesn't mean that I'm not longing for a bit of time to try this version out!

Raymond

On Tue, Oct 22, 2019 at 03:42 PM, n2msqrp wrote:

This looks like a mature version.

A new version is never a mature version. Old bugs may have been killed but new (buggy?) features and behaviour will have been introduced.
It may be powerful and feature-rich, but it's not mature.

Raymond

Of course - it's under the GPL, so the source code must remain open :-)

--
Rune / 5Q5R

Hi,
Is it possible to have the source code of this firmware version?
Regards

I am joining the club. After update to 0.3.0 i got the same issue. Tried everything mentioned here but no help. I am now going to search for v 0.1.1 to see if it helps.

I have a Hugen nanoVNA with the gen111.taobao.com firmware.
I use it for HF measurements and have been happy with the performance.
I have been waiting for the firmware revisions to settle down before I upgrade.
This looks like a mature version.
Should I be aware of any issues when upgrading to this version?

Thanks to all for the effort.

Mike N2MS

I meant lines drawn on graph that show where is 1:1.5 and 1:2 measurement regarding of the scale.

I also vote for hobby version. Two tracks are good enough and large fonts are must.

There is also reald fork () that keeps four tracks but sets somewhat larger font. It is at more readable.

I got NanoVNA with some old firmware. It worked ok up to 900 MHz. as it was missing number of features I decided to do upgrade.

I upgraded to reald NanoVNA-0.3.1-20191021-FONT.

After that I cannot do proper calbration for frequencies above 310 MHz.

Calibration for whole range 50kHy to 900MHz does not work, smith chart shows random lines all over the screen.

Calbration for range 1 MHz o 30 MHz works fine.

Also, calibration for range 100MHz to 310 MHz works ok.

But if I try any range that uses frequencies above 310 MHz shows erraticall readings.

On Tue, Oct 22, 2019 at 08:41 AM, Bo, OZ2M wrote:

How about using tablets for user interaction? I have no idea if the USB
communication is fast enough. But there is A LOT of older tablets that are
unused and being en route to scrap. I mean if they are stripped for all the
clutter and just run Android and a simple 1:1 viewer of what would otherwise
be shown on the NanoVNA itself.

Unfortunately, older Android OSes don't support the libraries needed by the application.
I think the earliest OS is Android 6 for the WEBusb app which runs nicely on my 8" tablet.

So - I installed the latest ALEX_M firmware that QRP posted the other day that will produce a red PLL on the display if it detects the synth will not go above 260MHz.

I got the dreaded RED PLL.

Even if I clear/reset the config and recalibrate, I get crazy lines all over the display.

Flashing the previous version of Hugen's AA Oct-18 F/W restores operation.

Who's firmware is correct and has anyone (Erik?) other than QRP confirmed that Alex_M's firmware actually works as described?

Thanks,
Larry

Hi

How about using tablets for user interaction? I have no idea if the USB communication is fast enough. But there is A LOT of older tablets that are unused and being en route to scrap. I mean if they are stripped for all the clutter and just run Android and a simple 1:1 viewer of what would otherwise be shown on the NanoVNA itself.

Bo

And that is why we have Rune's NanoVNA-Saver app......
Again, this device is great as a PORTABLE tool.
However, for BENCH WORK it's very advantageous to pair it with a PC running Rune's 'Saver application on a nice big computer display with several graphs/charts simultaneously displaying all the parameters you require without the need to decipher each trace on a single cluttered 2.8" display.
For precision work like tuning xtal filters, use the 'Saver app.
For field work, the AA version is best.
It always comes down to using the best tool (H/W, S/W or both) for the job at hand and not just creating one fantastically all inclusive device just because you can.

I will put in an enhancement request to Hugen to shift the STOP freq field to the left slightly to get another digit (or 2) to show.

Regards,Larry

It's easy to understand why Transmission Line Transformers work that way. The only time the transformation is perfect is when the TLT sees the designed-for impedance on its output. For instance, here is the impedance at my 1:1 choke-balun's input vs the impedance on the output looking into a ZS6BKW. The only time the transformation is 1:1 is when the impedance looking into the ZS65BKW is 50 ohms because that's the only time the SWR is 1:1.

On Tue, Oct 22, 2019 at 02:47 PM, Larry Rothman wrote:

1.hobby grade << two trace, large font, Ham-centric radio development and
testing version

I think two traces is not enough for hobby grade. For example, if you're tuning some bandpass filter you're want to see S11 logmag, S21 logmag and VSWR. Sometimes it even needs to show also S11 phase track. Usually I'm using all 4 tracks for hobby grade tasks, they configured in the following way:
1) S11
2) S21
3) VSWR
4) Smith.

These tracks are enough for almost all hobby grade tasks, and usually I just don't needs to change tracks, because all information already on the screen just after power on. Sometimes I change 4 track from Smith to Phase or Phase Delay.

Regarding to font size, just compare how looks AA version and normal versions (see screenshots).
As you can see AA version can't show that frequency is 123'456'789 Hz.

When you're using it for hobby grade, you're needs to tune Crystal filters with 3 kHz bandwidth. So, if device show you frequency with 1 kHz resolution, it is not enough. Because hobby grade ham radio amateur wants to see it with at least ±100 Hz resolution or even better.

Thank you. I actually have found an interesting ili9486 display. It's a 4.0" display for 13 us bucks, found here:

Wouldn't it be nice to have a nanoVNA where we can choose the right bridge for the right job? Software side is the easy part, but how to implement the hardware. Via plug in modules or switching units.

Tuck m0tcc

Good suggestion. I fall into the hobby ham group most definitely.

Paul G0VKT.

On Tue, Oct 22, 2019 at 06:50 AM, QRP RX wrote:

also AA firmware shows marker frequency with cut off hundreds of Hertz,
because it doesn't fit due to large font

For users with eyesight limitations, the larger font is good.
For many users, 2 traces will also suffice and the missing digits under 1KHz are not that important when at the top of a tower doing a test at even 1MHz

Again, the NanoVNA is a HOBBY device - not a laboratory, precision-engineered tool.

Being opensource is great as it allows everyone to 'play' with the hardware and firmware.

I think there should be two major distributions/forks of the firmware:

1.hobby grade << two trace, large font, Ham-centric radio development and testing version
2.experimental grade <<push-the-limits to 'see what this baby can do' version

Comments?

#68 : On The Most Reliable Comparison of [NanoVNA] with
any laboratory [VNA]

Hello,

Allow us, please, to inform you that we just revised the first
part of our previous answers [*] to our Fellow in Knowledge
Gary O' Neil, N3GO, in a way more general than that
personal one, as follows:


Q 00 GON : "I wish to have some clarification that I am
interpreting the test configuration correctly."

A 00 GZA : It is our pleasant duty to reply your specific
Questions regarding our work !

-

Q 01 GON : "What were the Putty commands you used to extract data
from the NanoVNA?"

A 01 GZA : The commands to [NanoVNA] using PuTTy are: [info],
[frequencies] and [data], as these are shown as headers inside
our data files, in order to make perfectly clear what we are
talking about, that is:

[info] to get the specific firmware information of [NanoVNA]

[frequencies] to get the 101 frequencies at which our [NanoVNA]
makes its measurements f by default, into a file with a name
clearly showing the letter f

[data] to get the 101 measurements at these 101 frequencies,
right after the connection and measurement of each of the four
4 needed loads, as follows:

SHORT, into a file with a name clearly showing the letter s,

LOAD, into a file with a name clearly showing the letter l,

OPEN, into a file with a name clearly showing the letter o, and

GAMMA, into a file with a name clearly showing the letter g

(see reference [1], please, just after the end of this text),
but take into account, please, that you have to edit all these
files in order to remove any headers and leave just 101 lines of
data, that is the number of frequencies of our [NanoVNA], if you
intend to use them with the current version of our [TheLeastVNA]
code (see [2]).

-

Q 02 GON : "Can you confirm the data as raw (uncorrected) or post
calibration corrected measurements?"

A 02 GZA : Sure. These data were directly obtained right after
each of the four needed measurements [A 01] shown in PuTTy's
console window and then selected, copied, and pasted to the
corresponding file [A 01]

-

Q 03 GON : "Your VNA data (blue) appears to have been taken at a
significant offset from the reference plane."

A 03 GZA : Not at all. Our [VNA] data were taken exactly on the
same reference plane as that of our [NanoVNA]. Otherwise a
comparison between the results in our Full Final Report 1
(see [3]) would not be possible at all, as it would not make any
sense at all. Please, be careful at this very point - you have
been warned.

-

Q 04 GON : "If this is uncorrected raw data it makes sense in an
automated VNA environment."

A 04 GZA : Yes, but not only.

Since, as you can see, this also can make sense in our [NanoVNA]
environment too, because it was by this most appropriate use of
it that we were finally been in the place to compare it in our
way with our [VNA], in the most reliable way.

In fact:

* W e * c o u l d * n o t * c u r r e n t l y * s e e * a n y *
* o t h e r * w a y * t o * d o * a * r e l i a b l e *
* c o m p a r i s o n * o f * a n y * [NanoVNA] * w i t h *
* e x i s t i n g * l a b o r a t o r y * e q u i p m e n t *
* a r o u n d * o f * [AnyVNA], * o t h e r * t h a n
* t h i s * v e r y * w a y * w e * f o l l o w e d * i t *.

But, if you can - or any other Fellow in Knowledge member of
this Group can - suggest another one, more reliable way than of
ours, please let us know accordingly.

Sincerely,

gin&pez@arg

References

[*]
#67 : On [TheLeastVNA] : 18 Questions and 15 Answers
/g/nanovna-users/message/5428
21 October 2019

-

[1] The needed data files

[info]: header in all of the following files

[frequencies]: sub-header in:


[data]: sub=header in:





-

[2] The Code

The core statements
#54 : [TheLeastVNA] Code with an Application to [NanoVNA]
/g/nanovna-users/message/5137
18 October 2019

The Instructions to use [TheLeastVNA]
#59 : UPDATE : [LeastVNA] : version 20191020
/g/nanovna-users/message/5269
20 October 2019

The current version
#65 : [TheLeastVNA] Code - Update 20191020
/g/nanovna-users/message/5356
20 October 2019

Direct Download:


-

[3] The Full Final Report 1:
#51: the full final report 1 with contiguous full online images is
here :

17 October 2019
/g/nanovna-users/message/5063

68#