开云体育

QRP wrote:

…. icon disappears if voltage on the pin is below 100 mV. So, you can get picture with no battery if diode is not installed.

Regarding to the edy555 firmware, there is some difference with hugen79 firmware:
1) hugen79 firmware has imbalance gain correction, which is missing from edy555 firmware
2) hugen79 firmware has a little different logic for frequency band/gain change.
3) hugen79 firmware has correct default touch calibration, which works ok with NanoVNA-H hardware even with no touch calibration. edy555 firmware has different default touch calibration which is incompatible with NanoVNA-H hardware, so you're needs to calibrate touch screen after switch to the edy555 firmware.

----------------------------------------------------

Very useful info. However I have not installed the diode and I still get a battery icon (see attachment). I thought the way it worked is that if a diode was not installed the icon always showed as empty.

- Herb

For active load with no reactance (such as cal-kit load, terminator or just some resistor) software correction may works ok. But when you try to measure reactive loads and resonant circuits, you will get errors. Because hardware 50 ohm ports will affect your circuit parameters.

The problem here is that NanoVNA has hardware 50 ohm input and output. You cannot fix it with software settings. Even if you apply error-adapter correction for 75 ohm, your NanoVNA ports are still 50 ohm and it will affect Q-factor of measured device. So, you will get shifted resonance frequency, shifted bandwidth and other errors.

it looks strange, as I understand it worked well before upgrade. So it looks like some settings issue.

Try to connect to your NanoVNA with terminal, for example PuTTY. type "help" it should show you list of all supported commands, in such way you can check that terminal connection is established successful. Then execute this command:

clearconfig

It will clean all settings to default state. After that power off and power on device and check if your issue is fixed or not?

Mini Circuits and several other companies sell 50-75 Ohm transformersjust for situations like this.??? There is also a 7 dB 'Min-Loss Pad'.? An
attenuator with resistance values such that one side is 50 Ohms and theother side 75 Ohms.? For S11 you would need to cal on the otherside of the 7 dB.pad.For S21/S12 you would need two pads and cal out the 14 dB of loss.
Kent

On Sun, Oct 13, 2019 at 05:40 AM, KE8CPD wrote:

I changed to span to 50khz to 300 mhz and it appeared to be normal (see photo).

I'm not sure what is wrong? Could you please explain your issue more detail?

If correction is disabled you can enable it with CAL => CORRECTION menu. Does it solve your issue?

On Sun, Oct 13, 2019 at 06:31 AM, hwalker wrote:

I'm pretty sure all version 0.2.3 firmware have the battery icon which I don't
see on your photos.

This icon disappears if voltage on the pin is below 100 mV. So, you can get picture with no battery if diode is not installed.

Regarding to the edy555 firmware, there is some difference with hugen79 firmware:
1) hugen79 firmware has imbalance gain correction, which is missing from edy555 firmware
2) hugen79 firmware has a little different logic for frequency band/gain change.
3) hugen79 firmware has correct default touch calibration, which works ok with NanoVNA-H hardware even with no touch calibration. edy555 firmware has different default touch calibration which is incompatible with NanoVNA-H hardware, so you're needs to calibrate touch screen after switch to the edy555 firmware.

On Sat, Oct 12, 2019 at 11:06 AM, Bill Hemmings wrote:

You know, after all the talk about matching impedances, I'm really

wondering .... we talk about POWER in watts but that's pretty much for

transmitters. But we talk about receivers in? VOLTS. Well, okay, microvolts,

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

receiver input impedance. Maybe it lowers the antenna bandwidth or Q?

Impedances have PHASE, but voltages do not. Care to comment?

Bill, you get maximum power transfer when the impedance is matched. Wiki "Maximum Power Transfer Theorem" for details. This applies to transmitter to coax to antenna to air (the ether). Or the ether to antenna to coax to receiver. Some energy is lost in the resistance of the coax wire, and in the inductance and capacitance that we measure as Xl and Xc. When there is a change in impedance, a discontinuity, some of that energy is absorbed at the discontinuity and some is reflected, causing a standing wave. The reflection moving back down the coax also loses the same proportion of energy as the first wave. Where it hits the transmitter matching unit or final, is reflecfted forward to the antenna and loses energy again in the coax . Etc. Signal strength (in the ether) is measured in micro volts (uV) per meter because it is a field, not just a current in a wire. If you have a mismatched receiving antenna system, you lose some of the signal, (and atmospheric noise, too) but retain the noise inside the receiver, so your signal to noise ratio goes down.
also see:



Jim, KA6TPR

KE8CPD,
I have the same NanoVNA (Black without shields) as you and also just upgraded to version 0.2.3. I'm pretty sure all version 0.2.3 firmware have the battery icon which I don't see on your photos. I upgraded using hugen's official release at . My NanoVNA came with the two trace software and I wanted to upgrade to four trace. The previous advice, when upgrading from two trace to four trace, was to load "CLEAR_MEMORY_DFU.dfu" first and then load the four trace software. Hugen says that is not necessary with his 0.2.3 release. In any event, if you use his release and things don't look right after calibration, ensure that "Correction" is highlighted under the "Cal" menu.

Herb

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

A poor impedance match is usually a bad idea for coax but a conjugate match using low loss parallel feedline is often acceptable. For instance, according to TLDetails, the matched line loss for 65 ft. of RG8x at 7 MHz is 0.5 dB. The loss in 65 ft. of 600 ohm parallel line at 7 MHz feeding a 50 ohm load is 0.2 dB even though the SWR on the 600 ohm feedline is 12:1. The loss in the impedance matched RG8x with an SWR of 1:1 is 2.5 times the loss in the impedance mismatched (but conjugately matched) 600 ohm feedline with an SWR of 12:1.

Good evening all,
I got out my NanoVNA (Black without shields) and without thinking i pulled the lastest firmware and flashed it. I calibrated like ive done so many time before, and made sure the "correction" was highlighted after the calibration was done. After all said and done i reconnected the 50 ohm load and the smith chart was all over the place (see photo). I changed to span to 50khz to 300 mhz and it appeared to be normal (see photo).

What am i doing wrong? The previous firmware worked great, with zero issue (like the issues im having now) to 900 mhz.

QRP RX

Yes. I've determined the screen is defective.

Thanks.

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