FR: Modem ADC Vpp/Vrms reporting

[nyaaaaaaatalie]

For doing modem autotunes (and just in general), being able to see the input Vpp/Vrms level into the STM32 would be helpful to detect circumstances such as too low or high input level. I understand these get normalized in the firmware but it should provide a good starting point to assist the automation in finding the correct input level for the modem.

Or really even just a no signal or clip reporting would achieve the same result.

[gatekeep]

The problem with this is its extremely dependent on the external Vref.

AFAIK the STM ADC always uses a reference voltage to make it's conversion. (One might connect Vdda to Vref, making Vdda the Vref).

As I understand it, 1 bit of a n-bit ADC always represents Vref / 2^n. For the 12-bit ADC on the STM32, that would be Vref / 4096. The problem is auto-tuning only becomes valid if the Vref is well-known and stable, if it swings incorrectly this feedback becomes difficult or impractical to use.

[gatekeep]

Or really even just a no signal or clip reporting would achieve the same result.

This is what the RB-STM32's do with the CLIP LED, we might consider perhaps updating the DVM-V1 board to include this CLIP signal into an extra ADC?

[W3AXL]

As I understand it, 1 bit of a n-bit ADC always represents Vref / 2^n. For the 12-bit ADC on the STM32, that would be Vref / 4096. The problem is auto-tuning only becomes valid if the Vref is well-known and stable, if it swings incorrectly this feedback becomes difficult or impractical to use.

If we're purely concerned about low signal & clipping detection, then the actual voltage doesn't matter and all we really care about is the sample values hitting the STM. If our RMS sample values are below some value, say like under 256/4096 or so (1/8 of max), that would be a low signal condition. Then on the other hand if we see consecutive max/min value samples (like multiple 4096s or 0s in a row) we know that we're clipping and should turn the gains down.

I could come up with a fairly simple proof of concept once I get my signal generator set back up. This would be a handy first troubleshooting message for people trying to get hotspots working. The user is already going to be looking at the console when tuning, so a message being printed is almost better than a physical hardware LED especially with softpot-based modems like the V1.

[gatekeep]

The user is already going to be looking at the console when tuning, so a message being printed is almost better than a physical hardware LED especially with softpot-based modems like the V1.

I was not suggesting we implement an LED, more implementing the CLIP circuit that the RB-STM32's and passing that to an ADC. But your approach at just analyzing the ADC levels would work as well.

What I'd be more interested in, is how we could implement Tx auto-tuning.

[nyaaaaaaatalie]

if it swings incorrectly this feedback becomes difficult or impractical to use.

Really all I'm looking for here is an indication that the signal is in the middle say 75% of the usable band of audio. This step in the autotune is mostly going to be a sanity check that the signal is making it into the modem and it's not clipping.

I was not suggesting we implement an LED, more implementing the CLIP circuit that the RB-STM32's and passing that to an ADC. But your approach at just analyzing the ADC levels would work as well.

Yeah, I was hoping to find a way to implement this outside of more hardware, but that would be ideal going forward.

What I'd be more interested in, is how we could implement Tx auto-tuning.

I have some ideas, right now I am planning to take measurements off the demod scope on the monitor to basically reverse the process I am describing in the FR. I'm still trying to figure out what makes sense to perform automatically and what makes sense to do manually but I'm mostly just in the initial validation testing phase right now.

[gatekeep]

if it swings incorrectly this feedback becomes difficult or impractical to use.

Really all I'm looking for here is an indication that the signal is in the middle say 75% of the usable band of audio. This step in the autotune is mostly going to be a sanity check that the signal is making it into the modem and it's not clipping.

Really then what we need to do is have a way to return ADC values back in a way that makes sense.

[W3AXL]

I think an optional modem debug print that displays sample statistics would be a good start - something like Vpp, Vrms, Vmax, Vmin, and a clipping boolean. We could scale based off the known Vref - even if it's noisy/unstable, that's a problem outside of our control.

[gatekeep]

I think an optional modem debug print that displays sample statistics would be a good start - something like Vpp, Vrms, Vmax, Vmin, and a clipping boolean. We could scale based off the known Vref - even if it's noisy/unstable, that's a problem outside of our control.

Hmm, I think the best way would be to perhaps get an average ADC level some how and return that. Like you said previously it is probably best to use the ADC level, instead of adding calculation logic to convert the value. Should be relatively straight forward to utilize the raw ADC level knowing it translates to Vpp/Vrms/Vmax/Vmin. If it is really necessary to represent those as voltage levels, I would suggest offloading the calculation to the host side for performance reasons, it may slow the modem down unnecessarily doing the calculation in firmware (of course I could be wrong).