开云体育

it doesn't means that impedance match cable/antenna is not needed for RX and impedance match transmitter/cable is not needed for TX. Such type of mismatch leads to signal loss. But this loss is not so high as loss due to standing wave in the cable.

The loss in the cable due standing wave happens with poor impedance match between receiver/cable for RX and cable/antenna for TX.

On Sat, Oct 12, 2019 at 09:06 PM, Bill Hemmings wrote:

Somehow, I don't see a good reason to CARE about matching

receiver input impedance.

it doesn't related with volts or watts, impedance mismatch has the same poor effect for any volts and watts.

Impedance mismatch just reduce signal level. But when you use cable, there is another issue - standing wave in the cable. Standing wave multiplies all losses in the cable. This is why standing wave in the cable leads to dramatic signal loss.

When you use TX, standing wave in the cable depends on cable load impedance (antenna). This is why it is very critical to match your cable with antenna. Note, I wrote cable (not TX output), this is not mistake, you're needs to match your cable impedance with antenna.

When you use RX, standing wave in the cable depends on cable load impedance (receiver input impedance). This is why antenna match is not critical for RX. But for RX you're needs to match your RX input with cable impedance, otherwise you will have the same issue as for TX.

If you use RX with proper impedance match between RX input and cable impedance (both impedances should be equals, for example 50 ohm), there is no standing wave in the cable. If your antenna has bad impedance match with cable, it just will leads to low signal level, but there is no multiple losses and distortions in the cable due to standing wave, because there is no standing wave. Your receiver can use high gain amplifier in order to compensate low signal level from antenna. This is why antenna match is not critical for receiver.

The same output impedance of transmitter is not critical, it just leads to lower efficiency, but there is no multiple losses and distortions due standing wave. Because standing wave is missing when you transmit to antenna which has good match with cable.

Bryan,
I'm glad you persevered and didn't give up. Thanks for feeding back the steps you took to get your unit running again. I'm sure some other user will benefit from your experience.

73,

Herb

did you tried to calibrate touchscreen? I mean touchscreen calibrartion, don't confuse with VNA calibration. See menu CONFIG => TOUCH CAL

Herb,

I think I have the edy555 version 0.2.3 firmware working well with nanoVNA-Saver 0.1.2, now. I no longer see weird data errors on the nanoVNA display or in the nanoVNA-Saver 0.1.2 displays.

I downloaded a different copy of the edy555 firmware. The one I used today was included in the post by reuterr at the link below.

/g/nanovna-users/topic/34428581#4280

The one I used previously was from and I had to convert ch.hex in the .zip file to a .dfu file using the software that comes with DfuSeDemo called "Dfu file manager". Prior to loading that version into the nanoVNA I loaded "DMR-CLEAR_MEMORY_DFU.dfu" which is not what I have been doing. I had previously been loading "DMR_FILL Flash with FF DFU.dfu". I don't know what the difference is between these .dfu files. Perhaps someone else knows. Does the "DMR-CLEAR_MEMORY_DFU.dfu" file write zeros to all locations?

So, this time I loaded "DMR_FILL Flash with FF DFU.dfu" and then the file from post 4280 in this user group called "nanoVNA_0.2.3-ch.dfu" included by reuterr in post #4280. After loading the firmware I asked the DfuSeDemo software to verify the download by using the available checkbox. There were no indications of any errors anywhere in this process. But, I did not see any errors in my first attempt either.

After installing the firmware, I cycled power on the nanoVNA, carefully set the screen calibration by gently using a wooden toothpick, and saved it. Then I immediately went to the calibration page, pressed "RESET" and initiated a cal. I noticed that the yellow line was about 3 divisions below the top of the display. Normally with a good cal and an open or short attached it 1 division below the top of the display. And, the device did not have a black background behind "CORRECTION". I then clicked on "RESET" followed by "CALIBRATE" and then went through the calibration procedure with "OPEN", "SHORT", "LOAD", "ISOLATION", and "THROUGH". I then saved this calibration in calibration memory 0. I also recalled calibration 0. I am not sure this is necessary, but... I immediately went to check the status of "CORRECTION" and it had that word highlighted by a black background. I am pretty sure that means that the "CORRECTION" from memory 0 is being used. I also confirmed that on the left side of the nanoVNA screen there was a "C0" in the first line, not "c0" which means that the calibration frequency range in memory zero matches the frequency range in use and nothing has been changed. I immediately went to check the calibration using an open, short, load, and through. Everything looks much better than before.

There seems to be a few possible changes that made the difference in the outcome.
1) I converted the .hex file to a .dfu file using the software "Dfu file manager" instead of using a .dfu file created by someone else.
2) I used a different .dfu file. A binary comparison does not show what I think is a difference in the part of the .dfu file that gets loaded; however, I could be wrong. The only difference I see is something about the path of the file that is stored in the .dfu file.
3) I cleared the memory of the nanoVNA with "DMR_FILL Flash with FF DFU.dfu" NOT "DMR-CLEAR_MEMORY_DFU.dfu."
4) I verified that what was loaded in the nanoVNA was the same as the file I was trying to load. I seriously doubt this is made a difference; however, I did not do that before.

#2 above may be a significant difference. Does anyone know what that might mean for operation of the nanoVNA? I certainly have no idea.

And, now when I use nanoVNA-Saver 0.1.2, things are working as I would expect.

By-the-way, when creating a calibration in nanoVNA-Saver, I set it up to average a minimum of 3 complete scans. I have considered doing many more (say 10). This will help reduce noise in the calibration itself. I think this has to be good for everything done with nanoVNA-Saver, especially above 300 MHz. Reducing the noise in calibration should be a good thing. I suggest everyone do this. I haven't seen this suggestion anywhere, but I haven't looked for it either.

I hope all of this is very clear and easy to understand.

--
Bryan, WA5VAH

Rune,
I just tried the new band stop filter analysis and the data looks spot on (See attachment), The firmware version I'm using was also correctly identified in the "About.." box. The only thing I found amiss is the "Hz/step" label was blanked (See attachment). I think I speak for the whole user community in thanking you for your continuing efforts.

- Herb

Symptoms suggest that there is a break in one of the substrate of the resistive layer of the sensor.
If there was an interlayer short circuit, the device would hang on the splash screen when turned on.
There is only a soldering of the loop, and checking two layers for resistance, a few hundredths of an ohm.

Thanks.

Removed the cover plate. No trash.
Still not working. It's got to be bad.

Andy - W4KIL

Thanks.
Loaded it and all I get is a solid white line down the right edge.
My touchscreen is faulty for sure.

Thanks again.

Andy - W4KIL

I made a special firmware to check the touchscreen. The test loads immediately upon startup.

It sounds like there is something pressing on the surface of the touchscreen.?
Remove the front frame and check for any debris, then try operating with the front frame removed and see if it works.??



On Sat, 12 Oct 2019 at 3:59 PM, Andy Yates<andyfranyates@...> wrote: Rune,
Thanks.
Don't have a serial interface. BTW I've tried dfu-util with linux and
DfuSe with Windows. Same result. I've done the stand-alone
touchscreen cal within the firmware which appears to work, It's
almost like the screen is upside down and backwards. i've tried
different corner combinations within the calibration. No success.
Any other ideas besides the serial interface ?

Andy -W4KIL

Herb,

I did not see that "my through measurement was about 10 dB down." Nor were other things centered around 50 ohms on the Smith chart. But....

Thanks for the tip. I will try it again and report back.

--
Bryan, WA5VAH

Bryan,
I had problems similar to yours when I upgraded to edy555's 0.2.3. After calibration my open and short loads on the Smith display stayed centered around 50 ohms and my through measurement was about 10 dB down. I never had similar issues using the previous firmware. My problem turned out to be the "Correction" setting under the "Cal" menu. In the previous firmware it was turned on by default, so I wasn't aware of its function and thought it was an advanced user setting like electrical delay. When I upgraded to edy555's 0.2.3 firmware "Correction" was turned off by default, and therefore; OSLT calibration was not being applied. Once I toggled that setting ON then 0.2,3 worked great and is the best version to date.

-Herb

OK. Tried it with Putty. The X coordinate for the lower right always
comes back with a "0" . I think my touchscreen is faulty.

On Sat, 12 Oct 2019 at 23:29, KV5R <kv5r@...> wrote:

Greetings to All,
I am very much enjoying the NanoVNA, and very grateful to the developers
for making this amazing and affordable instrument!
I would like to suggest a useful display format for use with CW stimulus
mode.
To me, it doesn't make sense to display CW mode on graphs, as the
frequency is fixed, not swept.

Your suggestion is very similar to the one I wrote about half an hour ago
about the vector voltmeter option on a FieldFox. I attach a screenshot of
that. The FieldFox one actually shows less than you want, but the concept
is much the same - big numbers at a fixed frequency. See screenshot taken
from Keysight website





--
Dr. David Kirkby,
Kirkby Microwave Ltd,
drkirkby@...

Telephone 01621-680100./ +44 1621 680100

Registered in England & Wales, company number 08914892.
Registered office:
Stokes Hall Lodge, Burnham Rd, Althorne, Chelmsford, Essex, CM3 6DT, United
Kingdom

Greetings to All,
I am very much enjoying the NanoVNA, and very grateful to the developers for making this amazing and affordable instrument!
I would like to suggest a useful display format for use with CW stimulus mode.
To me, it doesn't make sense to display CW mode on graphs, as the frequency is fixed, not swept.
In the typical use case of radio hobbyists fine-tuning antennas (usually to lowest SWR at resonance), a "big" text-only screen would be very useful when used with CW fixed frequency mode.
I imagine it would display 3-4 numeric lines -- Frequency, SWR, R+-jX, and maybe one more parameter.
Also, the toggle switch should change the CW frequency by +- 1kHz? steps, for more convenience in CW mode.
I understand the memory limitation of a big character font, but perhaps it could use the big red numbers already in the firmware, as used in the entry field of the number entry pad, but 3-4 lines on a full-screen white background. So perhaps it would only take a little code to format the text screen, and add it to the Format menu.
This would be easy to see in the field, and be familiar to people who have used character-based antenna analyzers.
It would make a nice and useful addition to the swept-graph screens, and would also show well in ad pictures! :-)
I welcome discussion from the developers and interested parties. If there is no interest, I would like to program it for myself, but first would like to know if it is even possible, before I install and learn the build environment.
Thanks, --KV5R

On Sat, Oct 12, 2019 at 04:02 PM, Rune Broberg wrote:

upgrade firmware to edy555's 0.2.3.

Rune,

I tried that firmware; however, I was getting very strange errors, even on the nanoVNA screen, with that version of firmware. When measuring an open I frequently get data which is obviously in error (a point is more than half way across the Smith chart from an open when I have an open on the CH0 port). And, the calibration I was able to get in the nanoVNA without using anything external was not very tight about the ideal location for an open, a short, or a load. Perhaps, I am not getting the calibration to be stored and recalled correctly; however, I tried several times without success. I am using the same approach to calibration with the newer firmware that I used with the firmware from September 20. Was there a change in the calibration approach on the nanoVNA with the latest edy555 firmware?

I would be happy to use the newer firmware, but don't want to live with these large errors which happen frequently (every few scans.) I never see such errors using Hugen's firmware from September 20.

--
Bryan, WA5VAH

Right on! There are many questions that don't seem to be asked, and answers don't

always much sense without some hands-on tests and data.


I got started with this round watching comparisons of assorted Baofeng-type antennas

for those really cheap Chinese walkie-talkies. (on youtube)


Then I got to wondering what difference does the impedance make.

One thing that makes some experimenting easy is telescoping antennas like the Nagy -704.

You can move the ''resonance'' all over the place!? For test signals there's things like garage door

openers and tire-pressure sensors.


Bill


- - - - - -

This certainly doesn't look right:

2019-10-12 15:52:00,598 - NanoVNASaver.Hardware - DEBUG - Found version
info: 0.1.1.1-5-gd609fb2

2019-10-12 15:52:00,598 - NanoVNASaver.Hardware - DEBUG - Parsed
version as 1.1.1-5-gd609fb2
2019-10-12 15:52:00,598 - NanoVNASaver.Hardware - DEBUG - Testing against 0.2.0
2019-10-12 15:52:00,598 - NanoVNASaver.Hardware - DEBUG - Parsed
version as 0.2.0
2019-10-12 15:52:00,598 - NanoVNASaver.Hardware - DEBUG - Newer than
0.2.0, using new scan command.


This certainly doesn't look right. The 4-digit version number of Hugen's (I
think?) is parsed as 1.1.1 instead of 0.1.1. My software only supports
3-part (major/minor/revision) version numbers, and I guess I need to make
it more clear that it's only to read the first 3 parts, and to treat the
rest as text.

I will fix it for 0.1.3, but for now, you may have to stick with
NanoVNA-Saver 0.1.1. Or upgrade firmware to edy555's 0.2.3. ;-)

--
Rune / 5Q5R

On Sat, 12 Oct 2019 at 23:55, bryburns via Groups.Io <bryburns=
[email protected]> wrote:

On Sat, Oct 12, 2019 at 03:48 PM, Rune Broberg wrote:

-D logfile.txt

Rune,

The logfile.txt is attached. I ran the initial scan, one without a
calibration loaded, loaded a calibration, and then ran another scan before
closing the file. You can probably tell all that from the information in
the text file.

--
Bryan, WA5VAH

I share your opinion of this seller; they seem to be giving away their items. Too good to believe.
Stuart K6YAZLos Angeles, USA