开云体育

It would if I had a H4 to test on Jos, but I don't have one so I can#t reliably compile it for the H4 unfortunately.
It would be easy enough for those out there with a H$ to make it H4 compatible if they are set up with the edit/compile tools.

Hi,

I tried this (once) with the latest code and it seemed to work fine. I also looked through the code and didn't see any reason for what you're describing. There have been a lot of changes to the export code recently.

Have you tried with the latest executable?

-Mark

Hi Larry,

On 15.07.20 12:28, Larry Rothman wrote:

Hi Holger, Thanks for the info on the low level operation. I had a
feeling that the NanovnaSaver application would be I/O bound,
impacting speed. As for the 32bit issue, I was thinking Nuitka might
be a useful utility but again, you're the expert here so you to
decide what's best to use. Cheers Larry

I would not say Nuitka wouldn't be better, but as now it is just
convenient to create binaries for linux, mac and windows with one
tool. So therefore there is less to debug if something broke in
build process.

73
Holger, DG5DBH

Some time ago I posted several comments regarding this. They were based on the ST manual and attending schematics.
1. The diode voltage drop approach left the diode operating intermittently (sampled too soon after turn on, IMO), and in an unstable region due to the low current draw. I don't know if the new units also use the diode.
2. I demonstrated a purely resistive approach, and was told that though the responder had not read the manual (I had), I must be wrong. I still have the resistor approach working well. (I attached references and schematics to my post...they were ignored in favor of "opinion".) The resistor approach obviated the diode questions.
3. ST ADC sampling recommendations were not followed, so the readings were all over the place. The solution implemented was to take many readings (I think 24?) and average them. I don't know if these were addressed, or if my suspicions are correct.

None of these statements are verified by another, so they are just my opinions.

4. Battery voltage probably fluctuates to some small degree depending on the capacity of the battery and the cycling of the CPU and hardware, depending on what function is performed. I have seen this on other small devices.
5. For me (maybe not for everyone) battery voltage to the nearest 10 mV is great. I don't care if the battery is at 3660 or 3680...I just want to know roughly how much operating time is left. I realize that this is a "field" response, not an "engineering" response, and I appreciate the value of both.

We should not be surprised at the erratic, but generally useful, VBAT values.

--
72/73 de Rich NE1EE
On the banks of the Piscataqua

Hi Holger,

By the time Rune started programming the "Early app for the NanoVNA" he was initially publishing 64-bit files. This changed in version 0.0.6 because he reported in message # 1950 that he was using the 32-bit version with the help of Ohan. (link: /g/nanovna-users/message/1950)
(Ohan link: )
Maybe He could help you with that - of course if you have a willingness to run the program on a 32-bit machine.

I apologize if my wording seems a little raw.
There are still many machines in use that run "only" 32 bits.
Otherwise, 0.3.0 ... 0.3.4 cannot be run on Windows 32 bits under Python, but 0.3.6 can already run.

73, Gyula HA3HZ
--
*** If you are not part of the solution, then you are the problem. ( ) ***

Hi Holger,?
Thanks for the info on the low level operation. I had a feeling that the NanovnaSaver application would be I/O bound, impacting speed.?
As for the 32bit issue, I was thinking Nuitka might be a useful utility but again, you're the expert here so you to decide what's best to use.?
Cheers
Larry


On Wed, 15 Jul 2020 at 6:02 AM, Holger Müller<dg5dbh@...> wrote: Hi Larry,

On 15.07.20 01:14, Larry Rothman wrote:

One of the newsletters I receive had an article on malware written in
Python. Part of the discussion revolved around how to get the size of
the windows package down and there were 3 different Python to EXE
utilities presented that are used for non-malware Python to Windows
uses.

One of these is: Nuitka -

Right now, the NanoVNA-Saver EXE application is very large and takes
time to execute. What Nuitka does is to convert Python code to C and
then compile. The resultant application size is a fraction of what
you get with py2exe or pyinstaller and runs much faster.

I doubt. Start up time can be shorter, but most timeconsuming in
the program is serial communication with the devivce. This wouldn't
benefit from such optimization.
GUI-Code is QT so when instantiated, tha code runs as native c++
compiled binaries.
Bigger calculations like averaging and spline interpolation
which uses native c lib with numpy.

Could you try Nuitka on NanovnaSaver to see if it speeds up the
application? I did not look over the entire website but if Nuitka
compiles C, it might be able to generate both 32 and 64 bit
binaries.

The 32bit issue is related to the fact, that i haven't found
a 32bit build env in github actions. It has nothing to do if
a transpiling would take place.

73
? ? Holger, DG5DBH

Hi Larry,

On 15.07.20 01:14, Larry Rothman wrote:

One of the newsletters I receive had an article on malware written in
Python. Part of the discussion revolved around how to get the size of
the windows package down and there were 3 different Python to EXE
utilities presented that are used for non-malware Python to Windows
uses.

One of these is: Nuitka -

Right now, the NanoVNA-Saver EXE application is very large and takes
time to execute. What Nuitka does is to convert Python code to C and
then compile. The resultant application size is a fraction of what
you get with py2exe or pyinstaller and runs much faster.

I doubt. Start up time can be shorter, but most timeconsuming in
the program is serial communication with the devivce. This wouldn't
benefit from such optimization.
GUI-Code is QT so when instantiated, tha code runs as native c++
compiled binaries.
Bigger calculations like averaging and spline interpolation
which uses native c lib with numpy.

Could you try Nuitka on NanovnaSaver to see if it speeds up the
application? I did not look over the entire website but if Nuitka
compiles C, it might be able to generate both 32 and 64 bit
binaries.

The 32bit issue is related to the fact, that i haven't found
a 32bit build env in github actions. It has nothing to do if
a transpiling would take place.

73
Holger, DG5DBH

HI,

Is your firmware usable for the NanoVNA -h4 version ?

Thanks

Jos


Op 14-7-2020 om 22:22 schreef OneOfEleven:

On version screen i show averanged from 32 vbat measure.
On vbat command - only one read.
Yes i know about noise on ADC (on next version added additional L/C filter for ADC ref in CPU), for graphic vbat icon not need this filter (need 0.1V step).

Hi Igor

I added a low pass filter to the battery voltage reading in my firmware some time back because of this. See what that tells you. If it's any better then maybe DiSlord could implement the same (very simple) LPF in his firmware ?

ADC readings can be a bit noisy on the NanoVNA due to the circuit/board design (ADC inputs should normally be R/C or L/C filtered along with any ADC supply/reference pins), having a switched mode boost converter on the PCB doesn't help (they are noisy beasts).

Hi, despite many "battery" related posts here with interesting info on batteries I opened my new H4 (1950mAh battery there, no sd socket) and measured the voltages at the battery connector. H4 freshly charged over night.

My HP34401A meater reads (aprox. 1min between measurements)

1. H4 turned off, no usb cable: 4.212V
2. H4 turned on, no usb cable: 4.153V +/- 2mV
3. H4 turned on, with active usb cable connected: 4.223V

During step 3 with vbat_offset set to 0 the vbat command returned values from 3682-3823.

My current understanding is as follows:
1. the battery gets a little bit overcharged
2. the "vbat" ADC reading is pretty noisy (see the graph below), provided it is done via stm32's 12b ADC, with a 2layer pcb and some decoupling the readings should stay within +/- 10mV, imho.

Hi AF7XT,
Please try 0.3.6 - possible version error, although I couldn't start only 0.3.6 on a 32-bit system.
73, Gyula HA3HZ
--
*** If you are not part of the solution, then you are the problem. ( ) ***

Thank you all for your help on this. Bought the NanoVNA-H last year and now could not resist the temptation to buy the H4 version with more features added!

BR
Nan

See this post for more information
/g/nanovna-users/message/14447

Hi Nan, here you can see the DiSlord firmware and links to the descriptions:
/g/nanovna-users/message/14450
Successful use

73, Gyula HA3HZ
--
*** If you are not part of the solution, then you are the problem. ( ) ***

Hi Hugen

Many thanks for the confirmation and I am relieved to note that I have bought an original version! The 32.768KHz X'tal is missing on this board although the MicroSD card is installed. Can you please point me to the need for the X'tal? I am away from home and might take several weeks before I can get back to my shack due to the pandemic.

BR
Nan

This version is produced by me. Thanks to DiSlord for completing the transplantation of microSD. For the newly produced PCB, we have installed a MicroSD card slot and replaced the 2000mAh battery. You can refresh DiSlord's latest firmware and use the microSD card after making holes in the case. I will modify the case and add a 32.768kHz crystal when the next larger version is updated.

Wow, you already have the SD-Card reader populated! The black box and that
SD card reader strongly suggests an authentic one, of the latest batch.
--
Sent from my mobile device, apologies for typos

PGP key:

Hi All

I just purchased a NanoVNA-H4 from a China seller via Lazada.sg in Singapore.
Can I get help to confirm if this is the original made by Hugen or a clone? It came pre-loaded with Hugen's latest firmware version of 21 Feb 2020.

BR
Nan

The iphone and android phones here in the house show both a battery icon level and the percentage at the same time, which we really like. I guess they know what their customers like (or not). But it's easy enough to comment out the bit of code I added to not show the battery percentage for those that don't want it, I'll add a #define in the nanovna.h file to make it easy to choose what one would like Larry.

But anyway, I need to move on soon, hopefully I've shown a tiny bit of what could be done to niciefy things up a teeny bit and add a little extra functionality. Lots more wonderful things could be done, a VNA is a tool that can do big things, but I really need to concentrate on other stuff. I may publish other changes/additions I need for my own use, but most likely at a later date.

Don't forget though, the user interface/experience is all important, as is functionality, they both go hand in hand, one without the other gets noticed very quickly on, any good user will/should thank you if at the end of the day they've had a nice and easy and fascinating time playing with what you've given 'em.

Tiz a wonderful and useful project !