Unidentified Bus Timetable Data
Hi there, our local bus company in Aberdeen transmits timetable information to bus stops using this mode... but I can't identify what type of transmission it is. Hope someone can help! Received on 204.9625 MHzMegaHertz (MHz) 10^6 Hz in Aberdeen, Scotland.
It sounds like noaa satellites.
I had a quick look at your data, and it looks indeed like AFSKAudio Frequency-Shift Keying with a bitrate of 2400 HzHertz (Hz), unit of frequency, defined as one cycle per second (1 Hz). and two symbols : 1200Hz and 2400Hz. In the following part, I assume that 1200 corresponds to a logical "1", but it might be the other way around.
I used GNUradio to do the demodulation from your audio file. I have included the flowgraph and some data in File:Unknown bus.zip
In the bitstream we can clearly see a repeating pattern of 448 bits. We have a bit sync preamble (0xaaaa) and a byte sync preamble (0xeb23). The rest of the packet is either all zeros, or some data padded with zeros with a 16 bits CRC at the end. So each message is 52 bytes long. Most messages start with 04ff00 and have a repeating pattern of 8 bytes, so this may be your telemetry data.
If you want to dig deeper, here is a list of all the non-null messages in your sample (including sync & CRC) :
This is great! I had tried to decode with sorcerer plain ascii and didn't get anything, but there was definitely a clear bit pattern involved. Possibly data packet frames being sent, possible ascii plaintext? It seems to be mostly data with some unknown formatting, we would need to know how to segment the frames.--Cartoonman (talk) 07:45, 1 February 2017 (NZDT)
I don't think it's ASCII. I tried to reverse bits (msb to lsb) and to inverse them (xor 1) and I found nothing. I'm not surprised because most of the traffic in this type of bus channels is used to update the displays every 30 seconds or so. As the bit-rate is quite low, they must send the data in binary form to avoid the ASCII overhead.
Now a few tips if someone is interested to decode the protocol :
As Cartoonman said, hunting ASCII strings is a good idea. Most of these systems allow the "Command Center" to send text notifications to drivers. It happens at least once a day, and finding an ASCII string is useful because you know that your bytes are not inverted or reversed. Another useful thing to do is to find the CRCs, which is useful to delimit the messages and check their integrity before you try to decode them. I have updated the colors to show the layer 1 CRC in red (unknown for now). Also, there is some funny business going on with the CRC-16-ANSI. I have highlighted in green some parts of the message verifying this CRC.
Now another thing to do is to find the "timestamp" message. It is often broadcast at regular intervals for the displays, and if you can decode it you're in the right way.
And the hardcore way : record the traffic for a whole day, convert each message to binary, and create a huge picture with each bit corresponding to a black or white pixel. This is very useful to see the pattern in the messages (for example, a counter of the time remaining until the next bus decrementing slowly, then getting high again). Tim (talk) 09:38, 4 February 2017 (NZDT)
Hi, I'm new to Wiki editing, so apologies if I'm not following protocol.
I hear similar signals here in West Gloucestershire(UK)on 181.0125 and 181.3125. I believe they are coming from Bristol, and they are connected with an MPT1327 system which has control on 181.6125 and voice channels on 181.1625 and 181.875. The control channel sends 'GoToChannel (data)' messages every 10 seconds which correspond to these signal channels. The voice channel conversations are obviously bus drivers etc.
I also see another (weak) signal on 183.0625, linked to an MPT1327 control on 182.7625 and MPT1327 voice channels on 182.450 and 183.2125. I believe this may be in Swindon.
I have also managed to decode these signals and I also get 448-bit patterns ( I call them 'packets' ) starting '0xaaaa 0xeb23 0x04ff', with a 16-bit CRC at the end. I believe the next 16-bit word after '0x04ff' is a Message Type. Common message types I see here are:-
0x002d Always 8 bytes long 0x002f Always 7 bytes long, constant for long periods. 0x004b Always 8 bytes long, constant for long periods. 0x007b Always 8 bytes long. This contains date and time. 0x007f Always 8 bytes long. I believe this may be a System ID, sent regularly every 10 seconds. 0x0083 Always 2 bytes long, a constant '0x1c01'.
In all the above the last 16-bits appear to be another CRC.
0x003e Variable length. By far the most common message (approx. 80%). Some of the characteristics of '0x003e' messages are :-
The first 8-bits after '0x003e' appear to be a Sub-Type, either 0,1,2,3, or 4. The following 8-bits give the length of this message (N) (maximum length seen is 42 (0x2a)). There then follow N bytes of data. Finally there is another 16-bit (apparent) CRC.
Hope this helps. Swinradio