开云体育

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.

Hi Jos,

please read this:
#3416 msg is correct. /g/nanovna-users/message/3416

73, Gyula HA3HZ

there is no "gotcha's" hardware is almost the same, but edy555 version uses a little different display, so it has different defautl touch calibration.

You can also check NanoVNA-Q 0.4.3:

it has tuning for NanoVNA-H hardware...

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

All:

I have no idea what hardware revision I have, or how to determine it. I updated the firmware to eddy55 0.4.0 and the CONFIG menu pick just keeps dumping me back to the main display as if it's a back button. All other buttons work so it's not a touchscreen calibration issue.

I installed the huygen79 NanoVNA-H latest version. It seems to run just fine, and it makes measurements. I'm just wondering are their any "gotcha's" in doing so, since I don't know if the hardware I have here is at the NanoVNA-H revision level (how can I tell?) It does have the metal shielding.

Note that I only care about measurements up to about 200MHz, if that makes a difference.

Thanks!

Hello guys!

Thanks for all the answers. I tested the repeater-setup and I go back to the first measurment.
That means I used the previous measurment, that works fine.

I discovered something else... At the NanoVNA, the lines dropped to the bottom. I thinks it's the end of the scale.
I didn't try to make the scale bigger, maybe it is impossible, I have to try that.
But... I saw that I can tune the filter more deep with the software on my computer!
See the attached picture, on the display I see a flat line but on the computer I see a great spike down on the desired frequency.

Dwight, what you say is completely true. Tuning is trying to come on the best point, it always can be better :)

Tonight I'm staying at home, but tomorrow I have some appointments around my house, then can I try my new tuned filter.

Well, thanks for the links and I understand that maybe this is not the exact way to tune filters.
The NanoVNA is cheap if you talk about a HP Spectrum Analyzer, so maybe are the false measurments explained :)

Now I'm looking for another software, I hope to find it with more exactly frequencies in the display.
With NanoVNA I see only 438.6 -> 438.8 -> 439 MHz. I like to see more vertical lines for more precision.

Thanks again, I have work to do with it, but I understand the tuning better now.

On the pictures: a screendump of the software, and a screendump of the same NanoVNA display.
Tuning is at 438.800 MHz and on the screendump of the software, there is a huge spike that I didn't see on the NanoVNA display.

Hi All,
Yesterday I flashed edy555's version 0.2.3 firmware,
I was not very happy, so I tried to flash some other firmware today.
But with the present firmware set in DFU mode DFUseDemo no more recognises my device.
So I can't flash no more !
Is there someone that had the same experience and/or has a solution ?
Thanks,
Jos

Hi KV5R
Thanks, in the mean time I had found that one,
But now I have a new problem, I wanted to flash DL9CAT's firmware, but with that firmware 0.2.3 from edy555 set in DFU mode the device is not recognised by DFUse software.
I also tried to shorten the two pins,but no luck.
So now I am not able to flash, strange, I'll make it a new ttopic for everyone.
Jos

Hi Joe,
Look at -- DL9CAT (reald) takes edy555's 0.4.0 and adds bigger font, and "info screen", and today he has added a dfu to the zip package so you no longer need to use Dfuse File converter to make the dfu from hex (though doing so is easy).
73, --kv5r

Thanks for the reply..
This morning I found a 0.4.2 from DL9CAT.
But now I have a much bigger problem,I had flashed edy555 latest firmware and it's working more or less ( much trouble with the touchscreen ), but when I set it in DFU mode, DFY software does not see the device,
I dit not have this with several other firmware that iI tried before.
Yesterday I downloaded a software package from STI and can make .dfu files from hex bin files.
Now I'm in trouble because the device is not recognised in dfu mode by DFUseDemo so I can't flash.
.Aany suggestions ?
Thanks in advance
Jos