I briefly looked into decoding and encoding with FLdigi. What we need it details of the checksum calculation that is appended to the packets an used for validation when decoding.

Personally I think trying to run this under arm Linux on a Pi is going to be too resource heavy to work reliably.

73
Nick

_

Why oh why do people keep trying to beat a round peg into a square hole?    It's intrinsically a kludge to run native Windows programs under Linux.  Trying to do this on a Ras Pi just makes it doubly kludgy since you don't have a native display, don't have a native keyboard/mouse,  don't have enough USB ports, etc.   By the time you acquire the rat's nest of USB hubs, mini HDMI cables, externalHDMI monitor (or VGA mon plus HDMI-to-VGA converter, etc) you will have spent far ;more than just installing the Messenger app on a cheap 7' or 8" Windows tablet that sells for less than $100.     

If you do want to kludge FLdigi to do Messenger-mode packets, here are the details you need.   this is a post made years ago by G4HYG

---

How it works...APRS over PSK-63     Revised 23 Nov 2014
   

Previous attempts to use the PSK modes for APRS using an add-on that the late Roger Barker G4IDE wrote for UI_View have been disappointing as no error checking or AFC was used in the original add-on. This resulted in incorrect callsigns and positions appearing on the UI-View map and APRS-IS.

I wanted to improve on this as the performance of HF 300 bd packet has been poor during the recent sunspot minimum.

So how does it work...

Let's say we want to send the following APRS packet:

G4HYG>APSK-63:=5332.76N/00225.91W&Testing APRS Messenger v2.26 on 10.1497 MHz

First the program calculates a checksum using the CRC-16 Modbus algorithm. For the above APRS packet it works out in hex as: 4B60
This is then added to the packet:

G4HYG>APSK-63:=5332.76N/00225.91W&Testing APRS Messenger v2.26 on 10.1497 MHz4B60

A start and end flag "~" tilde character is added at the start and end of the packet. This is similar to what is used in a AX.25 packet frame.
This gives:

~G4HYG>APSK-63:=5332.76N/00225.91W&Testing APRS Messenger v2.26 on 10.1497 MHz4B60~

To overcome any data corruption in the receiver due to the AFC locking on or AGC on a strong signal eight dots are added at the start ........
(Five dots in early APRS Messenger versions, eight dots from v 2.35 to reduce packet errors). A space is added after the final "~" tilde character so that the start and end tilde characters can be found in a stream of random noise characters.

We finally transmit the following packet:

........~G4HYG>APSK-63:=5332.76N/00225.91W&Testing APRS Messenger v2.26 on 10.1497 MHz4B60~

When this is received at another station it could be corrupted by interference or noise.

A typical received signal follows:

...~G4HYG>APSK-63:=5332.76N/00225.91W&Testing APRS Messenger v2.26 on 10.1497 MHz4B60~ kt e h

Note that two of the dots at the start are missing and "kt e h" has been added at the end as the receiver PSK squelch was closing.

The receive side of the program now looks for the start and end "~" tilde flags and extracts the text between them:

G4HYG>APSK-63:=5332.76N/00225.91W&Testing APRS Messenger v2.26 on 10.1497 MHz4B60

The last four characters are extracted and a CRC-16 Modbus checksum is calculated on what is left. This checksum is compared with the extracted four characters to confirm that the received packet is the same that sent by the sender. In this case it is:

4B60 is the same as 4B60 so the packet is confirmed as correct.

The packet is now displayed on the screen even if it has errors so that it can be manually read. If the packet has checked OK then it is sent to the APRS-IS:

G4HYG>APSK-63:=5332.76N/00225.91W&Testing APRS Messenger v2.26 on 10.1497 MHz

73,

Chris, G4HYG