POCSAG Midland SD225

[jgromes]

Following from #7

@brooksbUWO what does your receiver chain look like? PDW takes input either from soundcard or from RS-232.

[brooksbUWO]

Following from #7

@brooksbUWO what does your receiver chain look like? PDW takes input either from soundcard or from RS-232.

Soundcard with virtual audio cable.

[brooksbUWO]

The Midland radio is transmitting the POCSAG encoded command. The data is captured using a RS232 monitoring cable by monitoring the input to the Midland's RS232 pin 1.

Here's the captured data: 512 baud, 8 data bits, parity none, stop bits 1, none
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 3E 09 DD 78 91 30 F7 45 30 F7 45 30 F7 45 30 F7 45 30 F7 45 30 F7 45 30 F7 45 30 67 1C BF 50 18 56 9C 18 EE 99 18 80 9F 18 80 9B 18 B6 E6 D8 E8 CC 1A 0A 7D 09 DD 84 30 BC 37 0C D0 F2 7E 46 DB 00 C1 AF E4 98 F7 91 30 F7 45 30 F7 45 30 F7 45 30 F7 45 30 F7 45 30 F7 45 30 F7 45 30 F7 45 30 F7 45 30 F7 45 30 FF

I used Bray's Terminal for the serial data capture.

[jgromes]

That looks odd. The preamble should be 0xAA, not 0x55, so there might be some issues with endianness/MSB order. In addition, after preamble, there should be the frame sync word, 0x7CD215D8, but it's nowhere to be found.

[brooksbUWO]

I agree that it looks odd. The preamble should be 0xAA, but it is bit reversed and is 0x55. I don't have a data cable for the POCSAG receiver module, but there was a setting listing "Data Polarity". I don't know how the receiver's are actually programmed, but I'm starting to suspect they are inverted.

I'm not sure what the "Data Polarity" actually is suppose to mean. There is another project that has an option called "inverts the modulation polarity".

Maybe this is the reason RadioLib pages are not being received by the POCSAG data receiver? I'm going to attempt building a data cable to see if I can read the current settings.

[jgromes]

I think you're trying to do too many things at the same time. I would start by examination of the recorded data - what has to be done to turn them into POCSAG messages? Flipping bits? Some MSB/LSB reordering?

Once you have a message that conforms to the POCSAG specification (0xAA preamble, 0x7CD215D8 frame sync etc.), you will know exactly what is the transmitter doing. You can then look inside the frame and determine whether the data is actually binary or not.

[hheinreich]

I already know the format of the data. The data command is exactly the same as if I physically connect to the sign's serial port and send a command using Bray's Terminal or ESP32 or if the wireless POCSAG is connected to the signs serial port as it is for normal operation.

The command is what is being encoded into POCSAG and sent. Here's the command protocol.

https://www.brgprecision.com/pdffiles/Protocol12.pdf

My thought on temporarily reprogramming the POCSAG receiver module was to see if it could receive non-inverted POCSAG messages using RadioLib. The programming software is so old that I can't even get it to run on a virtual machine with Windows 2000.

So as you suggested, I am going to look at the data the radio is transmitting to see if it's just inverted POCSAG.

[sp2ong]

POCSAG is wide used by ham radio in Europe it maybe you can find some information on

https://hampager.de/dokuwiki/doku.php