开云体育

Hej Rune

Take your time! It is you who decide the pace of implementation and releases. Nobody else! All I want for Christmas is ... I will have to think.

My experience with adding tooltips is, that it is easier to write them, as the program progresses. Those missing can always be added later on.

Re units/div and grid structure we can discuss this later on. As it is right now the size of the traces may wobble a bit vs number of decimals of the measured parameters.

Bo

Background:

I received a nanoVNA with firmware in it dated 20190802 and time stamp 16:40:01. I learned this version information by using terminal emulator software and the "info" command. This firmware worked great by itself in the nanoVNA and also with all versions of nanoVNA-Saver I have, here, including 0.0.10, 0.0.11, and 0.0.12. In both the device and the nanoVNA-Saver software there would be a very occasional obvious error in the data; however, the rate of occurrence was very low and completely unobjectionable. In short, I was delighted with the device.

Desired upgrade:

The original firmware I received does not have TDR capability (it is available in nanoVNA-Saver) but newer versions from cho45 and edy555 promised to provide in-device TDR capability which I think is a very useful feature for a device like this.

Course of action taken to get improved capability:

Since cho45 put out a nice manual for his version of firmware, I decided to choose that version to install in my nanoVNA. After downloading the file NanoVNA_cho45_0.0.9.47.zip from



and unzipping the file, I installed "ch.dfu" into my nanoVNA using DfuSe_Demo V3.0.6 which was downloaded from the same Google Drive page. There were no issues reported during this process and, initially, everything appeared to be fine. I performed a new in-device, calibration; however, I had some significant difficulty getting what I thought was a good calibration due to obvious errors on the nanoVNA display screen.

On the device and in nanoVNA-Saver there are clearly data collection errors showing on all plots. They are definitely more frequent during scans using nanoVNA-Saver. At first, I thought this was a problem with the USB interface to the PC; however, they are present without even connecting the device to the PC (observed during the calibration process.)

So, I downloaded nanovna-firmware-0.2.2.zip which is created by edy555 from



This zip file does not contain a ".dfu" file; however, the "Dfu file manager" software with DfuSe_Demo V3.0.6 can create a ".dfu" file from a ".hex" so I did that conversion and then uploaded the result to my nanoVNA. No issues were reported during this whole process. However, the result is the very similar if not the same.

Resulting issues:

Certain frequencies seem to have repeated problems when scanning using nanoVNA-Saver version 0.0.12 software. During the scan of nanoVNA-Saver, the errors can be seen on the display of the nanoVNA itself. So, this does not appear to be a problem within the USB interface unless just exercising the USB interface is causing a problem. There are 4 or 5 obvious errors in a scan from 50 kHz to 900 MHz when using 5 101-point scans in nanoVNA-Saver. Often, the error will shift lower or higher in frequency by 1 sample; however, The errors are basically repeatable.

Questions:

Has anyone else used these versions of the firmware? Has anyone else had similar issues? What could I be doing wrong? Does this reflect a power supply by-passing issue in my particular device?

I did try to save a copy of my original firmware using DfuSeDemo. Has anyone else done this successfully? However, I have not tried to upload it to the device, yet. At this point, I am somewhat nervous about the whole thing. Does anyone know where can I find a known good copy of the firmware from August 2, 2019 at 16:40:01 in ".dfu" format?

--
Bryan, WA5VAH

That's probably why it's listed as "very alpha"!

Roy
WA0YMH

At least thru Paypal and Ebay we can take a mulligan. :-)
On Monday, September 30, 2019, 12:59:29 PM EDT, John VA7JBE via Groups.Io <va7jbe@...> wrote:

I rolled the dice, now we wait...

For anyone else having trouble running NanoVNA-Saver with Kaspersky anti-virus, simply make NanoVNA-Saver a "trusted application" under "exclusions" in Kaspersky settings.

Hah, I confuse myself: It was of course Dave, whom I just answered, who
suggested floating point max/min. Definitely, at some point, but for now
there's a number of charts that have issues with it. So I stuck to integers
in the first version. Probably going to be the release after the next. :-)

--
Rune

On Mon, 30 Sep 2019 at 19:45, Rune Broberg via Groups.Io <mihtjel=
[email protected]> wrote:

Hej Bo :-)

I think for now I'm going to stick to accepting correctly formatted
S-parameter files. I have made the development version accept the RFsim
files, but as this revealed a large number of bugs, I'm going to hold off
on working on the Elsie ones for a few days. The problem occurred once
*perfect* data was loaded, for example including readings that had exactly
0 real resistance leading to divide-by-zero when calculating Q.

Tooltips are an interesting enhancement, but given the development pace at
the moment, they're a luxury for a later time. ;-)

I'll consider improving the units on the charts. Someone elsewhere (I'll
get to them) suggested allowing decimal limits on the charts as well, which
will also need to be implemented, so maybe along with that.

Thanks for your continuing feedback :-)
--
Rune / 5Q5R

On Mon, 30 Sep 2019 at 19:01, Bo, OZ2M <groups.io@...> wrote:

Hej Rune

Here are some more ideas.

Loading (importing) S-files. Try to identify the source program, but also
show the first five, or a bit more, lines of the file. Then ask the the
user to confirm the source program/format from a number of radio buttons.

Adding tooltips can perhaps improve the usage/understanding of the

various

buttons and input fields.

To the right of the sweeps write the Hz/div. and dB/div.

Bo

Audio is exactly as nanovna. 3 mixers and stereo ADC. Switching witch manual switch for now

Hej Bo :-)

I think for now I'm going to stick to accepting correctly formatted
S-parameter files. I have made the development version accept the RFsim
files, but as this revealed a large number of bugs, I'm going to hold off
on working on the Elsie ones for a few days. The problem occurred once
*perfect* data was loaded, for example including readings that had exactly
0 real resistance leading to divide-by-zero when calculating Q.

Tooltips are an interesting enhancement, but given the development pace at
the moment, they're a luxury for a later time. ;-)

I'll consider improving the units on the charts. Someone elsewhere (I'll
get to them) suggested allowing decimal limits on the charts as well, which
will also need to be implemented, so maybe along with that.

Thanks for your continuing feedback :-)
--
Rune / 5Q5R

Hi Dave,
I might make an option to have the traces be wider - I recommend selecting
a high contrast colour for now. :-)

Thanks for the feedback!
--
Rune / 5Q5R

Some ten years ago I took some Chinese lessons with a native speaker living in Denmark. She told us that there are different kind of copies being made. There is the "Original" which is copied 1:1 into an "A copy". This one is then subject to minor mods and cost optimization resulting in a "B copy". Again this "B copy" is then subject to further mods which becomes a "C copy" and so on for many levels of copying. I.e. from the "B copy" and onwards the quality is going from relaxed to dubious.

Bo

I tried cho45's web app the other day. It looks great but it wouldn't work
at all on an elderly Lenovo tablet. It worked but in a very glitchy manner
on a Huawei M5 tablet, which resulted in large out of range excursions on
the charts. Looks like the NanoVNA's data isn't being read reliably.

The serial option seemed a little more stable but its still quite tricky
getting an uncorrupted screenshot.

Is anyone else having better success?

Mike B

I couldn't resist. I ordered this one if for nothing else, for spare parts. What will things be like a year from now?

Then again, those may be the "Rejects" !!

Richard S.

Sent from Outlook<>
________________________________
From: [email protected] <[email protected]> on behalf of Henning Weddig via Groups.Io <hweddig@...>
Sent: Monday, September 30, 2019 9:33 AM
To: [email protected] <[email protected]>
Subject: Re: [nanovna-users] Deal on ebay

it looks strange, only a few buyers, some of them are no longer
registered, other buyers did buy a lot of things from him.

Am 30.09.2019 um 17:45 schrieb Larry Rothman:ther buy a lot of items
from him...

Another eBay 'seller' - look for item# 362769877272 Now $17US

Probably a hijacked account.

Hej Rune

Here are some more ideas.

Loading (importing) S-files. Try to identify the source program, but also show the first five, or a bit more, lines of the file. Then ask the the user to confirm the source program/format from a number of radio buttons.

Adding tooltips can perhaps improve the usage/understanding of the various buttons and input fields.

To the right of the sweeps write the Hz/div. and dB/div.

Bo

I rolled the dice, now we wait...

To use the Nano, it is no problem that the IP5303 switches off after 35 seconds when switching off. For a battery pack with a low consumption device connected, that is something else.
The problem that I often hear is that the IP5303 does not switch on, with a consumption higher than 45 mA. I have already replaced and restored just about everything around the IP5303, but that doesn't help. The normal functions continue to work, only the start-up does not work.
The only solution is to start the IP5303 via the key pin 5 with a push button. This is only a partial solution, because after connecting the USB cable it no longer works.
After several days of measuring and testing, and 2x replacing an IP5303, I finally found a deviation. All measurements of the NanoVNA power consumption described here are actually wrong. You will not find any deviations.
However, if you are going to measure the power consumption of the IP5303 yourself, we will notice weird deviations.
The third day I planned to do only current measurements on the IP5306 and its components.
Like 'tinhead' suggested to place a resistor on C47, instead of a resistor I made a print with 4 lamps 6V / 60mA, and a 4-pole DIP switch.
This way I could switch the load per 60 mA on and off to observe the behavior of the IP5306.
Since the NanoVNA does not participate this time, the current must be measured at the 3.70V battery and not at the ON / OFF switch.
These prior measurements gave strange results:
Current measurement of the IP5303 in standby mode (32 sec): 2.70 mA
Current measurement of the NanoVNA, including the IP5303: 237mA!
Current measurement of the NanoVNA, minus the IP5303: 130mA.
Conclusion: the IP5303 has (too) high self-consumption.
I discovered that the IP5303 only worked well up to 222 mA. In addition, the IP5303 goes into a kind of protection mode, and switches off completely after about 10 seconds.
The following measurements are with my own load (lamps), without the Nano switched on.
With my external load I can therefore switch on 1,2,3 or 4 lamps.
1 lamp = 60 mA, 2 lamps = 120 mA, 3 lamps = 180 mA, 4 lamps = 240 mA.
With the standard inductor of 2.2 ?H (1 ?H also works, but the oscillator frequency is higher) and a load with:
1 lamp: current was 90.0 mA -> 30 mA too much
2 lights: current was 185 mA -> 65 mA too much!
3 lights: current was 276 mA -> 36 mA too much!
The load with 4 lamps did not want to start anymore.
This is really too much for the small Li-ion battery.
Strange is that the IP5303 with my own load did not fail, with the NanoVNA switched on it did fail.
So the ultimate consequence is that the NanoVNA does not want to start up, because it itself already needs 130 mA.
I did the same measurements again with a lab power supply connected instead of the battery, but the measurements were not much different.
The question is why the IP5303 does not meet its specifications.
There are probably some IPs that do not work well in some NanoVNAs.
Or some NanoVNAs have a slightly lower power consumption. I replaced the IP5303 twice, I was not lucky twice.
I'm still going to try with an IP5306, which could handle a slightly higher steam. But they still have to be ordered.

Probably the same seller as I posted since the write-up and pictures are identical.

it looks strange, only a few buyers, some of them are no longer registered, other buyers did buy a lot of things from him.

Am 30.09.2019 um 17:45 schrieb Larry Rothman:ther buy a lot of items from him...

I was hoping somebody would ask!
The bridge is simetrical. Just in your mind rotate it 90 degrees. I discovered using it this way improved directivity above 2 GHz

Any way you cut it, this is for gamblers... :-)
Mike WY6K


"... somewhere in the distance, there's a tower and a light, broadcastin' the resistance, through the rain and through the night..."