|
Larry,
Thanks - I didn't see it under releases.....
Roger
|
Herb,
Some of these changes look fairly nice - especially the fonts. I wonder if Hugen will merge them into his firmware.
Roger
|
On Wed, Feb 26, 2020 at 11:28 AM, Roger Need wrote:
Some of these changes look fairly nice - especially the fonts. I wonder if Hugen will merge them into his firmware.
=============================================================
Roger,
When hugen updated the -H4 firmware he merged edy555's 0.6.0 code into it. I expect he'll continuie that trend with the -H4 since he has plenty of flash memory to work with. I think the proportional fonts and units are a shoo-in. On the other hand, hugen has had to eliminate a save location and perform other optimizations just to have a -AA version. So merging 0.7.0 into the -AA firmware probably will depend on whether the extra 10 kb of flash memory saved in 0.7.0 is sufficient.
Of course other than the -H4, any NanoVNA-H including the v3.4 can take advantage of edy555's 0.7.0 right now without waiting for hugen to merge it into his non -AA firmware.
- Herb
|
On Wed, Feb 26, 2020 at 11:28 AM, Roger Need wrote:
Some of these changes look fairly nice - especially the fonts. I wonder if Hugen will merge them into his firmware.
=============================================================
Roger,
I forgot to touch on the fact that edy555's ver 0.6.0 and 0.7.0 opened up the stop frequency to above 1.5 GHz without any fanfare. This was done primarily to allow user's with NanoVNA-H v3.4 boards to experiment with the boards improvements above 1.5 GHz without any performace guarantee. The stop frequency change wasn't merged into hugen's latest -H4 release with the rest of the 0.6.0 code. I keep the edy555 0.7.0 firmware on my NanoVNA-H v3.4 if for no other reason than to be able to perform s21 measurements to 2 GHz with reduced dynamic range.
BTW, I enjoy following your content on the NanoVNA Facebook group. You have a lot more patience than I do, as I believe some of the group's members would have been better off purchasing an SWR meter :)
- Herb
|
Hi Herb,
after upgrading the edy555-0.7.0 firmware i thought i would do noise reduction stuff on v3.1 pcb.
I managed to make the conversion - adding that a P-MOSFET circuit does not charge the battery when turned on.
The battery is only charged when the power is off.
I was able to calibrate to 2.5GHz with the calibration kit that came with the device.
I didn't plan on measuring something at such a high frequency, the calibration also shows that something has changed.
I am very pleased that edy555 is developing successfully.
Fortunately, the nanoVNA-Saver completed the screen save, even though the stop frequency was not accepted.
Attachment: OSL 500M-2500M-2700M
73, Gyula HA3HZ
|
Speaking of the latest firmware, I am new at this so don¡¯t be too brutal, I downloaded it and tried to convert it to DFU using Dfu-Util file manager. It won¡¯t process the hex file for me and the bin processes but doesn¡¯t show up anywhere.
Thanks,
Jerry
toggle quoted message
Show quoted text
On Feb 26, 2020, at 11:28 AM, Roger Need via Groups.Io <sailtamarack@...> wrote:
Herb,
Some of these changes look fairly nice - especially the fonts. I wonder if Hugen will merge them into his firmware.
Roger
|
On Wed, Feb 26, 2020 at 11:20 PM, Jerry wrote:
Speaking of the latest firmware, I am new at this so don¡¯t be too brutal, I
downloaded it and tried to convert it to DFU using Dfu-Util file manager. It
won¡¯t process the hex file for me and the bin processes but doesn¡¯t show
up anywhere.
Thanks,
Jerry
On Feb 26, 2020, at 11:28 AM, Roger Need via Groups.Io <sailtamarack@...> wrote:
Herb,
Some of these changes look fairly nice - especially the fonts. I wonder if
Hugen will merge them into his firmware.
Roger
There is a part of the DfuSe Demo program called the DFU file manager. This will convert it from hex file to .dfu extension. If you remember Larry has already uploaded the .dfu file here, you can download it here: /g/nanovna-users/message/11251
|
I was not able to get the file manager to convert the hex. Gave an error. The bin worked but didn¡¯t produce a dfu file. Then searching I found the January update in DFU mode.
Thanks for the reply.
I still have issues with SWR. After calibration, my 75 ohm standard is producing 82.4 ohms on the Nano. I have more exploring to do before posting about it.
Regards,
Jerry
toggle quoted message
Show quoted text
On Feb 26, 2020, at 2:29 PM, Gyula Molnar <gyula.ha3hz@...> wrote:
On Wed, Feb 26, 2020 at 11:20 PM, Jerry wrote:
Speaking of the latest firmware, I am new at this so don¡¯t be too brutal, I
downloaded it and tried to convert it to DFU using Dfu-Util file manager. It
won¡¯t process the hex file for me and the bin processes but doesn¡¯t show
up anywhere.
Thanks,
Jerry
On Feb 26, 2020, at 11:28 AM, Roger Need via Groups.Io <sailtamarack@...> wrote:
Herb,
Some of these changes look fairly nice - especially the fonts. I wonder if
Hugen will merge them into his firmware.
Roger
There is a part of the DfuSe Demo program called the DFU file manager. This will convert it from hex file to .dfu extension.
If you remember Larry has already uploaded the .dfu file here, you can download it here:
/g/nanovna-users/message/11251
|
Jerry, I could never get a bin file to convert. It always produced a small output file.? Since you're new to this, please read my userguide... /g/nanovna-users/files/NanoVNA-User-Guide-English-reformat-Jan-15-20.pdfLook at page 28. Follow the instructions and when you click the Generate button, you will see a default value of *.dfu for a filename. Replace the * with the name you want.? ... Larry On Wed, 26 Feb 2020 at 6:24 PM, Jerry<jerry@...> wrote: I was not able to get the file manager to convert the hex.? Gave an error.? The bin worked but didn¡¯t produce a dfu file.? Then searching I found the January update in DFU mode. Thanks for the reply. I still have issues with SWR.? After calibration, my 75 ohm standard is producing 82.4 ohms on the Nano.? I have more exploring to do before posting about it. Regards, Jerry
On Feb 26, 2020, at 2:29 PM, Gyula Molnar <gyula.ha3hz@...> wrote:
On Wed, Feb 26, 2020 at 11:20 PM, Jerry wrote:
Speaking of the latest firmware, I am new at this so don¡¯t be too brutal, I
downloaded it and tried to convert it to DFU using Dfu-Util file manager.? It
won¡¯t process the hex file for me and the bin processes but doesn¡¯t show
up anywhere.
Thanks,
Jerry
On Feb 26, 2020, at 11:28 AM, Roger Need via Groups.Io <sailtamarack@...> wrote:
Herb,
Some of these changes look fairly nice - especially the fonts.? I wonder if
Hugen will merge them into his firmware.
Roger
There is a part of the DfuSe Demo program called the DFU file manager. This will convert it from hex file to .dfu extension.
If you remember Larry has already uploaded the .dfu file here, you can download it here:
/g/nanovna-users/message/11251
|
On Wed, Feb 26, 2020 at 02:09 PM, Gyula Molnar wrote:
".. I was able to calibrate to 2.5GHz with the calibration kit that came with the device. I didn't plan on measuring something at such a high frequency, the calibration also shows that something has changed. I am very pleased that edy555 is developing successfully..."
====================================================================================
Gyula,
The NanoVNA-H 3.4 results for my unit are similar to your modifications. The S21 noise floor averages about 30 dB above 1.5 GHz to about 2.2 GHz. That is good enough for my use. Reflection measurements get pretty noisy after 1.5 GHz and I don't put much reliance on them.
Its been years since edy555 made any contributions on the hardware side, which really surprises me. I too am happy that he has continued his development of the NanoVNA firmware. Every time he or one of the other developers adds a new firmware feature it's like getting a new toy for free.
- Herb
|
Larry, I tried every combination of generate and file name for about an hour before looking for the DFU again and finding it uploaded. The hex file gave me an error but the bin file, in every case displayed that it was generated but I couldn¡¯t fine the file. I¡¯m familiar with all these tools as I¡¯ve programmed a number of STM32F4 and F7 boards using 3 or 4 IDEs. Thanks for the guide. I¡¯ve been in there a bunch. Jerry On Feb 26, 2020, at 3:47 PM, Larry Rothman <nlroth@...> wrote:
Jerry,
I could never get a bin file to convert. It always produced a small output file.
Since you're new to this, please read my userguide...
/g/nanovna-users/files/NanoVNA-User-Guide-English-reformat-Jan-15-20.pdf
Look at page 28. Follow the instructions and when you click the Generate button, you will see a default value of *.dfu for a filename. Replace the * with the name you want.
... Larry
On Wed, 26 Feb 2020 at 6:24 PM, Jerry<jerry@...> wrote: I was not able to get the file manager to convert the hex. Gave an error. The bin worked but didn¡¯t produce a dfu file. Then searching I found the January update in DFU mode.
Thanks for the reply.
I still have issues with SWR. After calibration, my 75 ohm standard is producing 82.4 ohms on the Nano. I have more exploring to do before posting about it.
Regards,
Jerry
On Feb 26, 2020, at 2:29 PM, Gyula Molnar <gyula.ha3hz@...> wrote:
On Wed, Feb 26, 2020 at 11:20 PM, Jerry wrote:
Speaking of the latest firmware, I am new at this so don¡¯t be too brutal, I
downloaded it and tried to convert it to DFU using Dfu-Util file manager. It
won¡¯t process the hex file for me and the bin processes but doesn¡¯t show
up anywhere.
Thanks,
Jerry
On Feb 26, 2020, at 11:28 AM, Roger Need via Groups.Io <sailtamarack@...> wrote:
Herb,
Some of these changes look fairly nice - especially the fonts. I wonder if
Hugen will merge them into his firmware.
Roger
There is a part of the DfuSe Demo program called the DFU file manager. This will convert it from hex file to .dfu extension.
If you remember Larry has already uploaded the .dfu file here, you can download it here:
/g/nanovna-users/message/11251
Jerry Hancock jerry@...
|
Does anyone remember off the top of their head if the version before this from Edyy555 allowed 10 kHz start frequency?
Steve
|
IIRC, only QRP's firmware went down to 10khz.?
On Sat, 29 Feb 2020 at 7:59 PM, Stephen Hughey<shughey@...> wrote: Does anyone remember off the top of their head if the version before this from Edyy555 allowed 10 kHz start frequency?
Steve
|
On Sun, Mar 1, 2020 at 04:51 AM, Larry Rothman wrote:
" IIRC, only QRP's firmware went down to 10khz.?"
=================================================
hugen's current releases for the NanoVNA-H (including -AA version) and NanoVNA-H4 also go down to 10 kHz.
- Herb
|
Operating frequency 10 KHz -1.5 GHz. Old, familiar colors, and increased marker movement speed.
|
Dislord, the talented Russian coder, who collaborated with edy555 on his recent 0.7.0 firmware release has uploaded a beta 0.8 firmware with the following Google directly translated Russian comments:
" After edy555 added my font fixes, optimized space in RAM, I was offered many fixes regarding the speed, functionality and optimization of resources
In this beta firmware I added the color command, accelerated the speed of display and scanning, eliminated artifacts when displaying, accelerated marker and included display of the marker data when driving, eliminated problems with third-party software and more (as was the limit on the size of the site) add something else, 80% of the code was rewritten, as a result released about 18kB pso (Flash?) and 3kB oz (RAM?), which will give the opportunity to further build up the functionality) I post the current beta version at .
What is interesting, since the library for the generator has been rewritten, and the scanning has been significantly accelerated (but the stability must be improved), I would like to check whether everything has become good or bad (it is desirable to make a comparison with firmware from edy555 v0.7 and the last from hugen) the firmware is suitable for the original NanoVNA and NanoVNA-H, but not suitable for F or H4 (there is another processor and screen).
Maybe (if I buy the H4 version) I'll adapt the changes for it as well.
PS despite the faster-acting processors in the F and H4 versions, they don't work faster (the larger screen is a big load on the data processor) and the original NanoVNA bottleneck had a lack of resources (which was eliminated), as most of the time (about 60% of the time) the processor is idle waiting for the results of measurements, which has been much improved. " End of Quote
I loaded the beta firmware version on my NanoVNA-H without any problems using DFU-Demo. Screen update is faster and none of the display artifacts observed in previous firmware versions was noted during limited testing. This is a beta firmware version release so any bugs should be reported to DisLord's GitHub page. If you are not adventurous I would suggest waiting for edy555's official 0.8.0 release. Reiterating DisLord, please note that this beta firmware release is not for the NanoVNA-H4 or NanoVNA-F because they use different processors and screen sizes than the NanoVNA-H.
- Herb
|
Thanks Herb!
On the larger screen being a lot slower, it should only be slower based on the number of pixels compared between models.
I had to do a lot of rewriting of library lcd routines from Adafruit and others.? My screen updates were unacceptable using
the standard library routines.? I timed how long it took to write an entire line of text 32 pixels high.? then, starting to rewrite
the stuff one part at a time.? I ended up with code that was 17x faster.
I am hoping that was the "old" days 3 years ago, where the library routines were functional, but not optimized!
73
Glen K4KV
toggle quoted message
Show quoted text
On 3/14/2020 14:40, hwalker wrote: Dislord, the talented Russian coder, who collaborated with edy555 on his recent 0.7.0 firmware release has uploaded a beta 0.8 firmware with the following Google directly translated Russian comments:
" After edy555 added my font fixes, optimized space in RAM, I was offered many fixes regarding the speed, functionality and optimization of resources
In this beta firmware I added the color command, accelerated the speed of display and scanning, eliminated artifacts when displaying, accelerated marker and included display of the marker data when driving, eliminated problems with third-party software and more (as was the limit on the size of the site) add something else, 80% of the code was rewritten, as a result released about 18kB pso (Flash?) and 3kB oz (RAM?), which will give the opportunity to further build up the functionality) I post the current beta version at .
What is interesting, since the library for the generator has been rewritten, and the scanning has been significantly accelerated (but the stability must be improved), I would like to check whether everything has become good or bad (it is desirable to make a comparison with firmware from edy555 v0.7 and the last from hugen) the firmware is suitable for the original NanoVNA and NanoVNA-H, but not suitable for F or H4 (there is another processor and screen).
Maybe (if I buy the H4 version) I'll adapt the changes for it as well.
PS despite the faster-acting processors in the F and H4 versions, they don't work faster (the larger screen is a big load on the data processor) and the original NanoVNA bottleneck had a lack of resources (which was eliminated), as most of the time (about 60% of the time) the processor is idle waiting for the results of measurements, which has been much improved. " End of Quote
I loaded the beta firmware version on my NanoVNA-H without any problems using DFU-Demo. Screen update is faster and none of the display artifacts observed in previous firmware versions was noted during limited testing. This is a beta firmware version release so any bugs should be reported to DisLord's GitHub page. If you are not adventurous I would suggest waiting for edy555's official 0.8.0 release. Reiterating DisLord, please note that this beta firmware release is not for the NanoVNA-H4 or NanoVNA-F because they use different processors and screen sizes than the NanoVNA-H.
- Herb
|
Hot on the heels of his beta 0.8 firmware release for the NanoVNA, DiSlord has followed it up with an additional beta firmware release which adds user selectable averaging via a "DISPLAY->BANDWIDTH" menu. Bandwidth can be set to 1 kHz, 300 Hz, 100 Hz, 30 Hz or 10 Hz. As any who has used a commercial VNA can tell you, using averaging can smooth out your data but at the expense of sl-o-o-owing down sweep rates. Truly no such thing as a free lunch.
Latest beta is located at . This is a preview of where the next edy555 firmware release is headed.
I thought there were no more tricks in the firmware developers bags to add more features to the limited flash space of the NanoVNA-H. That was t the main reason I begin gravitating towards the NanoVNA-H4 and NanoVNA-F. DiSLord's re-write and optimization of the NanoVNA's firmware, shows the NanoVNA-H is not quite ready to relinquish its crown. Looks like the -H4 and -F will be behind the curve until the upcoming edy555 firmware releases are ported to them.
Per DiSLord:
"When you drop below 1kHz, the scanning speed is significantly reduced, and the responsiveness of the menu drops, but is generally workable."
Also as previously noted, this beta firmware release is not for the NanoVNA-H4 or NanoVNA-F.
- Herb
|
Hello,
If one uses *nanovnasaver*, what do you think it will be the best firmware?
I am fortunate to have a small PC at my desk to use with the VNA.
*73 de Lu¨ªs, CT2FZI*
<>
toggle quoted message
Show quoted text
On Mon, 16 Mar 2020 at 21:59, hwalker <herbwalker2476@...> wrote: Hot on the heels of his beta 0.8 firmware release for the NanoVNA,
DiSlord has followed it up with an additional beta firmware release which
adds user selectable averaging via a "DISPLAY->BANDWIDTH" menu. Bandwidth
can be set to 1 kHz, 300 Hz, 100 Hz, 30 Hz or 10 Hz. As any who has used a
commercial VNA can tell you, using averaging can smooth out your data but
at the expense of sl-o-o-owing down sweep rates. Truly no such thing as a
free lunch.
Latest beta is located at
.
This is a preview of where the next edy555 firmware release is headed.
I thought there were no more tricks in the firmware developers bags to
add more features to the limited flash space of the NanoVNA-H. That was t
the main reason I begin gravitating towards the NanoVNA-H4 and NanoVNA-F.
DiSLord's re-write and optimization of the NanoVNA's firmware, shows the
NanoVNA-H is not quite ready to relinquish its crown. Looks like the -H4
and -F will be behind the curve until the upcoming edy555 firmware releases
are ported to them.
Per DiSLord:
"When you drop below 1kHz, the scanning speed is significantly
reduced, and the responsiveness of the menu drops, but is generally
workable."
Also as previously noted, this beta firmware release is not for the
NanoVNA-H4 or NanoVNA-F.
- Herb
|
Roger Need
Gyula Molnar
Stephen Hughey
CT2FZI