Line Feed character sent over LoRa

[sq2mo]

During my recent tracker tests I've discovered that LF char (0x0a) is being sent to the air while using TNC2 protocol.
This is causing different funny behavior, as:

• ^J at the end of frame reported in the digi's syslog
• digipeated frame gets reported twice in aprsdroid - first frame is proper, second frame is empty (probably LF char).

Did a simple character check in void getData which proves the above and mitigates the issue:

        if (validateTNC2Frame(serialReceived)) {
            shouldSendToLoRa = true;
            if (serialReceived[size-1] == 0x0a) {
                serialReceived[size-1] = 0x00;
            }

Perhaps TNC2 frame should additionally be checked for non-text content.

[richonguzman]

Hi, can you explain a little further as I did not get it ? where is this getting add (and shouldn't)?

[sq2mo]

So I am using aprsdroid + 1W DIY LoRa board to work APRS. It seems that aprsdroid sends the frame with LF character at the end - and this is ok since this serves as a line termination in TNC2 protocol. Presence of the LF/0x0a character can be checked by hooking up a BT-to-UART adapter, or via debugs in your software and sending a beacon from aprsdroid.

The thing is, this character should either be removed or replaced by a C-style null terminator, once frame is not in TNC2 protocol anymore. Otherwise it is beaconed, digipeated and appears in aprsdroid/syslog, as described above.

[richonguzman]

This byte that should be removed comes only from aprsdroid over Bluetooth packet? (This question is to know where to look for this)

[sq2mo]

Yes, aprsdroid sends it as a last char of TNC2 text frame. Basically it's a newline.

[richonguzman]

I'm getting back:

so how do you think we should attack this issue? just kill the last byte of the incoming packet from aprsdroid (over BT)?

[sq2mo]

I would say: If last byte is 0x0a, remove it or replace with null terminator (easiest way), this worked for me.