RX of TX frames (local echo) caused by cross talk introduced by TRRS plugs and cables used with USB sound devices

[HarlekinSimplex]

Actually I see that sent beacons or KISS frames are received as local echoes, recognized and logged during TX even if DW operates in simplex (FULLDUP OFF) mode.

The root cause of course is a hardware issue that introduces a faint cross talk by using TRRS cables with joint groundings of playback and capture to connect a USB Interface with radios that don't have build in USB Codecs and/or CAT interfaces. As a typical device of that art there is digiri mobil or like DIY interfaces with or without GPIO or VOX triggered PTT. As soon as you use a TRRS Plug and cable of more than a couple cm of length, such a faint cross talk appears on the input line while sending data.

Though a hardware solution may be possible on the interface side, avoiding such faint echoes on standard TRRS cables entirely is more or less impossible.

One possible software soultion, at least for using dw in simplex mode, would be to just ignore any incomming data while sending. How ever, it may be difficult to handle the possible delay between TX and RX data to distinguish between echoes and real RX data.

Another possible solution would be to compare incomming data with the actual sent data and as soon RX frames appear that resemble TX frames that have been recently sent (within a very short time) these echo frames may be just discarded.

Since the cross talk comes in with a rather low audio level (approx. audio level 0..5) having an option to define a minimum audio level for processing incoming singnals would solve this crosstalk issue not only for simplex but for duplex and fullduplex as well.

I did not find anything regarding this on the web so far and friends of mine did not report such issues with soundmodem or like as well. Same goes with dw, nothing regarding such an issue is to be found on the internet by now. So I have to assume that these local echoes are no problem with other software TNCs, at least when used in simplex mode. I have no clue why it is that rare or unknown. Maybe the consequences of this issue do not cause any major problems with the majority of applications or like.

In my case,I tried to run the RNS (Reticulum) stack wit KISS frames using dw in simplexe mode as Sowftware TNC and those local echoes of the tested USB Sound devices seem to disrupt the communication entirely. Having set up two USB sound device as two fully separated audio paths (ADEVICE with separated Input and Output devices) did produce no echoes anymore and the RNS KISS protocol immediately did run perfect without any issues. So these echoes are clearly the reason why RNS did not work and with that they are a show stopper for me and a solution need to be found. Even if other applications, network protocols or software TNCs may be more resiliant to such local inbound copies of outbound frames, my whole setup is build around direwolf and reticulum and those two components shall not be chnaged.

How ever, even nobody seems to have that one so far but me, the problem can be reproduced quite easily. Just set up a 10sec beacon like this: OBEACON comment="Test Beacon" delay=0:10 every=00:10 OBJNAME=Test lat=0^0.0 long=0^0.0 dest=CQ

Plug in any USB Sound device you like with a TRRS socket attached to connect to audio equipment like headsets and you'll see the local echoes comming in, regardless if you have connected anything to the TRRS socket already or not.

I tested this with several brands of such USB devices and the results were always the same. Local echos at an audio level around 0..5 max. properly and flawlessly received, processed, reported and logged to the console by dw as incomming data. The longer the cables are, the higher the audio level gets. You even may use these echoes as a logging feature to see that audio encoding and decoding with dw does work and all sent frames are received, decoded and processed 100% error free. I thought in the beginning of using dw myself that this 'logging' was intentionally implemented this way, until I muted the capture channel using alsamixer during my investigations why the RNS stack does not work as expected. You may be able to envision my surprise as the 'logging' of those echoes stopped immediately as soon as I disabled the USB capture itself ... ! This may be another reason why these echoes are usually not considered or recognized as a bug. The 'logging' looks and feels too clean and useful to be a major HW/SW flaw...

The echoes could only be subdued by lowering the playback and capture levels to ridiculously low levels which usually leads to a sitution where the communication gets unacceptable unreliable just because of to low audio levels. It depends on the brand and design of the USB Sound Device and the cables attached and used though how bad things get.

I talked already to the manufacturer of digirig mobile and he was very supportive. However the digirig mobile interface HW uses TRRS sockets to connect to the radio and the echoes do only appear if a TRRS plug with a cable is inserted into this interfaces socket. So the issue is primarily introduced by the cable and the joint usage of mic and speaker grounding in TRRS plug and cable. How ever, my experiences showed that ANY cable, regardless how it is build or how execellently they are crafted, introduces those echoes as soon as the TRRS Plug is set into the socket. Even with perfect high value separated shielding of mic and speaker right after the plug did not reduce the cross talk entirely. Only cutting the joint grounding appart on the PCB to get 100% separated audio paths from the decoupling signal transformes to the radio together with proper shielding of both audio paths will stop the cross talk. So more or less each and every USB sound device using TRRS seem to be prone to that issue.

Since there are thousend like interfaces already in the wild, solving that for actual HW needs a software adoption like I have suggest above.

Would it be possible to implement one of those suggested soultions shortly? My wish would be to have the audio level filter implemented to ignore frames below a certain audio level. I guess that one would be the most simple, easy to implement and fexible solution (more or less one if statement plus a new commandline option and config parameter) to cover any crosstalk issues like that with TRRS plugs and cables.

pls adv Cheers Stephan de DD8SB

[na7q]

I will add that this issue is common. Rarely problematic. Certainly annoying. Surprisingly never hear much of it either.

[Tyler-2]

I had been seeing this too and thought it was just a "logging" feature like you said. But then I added a filter to not digipeat my own packets, which seemed like a strange thing to have to do.

I use an Easy-Digi.

[marrold]

I have been experimenting with "virtualised" Dire Wolf instances with audio loopbacks and experience the same issue. It makes sense as there's no PTT or radio switching from Rx to Tx, so Dire Wolf can always "hear" what's on the loopback.

It would be great if these packets could be filtered from the logs / KISS / AGW etc. For digipeating or igating it's less of an issue as these can be filtered already.

Thanks

[marrold]

Looking at the issues, these all seem related:

#401 #97 #288 #337

[wb2osz]

Fixed in the dev branch and will be in 1.7 release. Received audio is muted while transmitting.