开云体育

ideald shield should be soldered with no gap. Because any gap leads to ground loop. Longer gap leads to higher noise. Did you see these through holes on the pcb ground? These holes are named "vias", they plays the same role as shield soldering. As you can see, there are a lot of vias with a short distance. This is needed to avoid ground loops between front and back ground layers of pcb.

On Mon, Oct 21, 2019 at 01:04 AM, Mike_nano wrote:

What am I missing? Did I do something wrong?

yes, you did it wrong. There are two problems with your shields:
1) You're forgot to solder left top corner of shield. The distance to the ground is long, so the shield works as loop antenna and receiving noise.

2) the distance between shield and c26, c27 is too close. Short distance leads to capacitive coupling. You're needs to cut a small piece of left top corner of your shield in order to increase distance between shield and c26, c27.

Also, you didn't shown what is under the hood of the top shield. There is also may be problem with capacitive coupling due to short distance and missing soldering at some point. Also, there are needs two sections under shield for CH0. It's not clear from your photo if CH0 shield has two sections or one section.

Kurt, Just read your comment above. I think you said it works by Magic, Which I believe. I will have to get a bit of experimenting experience before I try ferrite beads I think.

Jim, KA6TPR

i did

if you search on the term battery size you will get a lot of information. But here is one post:


|kf7dur
|
|Sep 5 #1870 ?
|
|
|Karl,
|
|I used a 602040 450mAH (5x20x31.5mm) battery in my Banggood NanoVNA. I don't think anything bigger will fit.
|$8.99 from Amazon.
|
|Ken
|KF7DUR

I also added a nice board photo uploaded by Mike. Shows the battery very nicely.

Advice to newbies: Search .....Look at the Wiki..... Read the Tips and Users Guide. #RTFM Look at and use #Hashtags

The NanoVNA is not Plug and Play. Using a VNA is not Plug and Play if you want reliable results. It is not a grid dip meter (look that up) and it isn't an MFJ 259B. It is a work in progress, IT IS A KIT! Firmware is being revised every few weeks right now, and the NanoSaver software is maturing very nicely, but it is being worked on by people who are not getting paid. Don't worry about firmware upgrades until you have some time with the Nano.

Hi Bryan,
I haven't tried the 0.3.0 firmware yet. Looking at the (sparse) release
notes, it's not obvious that there would be anything there that changes how
NanoVNA-Saver interfaces with it. I'll see if I can't find the time to load
it onto my NanoVNA and test it out :-)

--
Rune / 5Q5R

On Mon, 21 Oct 2019 at 07:03, bryburns via Groups.Io <bryburns=
[email protected]> wrote:

Rune,

I have been using several new features in nanoVNA-Saver 0.1.3 and think
that they are great additions.

I am trying to use edy555 firmware version 0.3.0 with nanoVNA-Saver
version 0.1.3. There are several new features in this firmware that are
beneficial to me when I cannot use nanoVNA-Saver, so I would like to keep
this firmware loaded in my nanoVNA. However, I am seeing a lot more data
errors with this version of firmware than I saw with 0.2.3 from edy555. It
is so bad that I cannot get a reliable calibration in nanoVNA-Saver without
using 5 averages and dropping 2 values in nanoVNA-Saver that are the
worst. This was not the case with the 0.2.3 version of firmware. With the
new firmware and software I had to do repeated scans until there were no
obvious errors in the data for each termination/through condition in order
to get a calibration that was reasonable. I could not use the Calibration
assistant. The errors are often 0.25 to 0.5 dB in the S11 trace and quite
obvious. Even data in the isolation state for through calibration had
large errors in amplitude, as much as 20-30 dB. I never see these errors
when I operate the nanoVNA by itself and simply use the displayed result.
It appears to be either something in the transfer (timing?) or something
related to scanning. Generally, there are about 3 or 4 bad samples per
scan, often at exactly the same frequency. As I have observed with some
previous firmware, the bad data is never in the first scan you do from
nanoVNA-Saver.

I have to wondered if the by-passing on the 5V power supply may be related
to this issue. Without replacing the 5V supply or improving filtering I am
not sure how to isolate this potential issue. Up to this point, I have
been reluctant to start modifying the hardware.

Have you been working with the 0.3.0 firmware from edy555? Has anyone
else reported this issue?

--
Bryan, WA5VAH

Rune,

I have been using several new features in nanoVNA-Saver 0.1.3 and think that they are great additions.

I am trying to use edy555 firmware version 0.3.0 with nanoVNA-Saver version 0.1.3. There are several new features in this firmware that are beneficial to me when I cannot use nanoVNA-Saver, so I would like to keep this firmware loaded in my nanoVNA. However, I am seeing a lot more data errors with this version of firmware than I saw with 0.2.3 from edy555. It is so bad that I cannot get a reliable calibration in nanoVNA-Saver without using 5 averages and dropping 2 values in nanoVNA-Saver that are the worst. This was not the case with the 0.2.3 version of firmware. With the new firmware and software I had to do repeated scans until there were no obvious errors in the data for each termination/through condition in order to get a calibration that was reasonable. I could not use the Calibration assistant. The errors are often 0.25 to 0.5 dB in the S11 trace and quite obvious. Even data in the isolation state for through calibration had large errors in amplitude, as much as 20-30 dB. I never see these errors when I operate the nanoVNA by itself and simply use the displayed result. It appears to be either something in the transfer (timing?) or something related to scanning. Generally, there are about 3 or 4 bad samples per scan, often at exactly the same frequency. As I have observed with some previous firmware, the bad data is never in the first scan you do from nanoVNA-Saver.

I have to wondered if the by-passing on the 5V power supply may be related to this issue. Without replacing the 5V supply or improving filtering I am not sure how to isolate this potential issue. Up to this point, I have been reluctant to start modifying the hardware.

Have you been working with the 0.3.0 firmware from edy555? Has anyone else reported this issue?

--
Bryan, WA5VAH

I found it on Amazon. I don't know where else you might find it. 73 de K9GXC, Jim

Here is a link to the one I purchased:


Marco

Anyone have a recommendation for a good battery to add to a unit missing one?

Mike, looking at the photo of the shields and how they mount, there is nothing that is visible to me that is obviously wrong.

I say this because the ch1 shield is mounted on pads that seem to be tied to ground with plenty of vias, so if there were a ground noise issue, I’d expect noise to be improved, not worsened, when the shield is in place.

One thing I do notice, though, is that ch0 and ch1 both seem to have their own ground islands. And I’m wondering if the back plate of the instrument was screwed in place when you noticed the improvement in ch1 noise when it’s shield was removed. If the back plate is conductive (and from memory I think it’s made of PCB material), then it’s possible that the back plate is shorting all the grounds together through the standoffs and thus making a possible path for supply noise via rf ground. Compare the back plates of the two versions. Is one conductive and the other not?

Anyway...it’s difficult to troubleshoot a problem long distance! Experiment, see what improves performance and what worsens it, and always compare these effects to how you think the changes ought to be affecting the performance.

Jeff, k6jca

Just found it and started reading. Found a nice mod for a DFU switch. Go
to junk box, find last switch, break switch. I’ll have to find a new switch
but I am reading through the wiki now.

Thanks
Brad

On Mon, 21 Oct 2019 at 01:22, alan victor <avictor73@...> wrote:

Hi Martin,

Yes. The only issue I see is the display of X as pF (or maybe nH or uH) in
any case, all cases will be the parallel equivalent admittance (impedance).
Rune and I discussed and in all cases he is implementing the equations you
highlighted. All the series complex and Q are a-ok. And the conversions are
a-ok.

Alan

I mentioned some time ago that my HP LCR meter could show impedances in
many ways - I think there mist be about 20 ways. It doesn’t display
S-parameters though.

If its any help, I could do a single sweep then show every set of
measurements it shows. If a Touchstone file with one data line was created
to have the same parameters, it offers a way of comparing NanoVNA-Saver
with the LCR meter.

I am not suggesting that the NanoVNA software should implement all the ways
that the HP LCR meter does.

Some of the LCR meters on the market offer equivalent circuits with 3 or 4
components. I assume that requires looking at measured data over 2 or more
frequency points. My obsolete HP 4284A can not do anything clever like
that.??????

--

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

To replace the display with ili9486, you need to modify the ili9341_init_seq[] at line 151 of ili9341.c and change the LCD width and height at various files. But if you want to replace with ili9488, there will be more work. Please see my post at

/g/nanovna-users/message/5322

You can find the places to change the LCD width and height at my change list. Just look for "LCD_*".



Ken

Hmmm ... thanks for that. Let me play some more tomorrow and see what I can do.

Hi Mike_nano, Jeff...

One difference I note from prior photo's and shielding is the connection of the shield itself TO THE SMA CONNECTOR BODY. Each shield was returned to ground via the SAM. This connection could reveal an improvement and hence the presence of ground currents without that connection(s).

I am afraid that without the appropriate tools such as signal integrity simulation and EM, fooling around with shielding and cause and effect relations is like poking around in a dark closet with a sharp stick.

Alan

Hi Martin,

Yes. The only issue I see is the display of X as pF (or maybe nH or uH) in any case, all cases will be the parallel equivalent admittance (impedance). Rune and I discussed and in all cases he is implementing the equations you highlighted. All the series complex and Q are a-ok. And the conversions are a-ok.

Alan

ili9486 controller instead of the ili9341

Arduino folks do this sort of thing:


Practicing on e.g. a blue pill with Arduino_STM32 would seem a safer approach.

There are quite a number of wireless adapters with actual serial ports
AKA wireless device servers. Fewer with USB appear to be mostly for printers,
which is a different profile than for virtual COM ports.

An Amazon customer reports that the US$65
Hawking HMPS1A works with a USB to serial converter.


Power in is 5VDC, could be portable by USB power bank.

Hi DougVL -

I was (am) hoping someone might know of a wireless replacement for the USB
cable that goes from PC to NanoVNA.

I think there is no 64-pin STM32 micro that supports USB OTG,
so a bluetooth "dongle" that supports SCC profile and USB OTG is wanted.

although if something becomes available it might be very popular.

There are quite a number of wireless adapters with actual serial ports
AKA wireless device servers. Fewer with USB appear to be mostly for printers,
which is a different profile than for virtual COM ports.

There may be a way to add such a communication capability to the NanoVNA,
but it's probably a major effort and not worthwhile.
Unless there turns out to be a lot of other requests for it!

Moving the entire user interface to smartphone seems (IMO) desirable.
It might be possible to wire a so-called USB host shield into nanoVNA
that could drive existing bluetooth SCC dongles,
but would require stripping out existing function to add firmware support.

Particle Xenon uses a Nordic nRF52840 chip,
which has more capable STM32 than in nanoVNA and includes bluetooth,
so might make a great wireless nanoVNA-H 2.5 or 3.