Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Noise improvements. #14

Open
Pmax65 opened this issue Nov 11, 2019 · 104 comments
Open

Noise improvements. #14

Pmax65 opened this issue Nov 11, 2019 · 104 comments

Comments

@Pmax65
Copy link

Pmax65 commented Nov 11, 2019

I improved the noise adding few caps to the Silicon Labs clock generator chip and now the standalone instrument is fully working up to 1.5GHz with only a very little residual noise above 1.4GHz that it is appreciable in the Smith chart only.
I still have some issue with the PC communication because of the battery charger that disturbs the clock. I already thought a solution for this too, but I'm waiting for the sot23 P-MOSfet, to check if it works as thought. Once I fixed it I'll publish the "how to" of the whole hardware fixing.
In the meantime I have a couple of desiderata to your code.

  1. the flashing LED 2 is very noisy and useless. It's much better to keep it off, if your intention was to give a pace indicator, I suggest you to implement it as a virtual indicator somewhere on the LCD screen (I currently removed its limiting resistor to keep it off).
  2. Since there is still a little noise above 1.4GHz, It would be great if the calibration was done not by one acquisition of the raw data per calibration step as it is now. It should be better if you get more scans of the raw data and average them to get the correction coefficients averaged on more scans (say 10 scans, for example). This will take a little more time during the single calibration steps, but it should warrant that the noise is corrected on its averaged value and not randomly on the instantaneous values acquired during the single scan.
    Have a great day.
    Massimo
@qrp73
Copy link

qrp73 commented Nov 11, 2019

regarding to LED 2, NanoVNA-Q disable it during sweep cycle to avoid noise: https://github.com/qrp73/NanoVNA-Q/releases

so, there is no need to desolder something. You can just change firmware.

@Pmax65
Copy link
Author

Pmax65 commented Nov 11, 2019

Not really so.
The clock generator's inner PLLs are always locked also during the non scanning time.
So the perturbation on the integrators of those PLLs still deteriorate their output phase noise during the scan time.

BTW, even if I seen that in the latest versions the LED 2 is apparently off during the scan, using a DSO on the limiting resistor pad, I always see some voltage spikes of few ms in duration there.

For these reasons I removed that resistor and the noise above 900MHz dropped a lot, despite I already downloaded the latest version of NanoVNA-Q.

My current mods consist on:

  1. added one 4.7F X7R capacitor in parallel to C9 and one other on C10
  2. added one 68uF/6.3 tantalum capacitor in parallel to C9 and the 4.7uF already in parallel as above
  3. added one 68uF/6.3 tantalum capacitor soldered on U3 input pin and grounded to the ground plane near Y1
  4. removed R3

Doing the above, after a correct calibration, I get a Smith chart plot with just a little noisy plot of 2/3mm above 1.3GHz, making the instrument well usable in the HAM radio 23 cm band for antennas and filters checkings.
The SWR plot at 1.5GHz with the calibrated dummy load on the CH0 port shows 1:1.1 max 1:1.2 spikes, but below 1.3GHz is flat to 1:1
The return loss with the reference load used for the calibration, at 1.5GHz is better than -25dB on any board I checked, not that bad indeed
I did the test on 6 boards of three different versions, two having the ground clips and one having the nanoVNA-H board. And the results are almost the same.
Attaching the USB port, I still have noise above 900MHz, but I already checked that it is due to the battery charging. Detaching the battery positive wire and powering the VNA by the USB only, after a new calibration, the results are the same for the stand-alone running reported above.
For this reason I planned to put a P-MOSfet in series to the battery to detach the battery from the circuitry when the instrument is turned on and the power come from the USB port.
This way the battery charging will be still allowed when the instrument is turned off, but it's thought to remove that noise during the instrument is powered on. I just to check it when the MOSfets will be delivered.

Have a great day.

Massimo

@qrp73
Copy link

qrp73 commented Nov 11, 2019 •
edited
Loading

Not really so.
The clock generator's inner PLLs are always locked also during the non scanning time.
So the perturbation on the integrators of those PLLs still deteriorate their output phase noise during the scan time.

No, it performs PLL reset at the beginning of sweep. So, any voltage fluctuations outside sweep time doesn't matter.

NanoVNA-Q has 10 ms stabilization delay after LED off, before it starts sweep.

And NanoVNA-Q don't blink with LED at all until end of sweep.

@Pmax65
Copy link
Author

Pmax65 commented Nov 11, 2019

At this point I don't really know why I seen that sensible improvement after having removed R3.

Anyways, I'm sure that I also seen some glitches during the sweep. Let me return to home because now I'm in office and I can't check it one more time until I'll be back to home.

@qrp73
Copy link

qrp73 commented Nov 11, 2019 •
edited
Loading

You're seen it, because used firmware which uses LED blinking during sweep. NanoVNA-Q firmware disables LED during sweep and don't blink until the end of sweep.

@Pmax65
Copy link
Author

Pmax65 commented Nov 11, 2019

No, I'm not sure that I seen it with V0.4.3 indeed, but I'm sure that I seen it with your V 0.4.2, and (if I'm not wrong) that function should have been already done.

One doubt:
what is your noise above 1.3GHz without any additional caps on the 5V & 3.3V power lines?
My doubt is that having increased the capacitance on the 3.3V U3 output, that could have introduced some sort of instability at the voltage regulator output after current pulses on it's input that lasts more than those 10ms.
I must check resoldering R3.
I'll tell you this night.

@Pmax65
Copy link
Author

Pmax65 commented Nov 11, 2019

Hi qrp73.
yes you are right and I was wrong I didn't realized that when the LED2 is on, there is a PWM signal on it and having the horizontal scale of the DSO on 1ms/div I probably confused the ON state with OFF state of the LED2 when the PWM was there.
Here below you can see the 1.3GHz and 1.5GHz with the LED blinking.
(please note that I had to detach the battery + wire to get these plots from the nanoVNA Saver, because I still haven't received the MOSfets).
What do you think about the 10 time averaging suggestion during calibration?
It could better correct the scan above those 1.3GHz.

Thank you for sharing your work about this nice device.

With LED 1 3GHz
With LED 1 5GHz

@hugen79
Copy link
Owner

hugen79 commented Nov 12, 2019

Noise problems introduced by USB connection I will use the new power chip in NanoVNA-H V3.4 to improve this problem. I will try to increase the capacitance of the si5351 to reduce noise. The problem of LED flicker noise can be improved by software. If you prefer, you can send your address to my email at hugen@outlook.com and I will send you the modified PCB. Thank you!

@Pmax65
Copy link
Author

Pmax65 commented Nov 12, 2019 •
edited
Loading

hi hugen79,
first off all, thank you for considering this issue, and for sharing your work on the nanoVNA-H board.

Since I had 6 nanoVNA on the table (only one was mine, the others were owned by friends of my local radio-club, I'm not a collector :-) of course), I believe I missed to update one and probably I did the check on that one, because I well remember how the noise dropped down after having removed R3.
Anyways, considering how much the instrument is sensitive to the power supply noise I would keep that LED off since in my opinion is useless, but this is just an opinion of course.
About the USB connection I already ordered the MOSFETs and I hope they'll come here soon (Italian Postal Service permitting). I planned to detach the battery when the USB power is applied and the instrument is turned on, it should take just 3 components comprising the MOSFET, not that complicated indeed. I probably mount the components on a very small piece of prototyping board and solder it in place of the battery connector.

Anyways your nanoVNA-H 3.4 PCB is surely well accepted, I 'm curious to know how it is handled the new power chip.

By the way, do you know from where it cames the R40, C45 and C46 network configuration?
I admit that I know very little about the electrical layer USB specs, but do you know what's the usefulness of the 2ohm resistor in series to the second 10uF capacitance?

I'll send you a direct e-mail for the 3.4 PCB.

Have a great day.

Massimo

@hugen79
Copy link
Owner

hugen79 commented Nov 12, 2019

The specifications of r40, c45, and c46 are from the data sheet of Ip5303. The series r40 and c45 are used to ensure the loop stability of ip5303. However, when an external USB power supply is connected, the MOSFET inside the ip5303 turns on and uses an external USB power supply, causing external interference to enter the power supply. For the new PCB, I will use the FM9688, a power chip widely used in Bluetooth headset chargers in China. The chip charging circuit and DC-DC circuit work independently, and the external circuit is simple and easy to install on the nanoVNA PCB. on.

@Pmax65
Copy link
Author

Pmax65 commented Nov 12, 2019 •
edited
Loading

Hi hugen79,
thank you for the explanation, I seen that in the datasheet it was there, but (at least in the English version) I didn't find any explanation for it.

However, when an external USB power supply is connected, the MOSFET inside the ip5303 turns on
and uses an external USB power supply, causing external interference to enter the power supply.

I'm not sure the noise come from the USB line, I suppose is something due to the pulsed current into the battery during the charging process, because if you remove the battery and leave the USB power alone the noise is no longer there. For this reason I thought to put a MOSFET based switch between the battery and the Ip5303.
About the FM9688: I haven't found the english datasheet. I'm no way able to read the Chinese ideograms :-(
Have a great day.
Massimo

@qrp73
Copy link

qrp73 commented Nov 12, 2019

causing external interference to enter the power supply.

According to my tests, this is not external interference. You can apply very clean external power (with no noise), but anyway it will be noisy. Also it is not related with cable, because there is no noise when usb cable is connected, but external voltage is not supplied.

I think the root of cause may be the following:

  • IP5303 generate noise
  • external voltage leads to a little different power supply voltage and it leads to some change in behavior

@hugen79
Copy link
Owner

hugen79 commented Nov 12, 2019

causing external interference to enter the power supply.

According to my tests, this is not external interference. You can apply very clean external power (with no noise), but anyway it will be noisy. Also it is not related with cable, because there is no noise when usb cable is connected, but external voltage is not supplied.

I think the root of cause may be the following:

  • IP5303 generate noise
  • external voltage leads to a little different power supply voltage and it leads to some change in behavior

The difference in voltage will cause the gain of the sa612 to differ, resulting in errors. Maybe a separate charge pump can further reduce the noise, and I will do some tests.

@Pmax65
Copy link
Author

Pmax65 commented Nov 12, 2019 •
edited
Loading

I perfectly agree with qrp73 when he wrote:

According to my tests, this is not external interference. You can apply very clean external power (with no noise), but anyway it will be noisy. Also it is not related with cable, because there is no noise when usb cable is connected, but external voltage is not supplied.

In my opinion the problem is in the charging current pulses coming from the USB supply that produces inevitable little voltage spikes on the battery, since the voltage of the battery influences the calibration, in my opinion it's clear that those spikes are the cause of the performance deterioration.

I don't know if FM9688 will fix the issue, for doing that it should have two different switching mode PSU inside: one step-up for driving the load and one step-down for charging the battery; they should have very different PWM frequency to allow the step-up to be more reactive to the battery voltage changing caused by the lower frequency step-down charger.
In the datasheet, I see the schematic of the FM9688 and I don't see other than one inductor in that design, this lead me to think that it should not be much better than the Ip5303 under this context, but I could be wrong, of course.

Have a great day.

Massimo

@hugen79
Copy link
Owner

hugen79 commented Nov 12, 2019

I tried to replace the XC6206 with an ultra-low noise LDO RT9193, and I found that the noise has dropped. I will make a PCB test.
hugen

@Pmax65
Copy link
Author

Pmax65 commented Nov 12, 2019 •
edited
Loading

I tried to replace the XC6206 with an ultra-low noise LDO RT9193, and I found that the noise has dropped. I will make a PCB test.

Nice one. If it's confirmed the "thorn in the side" of the instrument is the clock generator, since the mixers are not powered from the 3.3V regulator.

@hugen79
Copy link
Owner

hugen79 commented Nov 13, 2019

I tried to replace the XC6206 with an ultra-low noise LDO RT9193, and I found that the noise has dropped. I will make a PCB test.

Nice one. If it's confirmed the "thorn in the side" of the instrument is the clock generator, since the mixers are not powered from the 3.3V regulator.

Sorry, I made a mistake. Due to my wrong connection to the RT9193 pin, the actual output voltage of the LDO rises to 3.6V, and the performance improvement is due to the voltage rise. But this gave me a new idea to improve performance, I am making new attempts.

@d51r3verse
Copy link

qrp73/NanoVNA-Q#13 (comment)
Mine(Green PCB) was around 6.5 MHz

@hugen79
Copy link
Owner

hugen79 commented Nov 13, 2019

qrp73/NanoVNA-Q#13 (comment)
Mine(Green PCB) was around 6.5 MHz

Thanks for your feedback, I will modify the schematic in v3.4.

@Pmax65
Copy link
Author

Pmax65 commented Nov 13, 2019

Hi hugen79,

Sorry, I made a mistake. Due to my wrong connection to the RT9193 pin, the actual output voltage of the LDO rises to 3.6V, and the performance improvement is due to the voltage rise. But this gave me a new idea to improve performance, I am making new attempts.

Don't worry:
anyone who has never made a mistake has never tried anything new!
(Albert Einstein)

:-)

I would have here the mosfets and tell you if the patch works for the USB powering.
Anyways, as I have them here, I'll surely inform you about how the patch works.

For the 7.5/6.5Mhz peak issue:
I didn't noticed of it, but I must say that I have already added the 100nF on the mixer as per the NXP datasheet. Since I don't see anything there on any of the 3 different versions I have here, I can confirm you that it works fine.
I didn't reported that caps mod, just because I was convinced that they did nothing to the instrument, since I never looked to that narrow range before.
My compliment to Owen for having catched that issue. Here in Italy we say: "he catched the the needle in the haystack".

@coralenka
Copy link

Hi
image

@Pmax65
Copy link
Author

Pmax65 commented Nov 13, 2019

Hi coralenka
Fantastic plots, how do you get them so noise-free up to 1.5GHz?

In the meantime, I just received the MOSFETs and checked the USB switcher and it works good, but above 1.3GHz as per the battery powered mode the noise is still there.

The mod consists of place on a small piece of proto-board (3 by 2 pads) an AO3401 P-channel MOSFET as follows:
DRAIN connected to the positive wire of the battery
SOURCE connected to the PCB positive battery pad
GATE connected to the ANODE of one 1N4148W diode and a 10kohm resistor (both on the little piece of proto-board).
The diode CATHODE is connected through a short wire to U3pin3, while the other pad of the 10kohm resistor is connected through a short wire to U2pin1.
Doing that circuitry, the battery charges only when the nanoVNA is not powered but the USB plug is connected to a current source.
When the nanoVNA is powered on, the battery is disconnected and the noise is as in the plots attached below.
Have a great day.

Massimo
1 5GHz with MOSFET switch
1 3GHz with MOSFET switch

@coralenka
Copy link

coralenka commented Nov 14, 2019 via email

@Pmax65
Copy link
Author

Pmax65 commented Nov 14, 2019

I made no mod to my device yet

Hi coralenka,
interesting.
Has your nanoVNA the battery installed?
I ask because when attached to the USB port, I experienced a great increase in noise bove 900MHz in all the 3 hardware versions I checked.
Your seems incredibly quiet even when attached to the PC.
Have a great day.
Massimo

@coralenka
Copy link

coralenka commented Nov 14, 2019 via email

@Pmax65
Copy link
Author

Pmax65 commented Nov 14, 2019

Hi coralenka,,
it's gorgeous.
Could you publish a photo of the nanoVNA?
Have a great day.
Massimo

@coralenka
Copy link

coralenka commented Nov 14, 2019 via email

@Pmax65
Copy link
Author

Pmax65 commented Nov 14, 2019

HI coralenka,
I'm not sure, did you send anything about how it looks your nanoVNA?
I can't see anything.

@coralenka
Copy link

coralenka commented Nov 15, 2019 via email

@Pmax65
Copy link
Author

Pmax65 commented Nov 15, 2019

It seems there is something wrong in the file handling because I can't see anything.
Could you send the photo to my e-mail?
My address is mporzio@teletu.it
I would like to know what HW it is, because I've some nanoVNAs from friends of my local radio club to modify and above 1.3GHz it seems really hard task to comply.
Thank you for considering my requests.
Have a nice day.
Massimo - IK1IZA

@hugen79
Copy link
Owner

hugen79 commented Nov 22, 2019

Hi hugen.
Well done!
Just to know:
A) why do your plots returned to have those peaks @ 300 & 900MHz?
B) In version 3.0 there was 3 100nF caps close to L3, L4 and L5 on the +5V side, aren't they no longer useful or it's an oversight? (I see that you named the new 100nF cap on the other side of the inductance with the same id)

I see you kept R29, R30 and R31 as not populated. Well done, I fully agree with your choice, because we should better investigate if overdriving the LO hasn't effectively unwanted side-effects.

By the way, if it's not too difficult to do for you, I would move the R16 terminal on the other side of R13. This way you could check if there are improvements in better adjusting the impedance that drive the input of the weston bridge (R10/R10 node), keeping the phase and amplitude monitoring by U6.
I don't want "teach the cat to climb the roof", but leave me suggest you to take care of the trace widths for the CLK2 signal and the CH0-CH1 ports.
Have a great day,

Massimo

Hello Massimo, thank you for your suggestion.
The 300M and 900M anomalies come from the difference error of the calibration values, as discussed earlier, the harmonic switching point has a larger error. It cannot be solved by correcting the PGA gain, and this point must be separately calibrated, which requires further optimization of the software.
I originally thought that the capacitance on the +5V side could be omitted, but after testing today, they should not be omitted and have been added again. The position of R13 has moved, and edy555 also reminds me that I need to pay attention to the line width of CH0 and CH1. I try to increase the line width as much as possible.

hugen

Schematic_nanovna_Sheet_1_20191122170138

@Pmax65
Copy link
Author

Pmax65 commented Nov 22, 2019

Hi Hugen,
just one other curiosity: I seen that you increased the CH1 input attenuator from 13 to 20dB.
Does this change thought to improve the input impedance along the higher frequencies?

By the way, since the space in the board is not that narrow, couldn't you use 0603 components?
I'm getting older and it's so hard to me view those microscopic bugs!
(It's just joke, :-) of course)

Have a great day.

Massimo

@hugen79
Copy link
Owner

hugen79 commented Nov 23, 2019

Hello Massimo, after canceling R13, the output power of CH0 is increased by 10dB. If the input attenuation of CH1 is not increased, the signal input to CH1 will exceed the effective dynamic of U8.
In addition, I am preparing to further reduce the pcb area occupied by components. The larger area is used to install larger batteries. The next version will increase the battery to 650mAh, so I will still use 0402 components, although this is not friendly to DIYers.

hugen

@Pmax65
Copy link
Author

Pmax65 commented Nov 23, 2019

Hi Hugen,

after canceling R13, the output power of CH0 is increased by 10dB. If the input attenuation of CH1 is not increased, the signal input to CH1 will exceed the effective dynamic of U8.

yes, I didn't look at that (I had just looked at the CH1 background noise) and you are right.
ASAP, I'll change it as per your new schematic and I'll measure the new impedance on CH1 port. If he current higher frequencies mismatch was due to the mixer input capacitance it should be improved a little. But, honestòy, it's possible that it was due to the too thin (abt 1cm length) input trace.
Once I'll measured it I tell you about.

In addition, I am preparing to further reduce the pcb area occupied by components. The larger area is used to install larger batteries. The next version will increase the battery to 650mAh, so I will still use 0402 components, although this is not friendly to DIYers.

As said, I was joking of course :-D
I wrote that just to complain with myself about my reduced capability of see these microscopic components of today. Unluckily, age has its pros & cons :-(

Have a great day.

Massimo

@Pmax65
Copy link
Author

Pmax65 commented Nov 24, 2019

Hi qrp73,
as promised, I publish here below the simulations about the behaviour of the signal at reference mixer U6 with R13 = 150ohm and with R13 = 0ohm.
As you can see WITH r13 = 150ohm, despite the impedance seen on the DUT port forces a wide signal variation on the bridge input port (the joint between R10 and R11, which change from 275mV to 417mV), the signal variation on the reference mixer input is tiny (126mV to 128mV).

Old Reference

Instead using R13 = 0ohm the changes on the bridge input (R10/R11 joint, which change from 924mV to 1.24V) are well reflected at the reference mixer input (66.4mV to 49.4mV).

New Reference

Have a great day.

Massimo

@Pmax65
Copy link
Author

Pmax65 commented Nov 24, 2019

Hi Hugen.
I did the measurements on the CH1 port and doing that I also discovered that the input measurements that I did 4 days ago on CH0 by night were wrong (my neurons were probably sleeping that time).
I did them having calibrated the HP8711A still too cold, not waiting for its warm up, and I didn't notice that those ondulation seen above 300MHz were due to the instrument drift.
This is the true CH0 Zin:
Ch0 Zin
As you can see, it's much better the those I published 4 days ago indeed.
Those more than -23dB of return loss make the instrument uncertainty lesser than +/-0.67dB@1.3GHz and those more than -29dB of return loss at 900MHz make the instrument uncertainty lesser than +/-0.21dB that I think is gorgeous for this very cheap device.

About V3.4.2 CH1 Zin, as expected, it improves even if only a little:
CH1 Z
Note how the little residual ondulation of the return loss it could be due to the fact that I don't have references open, short and load having an SMA-M connector, so I had to use a small SMA M-M adapter inserted between the HP0711A S11 calibrated port and the DUT ports. The male to male adapter reference planes distance it was about 16mm and that could be the culprit for that small ondulation.

Have a great day.

Massimo

@Pmax65
Copy link
Author

Pmax65 commented Nov 24, 2019

Hi Hugen,
I missed to tell you that the new CH1 impedance I published above is for R22 and R23 = 51 ohm not 49.9ohm since I don't have that value in my sample book.
The 51ohm resistors should behave a little better because the simulated impedance comprising the mixer input impedance is 49.59ohm, while the 49.9ohm resistors lead to a CH1 Zin of 49.16ohm.

Have a great day.

Massimo

@hugen79
Copy link
Owner

hugen79 commented Nov 25, 2019

Hi Hugen,
I missed to tell you that the new CH1 impedance I published above is for R22 and R23 = 51 ohm not 49.9ohm since I don't have that value in my sample book.
The 51ohm resistors should behave a little better because the simulated impedance comprising the mixer input impedance is 49.59ohm, while the 49.9ohm resistors lead to a CH1 Zin of 49.16ohm.

Have a great day.

Massimo

You are right, I will update, thank you!

hugen

@Pmax65 Pmax65 mentioned this issue Nov 26, 2019
Open
@hugen79
Copy link
Owner

hugen79 commented Dec 26, 2019

Hi Hugen,
I missed to tell you that the new CH1 impedance I published above is for R22 and R23 = 51 ohm not 49.9ohm since I don't have that value in my sample book.
The 51ohm resistors should behave a little better because the simulated impedance comprising the mixer input impedance is 49.59ohm, while the 49.9ohm resistors lead to a CH1 Zin of 49.16ohm.

Have a great day.

Massimo

Hello Pmax65, I have already made a PCB for V3.4, and send your shipping address to my email: hugen@outlook.com, and I will send you a new version of NanoVNA-H.

hugen

@hugen79
Copy link
Owner

hugen79 commented Dec 26, 2019

the root of cause for spikes at 300, 600, ... MHz in the latest firmware is incorrect behavior of si5351 control code. This error is not hardware. It is completely software due to mistake. The driver for si5351 needs to be rewritten in order to fix that.

But it's not so critical, because this issue happens when frequency point is 5 kHz away or more close to frequency boundary (300 / 600 / 900 / 1200 / 1500 MHz)

Hello Qrp73, I have already made a PCB for V3.4, and send your shipping address to my email: hugen@outlook.com, and I will send you a new version of NanoVNA-H.

hugen

@Pmax65
Copy link
Author

Pmax65 commented Dec 27, 2019 via email

@Pmax65
Copy link
Author

Pmax65 commented Dec 30, 2019 via email

@Pmax65
Copy link
Author

Pmax65 commented Dec 30, 2019 via email

@Pmax65
Copy link
Author

Pmax65 commented Dec 30, 2019 via email

@hugen79
Copy link
Owner

hugen79 commented Dec 30, 2019

I missed one more point (sorry). In case you can supply me a version of the FW with the spread spectrum enabled on output 2, and the ouput current wasn't already set to the minimum, it would be better if the 8MHz output 2 was set to the minimum current (2mA) of course.
…
--- New Outlook Express and Windows Live Mail replacement - get it here: https://www.oeclassic.com/ Massimo

Sorry, I still don't see the picture, you can use the "power 0" command to set the output power of the si5351 to 2mA.

hugen

@Pmax65
Copy link
Author

Pmax65 commented Dec 30, 2019 via email

@Pmax65
Copy link
Author

Pmax65 commented Dec 31, 2019

Hi Hugen,
I feel like an idiot!
Since you sent me also private emails, I was not aware that this was the GitHub email and replying to that address, evidently the email server removes the attachments.
Here is the image I was referring to:
Test 300kHz-600MHz

After changing C12 to 150ohms and R13 to 10uF the spurious noise fallen by 10dB.
Now the output signal from CH0 is what I can get with the old original configuration with R13 = 150ohm, but now the reference mixer U6 still works correctly.
Note that in your new PCB having moved R13 before the reference picking point, it suffices to make R13=150ohms again without the need of the 10uF capacitor.
Today I'm busy and I don't know if I could do other tests, but next I'll try other checks to see if I can improve its behaviour more.

Happy New Year

Massimo

@hugen79
Copy link
Owner

hugen79 commented Jan 1, 2020

Happy new year Pmax65, I made a simple low-pass filter for this test and got some similar results. This is really a bad problem and needs to be addressed in the next release. Our previous improvement increased the output power of ch0, but the noise also became larger. I will try your suggestions for further improvement.

No matter what the state is, the output 2 of si5351 in nanovna is 2mA.

Hi Hugen,
I feel like an idiot!
Since you sent me also private emails, I was not aware that this was the GitHub email and replying to that address, evidently the email server removes the attachments.
Here is the image I was referring to:
Test 300kHz-600MHz

After changing C12 to 150ohms and R13 to 10uF the spurious noise fallen by 10dB.
Now the output signal from CH0 is what I can get with the old original configuration with R13 = 150ohm, but now the reference mixer U6 still works correctly.
Note that in your new PCB having moved R13 before the reference picking point, it suffices to make R13=150ohms again without the need of the 10uF capacitor.
Today I'm busy and I don't know if I could do other tests, but next I'll try other checks to see if I can improve its behaviour more.

Happy New Year

Massimo

Happy new year Pmax65, I made a simple low-pass filter for this test and got some similar results. This is really a bad problem and needs to be addressed in the next release. Our previous improvement increased the output power of ch0, but the noise also became larger. I will try your suggestions for further improvement.

No matter what the state is, the output 2 of si5351 in nanovna is 2mA.

hugen

@Pmax65
Copy link
Author

Pmax65 commented Jan 1, 2020 •
edited
Loading

Hi Hugen,
I had some improvements placing a 10pF capacitor piggyback to the 150ohm resistor.
In this case, between 300 and 900MHz the noise remains below the -60dB level and when the DUT is a low-pass filter that allow the fundamental to pass through and reach the CH1 port, the noise improves of about 10dB, but the dynamic of CH1 between 100MHz and 300MHz deteriorates in the range from 70dB to 55dB.

I would like to see if enabling the spread spectrum on the Si5351 output 2 the situation improves or not.
By the way, the phase noise on that 8MHz output is already terrific because of the LED2 blinking,
For that, enabling the spread spectrum shouldn't be an issue for the MCU, it should reduce the global noise generated by the instrument instead.

Happy New Year again,

Massimo

@hugen79
Copy link
Owner

hugen79 commented Jan 1, 2020

Hello Massimo, Only Si5351's PLLA allows the use of spread spectrum, so I have no way to enable the spread spectrum of CLK2. But my new NanoVNA-H4 is equipped with a separate 8M crystal resonator, so I can turn off the CLK2 of Si5351 on my new NanoVNA-H4, but the measurement results have not improved.

hugen

@Pmax65
Copy link
Author

Pmax65 commented Jan 1, 2020

Hi Hugen.
Ok, that's was the next check I would do (that is, use a separate clock for the MCU), but since you already did it. It seems that it is something about the cross-talk between CH0 and CH1 at this point.
Anyways, it is surely a signal embedded in the CH0 output signal, because the CH1 terminated on a dummy load hasn't that noise there. For that, it shouldn't be embed in the mixers LO signals.

In the past month I already did some tests matching the mixers input Z for the best power transfer, but unexpectedly I got less dynamic from the CH1 port. In fact I had a lot of non-thermal noisy background along the whole 10kHz/1.5GHz spectrum. Probably the mixers went more sensitive receiving the various clock harmonics of the MCU and DSP whic probably are "unlistened" with the mixer input Z mismatched.

Honestly the nanoVNA is a great instrument anyway as it is. All my HAM-radio friend already get back their modified one and had experienced positive results using it for antenna tuning, which was the main reason they asked me to get it working at the 23cm band, where it was very noisy before.

Massimo

Massimo

@Pmax65
Copy link
Author

Pmax65 commented Jan 19, 2020 •
edited
Loading

Hi Hugen,
first of all thank you for the firmware updates, I'll give them a try next.
Instead, yesterday I gave a try to the new PCBs based instruments and (as already said), they are better than the older one.
Anyways returning the now correctly placed R13 to 150 ohm and making:
R25 = 22 ohm
R23 = 0 ohm
R22 = 68 ohm
R24 = 120 ohm
The CH0 and specially the CH1 impedances are better matched to the Z0 = 50 ohm.
Now the CH0 return loss is better than -20dB for the entire 10kHz-1.3GHz span and the CH1 return loss is better than a gorgeous -30dB up to 1GHz and -27dB up to 1.3GHz.
Note that I don't have a VNA up to 1.5GHz to check the return loss there, but using an HP86205A directional bridge with my Advantest R3131A spectrum analyzer and its tracking generator, the CH1 return loss looks better than -30dB along the whole 10kHz-1.3GHz (this tells all about the low accuracy on that low return loss levels).

For this reason I suggest you to change those components in the next production batch,

Returning instead to the low pass filter in baseband with stop band in the harmonics bands issue: I see that in nanoVNA-H4 you placed R49 and R50 to select the crystal or the Si5351, but I have a doubt about your previous check.
Do you just disabled the output amplifier of the Si5351 channel 2?
Reading a little more about that clock generator, it has a multiplexer matrix to select the output amplifiers sources and the internal dividers, I suspect that the interferences between channels could be due to their cross-talks, and not to the device ground quality as suggested from the people of the Arduino based SDR.
If I'm right, disabling the output amplifier doesn't do anything regarding this issue.
You should try to drive the MCU and the DSP with the crystal and set the channel 2 to the very same value of channel 1. It should be possible to do, since the Si5351 is made to supply clocks of the very same frequency at different outputs just phase-shifted. In case I was right all those subcarriers should clear away.
If you are busy, I could do it this check. Could you just give me a link for a Windows7 Compiler for those MCUs?

Have a great day.

Massimo

@hugen79
Copy link
Owner

hugen79 commented Jan 19, 2020

Hello Massimo, if you restore R13 to 150 ohms, CH0 cannot measure to 1.5GHz. I have carried out some new tests on the impedance of CH1, and I will also perform new tests as you suggest.

You can refer to this link to install the IDE, pay attention to using GCC 8.
https://gnu-mcu-eclipse.github.io/downloads/

Comment out line 30 of nanovna.h of the F303 branch to turn off the clk2 output of NanoVNA-H4.

hugen

@Pmax65
Copy link
Author

Pmax65 commented Jan 19, 2020

Hi Hugen,
thank you for the link to the IDE.

if you restore R13 to 150 ohms, CH0 cannot measure to 1.5GHz.

Really? I was talking with R13 placed between C12 and R14 as per the 3.4 schematic of course.
At this point, if you were right, it could be that I did something wrong in the check.
I write this because I'm almost sure that checking the 33 ohms and the 75 ohms 1:1.5 SWR references resistors, I had straight -13dB return loss lines along the whole 10kHz-1.5GHz range and two small lines positioned in the Smith's chart close to the resistive axis very close to the resistor resistance value (if I remember well there was few pH for the 33ohm reference and few pF for the 75ohm reference, probably due to the cable not well compensated above 1GHz).
Let me check it again and I tell you something.

Anyway, I don't suggest to modify those resistors until the next production batch, because the current advantage is of few dB in the range between 300 and 380MHz.

Have a great day.

Massimo

@d9thc31
Copy link

d9thc31 commented Jan 31, 2020 •
edited
Loading

Hi Hugen, please tell me where you can see the last version of the circuit - REV: 3.4?
I want to bring my REV: 3.3 as close as possible to the REV: 3.4 version without changing the circuit board.
And please tell me what you think about the use of resistors R22 and R23 with a resistance of 51 Ohms instead of 49.9 Ohms, unfortunately I can’t get 49.9 Ohms resistors right now.

I apologize if I am not accurate in words, I live in Russia and unfortunately do not know English, so I have to use a translator.

Dmitry

@Pmax65
Copy link
Author

Pmax65 commented Feb 1, 2020 •
edited
Loading

Hi Dmitry,
the 51ohm resistors behave better than the 49.9ohm for the port mach indeed.
Look at this link: #14 (comment)

Attached to this message you can find my docs to apply the modifications.
Please carefully read the warning in the frontpage.

Revision 1.0 is for make versions before 3.4 more or less similar to 3.4 (the pcb and the change of the dc-dc converter in version 3.4 make it different, but the performance are very little better).
Revision 1.1 is to improve the dynamic of CH1 when the DUT is a low-pass filter in the fundamental 10k-300MHz band. This degrades a little the S11 dynamic, but make useful the S21 in the range 300-400MHz (who really cares to get better than 60dB of return loss measurements?).

NanoVNA Rev. 3.0 Mods.1.0.pdf
NanoVNA Rev. 3.0 Mods.1.1.pdf

Have a great day.

Massimo IK1IZA

@d9thc31
Copy link

d9thc31 commented Feb 1, 2020

Hi Dmitry,
the 51ohm resistors behave better than the 49.9ohm for the port mach indeed.
Look at this link: #14 (comment)

Attached to this message you can find my docs to apply the modifications.
Please carefully read the warning in the frontpage.

Revision 1.0 is for make versions before 3.4 more or less similar to 3.4 (the pcb and the change of the dc-dc converter in version 3.4 make it different, but the performance are very little better).
Revision 1.1 is to improve the dynamic of CH1 when the DUT is a low-pass filter in the fundamental 10k-300MHz band. This degrades a little the S11 dynamic, but make useful the S21 in the range 300-400MHz (who really cares to get better than 60dB of return loss measurements?).

NanoVNA Rev. 3.0 Mods.1.0.pdf
NanoVNA Rev. 3.0 Mods.1.1.pdf

Have a great day.

Massimo IK1IZA

Hi Massimo, thanks for helping me, I am happy to follow your experiments to improve the analyzer.
Have a nice day!

Dmitriy

@d51r3verse d51r3verse mentioned this issue Mar 11, 2020
Closed
@Pmax65 Pmax65 mentioned this issue Jun 25, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@d51r3verse @hugen79 @coralenka @qrp73 @Pmax65 @d9thc31