开云体育

bug reports for this gcc bug are already exists.

I just fixed NanoVNA code to avoid it.

On Thu, Nov 28, 2019 at 06:28 AM, Rune Broberg wrote:

Python 2.7 is end-of-life in little over a month. Developing new software
using that cannot reasonably be encouraged.

Hi Rune,

please don't think that I am referring to your own excellent software.
I know it works when all the bits are in the right place ;)

What I refer to is the general disease of of always needing to mess about finding new dependencies, updating to a new version
of something or other or trashing and rebuilding hard disks for another OS and it wastes a lot of peoples time.

And all for what ?

The excuse of security updates is wearing thin, rarely do the end users see any tangible benefits and not everything is plugged into to the internet.

Every Android phone that's a day old seems to require a hundred updates.
Every day old Windows PC seems to need a a day connecting to Microsoft for updates.
You would have thought that with all these years gone by, things would be sorted out by now.
Linux is just as bad, nearly every day my update manager is offering more "security" updates.

Windows...another version of MS Silveright, another version of .NET crap just to continue to run another updated app.
All this update crap is everywhere and we end users want to get on with our lives.

That's why I think that some form of line needs to be drawn *generally* when releasing *anything*.
Maybe Python 3.5, that seems to be default in Linux or Raspberry Pi's only 12 months ago.

And look at Linux Mint.

LM 18.3 is still LTS.
Why would I want to upgrade to 19.x for no benefit.
THere's issues with WINE being installed.
And the last time I looked at a newer WINE it appeared to have dropped support for the od Win 3.1 stuff, which is the only reason why most of us need it anyway.
That is according to the WINECFG that I tried to set up, and it no longer allowed me to set up anything old than about WinXP from memory.

All this pushing the blame back to users to upgrade / update is not good enough.
It's devs being too lazy to think about making their apps works for the majority.

Well I'm not playing the game any more these days, I have a life to get on with.

A PC should be working for *me*, I am not it's damn slave anymore ;-)

73 de Andy

On 11/28/19 12:10 AM, QRP RX wrote:

just installed gcc and tested it. The root of cause is GCC compiler bug.
It produces garbage code. I will implement workaround for this GCC compiler bug.

???? And file a bug report?

Isnt it amazing how i cant get an answer to a simple question!,if i wanted to use a tab i would have asked that!!,pointless as my tab doesent support the app,just wanted to know what screen to get out of the 2 i linked too!.

just installed gcc and tested it. The root of cause is GCC compiler bug.
It produces garbage code. I will implement workaround for this GCC compiler bug.

Hi Andy,
Python 2.7 is end-of-life in little over a month. Developing new software
using that cannot reasonably be encouraged.

If anyone wants to port NanoVNA-Saver to other platforms or languages, it
is fully open source, so they can do so. :-)

--
Rune / 5Q5R

On Thu, 28 Nov 2019, 06:48 Andy via Groups.Io, <punkbiscuit=
[email protected]> wrote:

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 -

file board.c, line 65

I don't have gcc at the moment, so I cannot implement patch for your compiler.

You can try the following change:

volatile uint32_t dfu_reset_to_bootloader_magic __attribute__ ((section (".noinit")));

let me know if it works, I will add this patch for gcc.

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.

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.

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

Hello Dick,
There are several firmware versions available:
/g/nanovna-users/message/7477
has a snapshot of firmware in the wiki.

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/home
NanoVNA Files: /g/nanovna-users/files
Erik, PD0EK

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

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:

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

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: