Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Corrupted TX bitstream when FX.25 enabled #426

Open
dvanderlocht opened this issue Oct 5, 2022 · 3 comments
Open

Corrupted TX bitstream when FX.25 enabled #426

dvanderlocht opened this issue Oct 5, 2022 · 3 comments

Comments

@dvanderlocht
Copy link

I have observed that a TX bitstream gets corrupted at random places with FX.25 enabled.

Initially I thought there were problems with the receiving side (AX.25) but analyzing the HDLC bitstream showed me the bitstream is getting corrupted at the TX-ing side (Direwolf with FX.25 enabled). The issue isn't there when FX.25 is disabled / plain AX.25 is used.

Receiving stations with FX.25 support mostly can correct the wrong bits and don't seem to suffer.

@wb2osz
Copy link
Owner

wb2osz commented Oct 5, 2022

Please provide instructions on how to reproduce the problem.
Thanks.

@wb2osz
Copy link
Owner

wb2osz commented Oct 5, 2022

My digipeater is configured to transmit FX.25 and a Kenwood TH-D72 receives it fine.
aprs.fi shows about 16 other stations receiving my digipeater.
Please describe the exact conditions where this is observed.
Thanks.

@dvanderlocht
Copy link
Author

My side is running a 3 channel setup on a Raspberry Pi 4 running kernel 4.19 and I only observed the issue on the first channel (0) with 1200 baud AFSK modem setting. Receiving side device was an AEA PK-88 TNC, also tested with an MFJ 1274 TNC. My other 1200 baud AFSK channel (2) didn't seem to have the issue.

Replicating the issue can be tried by connecting and sending FX.25 frames to a receiving AX.25 device, in my case 2 different types of TNCs. When closely monitoring the receiving device and packet flow in Direwolf I noticed at random times/intervals the receiving device seemed to be a bit deaf.

At first I thought the receiving device indeed might be a bit deaf, until I used my logic analyzer with 2 different receiving devices and scope directly to my soundcard output to analyze the HDLC protocol bitstream. I've noticed there that the bitstream sometimes seems to be corrupted/incorrect at different/random places. First I thought it might be the TNC's demodulator IC gone bad or something, until I hooked up a different TNC with different hardware+firmware and did the same analyzing at Direwolf's soundcard output. With the latter I saw it weren't both TNCs demodulating it wrong, but the modulated AFSK signal was already wrong at the soundcard output.

The thing is that it doesn't seem to be an issue constantly there. Sometimes it's 1 out of 100 frames (or less) and at times it's 1 out of 10 frames getting corrupted mid-stream. With FX.25 disabled / using plain AX.25 in my Direwolf config this wasn't happening at all.

Last evening I did some more testing by using another Raspberry Pi 4 with latest Raspberry Pi OS. With the exact same USB soundcards and config I didn't notice any corruption in the bitstream with FX.25 enabled. After switching back to the Raspberry Pi 4 running kernel 4.19 (in an attempt to figure out what is going wrong there), I surprisingly also didn't notice any corruption in the bitstream anymore with FX.25 enabled...

For now I'm not having/seeing issues but I'm not sure what happened as there's nothing changed, except for the fact my USB soundcards might be switched with replacing the Raspberry Pi 4 and back. On both USB soundcard outputs I'm not seeing any corruption anymore either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants