Hi Rune,
Many thanks again for your ongoing development of nanoVNA-Saver - fabulous work!
I am not sure if I should waste your time reporting this as it is not a significant issue....just apple polishing.
I noticed when I first start version 0.2.0 that the Center, Stop and Span frequency info within "Sweep Control" section overflows the window widths. At startup it displays 9 digits as shown below. Once I enter new sweep control frequencies it displays normally. However Center still overflows just a little. I have my sweep Stop set at 850M and the Center is showing 425.025MHz which just exceeds the window width by about a half digit. With initialization the data is about twice as wide as the window width with the most significant digits hidden from view then it reverts to normal upon receiving a new manual frequency entry.
Initialization displayed data:
SPAN 849.949952MHz
STOP 849.999952MHz
CENTER 425.024976MHz
Hope this feedback is useful.
--
Best Regards,
Tom
VA7TA
|
Re: Correction menu option ?
|
Thanks for doing the test Nick! I guess we are all having a great time working with this little unit. I was considering buying an 8753 and retrofitting it with an after-marked LCD display but I think for what I am doing now the Nanovna is all I need. Just wish it could measure higher impedances more accurately but when that is needed I have used my old General Radio bridges.
|
I am using the free STM32CUBEIDE from ST Micro the Mc manufacture
to build some SDR control code for a home project and it seems to work well. I guess STM32CubeMX integration and STM support are main claims to fame for STM32CUBEIDE, which otherwise is another customization of ECLIPSE?/CDT IDE. NanoVNA uses ChibiOS, which has a dedicated ECLIPSE?-based IDE, namely ChibiStudio, and a utility for converting CubeMX output for ChibiOS ... which is already done for nanoVNA source, then STM32CUBEIDE seems for ChibiOS firmware a step backwards from ChibiStudio
|
Re: errors of "error" models
[ann] next-to-come : on the measurement of s-parameters using the [LeastVNA] only
|
Re: Correction menu option ?
Why would you want to ever disable this?
|
Re: [nanovna-f] NanoVNA-Saver 0.2.0
An excellent piece of software just got better. Congratulations and thanks for your efforts !73 de YO4AUL
toggle quoted message
Show quoted text
On Tuesday, November 12, 2019, 03:35:23 PM GMT+2, Rune Broberg <mihtjel@...> wrote:
Earlier today I released NanoVNA-Saver 0.2.0: notes:New feature: Zooming
This release adds the ability to "zoom" on the frequency-based charts: Use your mouse's scroll wheel to zoom in and out - or hold the control button and drag a box on the chart to zoom into.
New chart type: Group Delay
Group delay can now be displayed as a chart, and can also be enabled for the marker data display for both S11 and S21.
New chart type: Permeability
A new chart, R/¦Ø & X/¦Ø, is available for determining permeability characteristics of toroids. Thanks to David, F4HTQ, for requesting and helping out with this.
Logarithmic Y-scale:
The VSWR and Permeability charts now have the option of having the Y-scale shown as Linear or Logarithmic.
Changes to markers:
Now able to display Group Delay for S11 and S21
Markers can be filled or "hollow"
Markers can be shown centered, or with the point at the tip
Markers can be locked from mouse control by selecting the radio button next to "Show/Hide data"
Time-delay reflectometry:
Min/max impedance values can be manually set
There's a movable marker to measure distance in the TDR chart
New scaling function for values:
Holger M¨¹ller, DG5DBH, contributed new code to show values more correctly, using SI-prefixes. David Hunt provided further changes to avoid losing precision when displaying frequencies for sweep settings.
Also included: Several bug fixes!
As ever, I look forward to hearing about any feedback, suggestions and bugs!
Thank you very much to all the kind testers, many of whom were recruited on these very mailing lists!--?Rune / 5Q5R
|
This is a little off topic however I reply to the question on firmware development enviroment. I am using the free STM32CUBEIDE from ST Micro the Mc manufacture to build some SDR control code for a home project and it seems to work well. On Tue, Nov 12, 2019, 7:42 AM vaclav_sal via Groups.Io <vaclav_sal= [email protected]> wrote: On Tue, Nov 12, 2019 at 05:35 AM, Rune Broberg wrote:
As ever, I look forward to hearing about any feedback, suggestions and
bugs!
Thank you very much to all the kind testers, many of whom were recruited on
these very mailing lists!
Rune,
since I now know that you are an actual coder / developer , I like to ask
/ give a feedback if as "not recently experienced person" is allowed.
1. What is your development tool ? ( In few words , do not want to take
too much of your time ).
2. I understand that NanoVNA is "an embedded processor " hardware. As of
today I do not own one, I started with "cloning" software - my choice. I am
making progress going that direction.
Along that line - real technical question - how can I add standard ANSI C
"includes " ? Perhaps C++ I/O ( cout ) includes so I can trace the code
flow using I/O to standard console? For debugging purposes - not to be
included in final code to flash to NanoVNA memory.
3. Related to above point #2 ¨C example code . How can I print this code
output to standard I/O file / console ? (Besides makefile I do not see
other ways to option the compilation / linking - no such options in
Eclipse Egit )
// test access
int a = 3;
#ifdef DEBUG
chsnprintf("Test print ",10,"%d2", a );
#endif
4. Here is a minor feedback ¨C just warning by make
z@z-desktop:~/git/NanoVNA-H-GIT$ make
Compiling main.c
main.c: In function 'hard_fault_handler_c':
main.c:2189:1: warning: stack usage computation not supported for this
target
}
^
Linking build/ch.elf
Creating build/ch.hex
Creating build/ch.bin
Creating build/ch.dmp
text data bss dec hex filename
92904 5028 11544 109476 1aba4 build/ch.elf
Creating build/ch.list
Done
|
Golden rule of reducing uncertainty, use the connector type that you will be using to connect directly to
the equipment / antenna that you test.
Otherwise, I'd need more adapters to connect to a different type calibration kit that introduces just as
much uncertainty as the original UHF style connector.
I calculated that even at 500Mhz, my quick bodge PL259 cal kit would introduce 0..2 ohms on the 50R
load and a phase error of 3 degrees, and that's what I see.
So for those of us that are really 0-50Mhz users it's more than good enough, and certainly accurate enough
as a daily driver even at UHF.
Heck, I've relied upon no more than 2 x 1N4148's and an LED to tune my HF stuff up -
Even my HF amp uses one (see attached). (And that uses audio style push connectors for the antenna output) ;-)))
So using a vna like this is overkill for some of us.
The nice thing is, if at anytime my requirements change, then I just change the bulkhead connectors to suit
The larger box also allows me to introduce a larger battery if I need it.
At some time in the next few years that tiny Li-Ion is gonna fail and I may have difficulty replacing it.
With the extra space in the box, I could go for a a bunch of AA's, or even just a single 2000mah 18650 cell.
It works, it's future proof, no messy switch extensions, it KISS.
Time to think about an external component test fixture next to keep me amused.
Ideas anyone ?
73 de Andy
|
yes, UHF connectors have terrible performance even on HF
|
Ugg. You used UHF connectors. They are not very good impedance above HF..... You should use N style connectors.
|
On Tue, Nov 12, 2019 at 02:35 PM, Nick wrote: In the attached picture the isolated plot is green and the connected plot is
red.
|
Hi Vaclav, for NanoVNA-Saver I use PyCharm - which is Python specific, and not usable for the firmware development side of things. On Windows, I might choose something like Visual Studio Code with a fitting set of plugins for developing for the NanoVNA. On Linux I use vim and make and things like that ;-) I don't think there's any way to print anything to a standard console - the only way to run the code is on the device itself, and that does not have a standard console. You *might* be able to make something that prints to the serial port, and then listen in to that; or using a hardware debugger for the microcontroller. I hope you find a good development environment for your project! -- Rune / 5Q5R On Tue, 12 Nov 2019 at 15:42, vaclav_sal via Groups.Io <vaclav_sal= [email protected]> wrote: On Tue, Nov 12, 2019 at 05:35 AM, Rune Broberg wrote:
As ever, I look forward to hearing about any feedback, suggestions and
bugs!
Thank you very much to all the kind testers, many of whom were recruited on
these very mailing lists!
Rune,
since I now know that you are an actual coder / developer , I like to ask
/ give a feedback if as "not recently experienced person" is allowed.
1. What is your development tool ? ( In few words , do not want to take
too much of your time ).
2. I understand that NanoVNA is "an embedded processor " hardware. As of
today I do not own one, I started with "cloning" software - my choice. I am
making progress going that direction.
Along that line - real technical question - how can I add standard ANSI C
"includes " ? Perhaps C++ I/O ( cout ) includes so I can trace the code
flow using I/O to standard console? For debugging purposes - not to be
included in final code to flash to NanoVNA memory.
3. Related to above point #2 ¨C example code . How can I print this code
output to standard I/O file / console ? (Besides makefile I do not see
other ways to option the compilation / linking - no such options in
Eclipse Egit )
// test access
int a = 3;
#ifdef DEBUG
chsnprintf("Test print ",10,"%d2", a );
#endif
4. Here is a minor feedback ¨C just warning by make
z@z-desktop:~/git/NanoVNA-H-GIT$ make
Compiling main.c
main.c: In function 'hard_fault_handler_c':
main.c:2189:1: warning: stack usage computation not supported for this
target
}
^
Linking build/ch.elf
Creating build/ch.hex
Creating build/ch.bin
Creating build/ch.dmp
text data bss dec hex filename
92904 5028 11544 109476 1aba4 build/ch.elf
Creating build/ch.list
Done
|
On Tue, Nov 12, 2019 at 05:35 AM, Rune Broberg wrote:
As ever, I look forward to hearing about any feedback, suggestions and bugs!
Thank you very much to all the kind testers, many of whom were recruited on
these very mailing lists!
Rune, since I now know that you are an actual coder / developer , I like to ask / give a feedback if as "not recently experienced person" is allowed. 1. What is your development tool ? ( In few words , do not want to take too much of your time ). 2. I understand that NanoVNA is "an embedded processor " hardware. As of today I do not own one, I started with "cloning" software - my choice. I am making progress going that direction. Along that line - real technical question - how can I add standard ANSI C "includes " ? Perhaps C++ I/O ( cout ) includes so I can trace the code flow using I/O to standard console? For debugging purposes - not to be included in final code to flash to NanoVNA memory. 3. Related to above point #2 ¨C example code . How can I print this code output to standard I/O file / console ? (Besides makefile I do not see other ways to option the compilation / linking - no such options in Eclipse Egit ) // test access int a = 3; #ifdef DEBUG chsnprintf("Test print ",10,"%d2", a ); #endif 4. Here is a minor feedback ¨C just warning by make z@z-desktop:~/git/NanoVNA-H-GIT$ make Compiling main.c main.c: In function 'hard_fault_handler_c': main.c:2189:1: warning: stack usage computation not supported for this target } ^ Linking build/ch.elf Creating build/ch.hex Creating build/ch.bin Creating build/ch.dmp text data bss dec hex filename 92904 5028 11544 109476 1aba4 build/ch.elf Creating build/ch.list Done
|
On Mon, Nov 11, 2019 at 07:24 PM, WB2UAQ wrote: All network analyzers that I have worked on (repaired, calibrated and use
nearly every work day) since 1977 (8409, 8505, 8753, 8510.......) have the
test ports connected to and thru the same front panel (built in or on the
S-parameter test set). I see absolutely no reason to isolate them on the nano.
I have not used the isolation part of the cal yet but isn't that the reason
for doing isolation? Thank you Pete and Dana for your helpful replies. I connected the two supplied SMA cables to the nvna and calibrated from 10kHz to 1500MHz. With both ends terminated in 50 Ohms the nvna cannot measure any difference in isolation with the grounds of the load ends floating or connected. In the attached picture the isolated plot is green and the connected plot is red. Both are averaged over 100 scans. Worst case isolation is 45dB @ 1.5GHz limited by the nvna itself. See also post #6867.
|
Re: [nanovna-f] NanoVNA-Saver 0.2.0
|
Hi,
a drag function is definitely on the list for a future version! Thanks for
the feedback!
--
Rune / 5Q5R
toggle quoted message
Show quoted text
On Tue, 12 Nov 2019 at 15:04, <robnj74@...> wrote: Perhaps a way to drag/move that zoomed in display would be great, it
seems to at times just move out of view when zoomed in.
|
Perhaps a way to drag/move that zoomed in display would be great, it seems to at times just move out of view when zoomed in.
|
Re: [nanovna-f] NanoVNA-Saver 0.2.0
I don¡¯t suppose Mac versions of the software are possible.
Ray
toggle quoted message
Show quoted text
On Nov 12, 2019, at 08:35, Rune Broberg <mihtjel@...> wrote:
?
Earlier today I released NanoVNA-Saver 0.2.0:
Release notes:
New feature: Zooming
This release adds the ability to "zoom" on the frequency-based charts: Use your mouse's scroll wheel to zoom in and out - or hold the control button and drag a box on the chart to zoom into.
New chart type: Group Delay
Group delay can now be displayed as a chart, and can also be enabled for the marker data display for both S11 and S21.
New chart type: Permeability
A new chart, R/¦Ø & X/¦Ø, is available for determining permeability characteristics of toroids. Thanks to David, F4HTQ, for requesting and helping out with this.
Logarithmic Y-scale:
The VSWR and Permeability charts now have the option of having the Y-scale shown as Linear or Logarithmic.
Changes to markers:
Now able to display Group Delay for S11 and S21
Markers can be filled or "hollow"
Markers can be shown centered, or with the point at the tip
Markers can be locked from mouse control by selecting the radio button next to "Show/Hide data"
Time-delay reflectometry:
Min/max impedance values can be manually set
There's a movable marker to measure distance in the TDR chart
New scaling function for values:
Holger M¨¹ller, DG5DBH, contributed new code to show values more correctly, using SI-prefixes. David Hunt provided further changes to avoid losing precision when displaying frequencies for sweep settings.
Also included: Several bug fixes!
As ever, I look forward to hearing about any feedback, suggestions and bugs!
Thank you very much to all the kind testers, many of whom were recruited on these very mailing lists!
--
Rune / 5Q5R
|
Earlier today I released NanoVNA-Saver 0.2.0:
Release notes:
New feature: Zooming
This release adds the ability to "zoom" on the frequency-based charts: Use
your mouse's scroll wheel to zoom in and out - or hold the control button
and drag a box on the chart to zoom into.
New chart type: Group Delay
Group delay can now be displayed as a chart, and can also be enabled for
the marker data display for both S11 and S21.
New chart type: Permeability
A new chart, R/¦Ø & X/¦Ø, is available for determining permeability
characteristics of toroids. Thanks to David, F4HTQ, for requesting and
helping out with this.
Logarithmic Y-scale:
The VSWR and Permeability charts now have the option of having the Y-scale
shown as Linear or Logarithmic.
Changes to markers:
Now able to display Group Delay for S11 and S21
Markers can be filled or "hollow"
Markers can be shown centered, or with the point at the tip
Markers can be locked from mouse control by selecting the radio button next
to "Show/Hide data"
Time-delay reflectometry:
Min/max impedance values can be manually set
There's a movable marker to measure distance in the TDR chart
New scaling function for values:
Holger M¨¹ller, DG5DBH, contributed new code to show values more correctly,
using SI-prefixes. David Hunt provided further changes to avoid losing
precision when displaying frequencies for sweep settings.
Also included: Several bug fixes!
As ever, I look forward to hearing about any feedback, suggestions and bugs!
Thank you very much to all the kind testers, many of whom were recruited on
these very mailing lists!
--
Rune / 5Q5R
|
Oristo
gin&pez@arg
