APRSdroid Transmitted Packets Illegible

Question

APRSdroid Transmitted Packets Illegible

Opened this issue 8 years ago · 8 comments

Everything seems to be working; I am decoding received packets no problem and when I transmit I get a green log message, VOX is tripped (I am using AFSK) and the radio transmits the packet. I have a second radio on which I can hear the transmitted packet to confirm it has sent. The problem is the second radio and the APRS program on my computer can hear the transmitted packet, but cannot decode it. Neither can the local repeater (it’s not being picked up by the nearly iGate, whereas numerous packets sent by other people in the vicinity are). I am running the latest release of APRSdroid on a Samsung Galaxy S5 Neo with Android 6.0.1. Not sure what is wrong, but it appears to be something related to the packets APRSdroid is generating? Maybe it is incorrect AFSK modulation?

Thanks and 73

Answer 1 · 2017-03-02T06:43:43.000Z

The AFSK modulation should be fine, people all over the world are using it. Have you tried increasing the "Frame Sync Prefix", the number of milliseconds to trigger VOX?

Answer 2 · 2017-03-06T00:18:44.000Z

Yes, I have. It is currently set at 400, but I have tried it as high as 800. When I use APRSdroid on my Samsung Galaxy S3 it works without issue, the local digipeater picks up the signal and forwards it to an IGate. When transmitting with my Samsung Galaxy S5 Neo the transmitted packets are unable to be decoded by myself, digipeaters, IGates or anything else. The frequency sounds almost as if it is slightly off.

Answer 3 · 2017-05-11T14:56:48.000Z

If the frequency is slightly off, it might be a driver compatibility issue. APRSdroid is using a fixed sampling rate of 22050 Hz; if your S5 Neo doesn't support that, it might play back the audio at a different frequency indeed, though I can not find any indication of such behavior.

I have created a version that uses a corrected sample rate: https://aprsdroid.org/download/builds/APRSdroid-gl-2017-05-11.apk

Could you please test?

Answer 4 · 2017-06-11T01:55:31.000Z

I notice that AFSK output works fine with one local digipeater, but another seems to be totally deaf to my AFSK. When I switch to a mobilinkd bluetooth device, the other digipeater responds very well, as equally to the other digipeater that was only responding to my aprsdroid generated AFSK.

This is quite puzzling to me. Does anyone have any ideas?

I have adjusted preambles and audio levels to no avail. I can get the 'working' digipeater to respond to preambles as low as 100ms.

I love the aprsdroid application, thank you your work.

Answer 5 · 2017-06-11T17:48:11.000Z

I recorded identical audio from the android and the Mobilinkd. They waveforms on the surface look identical, except for the mobilinkd has a MUCH longer transmit tail. The android basically has a 10ms tail from what I can see, and the Mobilinkd has 300 ms??? woah. Can this be a difference?

The PTT line on Mobilinkd is also asserted for the entire time including the TX tail.

Answer 6 · 2017-06-11T22:57:34.000Z

I think the Mobilinkd is sending a bunch of 'Flag' bytes after the data.

Can there be a way to do this with aprsdroid? Tack on extra 'flag' bytes after the data?

Answer 7 · 2017-06-17T08:37:13.000Z

I suppose that #172 tells us that this was not the right answer and this is still a mystery?

Answer 8 · 2017-06-17T13:36:00.000Z

Yes, no idea myself.

I looked closer at the waveforms between mobilinkd and afsk, and the mobilinkd looked 'cleaner'. What I mean is, for the same short time period, the mobilinkd had equally spaced peaks, and the afsk was a little 'unsteady'.

I ran the recorded wav files through 'soundmodem' and they were decoded properly. This one digipeater must be more sensitive to the waveforms.

This is my best guess--maybe this is repeatable by someone else?