开云体育

I wouldn't go that far. 8*)

Sure, you _can_ assign I/O pins in software.

However, that leads down the rathole of _both_ sides having to programmatically assign pins of Tx and Rx, and have potentially different meanings for each side, and now we've got four arrangements of software switch in addition to what wire goes where. At the end of the day, we only have to figure out that _this_ hardware pin is an input, and should be connected to the output pin from the other side, and we only have to figure it out _once_, not every time someone changes some stuff in software, or the device gets factory reset, or something.

And then there's the UI around how do I tell the software what pin I want to be the input and what one I want to be the output, and what I want to label them (Tx, Rx, Input, Output, SerialTTLtoTheOtherSide, SerialTTLfromtheOtherSide, etc), and how I even tell the software those things without connecting hardware to it and communicating with it, and if I do that I'm done!

73, Willie N1JBJ

Jos - please put a copy of your file into the forum's file section and create an entry in the Wiki, pointing to the file.
Thanks!

2. as far as having tx -rx lines reversed in nanoVNA - could that be done in software much easier than in hardware ?

I'm probably stupid, but for you Tx and Rx these are just labels next to contacts ... just labels, and you propose to programmatically change their meaning simply because you do not understand what it is
Great idea.

On 7/20/21 9:16 PM, Anne Ranch wrote:

Sorry for the wrong link, senior moment.
Just been reaading the mail on th eorignal HC-05 "problem".
One poster made a comment on Windoze response - "Coupled" .
Never encountered such term in Bluetooth or Linux.
If true, talking about making -up own terminology .


Now this is little premature to mention, I like to get the hardware questions sorted out first , but

1. in the other tread they mentioned receiving unwanted characters or working at specific baud rate only
my guess it still goes back to understanding the serial communication protocol - not only baud rate but start / stop , parity etc.

For an interface that is so simple at some levels, over the past 50 years, I have had more problems with serial interfaces than any other.? Mostly because there's myriad ways its implemented and options - speed, start/stop/parity - flow control - pinouts - actual voltage levels needed.

2. as far as having tx -rx lines reversed in nanoVNA - could that be done in software much easier than in hardware ?
a question to the author of the software - will ask much later

I don't know about that specific microcontroller, but in most of the others I've worked with, the pin functions are fixed.? You might be able to make it a SPI interface, or GPIO pins, instead of UART in/out, but that assignment is fixed.



Section 3.17 describes the USARTs (4 of them!)
Table 14 shows the pin assignments - 30,31 (on pdf page 41)

On 7/20/21 7:11 PM, Roger Need via groups.io wrote:

How did you calibrate? If you keep clips at a fixed distance during calibration and measurement you will get better results.

calibrated using a 50 ohm BNC load, a BNC short, and left it open.

Yes, if I were to tape the leads down, it would probably work better, but this was a first try at a "rough and ready" measurement

I'm thinking that the "parasitic inductance" of that 100 ohm resistor is probably pretty small, which was the idea.

Maybe I'll take the resistor into work and measure it on a real LCR meter.

Roger

Hello DiSlord, Gyula and all others,

I finally succeeded to have my NanoVNA-H4 run under BlueTooth, thanks to your help.

I have attached the procedure I used successfully, for those who are interested.

Thank you all,

Jos

Op 19-7-2021 om 20:45 schreef DiSlord:

--
Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware.

BTW, the device does show up (at least on my Win7) device mgr.

On Wed, Jul 21, 2021 at 06:16 AM, Anne Ranch wrote:

2. as far as having tx -rx lines reversed in nanoVNA - could that be done in
software much easier than in hardware ?
a question to the author of the software - will ask much later

They are NOT reversed, TX always means output and RX is always input - you should never connect output to output (possible damage) and input to input.

Thanks for the welcome and very helpful suggestions Larry.

I followed your advice and found many great resources in the files section. With the advice from you and the file guides I updated the firmware. All seems to be working. Nanovna-saver allowed easy testing of several filters that I had built and yielded great data and plots.

Best wishes, Roger

Sorry for the wrong link, senior moment.
Just been reaading the mail on th eorignal HC-05 "problem".
One poster made a comment on Windoze response - "Coupled" .
Never encountered such term in Bluetooth or Linux.
If true, talking about making -up own terminology .


Now this is little premature to mention, I like to get the hardware questions sorted out first , but

1. in the other tread they mentioned receiving unwanted characters or working at specific baud rate only
my guess it still goes back to understanding the serial communication protocol - not only baud rate but start / stop , parity etc.
2. as far as having tx -rx lines reversed in nanoVNA - could that be done in software much easier than in hardware ?
a question to the author of the software - will ask much later

How did you calibrate? If you keep clips at a fixed distance during calibration and measurement you will get better results.

Roger

On 7/20/21 10:15 AM, Donald S Brant Jr wrote:

Kent: Since you are making up for system losses, you could place the amplifier at the receive port as well, or anywhere in the system that it is convenient. As long as you calibrate with the reference antennas (and the amplifier or receiver is not being saturated) the results will be the same. It would increase the susceptibility to interference, though; bandpass filtering would be helpful in this case.

Or both.. They've gotten kind of expensive ($150 each, they used to be $50), but I've made lots of use of the Minicircuits ZX60-4016E for this kind of measurement, with suitable filters. 20M-4G, 18dB gain, P1dB 16.45dBm, 3.5 NF..?? Set up your cal process right, and the amplfiers and filters are "inside the cal".

On 7/20/21 10:04 AM, roncraig1@... wrote:

Passive antennas have directivity not really gain but the term 'gain' is often used to express the amount of energy directed in a given direction compared to some reference antenna like a dipole.. An antenna is an energy directing impedance transformer from transmission line to free space.

Not to get into a discussion about "gain" for passive devices.. But Antenna Gain, in virtually all the literature, given with a reference (usually isotropic) means the relative far field intensity compared to the reference, in a given direction.? So it includes "antenna losses".? Directivity would be "lossless".

So for "real" passive antennas, D is always > G.

If gain is given in an equation with no reference, then it is "compared to isotropic, which by definition has G=1".?? For instance, in a Radar Equation, you'll see Gr*Gt in the received power formula

The model as an impedance transformer is a fairly good one.

One can go down quite a rabbit hole when making precision antenna measurements - Have you accounted for the uncertainty in the mismatch of the source and the receiver, for instance.? If you have multiple feedpoints (pretty common today, with MIMO systems), then the impedance seen at feedpoint #1 is affected by the impedance connected to feedpoint #2-N.

For most practical applications, one cares about gain (=directivity - ohmic or dissipative losses).


The other antenna measurement of interest is the "effective height" or "effective aperture" - the former is the ratio between the incident electric field and the open circuit voltage at the antenna terminals. The latter is the ratio between of power density incident on the antenna and power available at the antenna terminals.

The primary issue with direct antenna measurements is environmental effects, most significantly the effects of being close to a ground. The environment can reflect and/or dissiplate radiated energy. The conductivity of ground determines this.

If you are trying to measure a 40 meter antenna close to ground the proximity of ground has a significant effect on antenna pattern and antenna terminal impedance.
At 21-10 meter beam on a tall tower, there are less ground effects, although there is some effect due to close proximity of metal support tower.

Ground proximity usually effects the upward warping of the antenna's main radiating lobe. It can even cause pattern to break into multiple elevation angle lobes at different angles of peak radiation. If you know or can accurately predict this you can use it to optimize radiation for a given freq/altitide ionospheric bound by adjusting height above ground of antenna.

Even with small VHF and UHF antenna you have to worry about reflections off of ground, typically reflections from half the distance between equal height mounted Tx and Rx points antennas. It is very easy to fabricate a reference dipole for these frequencies and achieve a reference dipole within a couple tenth's of dB from theoretical.

So for HF measurements, the biggest challenge is the upward pattern tilt and possible multiple elevation lobes. You need to understand all the peripheral environmental factors and check/eliminate their influence. Running a long coax from Tx to Rx antenna to a nano becomes part of the environmental impact.

Finding a random 100 5% ohm resistor (almost certainly film) in the junkbox, I measured it..

DC it's 98.3 ohms (on a 20 year old DMM that has never been recalibrated)

Using a BNC to clips adapter, and calibrating at the BNC/SMA adapter plane, I got interesting data..

The series L appears to be about 200-250 nH, of which a substantial portion is the clipleads (since measuring the clipleads by themselves gives 250-300 nH) - I didn't go to any effort to make the clipleads have a consistent spacing, etc.? Next time around, perhaps.


And the resistance increases as the frequency goes up (skin effect? if it's as sqrt(f) then it would be.)

Without a balun, the coax shield is also part of the antenna.
Got any Ferrite beads?? ?Big ones that you can slide over the coax, or?better yet some of the clip on ones often used on AC power cords?
Clip one or two of those on the coax near the antenna and I bet both plots will be very similar.
Kent

Thanks Larry. That is what I was hoping someone would advise!
Best wishes,
Roger

If you can flash and talk to the unit with the current driver's, don't change anything.?


On Tue., 20 Jul. 2021 at 6:26 p.m., Roger<ve7vv@...> wrote: Hello,

I have searched the site and did not find a relevant message for my question.

I did connect the nanovna usb cable to the Win7 laptop before installing the new driver - which may have been a mistake. Windows did install a driver. Device Manager identified the driver as STMicroelectronics, 24/04/2010, driver version 1.3.1.0.

I downloaded and installed the STM version 1.5.0 driver installation software. Windows said the installation was successful. Device manager still showed driver as the 1.3.1.0 2010 version. Restart had no effect.

Nanovna-saver installed and works fine.
DeFuseDemo installed, recognized the Nanovna in DFU mode (even though it does not show up in Device Manager when in DFU mode), and upgraded firmware to 1.0.64.
So, as far as I can tell from the above, the device is connecting to the Win7 laptop well.

Nevertheless, when I followed all of the various driver upgrade methods shown in the Absolute Beginner Guide, plus uninstalling the driver for the device in Device Manager, re-running the STM driver installation program, directing Windows to the new DeFuseDemo driver files, nothing worked. In every case Windows said that the driver was "up to date".

So, finally, my question: is there any reason to persist with trying to get a newer version of the driver to be associated with the nanovna given that the Windows software seems to work OK with the old version? If so, how to do it?

Thank you.

Roger

William,

Try:

Don, K5DW

I recently built a 340 MHz dipole for test purposes. My NanoVNA-H4 was calibrated initially at the transmitter end of the coax cable. The first attachment shows the response of the antenna with transmission line from 200 MHz through 500 MHz. It was quite surprising to see the result. The transmission line is 15 feet of RG-58A/U coax.

The next step was to calibrate the NanoVNA-H4 at the antenna end of the transmission line. As you can see in the second attachment, the difference is quite dramatic.

I'd be interested in any comments. There is a 24 MHz difference between the various peaks and valleys in the first chart. It turns out that the transmission line is a half wavelength at 24 MHz after accounting for the velocity factor. It appears that frequencies that are multiples of 24 MHz come into play. I wonder if there is also an effect from frequencies that are odd multiples of a quarter wavelength.

73, Kent
AA6P

Hello,

I have searched the site and did not find a relevant message for my question.

I did connect the nanovna usb cable to the Win7 laptop before installing the new driver - which may have been a mistake. Windows did install a driver. Device Manager identified the driver as STMicroelectronics, 24/04/2010, driver version 1.3.1.0.

I downloaded and installed the STM version 1.5.0 driver installation software. Windows said the installation was successful. Device manager still showed driver as the 1.3.1.0 2010 version. Restart had no effect.

Nanovna-saver installed and works fine.
DeFuseDemo installed, recognized the Nanovna in DFU mode (even though it does not show up in Device Manager when in DFU mode), and upgraded firmware to 1.0.64.
So, as far as I can tell from the above, the device is connecting to the Win7 laptop well.

Nevertheless, when I followed all of the various driver upgrade methods shown in the Absolute Beginner Guide, plus uninstalling the driver for the device in Device Manager, re-running the STM driver installation program, directing Windows to the new DeFuseDemo driver files, nothing worked. In every case Windows said that the driver was "up to date".

So, finally, my question: is there any reason to persist with trying to get a newer version of the driver to be associated with the nanovna given that the Windows software seems to work OK with the old version? If so, how to do it?

Thank you.

Roger