Having a project that sits a couple of miles and an hours' walk up a hillside is not conducive of easy debugging!

AIS message types 5 and 24 (static and voyage data) that contain vessel name are split over two AIS sentences. For some reason I was receiving none of these message types.

Fields that are not full, such as DESTINATION, are padded out, and lead to AIS sentences with long repeating character strings. Example below "222222222" and "88888888888"

!AIVDM,2,1,1,A,55?MbV02;H;s<HtKR20EHE:address@hidden@Dn2222222216L961O5Gf0NSQEp6ClRp8,0*1C

!AIVDM,2,2,1,A,88888888880,2*25  

For some reason, something in the transmission chain is adding an extra byte "1" when a string of several similar characters is transmitted.

Example bytes received for 2nd sentence:

33 65 73 86 68 77 44 50 44 50 44 49 44 65 44 56 56 56 56 56 56 56 1 56 56 56 48 44 50 42 50 53

(did you see that extra 1 in there?).

Whether this is the AIS receiver (unlikely), the LoRa transmitter on the hill (most likely) or the LoRa receiver/parser (likely, but less so), I don't currently know as I don't have opportunity to fetch the box from the hill.

In the meantime, I add code to the Python script to simply strip out invalid characters from the payload, then pass to the AIS parser/UDP forwarder.

Due to the 6-bit ascii encoding of AIS data, valid characters in an AIS payload are decimal values 48-87, 96-119. I can afford to just discard invalid characters as the checksum validator in the AIS parsing code will take care of any corrupted bytes; extra bytes introduced in the LoRa datastream are then stripped out correctly and pass validation.

http://catb.org/gpsd/AIVDM.html#_ais_payload_byte_alignment_padding_and_bit_stuffing