There does not seem to be much if any info on how to precisely set Rx and Tx audio levels on nodes (for those of us who do not have high-$ service monitors, which is probably 98% of AllStar users).
My thought (as an audio engineer and EE) is that fundamentally what we want the calibration to do is maximize dynamic range, ie. ensuring that (1.) the output from the receiver does not clip the ADC in the radio interface, and that (2.) the audio going to the transmitter does not clip or result in over-compression in the transmitter. This may be an oversimplification that will not achieve as precise of results as using a service monitor and verifying actual deviation levels, but it’s probably good enough to get consistent levels through a wide variety of nodes +/- a couple dB.
On the receive side this seems easy to adjust, with the tune menu utility “Set Rx Voice Level (using display)” option, then adjusting the rxmixerset value until the level meter shows 5KHz deviation with squelch open on the receiver – which in my observations seems to be the loudest signal the receiver will output, and thus represents a Full-Scale signal. This seems to work very well and I’ve never had any issue with Rx levels being too low or high with this approach.
On the transmit side it’s a little more complicated though because most node transmitters don’t have a level meter for the audio input. So I do a parrot test, open the squelch on the receiver for a couple seconds, and then check that the parroted signal is close to full scale, which I do by looking at the receive audio from another (“monitoring”) radio going into an audio recording interface and wave editor. I then adjust the volume on the monitoring radio so that I get a 0 to -1 dB (full-scale) signal in the wave editor, with no clipping, when squelch is open on the monitoring radio. If I then do a parrot test I can then adjust the txmixer levels until the squelch burst is around -1dB.
It occurred to me that this might be more precise if I could just look at a test tone eg. using the “Flash (Toggle PTT and Tone output several times)” option, or looking at the courtesy tone or Morse telemetry levels. Problem is I can’t find any reference on those values.
Having calibrated a node to where parrot of a squelch burst (white noise) is around -1dB, the test tones now show up at exactly -6dB, which seems like a sensible level for a test tone. Does anyone know what level those “Flash” test tones actually are? (ie. relative to the max output of a 16-bit DAC where 0dB(FS) = 32767).
Similarly, in rpt.conf, courtesy tones are listed with amplitudes of around 2048 to 4096, but it’s not clear what the max amplitude value is. I experimented with some courtesy tones, eg. ct2 = |t(660,880,150,2048)(660,880,150,4096)(660,880,150,8192)(660,880,150,16384)(660,880,150,32768)
and with my txmix gain set very low I do see a 6dB jump between 2048, 4096, and 8192, but then higher values result in distorted tones that are not much louder than the 8192 amplitude tone. So next question is what amplitude setting would actually result in 0dB (Full-Scale) output from the DAC? It would seem it’s 8192 as I get a fairly clear tone there that’s 6dB louder than 4096, but if so why was the arbitrary value of 8192 chosen for the max amplitude value?
With txmix set higher the tones are louder, and I only see a 3dB instead of 6dB increase between amplitudes of 4096 and 8192, which indicates the transmitter is now doing some limiting - which is good as you wouldn’t want to set your levels so there is never any limiting. A reasonable amount of limiting increases intelligibility for listeners in a higher noise environment (eg. driving) and gives more consistent levels. To put this question another way, what max number of dB of limiting should be happening in a node transmitter for optimum audio quality across the network? I would guess 6-10dB but the actual numbers across a wide range of users may be way different.
Thus on the receive side things are simple - there is no limiter ahead of the ADC so you just set rxmix for a “5 KHz” reading at full scale input and you should be good, but on the transmit side you have limiting in the transmitter and possibly in app-rpt itself so there is more room for adjustment.
To more succinctly summarize all the above: Is there a better/simpler way to optimize Rx and Tx audio levels for those who do not have a service monitor but who would like to have their audio levels be as consistent as possible with other AllStar users? There are some parrot tests that look at overall audio, but those depend on the mic gain on the radio you’re going into the node with and on overall voice levels which at any time could vary by +/- 6dB or more, thus any testing would need to look at just the node itself and use consistent test tones or noise, whether that’s open squelch white noise, or tones/noise that could be easily provided from any PC audio out or from ASL itself. The Calibrating Audio Levels - AllStarLink Wiki page has some good insights but this is targeted more toward repeater systems and high-$ test equipment, so it would be nice if that page was adapted to personal AllStar nodes and tests that can be done with nothing more than a computer audio interface and wave editor (which can do a lot). Those may not be accurate to <1dB but might help ensure more consistent levels for everyone.
I should also mention that this question relates specifically to low-cost personal nodes, using basic radios that have a mic in and speaker out such that ASL is processing bandwidth-limited speaker audio and not doing any CTCSS encode or decode. eg. a node using the simpleusb driver with default settings.
In the meantime I suspect the majority of DiY node builders just set the levels where they sound good and with a bit of fine tuning over time that should get you within 3dB of the optimal levels. I’ve also seen some mentions of being able to calculate deviation from looking at the Tx waveform in an SDR so that might be interesting and I may give that a try, though most users probably don’t have an SDR so a more general approach looking just at audio levels and dynamic range at various points might be more useful. Thanks, David