开云体育

On Wed, Nov 6, 2019 at 06:41 AM, Nick wrote:

With BAV99 2 diodes and a fully charged battery set vbat_offset to 1000
and
VBAT reads 4210mV on Version screen.

Just calibrated by setting vbat_offset so that the indicated voltage on the
Version screen = measured battery voltage.

Fully charged reading (LED1 not blinking) now 4140mV with vbat_offset set to
950.

Estimated error +/-1%.

The on screen charge indicator works well as the battery runs down.

VBAT now < 3.7V under all charge conditions. Within Absolute maximum rating
spec of 4.0V.

Looking at the Fairchild data sheet a pair of 1N4148 should give similar
results.

Hi,
Now I have a VBAT: 4024mV, and measured after the diode: 3963mV. I don't know where I can enter vbat_offset.
Can anyone "lead my hand"?

The resistance is a bit of and there is some capacitance

How would that error impact your other VNA?

I did.
The resistance is a bit of and there is some capacitance. Do you suggest to add that capacitance to the cable? But that capacitance is already there in the open calibration? I'm not quick in understanding this....

--
Erik, PD0EK

They must be specific for the design of the nanoVNA

How about measuring CH0 impedance by another VNA?

I already did
The same cables measured in the same way at another vna do not show these oscillations. Even though the same calibration kit calibrated perfect on both vna's. They must be specific for the design of the nanoVNA


--
Erik, PD0EK

The oscillation seems to be faster then the rotation speed from the cable
length so there could be some capacitive factor involved.

Using the open for calibration also at the end of cables
could eliminate one variable.

on the other end of the "scale" ..someone gifted me a HP Stream (2018 model) ...running Linux Mint 19.1 ..has more than 10 g freespace left on solid-state fixed drive
(if you don't want to mess with your current device) ...approx $200 on amazon

Jim

Setting power to 1 removed most of the noise and also the jump when switching to harmonics mode disappeared but it also resulted in yet another different oscillation pattern above 600MHz.
For measurements till about 400MHz power level 1 is for sure the best as the cable attenuation for both cables is very lineair, even for the RG58
Above 400MHz there is still a ghost hiding somewhere
The oscillation seems to be faster then the rotation speed from the cable length so there could be some capacitive factor involved.
For the cable model I use only a first order rotation with frequency. Should I add somewhere a cable specific capacity that accelerates and amplifies the rotation impact at higher frequencies?
--
Erik, PD0EK

On 11/6/19 9:38 AM, DougVL wrote:

My PC runs Windows Vista with all available updates made. I suspect this may be the problem, but no newer operating system is available for this computer.

???? Yes, there is a newer operating system available for your computer:? Linux.? Windows Vista is out of support and no longer updated, so, if you continue to use it, at a minimum you should keep it off the internet.? I have updated many older computers running Vista, XP (and even earlier versions) to Linux.? A common comment from the owners of those computers is, "Wow, this is faster than it ever was, even when it was new!"? Linux is a great way to breathe new life into older computers.? Something to think about, anyway.? If you want more information on using Linux on our old computer, you can email me off-list.

????????????????????????????????????????????? Jim, N7JA

On Wed, Nov 6, 2019 at 01:16 AM, Rune Broberg wrote:

Have you set the NanoVNA to normal (non-TDR) mode before making the
readings?
If you would be willing to send me a Touchstone file of the data, that would be helpful for testing! :-)

Rune,

Yes, I did set the nanoVNA to non-TDR mode before making the readings. This is essential to getting good data in nanoVNA-Saver from the nanoVNA. I recalled cal0 which was created with my best SMA calibrators (from another VNA) on short male-female connector savers attached directly to the nanoVNA.

Attached is an S1P file from the ~0.5m long RG316. I also have attached an S1P file from the ~1 m long 75 ohm cable that you can use for testing with nanoVNA-Saver 0.1.5. Using the velocity factor for RG316 as 0.695 give a length of 0.56 m for that cable. Setting the velocity factor for the 75 ohm cable to 0.66 yields a cable length of 1.086 m. The cables are showing a little longer than the measured length because of some 50 ohm adapters that are about a total of 2" long on the nanoVNA end of the cables. These are the same cables I used in the nanoVNA screen shots shown above.

Both cable measurements were made using my best nanoVNA calibration and the best tuned nanoVNA-Saver calibration.

I hope these help your efforts with the TDR software to show the impedance vs time.

--
Bryan, WA5VAH

4 traces, big font, big info screen, 1500 Mhz, battery indicator

Has anyone tried it lately?
YT9TP - Pedja could not calibrate over 310MHz on Oct 22
/g/nanovna-users/message/5510

That is a lot of data to buffer.

Given custom NodeMcu/nRF5 firmware, nanoVNA need pass only 101x2x4 bytes of float per scan,
which could then be converted to ASCII by BTLE micro for USB COM compatibility.

Hi,

Maybe this in interesting for you:

4 traces, big font, big info screen, 1500 Mhz, battery indicator

2 traces (AA version), big font, 1500 Mhz, battery indicator

Battery indicator requires an additional diode.

Dana,

Indeed, and for that reason I measured the same cables with the same calibration kit on thee different VNA's. (one the nanoVNA)
The results from the 3GHz VNA convinced me the fluctuations seen at the nanoVNA where not originating from the cable as such.
If this is a a wrong assumption I'd welcome an explanation to avoid I'm chasing ghosts
--
Erik, PD0EK

Hi Erik;

I was raised to believe that there is no such thing as a stupid question, but after several decades of not being exposed to the light, I discovered that there are actually many... All of them are the ones that never get asked. :-)

From my perspective at least, the question you asked was a brilliant one, as evidenced by the response it solicited. It is a struggle for me to capture much of the understanding I'm attempting to achieve through the many segmented and translated responses. Its only fair to assume that the reverse holds true for them as well. Their published documents on this are much better written English translations, but they don't stand on their own for all readers, and for those of us who have had limited if any exposure, are left with many unanswered questions.

We ask questions to get smarter. Very often it is helpful to hear "You don't understand." If we fail to ask questions that solicit such a response, we might well go through our lives with the truly stupid notion that "We must be pretty smart."; while in fact we have no understanding at all. :-)

Sometimes I ask questions that I believe I know the answer to very well, to verify my understanding. I am a married man, so I have learned that just because I'm confident that I have all of the right answers; most of the time they are entirely incorrect. LOL!

--
73

Gary, N3GO

That is a lot of data to buffer

nRF52832-QFAA/QFN48 has 64KB RAM + 512KB flash

ESP8266 reportedly has > 40KB heap+data space available.

I guess HC-05/6 is unbuffered but also not BTLE,
so less interesting for e.g. Web Bluetooth API

I've tried NanoVNASaver v0.1.3 and v0.1.4 but they will not start. I get a DOS window with the error message:
"Could not load the Qt platform plugin "Windows" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: minimal, offscreen, webg1, windows."

Reinstalling NanoVNASaver (either version) did not fix the problem.

My PC runs Windows Vista with all available updates made. I suspect this may be the problem, but no newer operating system is available for this computer.

Is there any known solution to not loading the Qt platform?

NanoVNA Sharp works well, though.

Thanks,
Doug, K8RFT

That is a lot of data to buffer.

On Wednesday, November 6, 2019, 12:14:38 p.m. GMT-5, Oristo <ormpoa@...> wrote:

> At the minimum you may

need to include some ferrite beads in the power and serial connections.

Firmware should sleep Bluetooth while sweeping and pause sweeps while Bluetooth is active.

At the minimum you may
need to include some ferrite beads in the power and serial connections.

Firmware should sleep Bluetooth while sweeping and pause sweeps while Bluetooth is active.

Before adding a radio transmitter and a second microcontroller such as a
HC-05 to the NanoVNA, you may want to examine how much RFI it might
introduce into the NanoVNA. My experience with my VNA, which I have
connected a HC-05 to, is that it introduces a lot. At the minimum you may
need to include some ferrite beads in the power and serial connections.

On Wed, Nov 6, 2019 at 11:27 AM William Heller <wheller34052@...>
wrote:

I am a retired embedded processor engineer an can recommend the ESP32
programmed as a serial to bluetooth/WIFI adapter it is a 32 bit processor
with the usual peripherals and both bluetooth and WiFi built in and do on
and do small pub only costs a few do?lars.

On Wed, Nov 6, 2019, 7:42 AM vaclav_sal via Groups.Io <vaclav_sal=
[email protected]> wrote:

Nice, but I am after adding the bluetooth externally.

Like to ask if it would make more sense to add processor internally
supporting wireless commodification.
I have not done any research if such processor exists.

Something in Raspberry Pi Zero style.