Open Pmax65 opened 4 years ago
As I know, the only way to measure output impedance is to use RF voltmeter and different loads. I'm wonder how did you used VNA to measure output impedance?
Output impdeance of CH0 should be different for 0-300 MHz and 300-1500 MHz, because firmware uses different settings for si5351 output impedance control. So, the things are more complicated...
Hi qrp73,
As I know, some documentation of Si5351 mentioned 50 ohm impedance of si5351, but according to my measurements, it is a little different. May be 60 ohm or something like that, I didn't tested it deep. And you can change output impedance of si5351 by selecting output current in control register.
AFIK, si5351 is slightly different from Si5351A-B-GT. The on-line data sheets differs exactly per their output impedance, the later have improved the output driver for the 8mA current availability and moved the Zout from 50 to 85ohm.
How did you measured output impedance of CH0 with VNA? As I know this is impossible to measure output impedance with VNA. Measurement of input impedance for CH0 is even more complicated, because it always has output signal, so you cannot measure it with VNA.
You can do it because the scanned output signal of the DUT is not in sync with the scanned test signal of the VNA, so adjusting the right way the VNA sweep time to get just sporadic dips power for any VNA scan, if you set the VNA to average more scans those sporadic dips are averaged on the whole VNA scan points and their influence become negligible. The fact that I measured the Multisim 11 predicted value with few tenth of ohm of difference demonstrates it. Note that I turned off the nanoVNA and I measured exactly the static Z as predicted by Multisim 11. I'm quiet confident in that measurement I did.
AFIK, si5351 is slightly different from Si5351A-B-GT
I see that si5351-B (which is used in NanoVNA), according to the datasheet has 50 ohm:
But the things are more difficult, because NanoVNA firmware uses different impedance settings for different frequency band.
Note that I turned off the nanoVNA and I measured exactly the static Z
I think this is incorrect measurement, because when you turned off NanoVNA, it's ports impedance are changed.
You're talking about input CH0 impedance. But how did you measured output CH0 impedance?
Found another glitches around at CENTER 64 MHz / SPAN 80 MHz ( Not connected anything / Uncalibrated sweep ) Maybe influenced by 6.5 MHz issue? But, this sweep does not glitches CH0 Delay.
Is it appearing at 100MHz?
I can not see any glitches around 100 MHz. only appeared 6.5 MHz and 64 MHz
GridScale_0.004656872_6.5MHz
GridScale_0.110340707_64MHz
GridScale_0.007800729_64MHz_Zoom
Hi qrp73,
I think this is incorrect measurement, because when you turned off NanoVNA, it's ports impedance are changed.
Maybe I've been not clear. I just did that measurement to check the reliability of the Multisim 11 simulator for the static Z computation. And it demonstrated to be reliable indeed.
Then I used it to compute the dynamic Z including in the simulation the Si5351A-B-GT Zout, and checked it with VNA and reported almost the same value (few tenths of ohms of difference). I took an another look to the datasheets, and indeed it seems that the last one (rev 1.1) reports 50ohm (the one reporting 85ohm was revision 0.95). This could be the reason of those few tenths of ohms of difference I measured. This night I'll check with the simulator for the Si5351A-B-GT Zout 50ohm impedance and I report you the results.
Have a great day.
Massimo
My nanovna also don't have glitch on 100 MHz, but some small glitch is present on 6.5 MHz.
Scale is 0.1 dB:
qrp73, Maybe I missed something in your messages:
You're talking about input CH0 impedance. But how did you measured output CH0 impedance?
What do you mean with Zin and Zout? A port has one impedance, I wrote "input" just for indicate the CH0 input port, but there is not a Zin and a Zout. Do I missed something?
Massimo
when you use port as a source, this source has some internal impedance, this is output impedance of the port.
When you use port as a load, this load has some internal impedance, this is input impedance of the port.
Input and output impedances are diffrent, because source used in NanoVNA is non-linear component (si5351), and even more, source impedance depends on it's internal frequency in different way than input impedance depends on external frequency.
The port CH0 working simultaneously as a source and as a load. So, both impedances are involved.
My nanovna also don't have glitch on 100 MHz, but some small glitch is present on 6.5 MHz.
Scale is 0.1 dB:
The glitch near 100MHz comes from the firmware of edy555. The wait time after switching the division factor of si5351 is not enough. The problem is not existed in nanoVNA-Q.
hugen
Hi qrp73,
when you use port as a source, this source has some internal impedance, this is output impedance of the port. When you use port as a load, this load has some internal impedance, this is input impedance of the port. Input and output impedances are diffrent, because source used in NanoVNA is non-linear component (si5351), and even more, source impedance depends on it's internal frequency in different way than input impedance depends on external frequency.
Ok, now I get your point, but I can't imagine that an impedance between two points could be different depending on where the signal is coming. Could you make me an example where you can demonstrate that an external signal generator with a given Z produces different results (V and I, the phase between them shouldn't matter because is compensated by the reference detector) compared to the same results measured in that very same port attaching an external load of the same Z of that generator? It shouldn't matter if the generators are not linear because both are monitored and corrected for their effective power signal amplitude and phase to linearize them. At this point the superimposition of the effects should apply, and the si5351 internal ideal current generator should be considered an open circuit when the external generator is taken in account, so on the CH0 port the impedance should be the same. The same should apply vice-versa when the external generator is considered only for it's Z. The only problem should raise when both the signal generators are on the very same frequency, because the reference external VNA could receive the inner generator power vectorially added to its back reflected signal. But as said, making the scan speed of the two sweeps very different the coincidence happens for very little time respect the whole span making the error negligible (not zero of course).
Have a great day.
Massimo
Could you make me an example where you can demonstrate that an external signal generator with a given Z produces different results (V and I
Also, did you take into account, that NanoVNA firmware continuously switching si5351 output impedance with control register? si5351 output impedance is not constant, it can be changed by software and NanoVNA doing it continuously during sweep.
Hi qrp73, I don't agree that this is the case we are arguing about because: A) The internal source must drive the two nodes where R3 is joined (the port), so that diode must let the RF pass through it, and if it does the DUT signal pass through too in the opposite direction. B) the signal is monitored for its amplitude by U6 which must measure phase and amplitude at the bridge input to correct them and get the right value for the DUT reflected power measured at its balanced output. C) I don't know why you asserts that the Si5351 changes it's output impedance. Being a clock driver I can imagine it's a push-pull mosfets based drive thought to warrant the CMOS output voltage span, with an Rds_on trimmed to get the specified Zout, (otherwise why do they specify it?). You can control the output current, but this doesn't mean that the impedance changes. In fact in datasheet Rev.1.1 Page 23 Fig.18 they specify to use a Zo = 50ohm for the micro stripline to drive the devices to avoid high VSWR and consequent echoes.
And again the port joints doesn't know if the signal incoming from the DUT is a reflection of its impedance (Zdut) or it is self generated by the DUT being an external generator. The bridge measures both the same ways. To avoid the unwanted signal eventually coming from the DUT it suffices to stay away from its generated frequency, so the unwanted signal doesn't pass through the VNA IF filter.
By the way, maybe that I've been not clear. The Zo that I measured was the one at the lower frequencies (that is, where it has a meaning to be measured). It's obvious that in the Smith chart it wasn't a point but a spiral around the 50ohm value very close to the center of the chart, due to the parasitic components of the bridge network. Those ondulation into the S11 return loss graphic visible at the higher frequencies are probably due to that parasitic components, but having reduced the bridge input impedance (making that R13=0ohm) they moved to higher frequency than before.
Have a great day.
Massimo
I don't know why you asserts that the Si5351 changes it's output impedance
Because there is a code in firmware. The firmware set about 50 Ohm output when frequency is higher than harmonic threshold (300 MHz). When frequency is lower than 300 MHz firmware set some higher impedance, 200 Ohm or something like that. It switch higher impedance for the main harmonic mode in order to reduce signal power level...
Could you please check the input impedance of CH0 for two cases? 1) for sweep 10 MHz - 20 MHz 2) for sweep 310 MHz - 320 MHz
Hi qrp73, ok, Let me have dinner and this night I'll do it and I tell you the results.
Have a great day (or night? I don't know where you are from so it could be that it's already night there).
Massimo
Hi qrp73, here below you can see the plots of the return loss and the Smith charts that I measured on the modified nanoVNA (adjusted for the 50ohm Si5351 Zout). The mod is now turned as follows to get a low frequency CH0 Zin of about 50.3ohm: R13 = 0ohm R9 = 200ohm Removed R29, R30 and R31
I did the measurement with the nanoVNA emitting a CW signal at 500MHz (upper graphs) and at 100MHz (lower graphs). Effectively there is a clear change in impedance when in the fundamental band. The RL raise to -20.23dB in the worst case which equates to an uncertainty of about +/- 0.9dB. While in odd harmonics mode the -22.52dB equates to an uncertainty of about +/- 0.6dB. I don't believe that's so bad, but I don't understand why this switch of impedances is due, Shouldn't that impedance be left to 50ohm along the entire full 1500MHz span? In that case up to 700MHz the RL is better than -30dB which equates to gorgeous uncertainty of about +/- 0.28dB.
BTW, note those small peaks at 200 and 300MHz due to the nanoVNA 100MHz emission, as said they don't influence the impedance analysis on other frequencies, hey just beat .
Have a great day.
Massimo
Hi qrp73, here below you can see the plots of the return loss and the Smith charts that I measured on the modified nanoVNA (adjusted for the 50ohm Si5351 Zout). The mod is now turned as follows to get a low frequency CH0 Zin of about 50.3ohm: R13 = 0ohm R9 = 200ohm Removed R29, R30 and R31
I did the measurement with the nanoVNA emitting a CW signal at 500MHz (upper graphs) and at 100MHz (lower graphs). Effectively there is a clear change in impedance when in the fundamental band. The RL raise to -20.23dB in the worst case which equates to an uncertainty of about +/- 0.9dB. While in odd harmonics mode the -22.52dB equates to an uncertainty of about +/- 0.6dB. I don't believe that's so bad, but I don't understand why this switch of impedances is due, Shouldn't that impedance be left to 50ohm along the entire full 1500MHz span? In that case up to 700MHz the RL is better than -30dB which equates to gorgeous uncertainty of about +/- 0.28dB.
BTW, note those small peaks at 200 and 300MHz due to the nanoVNA 100MHz emission, as said they don't influence the impedance analysis on other frequencies, hey just beat .
Have a great day.
Massimo
Hi Pmax65, In the original design of edy555, NanoVNA is only used for 50K-300MHz, so that the si5351 output smaller current can reduce harmonic interference and save current consumption. When I try to use harmonic measurements, I need to get larger harmonics, so I need to increase the output current of the si5351, which will cause the output impedance to decrease.
hugen
Hi hugen79, unluckily yesterday night have been busy with the qrp73 impedance change issue and I had not time to check the edy555's cross band correction interpolation fix, and this night I'll be busy with the HF transceiver of an HAM radio friend who stopped transmitting yesterday and became a "red emergency" issue (there are some HAM radio guys like that who are retired and without their RTX are in panic), so I have to suspend my work on this instrument.
I know that edy555 did it for the 50kHz to 300MHz band and I suspected that he used that low current for extend the battery autonomy, I just did not imagine that the Si5351 changed its Zout for doing that, because in digital systems using the wrong impedance for distributing a clock deteriorate the clock signal. I must say that that clock generator was designed prevalently to get fixed frequency clock outputs, so the PCB traces could be designed for the low or high impedance when needed. But I didn't find any mention of that in the datasheet.
Anyways when I wrote the message to qrp73 it was 1:30 and I was not that "awake", so I overestimated the problem because those two plots weren't show the real CH0 Z. That because thinking a little more about it, this morning I realized that the real Z plot is the mix of the twos LOG plots indeed. That is, below 300MHz the Z is the one represented by the lower plot and above 300MHz it is the one represented by the upper plot. So the situation is better than I thought, the uncertainty shouldn't be worse than +/- 0.6dB. I still never checked the current consumption, but if it was not a problem I would you fix that impedance to 50ohm all along the full span, so the instrument became really reliable below 700MHz.
If you are planning to redo the PCB, I suggest you to reconsider the traces width for their impedance. In the past I worked for 6 years for a safety grade level N+1 redundant radio control factory as designer. In that experience I fought against the PCB trace design for the above 1GHz models. Getting from that experience, I think that those flatness anomalies above 300MHz in the CH Z could be reconducible to the too thin traces of the bridge front-end, and in particular the thin trace which connects C12 to R13 pad. If I remember well, with a 1.6mm thick FR4 dielectric to get a 50ohm microstripline the width should be in the range of 3.9/4mm. Even if the FR4 pcb is surely not the best dielectric to use above 1GHz, but let me assert that we are not looking for a professional VNA, but the right compromise to give to the hobbyists a great low cost instrument. In the figure that I attached below I did a mix of the two LOG plots to evidence how much improvement we should get if the Z is fixed to 50ohm. The green area represent the spectral RL gain in terms of best matching. BTW in case also the LO signal clock is driven with different impedances below and above the 300MHz point, it could be a a nice hint to check if the performance improves fixing that Z to 50ohm too (it could be not the case, because the signal it should be already sufficiently strong to saturate the mixers LO input). Have a great day.
Massimo
Shouldn't that impedance be left to 50ohm along the entire full 1500MHz span?
I'm also not sure if this impedance switch is really needed. Needs to try remove it and test results, may be it will give more dynamic range for 0-300 MHz range...
just tried to use 50-ohm output for full frequency range, but it seems that it works a little worse. I didn't tried to play with gain, may be it can help to improve results.
I performed full calibration for 10 kHz - 500 MHz range, and take S11/S21 with 50-ohm loads on both ports.
First image is current version with impedance switch. Second image is a version with si5351 constant 50-ohm output.
Current version with impedance switch at 300 MHz:
Version with si5351 constant 50-ohm output:
Hi qrp73, effectively that impedance change is really a mess. As already I wrote to hugen, if this method was applied to the LO clock too, it could be a good hint to try set that output to 50ohm also below the 300MHz limit and see if it improves the performances of the instrument. I hadn't been aware of it because I previously interpreted that "heartbeat" as a consequence of the nanoVNA outgoing signal, when you suggested the two spans test, I realized that the best (and fastest) way to get the Z measurement, it is setting the DUT to a CW frequency and then I clearly seen the impedance change. Thank you for having highlight me this issue which I was completely ignoring.
First image is current version with impedance switch. Second image is a version with si5351 constant 50-ohm output.
Do you have already made R13 = 0ohm; R9 = 200ohm and removed R29, R30 and R31? Anyways it should be better to look at the full span to see if there are some issues on higher frequencies (I don't think, but it take a little to check it).
The RL seems to have lost dynamic, but having flatten a lot around the 10kHz level induces me to believe it's more realistic now, especially if the plot is less noisy now.
I don't know how noisy is that S21 plot, but it seems to me that the CH0/CH1 cross talk reduced a lot, is that or is it just an impression?
Massimo
Do you have already made R13 = 0ohm; R9 = 200ohm and removed R29, R30 and R31?
I tried it with default R13
Anyways it should be better to look at the full span to see if there are some issues on higher frequencies
Frequencies higher than 300 MHz are not affected. Because current version uses 50-ohm output for frequencies above 300 MHz...
but it seems to me that the CH0/CH1 cross talk reduced a lot, is that or is it just an impression?
probably this is an effect of calibration. Higher signal level leads to lower noise floor relative to carrier.
I tried it with default R13
If you are saying that R13 is 150ohm then you can't get any improvement, because when the DUT changes amongst open-short-load, U6 isn't practically measuring the voltage drop at the bridge reference signal input to correct the measurements. Other than increasing the power level applied to the mixers LO inputs, that's the real improvement of the last mod that I proposed.
With R13 = 150 you can see how U6 is not working looking at the 300MHz and 900MHz bands cross points. Having still R13 = 150ohm, after a correct calibration, if you zoom around those cross point you can't see any spike due to the interpolation between the 15MHz spaced reference points. In fact only one measurement is made exactly on that point. I guess that it is the one of the lower band of the twos. So it can't be used to compute the interpolated correction points for the upper band. Making R13 = 0ohm you get the spikes that are expected because the interpolation point on the crossing band points lead to that wrong correction coefficients for the points between it and the first point of the higher band. For this reason, in those frequency ranges, I suggested to Hugen to change the calibration interpolation extending the last two points linearization of the lower band up to the crossband point and the first two points linearization of the upper band down to the crossband point.
Frequencies higher than 300 MHz are not affected. Because current version uses 50-ohm output for frequencies above 300 MHz...
Yes, you are right. Effectively that check has no reasons to be done.
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)
Hi qrp73. No I'm not talking about that. The issue that arise making R13 = 0ohm is due to the now correct working of the reference mixer U6. The spikes you arguing can't be removed by a calibration, while the ones that I refer once you zoomed are completely removed by redoing the calibration with the stimulus set to the zoomed range. Leaving R13 = 150ohm U6 measures the phase/amplitude of the clock generator output, not those of the weston bridge input port (the R10/R11 junction). This last measuring point is fundamental for getting the right RL plot. I don't know if this night I could do it, because I'm busy with a RTX repair, but as soon I can do it I'll publish the simulation screenshots of what it happen when there is a load, a short and an open attached to the weston bridge DUT port and you'll can easily see that while the R10/R11 junction (the bridge unbalanced input port) changes a lot, the U6 picking point is practically unchanged. Said that, there is a wrong behaviour of the interpolation algorithm when the interpolation is computed between the two interpolation reference points around the band switching point, or when the interpolation is computed between those two points and the very same band switching point. In the meantime, have a great day.
Massimo
This is the schematic of my re-editing.
After calibration
Measuring 20dB attenuator
hugen
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
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
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
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
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
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).
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).
Have a great day.
Massimo
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:
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:
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
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
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
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
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
Hi Hugen,
I just realized that you sent the message below to me instead of sending it to Qrp73.
Check if you already sent it to him too
New Outlook Express and Windows Live Mail replacement - get it here: https://www.oeclassic.com/
.
Have a great day.
Massimo
----- Original Message ----- From: hugen79 notifications@github.com Reply-To: hugen79/NanoVNA-H reply@reply.github.com To: hugen79/NanoVNA-H NanoVNA-H@noreply.github.com Cc: Pmax65 mporzio@teletu.it, Author author@noreply.github.com Sent: 26/12/2019 09:36:21 Subject: Re: [hugen79/NanoVNA-H] Noise improvements. (#14)
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 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
Virus-free. www.avg.com
Hi Hugen, I discovered a new issue that probably could be solved (or at least reduced) via firmware modification. Attached to this message you can see an image of the analysis of the VHF port of one of my VHF/UHF duplexer. The black plots are from my HP8711A VNA, while the red plot is the nanoVNA S21 and the blue plot is the nanoVNa S11.
While the S11 mismatching isn't a real issue because my HP8711A was calibrated using a N connectors calibration kit, and that easily justify the discrepancy at the lower frequency. The S21 has a clear problem at the 300MHz band-switch crossover point.
Analyzing the spectrum of the nanoVNA CH0 output set to a CW frequency at 310, 312 and 315MHz, I discovered a series of sub-carriers around the 3rd harmonic fundamentals at respectively 103.333MHz, 104MHz and 105MHz which could justify that noise excess between 300 and 600MHz because those sub-carriers have themselves sub-carriers shifted exactly 5kHz from their carrier which fit the nanoVNA IF. Since those sub-carrier are shifted from the fundamental of a frequency that it is equal to the difference of the 5th harmonics fundamental and a multiple of 8MHz which is the MCU clock, I tried to smooth the 8MHz output with a capacitor, but despite it changed from a square-wave to a triangle one, the issue doesn't improve. It improved, matching the HP8711A between 300MHz and 384MHz, when I inserted a 10dB attenuator on the CH1 input (probably because the +3dBm CH0 output is still a little too high for the CH1 3rd IP), but there still was a Gaussian shaped noise between 384MHz and 528MHz that peaked at 450MHz.
I suspect that this is a cross-talk of the outputs buffers inside the Si5351. Since the Si5351 allow the spread spectrum on any single output, I would like to know if you could compile a special version of your firmware with the spread spectrum activated on output 2 set to the maximum spread (+/-1.5% in center spread mode).
It's just a check, so it shouldn't be a new release of the firmware for the moment.
Have a great day.
Massimo
New Outlook Express and Windows Live Mail replacement - get it here: https://www.oeclassic.com/
Hoops! Sorry I missed to attache the image to my previous message.
New Outlook Express and Windows Live Mail replacement - get it here: https://www.oeclassic.com/
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
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
Hi Hugen, I sent the picture again attached to this message in pdf format.
Your wrote "you can use the "power 0" command to set the output power of the si5351 to 2mA." I need to reduce the current only from from Si5351 output 2, which is the 8MHz MCU clock, is that command available for output 2 too?
Anyways I gone ahead and I reduced that noise down to -40dB from the carrier just installing the 150 ohms resistor (ex R13) in place of C12, and in place of R13 I had put a 10uF X7R capacitor, doing that the cross-talk reduced a lot. It seems to be a know issue for the Si5351 I found some people arguing about that into an Arduino SDR blog. It seems that it is all due to the maximum current allowed to the chip, in case it exceed 5.6mA per output a cross-talk happens in the form of jitter on the output signal.
Have a great day.
Massimo
New Outlook Express and Windows Live Mail replacement - get it here: https://www.oeclassic.com/
----- Original Message ----- From: hugen79 notifications@github.com Reply-To: hugen79/NanoVNA-H reply@reply.github.com To: hugen79/NanoVNA-H NanoVNA-H@noreply.github.com Cc: Pmax65 mporzio@teletu.it, Author author@noreply.github.com Sent: 30/12/2019 12:42:03 Subject: Re: [hugen79/NanoVNA-H] Noise improvements. (#14)
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 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
Virus-free. www.avg.com
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:
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.
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:
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
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
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
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
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
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
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