NanoVNA Custom Software

[DiSlord]

>0 to 3 used this value, 4 use AGC

Set 0 to 3 for thru data (0xEA) and you can see changes in noise level.

[joeqsmith]

Could you provide gain values?

Setting a value of:
0  Av=?
1  Av=?
2  Av=?
3  Av=?
4 = AGC enabled

[DiSlord]

This depend from hardware, you can see it in CONGIG->DMSG screen as GAIN0 to GAIN3

Not need recalculate, device do it by self in any case.

[joeqsmith]

So there are different revisions of the Lite hardware with different gains?   There is some sort of diagnostic menu that displays these gain values? 

[DiSlord]

No all Lite have ¬equal gain settings. Difference only from the accuracy of the components used (resistors and capasitors)

Go to CONGIG->DMSG menu (i write this 3 times)
BBGAIN0 to 3 gain levels

[joeqsmith]

>>(i write this 3 times)
lol,  yes, I know but I do not have the Lite sitting here.  I am away right now.   Let me get back with you after I have a chance to look at it. 

[joeqsmith]

This is very interesting.  So you add some amount of attenuation.

Power cycling my Lite several times, it will come up with new numbers.   So you attempt to calculate these on power up.   With you switching these, how is the calibration handled?  I would doubt very much that the attenuation is flat over the entire operating range.  So when running the SOLT, it would only be for one attenuation setting. 

[joeqsmith]

Shown with the Lite sweeping from 150M to 2GHz,  no calibration was performed, cable attached between the two ports.

Red with 0xEA set to 0, yellow with it set to 2.   Note that the attenuator is not perfect.  Treating it like it is will cause more problems than good.    So, how does your AGC handle these errors?

[gf]

How do 1, 3 and AGC look, for comparison?
Do any of the 5 curves (0,1,2,3,AGC) match with each other? (ignoring noise)
Are you sure that you don't overdrive the IF amp and/or ADC? [ That's of course a potential risk of manual gain. ]

[joeqsmith]

Are you sure that you don't overdrive the IF amp and/or ADC? [ That's of course a potential risk of manual gain. ]

I am testing with a section of coax, so yes I am sure I am not overdriving the input.

Do any of the 5 curves (0,1,2,3,AGC) match with each other? (ignoring noise)

Yes.  With the coax attached, the AGC appears to use a setting of 0 (no attenuation, no surprise).   These two settings match.

How do 1, 3 and AGC look, for comparison?

Shown with all five settings.  Again, no cal, coax from port 1 to port 2.
**
Sorry, wrong setting on graph.

[joeqsmith]

Same data but attempting to show the difference in the slope at 100MHz.   

Again the feature may be useful in some cases.   I'll need to give it some thought.   Normally I would want the step attenuator right at the front end.

One thing I am not sure about is how these settings effect an LC tank.   I'll check that later to make sure that turning off the AGC solves it.   

[joeqsmith]

The step in the transmission is certainly from the AGC algorithm. 

Attached, notice how as the signal starts to rise, they actually reduce the attenuation making the signal even larger, then as the signal starts to drop again it adds attenuation.  If its not saturating the ADC,  why reduce the signal at all?  Leave it at 0dB so we get the most signal through.   

Even if we were working in some non-linear region of the ADC, the logic is backwards.  Looks like a bug to me but hopefully Dislord can clear things up.   

[gf]

Yellow is obviously AGC. What is red and purple?

[joeqsmith]

Manually changing gain to match AGC is all.   Funny, -15dB down, even with no cal, we are no where near pushing that ADC. 

[gf]

The ripple at the top of the purple trace is strange. If it were just noise, I'd rather expect it at lower levels, not at higher ones. What gain is purple?

[joeqsmith]

Just for fun, I added an amplifier and step attenuator between the LC tank and port 2.  I set 0xEA to 0 and increased the amplitude until I started to detect compression.   It's about 20dB higher than the signal we are trying to measure.    I must really be missing something basic.  Could be lack of sleep. 

[joeqsmith]

Looking at the schematic for the V2_2, it does appear to be a gain stage.   This makes more sense with what Dislord has posted.   So I tried setting 0xEA to 3 which I expect to add -20dB of gain but instead it it saturates the ADC.  The firmware however reports an even lower gain.    So the firmware must be trying to help me.     

To I connect a 10MHz -50dBm signal to port 2 and measure the reported amplitude with the 4 different gain settings and sure enough they are all the same.  Yep, it's trying to make my life easier by doing some calculations for me.    I then set 0XEA to 3 and the input signal to 0dBm.  Saturates.    As I lower the input signal and then measure where it starts to decompress for the 4 different gain settings, these appear to match up with Dislord's numbers.   

So as the signal gets smaller, indeed he attempts to gain it up.   It just didn't make sense as the firmware doesn't report the actual raw ADC values.   

[joeqsmith]

Assuming that's correct, I am back to how do you compensate for the errors the gain stage makes?   Does it even make sense to have AGC?  I could see some cases where gaining up the signal may make sense assuming we are just not amplifying noise....  We could select the gain we want and just cal out the errors.   

Now that its all clear as mud let's try to compare the AGC algorithm against manually setting the gain with a very low level signal.    Back to shunt thru PDN measurements with my 100uOhm standard...

Shown with the gain set to 1, 3 and with the ACG enabled.  I don't think this is a good use case for it.

[gf]

I guess the reported BBGAINx numbers just have the wrong sign. Or they are meant to be the correction factors (i.e. 1/gain, or 20*log10(1/gain) in dB) to be applied (by the firmware) in order to normalize raw readings with different gain to a common scale. Since different frequency points can be measured with a different gain (when AGC is on), it makes sense to normalize them to a common scale. If I did understand DISlord correctly, then in case of averaging even each of the chunks being averaged could have been acquired with different gain, which also mandates a common scale.

[joeqsmith]

I suspect when Dislord calls it gain but uses a negative sign its a language difference.  It's not a problem as long as I understand it.  I don't look at these menus and when using the PC they are disabled anyway.    The problem is what does it mean.  A gain setting of 3 for example may indeed represent 20ishdB of gain at 10 MHz but not at 2 or 6GHz. 

If they wanted to normalize the gain,  then they should characterize it for each gain level over the entire sweep range not just one data point.  Maybe it can be done.  The PC could certainly do it.    Still not sure I want the firmware mucking with it.  Measuring group delay is a good example of where AGC can cause problems.     

As I said, even power cycling the unit several times, it will show different gain vales due to the noise.  If this is a single constant being applies, we are at the mercy of whatever the firmware came up with for a gain value on power up.     To get around the warmup, maybe you can reset or something to have it recalculate without power cycling.

IMO when using software, the closer it can get to having the the raw data the better.    If makes the firmware easier to code, requires less resources in the embedded system and makes the system more flexible.   

Details, details...   

[joeqsmith]

With all the open source interface software which as I understand it, allows everyone to modify the source.  Coupled with how popular these devices are, I'm surprised we don't see more people running such experiments and asking these basic questions.    Then again, it's always possible my lack of sleep is not allowing me to clearly think about it.   

[DiSlord]

Gain value normalized to Gain0
These are correction factors in order to bring the value to a single value (Gain0 was chosen for it, so I need apply -20dB if use Gain3)

Signal amplitude various in all range, so need use correction.

You can control it from external software (use this debug register), but you can`t know then you get wrong values due to overflow from selected.

You get errors in any case use or not gain due not linear OpAMP (if use AGC you get less error), yes you not see steps (measures look as OpAMP linear, but no - see green line on image)
If use AGC OpAPM range divided by regions, and relative error less. But difficult glue all regions (red lines).

Addition problem: gain values depend from frequency. Most good way - made N GAIN measures in all range and use interpolation, but in less ¬300MHz range not possible calibrate Gain 3 due to overflow in any case.

[gf]

Addition problem: gain values depend from frequency.Most good way - made N GAIN measures in all range and use interpolation

Why does it actually depend on frequency? Isn't the gain always applied to the same 60kHz IF frequency? ¹⁾
Then flatness should not matter. Do you have an explaination?

I wonder, btw, is the gain calibration a vector calibration (complex scaling factor) or just magnitude?
I were not surprised, if the phase response of the amplifier (at the IF frequency) were slightly different for different gain.


¹⁾ I can understand it for very low frequencies, since a different (lower) IF is used. But shouldn't one calibration for each IF frequency then suffice?

[DiSlord]

On different freq range i get different base amplitude, so i measure different points on gain curve.

I don`t know real signal amplitude before gain, just after gain

Most this problems fixed by calibration, but calibration can`t fix non linearity.

[joeqsmith]

Gain value normalized to Gain0

...

You can control it from external software (use this debug register), but you can`t know then you get wrong values due to overflow from selected.

Are the Gain0-3 values that the firmware calculates exposed to the software?  Is there a flag that will turn off the normalized values while still allowing the gain to to be changed?