开云体育

Hi Andy,
upgrading to a higher frequency range doesn't lose you any other features,
and you don't *have* to use it ;-) But the newer firmwares DO contain
bugfixes, and new features. QRP RX has been very active in fixing errors
and improving the readings of the NanoVNA. So even if you won't use it at
1500MHz, do consider upgrading. :-)

--
Rune / 5Q5R

On Sun, 10 Nov 2019 at 17:47, Andy via Groups.Io <punkbiscuit=
[email protected]> wrote:

OK thanks everyone for your replies.

I'm not exactly seeing overwhelming evidence that I should upgrade to a
1500Mhz firmware.
I'd probably be better off with an old GDO and a field strength meter up
there ;-)

73 de Andy

No, I did read several user guids but not none that have info on the zdiag utility, can guide me to it ?

I? can google for it as well.

Referring to the WinUSB driver, Windows' Device Manager shows : " STM32 bootloader" .


Op 10-11-2019 om 19:46 schreef Larry Rothman:

Ok, I stand corrected, Nooelec is the ttrftech authorized distributor. I hadn't look at edy555' GitHub page in a while.

I *think* I had to use something called Zadig to change the USB driver used:



I certainly used it, at least, but quite *what* driver I had to change to I
don't remember - and this was on my Windows 7 machine, whereas my Window 10
machine just worked, as I remember it.

Maybe that's a place to start searching from.

--
Rune / 5Q5R

I don't know where you got your info from but ttrftech's edy555 was the original designer of the NanoVNA and hugen modified the charging circuit and designed the current PCB and was selling them on taobao.?
Nooelec is NOT the official seller, hugen is through his taobao site and on a site on AliExpress. As far as hugen is concerned, Nooelec is selling clones of his design.?
If you're looking for board files, look at the ttrftech GitHub repo. If you ask hugen nicely, he might share his redesigned PCB with you. The biggest area to be concerned with in the design is around the port 1 and 2 bridge circuits and the mixer.?
... Larry



On Sun, 10 Nov 2019 at 1:32 PM, dhu1342@...<dhu1342@...> wrote: I purchased a NanoVNA from Nooelec (the authorized distributor from the edy555/ttrftech github page). I didn't realize at the time that all of the designs were actually based on hugen79's schematic designs, otherwise I would have purchased through Alibaba instead. Anyway, the point being that at the same time that I purchased mine, which I will consider "the original design", a friend of mine also purchased one from Amazon, which I will call "the clone design". When they came in, we took them both apart and compared the boards, and as far as we could see they were identical. We then calibrated both, used each to scan the RTL-SDR FM bandstop filter from 50KHz to 900MHz, overlayed the plots using NanoVNA-Saver, and they were also identical.

It seems that the Chinese manufacturers making the clone designs (at least this one) have finally copied the designs exactly. That makes it seam as though not publishing the board files at this point is mostly hampering the Ham Radio enthusiasts who are trying to help, and isn't doing much to stop the clone manufacturers. Are there plans at some point in the future to publish KiCAD files (or similar)? Has this been discussed at all? When I search for layout, I only see one message about the V2 design, and that 'appears' to have no plans for being open-source.

Vaclav,
it sounds like you have the background for it then, but maybe just not
recent experience! The error you got concerning C99/C11 should be fairly
self-explanatory, and probably just depends on what compiler you are using
- setting the right options in the Makefile should clear it. :-)

Good luck!
--
Rune / 5Q5R

On Sun, 10 Nov 2019 at 19:37, vaclav_sal via Groups.Io <vaclav_sal=
[email protected]> wrote:

Sorry , I have an issue with replying to specific post.
My apology to everybody.


Hello,
I found your idea of adding Bluetooth interesting, but I am a little
confused: Are you normally a C-programmer? Do you work with embedded
software? The firmware is written in C, and I probably wouldn't recommend a
project like this as a first go - it would take at least some experience
:-)

Rune,
here is SOME of my background.

I wrote my first (professional ) program in 1972 , in an assembly.
The task was to set-up a path thru long distance telephone switch and test
it for continuity.
I "switched" to C language and wrote another (paid for) program passing
data thru similar network - somewhere around 1980ish.

I am happy retired and as form of punishment I write C/C++ code - for fun.
I "did" Arduino and ditched the "kindergarten educational toy" after few
years.
I have several project "work in (slow) progress" using Raspberry Pi 3 ,
I did tried Raspberry Zero and ditched that - it did not yield to remote
programming .
I am still working on my own version of VNA , got the hardware about 75%
wired , and got stuck on adding Bluetooth to that hardware.
So I decided to use NanoVNA to do the Bluetooth addition there.
No, I am not doing all this for money , just a hobby.
Cheers
Vaclav AA7EJ

Please read up on the zdiag utility.?
Check here...?/g/nanovna-users/message/4624
I had a similar issue at one point. You need to ensure you've got the win.usb driver installed.?
... Larry



On Sun, 10 Nov 2019 at 1:31 PM, Jos Stevens<jrs@...> wrote: i did more,

1) Un-installed DFUseDemo

2) Cleaned the registry.

3) Restarted the PC.

4) Re-injstalled DFUsePackage

5) Looked in Windows Device manager : USB Devices ----> STM32 bootloadeer.

6) Result : NONE, DFUSE does not see NanoVNA.


Op 10-11-2019 om 18:29 schreef QRP RX:

I purchased a NanoVNA from Nooelec (the authorized distributor from the edy555/ttrftech github page). I didn't realize at the time that all of the designs were actually based on hugen79's schematic designs, otherwise I would have purchased through Alibaba instead. Anyway, the point being that at the same time that I purchased mine, which I will consider "the original design", a friend of mine also purchased one from Amazon, which I will call "the clone design". When they came in, we took them both apart and compared the boards, and as far as we could see they were identical. We then calibrated both, used each to scan the RTL-SDR FM bandstop filter from 50KHz to 900MHz, overlayed the plots using NanoVNA-Saver, and they were also identical.

It seems that the Chinese manufacturers making the clone designs (at least this one) have finally copied the designs exactly. That makes it seam as though not publishing the board files at this point is mostly hampering the Ham Radio enthusiasts who are trying to help, and isn't doing much to stop the clone manufacturers. Are there plans at some point in the future to publish KiCAD files (or similar)? Has this been discussed at all? When I search for layout, I only see one message about the V2 design, and that 'appears' to have no plans for being open-source.

i did more,

1) Un-installed DFUseDemo

2) Cleaned the registry.

3) Restarted the PC.

4) Re-injstalled DFUsePackage

5) Looked in Windows Device manager : USB Devices ----> STM32 bootloadeer.

6) Result : NONE, DFUSE does not see NanoVNA.


Op 10-11-2019 om 18:29 schreef QRP RX:

On Thu, Nov 7, 2019 at 02:12 PM, Oristo wrote:

I may even try to add my own "project" to keep the rest untouched.

That is the purpose for git; create a branch

I am not sure I agree.
It is MY understanding that (git) branch is sort-of "making a detour" in coding and eventually include such detour into the main flow.

Assuming that I have the original
code "divided" into plain C code projects I woudl like to add my own project, not modify existing projects.

However, I am not in position to try that - I am still trying to make sure I can reliably replicate what I know about hacking the original code. So far it looks as Eclipse EGit is actually making this learning process worst. Pretty frustrating IMHO.

Hello,
I found your idea of adding Bluetooth interesting, but I am a little
confused: Are you normally a C-programmer? Do you work with embedded
software? The firmware is written in C, and I probably wouldn't recommend a
project like this as a first go - it would take at least some experience :-)

--
Rune / 5Q5R

On Sun, 10 Nov 2019 at 19:10, vaclav_sal via Groups.Io <vaclav_sal=
[email protected]> wrote:

I did start this thread as me "hacking NanoVNA " software.
I am not sure if it is OK to continue in that direction.
For one, long threads are not mu favorite, however some administrators
object to "re-posts".

I have cloned NanoVNA-H and run "make" in my local repository.

I run into same error as with previous "NanoVNA".

The error is fixable by using "make" recommended solution, no problem
there.

What is puzzling is - as a "copy" of some original NanoVNA software, why
does NanoVNA-H still objects to the
"missing C11" options in compiler options? What is so different with fft.h
file? ( I have not look at the actual file , not yet.)
Actually how do other "software developers" deal with this ?


Here is a snippet of "make" output:


fft.h: In function 'reverse_bits':
fft.h:31:2: error: 'for' loop initial declarations are only allowed in C99
or C11 mode
for (int i = 0; i < n; i++, x >>= 1)
^
fft.h:31:2: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11
to compile your code

Hi Guyla

Yes, I read that. But it does not say *why* the grounds for the N connectors are kept separate.

Any ideas?

73
Nick
G3VNC

Thanks Hyula

I read the message, looks like I have to buy a STM-link device.

I de-installed DFUse Demo pack cleaned the register, re-installed DFU pack,? restarted the PC .......... device NOT recognised. by DFUse.

Windows device manager reports USB devices -----> STM32 Bootloader.

Use it with NanoVNA-SAVER, GREAT SOFTWARE.

Thanks very much es 73

Jos (PA3CCE)


Op 10-11-2019 om 18:28 schreef Gyula Molnar:

With the NanoVNA in hand, it is worth looking at the passband response of a typical duplexer over the range of, say, 10-900 MHz.

In most cases - and with almost every brand and model used in typical amateur communications - you will note that the off-frequency response (>20 MHz away from the intended frequency) that signals will sail right through most duplexers: The fact that they might be labeled "Bp/Br" (Band-Pass/Band-Reject) should be viewed with suspicion as this typically applies only at frequencies very close to the notch responses.

What this means is that as they are, duplexers used in Amateur Radio service are not usable at shared repeater sites - at least if you want to be a good neighbor. In this area, many repeaters are on mountain tops that are shared with other land-mobile users and FM/TV broadcast stations and it was discovered, when they "upgrade" to a new repeater (replaced an old GE or Motorola with a Yaesu or especially Icom) repeater that they suddenly had a very deaf - or intermittently deaf - receive system since the "new" radios usually do not have the narrow-band helical resonators on the front end since they are typically parts of modified mobile radios that are crammed into a box - and we all know how easily Mobile rigs are to overload!

In all cases, the "fix" has been to add at least one "pass" cavity (Icom D-Star stacks seem to require two on the receive side at busy sites since their receivers are so miserably bad) on both the receive and transmit antenna paths - an preferably include a low-pass filter (especially on 2 meter repeaters) to attenuate the inevitable "3x" odd-order response that all of these cavities have, and to prevent these off-frequency signals from getting back into the isolator (all your repeaters have one on the TX side, right?) which will do very little on frequencies far-removed from the desired transmit frequency - and a true band-pass only cavity - along with proper grounding - provides excellent lightning protection, too.

73,
Clint
KA7OEI

I did start this thread as me "hacking NanoVNA " software.
I am not sure if it is OK to continue in that direction.
For one, long threads are not mu favorite, however some administrators object to "re-posts".

I have cloned NanoVNA-H and run "make" in my local repository.

I run into same error as with previous "NanoVNA".

The error is fixable by using "make" recommended solution, no problem there.

What is puzzling is - as a "copy" of some original NanoVNA software, why does NanoVNA-H still objects to the
"missing C11" options in compiler options? What is so different with fft.h file? ( I have not look at the actual file , not yet.)
Actually how do other "software developers" deal with this ?


Here is a snippet of "make" output:


fft.h: In function 'reverse_bits':
fft.h:31:2: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
for (int i = 0; i < n; i++, x >>= 1)
^
fft.h:31:2: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code

I have loaded edy555's latest version and the touch menu acts horrible !.

Jos

Op 10-11-2019 om 17:41 schreef aa777888athotmaildotcom:

I did , even de- re-installed DFUseDemo pavkage, cleaned register, resart PC? .... same result.

Windows evice manager reports : USB Devices -> STM32 bootloader

Thanks anyhow.

Jos

Op 10-11-2019 om 18:29 schreef QRP RX:

Hi Nick,

Can you read here: /g/nanovna-users/files/Housing%20and%20Case%20Designs/N%20connectors%20for%20the%20NanoVNA%20-%20k6jca.pdf

73, Gyula HA3HZ

On Fri, Nov 8, 2019 at 12:08 AM, WB2UAQ wrote:

The toughest part of adding the N connectors was to get a pair of short
semi-rigid coax SMA to SMA jumpers close to the same length so I didn't over
stress the SMA's and the PCB on the Nano.

I will shortly repackage my nano with N connectors. I have found a couple of bulkhead types in my junkbox. They are for 1/2" coax, but can be adapted for some 1/4" PTFE coax from the same source :)

I want to use a diecast box (e,g, Hammond) to house the nano if possible.

Although the shells of both SMA connectors on the nano are shown connected to ground on the schematic, they appear to be soldered to separate areas of ground plane on the component side of the board.

I see from your pictures that the shells of both the N bulkhead connectors are connected to each other via the the aluminium chassis.

Have you noticed any deleterious effects as a result of mounting them in this way?

Other posters have isolated the shells of the bulkhead connectors from each other, either by mounting on an insulating panel, or by cutting separate lands on single sided pcb material.

Has anyone got any information on which way to go with this before I start cutting metal?

Try reboot your PC.