you can fix that bug for your compiler by placing variable dfu_reset_to_bootloader_magic into non initialized section to prevent it's initialization on startup.
|
Re: host software for nanovna, for linux users.
If something was written in a common base version, such as 2.7 for Python, which is probably pre-packaged in 90% of Linux OS's then
I bet life would be much easier.
- Andy -
|
On Thu, Nov 28, 2019 at 07:11 AM, RFy wrote:
Revert back to original( ttrftech ) board.c and change callback in UI,
problems( not to jump address ) gone
With my compiler it leads to "dfu mode won't work" bug. original board.c method uses hardcoded random ram address which may be randomly overwritten by stack filler.
|
Re: host software for nanovna, for linux users.
On 11/26/19 1:20 PM, ajparent1/kb1gmx wrote: I have them and not a noob to linux.
Python is an issue as the system is mint v17.3, so the current version of python is 2.7.... ???? If you're not a noob to Linux, then why are you using Mint 17.x which is out of support? ???? I run nanovna-saver on Linux Mint 19.1 and it works quite well.? Installing Python 3.7 was no problem, in fact it was so easy that I don't remember for sure how I did it.? Probably the official Python Ubuntu/Mint PPA.
|
On Wed, Nov 27, 2019 at 10:08 PM, QRP RX wrote:
On Wed, Nov 27, 2019 at 01:28 PM, RFy wrote:
it can enter into DFU with no issue, this is your compiler issue.
Revert back to original( ttrftech ) board.c and change callback in UI, problems( not to jump address ) gone
|
The included cables are not Rosenbergers but are there any good and low cost sets?
Or are they more than the VNA itself?
John
I ain't designing a ecm GHz device, just sweeping antennas
|
|
|
Small post giving some background on the building and tuning of the 2GHz cavity filter. I was able to use my nanoVNA to check the tuning of this filter as described in another post -- NanoVNA Wiki: /g/nanovna-users/wiki/homeNanoVNA Files: /g/nanovna-users/filesErik, PD0EK
|
Re: retrofit a bigger screen
Actually, his Android app still calls home to mama Google for statistics.?? If you have your Android device's WiFi enabled and connected, the NanoVNA app starts right up. However, I run a firewall (No-root firewall by Greyshirts) on my Android devices and the network request from the NanoVNA app (when it starts up only) takes about 60 seconds to timeout before the main screen appears. If I allow the app through the firewall, it starts immediately. I spoke to CHO45 about this and he said it's the Google library he's using as he explicitly performs no network requests. On Wednesday, November 27, 2019, 10:55:46 a.m. GMT-5, Oristo <ormpoa@...> wrote: > package it up with an Android tablet and use NanoVNA WebApp as the user interface Using cho45's NanoVNA apk avoids Internet dependency: .. and Amazon Fire tablet is currently < US$30 /g/nanovna-users/topic/50171909
|
Re: NanoVNA-Saver and NanioVNA-Q
Hi? Rune and QRP RX
Yes indeed, running a calibration on my NanoVNA-H itself first, solved my prtoblem.
The calibration with 60 segments and 10/5 Averaging over 10K to 900M is still running :-D:-D
Oh no, now I'm asked to connect the ?pen":-X
Many thanks,
Jos
Op 27-11-2019 om 16:09 schreef QRP RX:
toggle quoted message
Show quoted text
if firmware detects incompatible calibration it reset calibration and settings.
You're needs to perform calibration after firmware update.
|
Re: retrofit a bigger screen
package it up with an Android tablet
and use NanoVNA WebApp as the user interface Using cho45's NanoVNA apk avoids Internet dependency: .. and Amazon Fire tablet is currently < US$30 /g/nanovna-users/topic/50171909
|
Re: NanoVNA-Saver and NanioVNA-Q
Thanks Rune and QRP for responding that quickly, I did nothing more? than the flashing and trying to calibrate in NanoVNA-Saver, I wil run a calibration on NanoVNA itself and see if it solved it !
Best regards
Jos
Op 27-11-2019 om 16:10 schreef Rune Broberg:
toggle quoted message
Show quoted text
Hi Jos,
I haven't done anything in particular relating to the NanoVNA-Q firmware,
so any changes, assuming you are using the same version of NanoVNA-Saver,
is in the firmware. :-)
The individual buttons have never done any measurement - they save the
currently displayed data as the calibration data for that particular
standard.
|
Re: retrofit a bigger screen
Another way to do this would be to package it up with an Android tablet and use NanoVNA WebApp as the user interface (remove or hide the built-in LCD).
I'd like to try this but the android app won't load on my older tablet, despite it having been updated to Android 6.1.
It would also be possible to build in a raspberry pi and use nanovna-saver, but the android app seems a better fit if you don't have a keyboard.
|
Re: NanoVNA-Saver and NanioVNA-Q
even if you cleaned your connector with alcohol, you're needs to perform calibration after that
|
Re: NanoVNA-Saver and NanioVNA-Q
any change, firmware or hardware requires a new calibration.
|
Re: NanoVNA-Saver and NanioVNA-Q
Hi Jos,
I haven't done anything in particular relating to the NanoVNA-Q firmware,
so any changes, assuming you are using the same version of NanoVNA-Saver,
is in the firmware. :-)
The individual buttons have never done any measurement - they save the
currently displayed data as the calibration data for that particular
standard.
--
Rune / 5Q5R
toggle quoted message
Show quoted text
On Wed, 27 Nov 2019 at 16:04, Jos Stevens <jrs@...> wrote: Hi Rune
After Flashing NanoVNA-Q-0.4.4 I found that the calibration in
Nan0VNA-Saver has changed.
I am used to set the sweep settings in the NanoVNA-Saver to a high
number of segments and averaging while running a calibration, causing
long sweep times
When doing so with this new firmware it took 1 minute and about ten
seconds per calibration sweep only, it looks like VNA-Saver is not using
the settings set by the user, and/or is using the setting in the firmware.
I also noticed that it is no more possible to calibrate manually
(without using the Calibration Manager), when you click "Short", "Open"
or "Load" in the calibration screen it immedeately loads 1010 points of
measurements and no measurement is performed.
Thanks for this great software.
Kind regards,
Jos
|
Re: NanoVNA-Saver and NanioVNA-Q
if firmware detects incompatible calibration it reset calibration and settings.
You're needs to perform calibration after firmware update.
|
Re: NanoVNA-Saver and NanioVNA-Q
Hi Rune
After Flashing NanoVNA-Q-0.4.4 I found that the calibration in Nan0VNA-Saver has changed.
I am used to set the sweep settings in the NanoVNA-Saver to a high number of segments and averaging while running a calibration, causing long sweep times
When doing so with this new firmware it took 1 minute and about ten seconds per calibration sweep only, it looks like VNA-Saver is not using the settings set by the user, and/or is using? the setting in the firmware.
I also noticed that it is no more possible to calibrate manually (without using the Calibration Manager), when you click "Short", "Open" or "Load" in the calibration screen it immedeately loads 1010 points of measurements and no measurement is performed.
Thanks for this great software.
Kind regards,
Jos
|
On Wed, Nov 27, 2019 at 01:28 PM, RFy wrote:
Q branch can not enter DFU mode via command
it can enter into DFU with no issue, this is your compiler issue.
|
Tested: original(191124), Q(191119), H(191125)
- Compiled with ARM-GCC/2019-Q4
- Each firmware flashed before FF overwrite & clearconfig & uncalibrated( cal reset & cal off ) nothing connected
- trace 0 scale:3/ref:13.746025507
- trace 1 scale:11/ref:11.5512126265
* Glitches at 6.5 MHz, 64 MHz( seems DC )
* "cal data" all terms returned 0.
* Q and H branch firmware "data 2 ~ 6" returns garbage( not zero-ed array )
* Q branch can not enter DFU mode via command( Not tested IAR precompiled version )
* "marker 1...4 off" -> "trace all off" -> Iterating "scan" & "data 0..1" : populates weird +22dB CH0 logmag
|
Jim Allyn - N7JA
John
Oristo
