DSDPlus 2.547 / FMP24 2.86 – live VC audio clipping in dual-receiver TIIInonStd trunk following

[Scotty_B]

Hi,

I am experiencing a repeatable live-audio clipping problem with DSDPlus 2.547 and FMP24 2.86 when monitoring a TIIInonStd / Capacity Max system using two RTL-SDR dongles.

System being monitored

• DMR TIIInonStd / Capacity Max
• Network/site displayed by DSDPlus as TIIInonStd L1 9
• Control channel: 464.225 MHz
• Windows 10
• Two RTL-SDR dongles with unique serial numbers
• DSDPlus 2.547
• FMP24 2.86

Normal dual-receiver configuration


CC.bat:
DSDPlus -rc -i20001 -o0 -O NUL >>CC.log

VC.bat:
DSDPlus -rv -i20002 -o1 -O DSDPlus.wav >>VC.log

FMP24-CC.bat:
FMP24 -rc -i"00000002" -o20001 -P23.5 -f464.225

FMP24-VC.bat:
FMP24 -rv -i"00000001" -o20002 -P5.1 -f464.225


The CC receiver works normally. The problem affects live audio from the VC side while FMP24-VC is in trunk voice-following mode.

Main symptom

During trunk-followed voice calls, the live DSDPlus audio intermittently clips or chops off parts of syllables.

The important point is that the simultaneous DSDPlus.wav recording is clean. Speech that is missing from the live audio can still be heard correctly in the WAV recording.

This suggests that the RF signal and voice decoding are succeeding, but something is affecting the live-audio path.

Most significant test

I can reproduce the following behaviour:

1. Allow FMP24-VC to follow a voice call normally.
2. The live audio begins clipping.
3. While the same transmission is still active, I press Esc once in FMP24-VC to terminate trunk voice following.
4. FMP24 remains tuned to the active traffic frequency.
5. The clipping stops almost immediately and the remainder of the same transmission becomes clean.

This has now been reproduced more than once.

In other words:


Active call + VC trunk following = clipping

Press Esc during same active call
= clipping stops almost immediately


No RF-frequency change, gain change or audio-device change is required for the clipping to stop.

Other tests performed

• Single-receiver 1R mode is essentially clean.
• Normal dual CC/VC operation clips.
• Using two RTL dongles alone does not appear to cause the problem.
• Running a second FMP24 instance without normal VC trunk following did not reproduce the clipping.
• Running a second DSDPlus process by itself did not reproduce the problem.
• Multiple FMP24 L I/Q dropout tests have completed without detecting dropouts.
• I have seen an isolated I/Q data loss detected message previously, but this is very uncommon and does not correlate with the recurring clipping.
• Live clipping occurs through normal speakers/headphones.
• The same clipping was reproduced when audio was routed through a virtual audio path/Zello, while the simultaneously recorded WAV remained clean.
• Disabling Windows audio enhancements and exclusive mode did not fix it.
• Changing USB ports did not fix it.
• Changing RTL gain did not fix it.
• Changing FMP24 FFT/update settings did not fix it.
• A fresh DSDPlus test folder reproduced the clipping.
• The rtlsdr.dll and libusb-1.0.dll files in the normal and clean-test folders have identical SHA-256 hashes.
• Windows detects only the two real RTL2838 devices; no extra/dummy RTL device appears to be installed.

Direct-link versus TCP test

I also changed only the VC connection from direct linking to TCP.

Direct-link configuration:


FMP24-VC: -o20002
VC DSD+: -i20002


TCP configuration:


FMP24-VC: -oT20002
VC DSD+: -iT127.0.0.1:20002


The clipping still occurred with TCP.

Therefore, the problem does not appear to be specific to the direct-link transport.

Additional observation

While the VC receiver is idle, FMP24 occasionally briefly displays:


Traffic: TIIInonStd_L1-9_0734_466.075000_PC_3000250_66104


Every instance I have noticed contains the same IDs 3000250 and 66104.

These messages only seem to appear while VC is idle, not during active transmissions, so I do not know whether they are related to the clipping.

Changing private-call priority did not stop these idle messages.

Current conclusion

The strongest correlation I have found is specifically with FMP24-VC being in active trunk voice-following mode.

The same voice transmission clips while VC following is enabled, then becomes clean almost immediately when Esc is pressed to take FMP24-VC out of voice-following mode.

The problem occurs with both direct linking and TCP, while single-receiver operation is clean and the simultaneously recorded DSDPlus WAV is clean.

I would appreciate any suggestions for further testing, or confirmation of whether this could be an FMP24/DSDPlus dual-receiver TIIInonStd voice-following issue.


Thanks.

 

[mtindor]

Traffic: TIIInonStd_L1-9_0734_466.075000_PC_3000250_66104

Thanks.

You don't happen to have CTRL --> Tune to Voice Call Repeater Inputs enabled do you?

I ask because 466.075 would be a mobile input, and under normal circumstances should never be tuning to such a frequency or referencing such a frequency.

Then again, I forgot you were in upsidedown land. Maybe 466.075 is a completely legit repeater output frequency.

 

[Scotty_B]

You don't happen to have CTRL --> Tune to Voice Call Repeater Inputs enabled do you?

I ask because 466.075 would be a mobile input, and under normal circumstances should never be tuning to such a frequency or referencing such a frequency.

Then again, I forgot you were in upsidedown land. Maybe 466.075 is a completely legit repeater output frequency.

Thank you for your reply.


'Tune to Voice Call Repeater Inputs' is not enabled on either the VC or CC side.

And yes, in upside-down land, 466.075 MHz is a legitimate repeater output frequency.