开云体育

Or, they might be dumping inventory to get liquidity.

Hi Rune,
thanks for the software update and for the additional features!
One issue I recognized: S21 is with the previous version after calibration
right on the 0 dB line and on the current version somewhat below the 0 dB
line.
Am I doing something wrong with the new version?

Kind regards
Norbert, DG1KPN

Hi Rune,
thanks for the software update and for the additional features!
One issue I recognized: S21 is with the previous version after calibration
right on the 0 dB line and on the current version somewhat below the 0 dB
line.
Am I doing something wrong with the new version?

Kind regards
Norbert, DG1KPN

Here I am working on a circularly polarized 440 MHz antenna for satellite
ops. The first screenshot shows initial results when it was first
connected. The second trace is after tuning. To be able to see Return Loss
and the Smith Chart at the same time, in real time, was invaluable in
getting this thing corralled.

Next step: build a second one and phase them to give me a 2 bay CP
transmit antenna with 0 dBi gain. Exactly what I wanted.

WA8TOD

Hi Bryan,
sweeping currently works as follows:
1) The requested frequency range is set (start and stop frequency)
2) A delay of 300 ms
3) The frequencies are read back by sending the text "frequencies", waiting
50 ms, and then reading them
4) The S11 data is read (again, 50 ms delay included)
5) The S21 data is read

I decided on 300 ms after testing a few times, and figuring that it was
"probably fine". Setting no delay sometimes let to errors, and more than
250 ms seemed to be fine, so I set it to 300. Maybe it's too low? But
then I was using Hugen's firmware.

If you can make a non-continuous sweep that produces a noticeable error,
you can try exporting the S1P/S2P Touchstone file, and looking at the
frequencies. The Touchstone export reads the exact frequencies reported
back by the NanoVNA, so it should tell you what frequencies it thinks it's
reporting data for.

Sadly I don't think it's something I can really address in the application
- I believe it has to be accounted for in the firmware.

Thanks for the work you're doing on this issue, though! Good luck with it!

--
Rune / 5Q5R

On Tue, 1 Oct 2019 at 16:40, bryburns via Groups.Io <bryburns=
[email protected]> wrote:

Rune,

Thanks for taking a look at this thread!

My biggest concern is that with the firmware 0.2.2 from edy555 I always
see incorrect data in the second scan when using 2 scans between 80 and 120
MHz. With a single scan there are no errors over the same frequency
range. The incorrect data is always wrong in the same way. I.E. it is
actual measurements but they are from the wrong frequencies. If I do 5
scans, it appears that the first part of scans 2 through 5 is almost always
incorrect data. If it were occasional errors, I could work with it;
however, it is repeated with my nanoVNA and this firmware. When I request
a single scan over the exact same frequencies as the 2nd or 3rd or 4th or
5th scan, I very rarely, if ever, see an error in the nanoVNA-Saver data,
even in continuous sweep mode. What is different about continuous sweep
mode? Is there a pause between the scans?

I very rarely, if ever, see it with firmware from hugen dated August 2,
2019 using the exact same scan settings 2 or 3 or 4 or 5... Yes, I will
occasionally see errors with the hugen firmware but they are quite rare and
usually pretty obvious. Repeating a sweep or measurement will clear the
errant data.

I don't know much about the transfer protocol between the nanoVNA and the
PC. From your comment above, I would have to assume that you do not get
the frequency information in the same message as the data so there is no
way to throw out data based on the fact that the frequencies you requested
are not the frequencies sent from the nanoVNA. Is that correct?

A few questions, mostly thinking out loud. :>) I wonder if data is being
sent from the firmware before the hardware has actually stabilized at the
new frequencies you have requested? Would it help to pause a bit after
requesting a new set of frequencies?

I will continue looking for more clues to this issue.

--
Bryan, WA5VAH

On October 1, 2019 at 8:49 PM John Kolb <jlkolb@...> wrote:



I've ordered a pair of SMA male to SMA female adapters to attach
permanently directly to the nanoVNA to protect it's connectors.
Hopefully they will arrive before the VNA does.

John KK6IL

On 10/1/2019 5:03 PM, mike watts via Groups.Io wrote:

No No Roy! You need the female to female adapters if you use a coax jumper to move the calibration plane away from the VNA and to protect the connector on the VNA from physical stress. Attaching a DUT directly to the VNA connector puts the VNA connector at some risk. My standard procedure is to attach a coax jumper - rather than the DUT - to the VNA, otherwise you wind up with some rather large rigid object sticking out in the air, just asking for trouble. That is such standard procedure for me that using it any other way didn't occur to me. That is what I recommend, but I realize not everyone will always want to use it that way.

Whatever adapter you attach to the calibration standards must have a female connection on that end since the calibration standard is male. The other end should also be female if you use a coax jumper (almost all of which have male connectors on both ends - including the ones included with the NanoVNA). If you do not intend to use a coax jumper, then the other side of the adapter should be male. I just didn't think to point out this possibility in my notes.

I shall attempt to clarify that.

Thanks,
Mike WY6K