Open sq2mo opened 3 weeks ago
Hi, can you explain a little further as I did not get it ? where is this getting add (and shouldn't)?
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.
This byte that should be removed comes only from aprsdroid over Bluetooth packet? (This question is to know where to look for this)
Yes, aprsdroid sends it as a last char of TNC2 text frame. Basically it's a newline.
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)?
I would say: If last byte is 0x0a, remove it or replace with null terminator (easiest way), this worked for me.
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:
Did a simple character check in
void getData
which proves the above and mitigates the issue:Perhaps TNC2 frame should additionally be checked for non-text content.