Open Pmax65 opened 4 years ago
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.
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
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.
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.
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.
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.
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.
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!
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
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.
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
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:
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.
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
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
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.
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.
https://github.com/qrp73/NanoVNA-Q/issues/13#issuecomment-552679259 Mine(Green PCB) was around 6.5 MHz
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.
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".
Hi
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
HiI made no mod to my device yet
Trimis din Yahoo Mail pe Android
Pe joi, nov. 14, 2019 la 0:45, Pmax65notifications@github.com a scris:
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
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
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
Yes the battery is attached and at the same time the device is connected to the computer...I use the hardware version 0.4.0-273 de YO4AUL
Trimis din Yahoo Mail pe Android
Pe joi, nov. 14, 2019 la 15:14, Pmax65notifications@github.com a scris:
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
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
Hi coralenka,, it's gorgeous. Could you publish a photo of the nanoVNA? Have a great day. Massimo
This is my device
Trimis din Yahoo Mail pe Android
Pe joi, nov. 14, 2019 la 20:12, Pmax65notifications@github.com a scris:
Hi coralenka,,
it's gorgeous.
Could you publish a photo of the nanoVNA?
Have a great day.
Massimo
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
HI coralenka, I'm not sure, did you send anything about how it looks your nanoVNA? I can't see anything.
This is my device
Trimis din Yahoo Mail pe Android
Pe vin., nov. 15, 2019 la 1:02, Pmax65notifications@github.com a scris:
HI coralenka,
I'm not sure, did you send anything about how it looks your nanoVNA?
I can't see anything.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
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
The new pcb seems to be better.
After the port is calibrated, the 20cm RG316 cable is measured, and it seems that 1.3GHz can work normally.
Hi hugen79, this is more or less what I got with the one I have at home and I think that that make it a nice tool for HAM radio requirements. How do you dealt with the USB charging noise? Have a great day.
Massimo
Hi hugen79, maybe I was not clear in my previous comment about your new pcb, I was referring to the noise of course. About the accuracy and precision of the measurement, it seems that the older ones have a sort of resonance around 1180MHz that (despite the noise is quite low), it practically invalidate any useful Z measurement up there, but most of the HAM radio would use this instrument for antenna measurements which which have not such precision and accuracy requirements, so I guess it's good enough for them. In my case, who I own an HP8711A VNA (yes it was scalar, but some years ago I hacked it firmware to turn it into an HP8712A which is vectorial), I think this instrument is still a great deal for on field antenna or filters measurements.
You new PCB seems perform much better instead. Have a great day.
Massimo
Hi hugen79, this is more or less what I got with the one I have at home and I think that that make it a nice tool for HAM radio requirements. How do you dealt with the USB charging noise? Have a great day.
Massimo
The pcb using the FM9688 seems to have a smaller usb noise, and a pcb with tantalum capacitors is being produced. I will test it further.、
hugen
The pcb using the FM9688 seems to have a smaller usb noise, and a pcb with tantalum capacitors is being produced. I will test it further.、
hugen
Nice one.
HI coralenka, I tried to reply to your email directly, but I received a deny alert from my mail server. I was asking you a photo of the components side of your nanoVNA and (if possible, I don't want bore you) three photos of the instrument while it is measuring the open, short and load references.
Thank you for considering my requests.
Have a great day.
Massimo
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.
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?
Hi hugen79, I finally gave a look to the reflectometric bridge section and found some weird things. I refer to your schematic Rev. 3.0 which seems reflect the components mounted on the nanoVNAs I've here on my desk. I can't understand the usefulness of R13. That resistor placed there almost completely invalidates the function of the reference mixer U6 because the changes at the input port of the bridge when the DUT has very different Z are practically no longer measured because of that. Not only that, with that configuration the level at U6 input was -6dBm, well above the 3rd order intercept point stated by its specs. I made R13 = 0ohm and now everything works great till 1500MHz. Now, without that attenuation resistor, when an open reference is attached to the DUT port of the bridge, the U7 single ended input at pin IN-B exceeds the mixer 3rd order intercept point specs of -13dBm, but since that limit is determined by the conversion gain, it should not be a real issue since the differential input in that case is limited to -19dBm indeed. I also changed R9 from 82ohm to 150ohm to better match the DUT port Z to 50ohm (it seems that the previous value didn't take account of the Si5351A-B-GT output impedance which is 85ohm). I applied the mods only on one of the nanoVNAs that I've and now the measurements looks much better. I also removed R29, R30 and R31 to give "a push" to the LO signal. I know that the SA612AD suggest to center the value between 200 and 300mVpp, but I suppose they do that to avoid spurious harmonics on the LO signal to drive the mixer, but we need that instead for the higher bands that use the odd harmonics method. The attached images show the results with this configuration. Note that the shields were not there because the nanoVNA arrived without them and I'm still waiting for the ground clips. The mounted mixer are SA602A not SA612A, but that seems not that critical.
Have a great day,
Massimo - IK1IZA
After the mods described above, the corrective function of U6 now works, and it highlighted now a software issue at the band switch point of 300 and 900MHz. If the calibration has been made with a large span (for example at full 1.5GHz span) zooming around those points is evident that the calibration correction fails because interpolates between two point having very different correction coefficients (one below the band switch and one above it). The right algorithm should extend the last calibrated point correction value below up to the band switch point, and should extend the first calibrated point correction value above down to the band switch point. A much better algorithm should use the last two calibrated point correction values below and the first two calibrated points correction values above to compute the correction coefficients extending the linear interpolation between them to the two segments of data close to the band switch point that have no correction values computed (it should be an extension of the two interpolation lines).
Note that the glitch is already easily removed calibrating the instrument with the narrow span.
Have a great day.
Massimo IK1IZA
After the mods described above, the corrective function of U6 now works, and it highlighted now a software issue at the band switch point of 300 and 900MHz. If the calibration has been made with a large span (for example at full 1.5GHz span) zooming around those points is evident that the calibration correction fails because interpolates between two point having very different correction coefficients (one below the band switch and one above it). The right algorithm should extend the last calibrated point correction value below up to the band switch point, and should extend the first calibrated point correction value above down to the band switch point. A much better algorithm should use the last two calibrated point correction values below and the first two calibrated points correction values above to compute the correction coefficients extending the linear interpolation between them to the two segments of data close to the band switch point that have no correction values computed (it should be an extension of the two interpolation lines).
Note that the glitch is already easily removed calibrating the instrument with the narrow span.
Have a great day.
Massimo IK1IZA
Thanks for your exploration, I conducted simulations and tests, and the results show that the new bridge is more reasonable. I will discuss the modification of the bridge with edy555. The discontinuity of the band switching point can be improved by modifying the codec's PGA.
hugen
I can't understand the usefulness of R13.
R13 is needed to get 50 ohm output impedance on the port CH0. If you remove it, your CH0 output impedance will be changed and uncertainty of measurement will be increased.
Did you measured output impedace of port CH0? You can do it by measure output amplitude for different load resistance.
According to my measurements, output impedance of CH0 is about 52-55 ohm, so I suspect that R13 has correct value by default. And when you short it, it will leads to incorrect output impedance.
I didn't checked resistance values on schematic of port CH0 bridge, but I think it should be correct. You're needs to use precise resistors in the bridge, because it affects measurements.
R13 is needed to get 50 ohm output impedance on the port CH0. If you remove it, your CH0 output impedance will be changed and uncertainty of measurement will be increased.
I simulated the front-end with Multisim 11 and now with R9 moved to 150ohm the device shows 50.3ohm at the DUT port of the bridge. I also previously measured the CH0 Z with my HP8711A VNA and for that reason I decided to discuss the reliability of the front-end. If U6 gets the power value at the bridge input impedance and not before R13, the bridge input impedance shouldn't be critical for the measurements. The previous DUT impedance was set to 55ohm instead of the 49.6ohm probably expected. I suppose that probably the designer did not accounted for the output impedance of the Si5351A-B-GT clock generator which is 85ohm not 0ohm (it's just a guess of course). Now my HP8711A reports a dynamic CH0 Zin of 50.3ohm (the static impedance is higher of course but not pertinent to our context). Now (up to 1.3GHz) the nanoVNA gave almost the same Smith plot of my HP8711A. I can't measure the phase/amplitude above 1.3GHz using the HP8711A just because it stops at 1.3GHz, but I suspect that nanoVNA is not performing well up to 1.5GHz, because the ondulation of its return loss plot with the 30cm cable on CH0 port makes me think that there is a resonating element somewhere in the bridge circuitry that before this mod was at abt 1180MHz and now seems have shifted to a little more than 1.5GHz.
By the way, when I wrote that message last night it was almost 1AM here i Italy and I did a mistake, the power values I simulated were peak-to-peak values not RMS, for this reason all my reasonings about the 3rd intercept point of the mixers were probably wrong. The power values should be safely below the specs limits instead.
Have a great day.
Massimo.
Hi Pmax65 , the band switching point discontinuity I have modified the software to get improved, when using harmonics, the modified circuit will output a larger signal, we need to modify the CH1 input appropriately, I modify R22 and R23 to 43 ohms and the R25 is modified to 13 ohms. It seems to work better now. Maybe the U8 input input attenuation should be a little bigger.
hugen
R13 is needed to get 50 ohm output impedance on the port CH0. If you remove it, your CH0 output impedance will be changed and uncertainty of measurement will be increased.
I simulated the front-end with Multisim 11 and now with R9 moved to 150ohm the device shows 50.3ohm at the DUT port of the bridge. I also previously measured the CH0 Z with my HP8711A VNA and for that reason I decided to discuss the reliability of the front-end. If U6 gets the power value at the bridge input impedance and not before R13, the bridge input impedance shouldn't be critical for the measurements. The previous DUT impedance was set to 55ohm instead of the 49.6ohm probably expected. I suppose that probably the designer did not accounted for the output impedance of the Si5351A-B-GT clock generator which is 85ohm not 0ohm (it's just a guess of course). Now my HP8711A reports a dynamic CH0 Zin of 50.3ohm (the static impedance is higher of course but not pertinent to our context). Now (up to 1.3GHz) the nanoVNA gave almost the same Smith plot of my HP8711A. I can't measure the phase/amplitude above 1.3GHz using the HP8711A just because it stops at 1.3GHz, but I suspect that nanoVNA is not performing well up to 1.5GHz, because the ondulation of its return loss plot with the 30cm cable on CH0 port makes me think that there is a resonating element somewhere in the bridge circuitry that before this mod was at abt 1180MHz and now seems have shifted to a little more than 1.5GHz.
By the way, when I wrote that message last night it was almost 1AM here i Italy and I did a mistake, the power values I simulated were peak-to-peak values not RMS, for this reason all my reasonings about the 3rd intercept point of the mixers were probably wrong. The power values should be safely below the specs limits instead.
Have a great day.
Massimo.
I am very sorry, Pmax65, I mistakenly deleted your reply. You can use the firmware of edy555 to test, the discontinuity will be much smaller, you find serious discontinuity in using the firmware of me and qrp73 because we set different PGA values for the nonlinear state of the previous circuit U6, you improve The circuit has been modified to work with U6. You can use the Edy555 firmware without setting a separate PGA value for the U6 output (IN2 of tlv320aic3204).
and now with R9 moved to 150ohm the device shows 50.3ohm at the DUT port of the bridge.
you cannot measure output impedance of CH0 with NanoVNA. The only way is to use external RF voltmeter and two loads with non-inductive resistors.
output impedance of the Si5351A-B-GT clock generator which is 85ohm
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.
Now my HP8711A reports a dynamic CH0 Zin of 50.3ohm (the static impedance is higher of course but not pertinent to our context).
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.
Hi hugen,
I am very sorry, Pmax65, I mistakenly deleted your reply.
don't worry it was just a compliment for you, Edy555 and qrt73, that I wrote to thanks you all for your care about this nice instrument.
You can use the firmware of edy555 to test, the discontinuity will be much smaller, you find serious discontinuity in using the firmware of me and qrp73 because we set different PGA values for the nonlinear state of the previous circuit U6, you improve
As said: anyone who has never made a mistake has never tried anything new!
Instead, I honestly I was dubious about your:
the modified circuit will output a larger signal, we need to modify the CH1 input appropriately, I modify R22 and R23 to 43 ohms and the R25 is modified to 13 ohms. It seems to work better now. Maybe the U8 input input attenuation should be a little bigger.
This night I'll check, because I did some measurement of the output power from CH0 and (if I didn't made a mistake, because it was late at night) and I measured more or less the same levels declared for the original nanoVNA specs. If I remember well, I measured -9dBm @ 1MHz almost flat up to 280MHz and a worst case of -19/-20dBm @ 1.5GHz (narrow band measurements made with an Advantest R3131 spectrum analyzer).
Have a great day.
Massimo
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