Unidentified Bus Timetable Data
 | |
|---|---|
| Frequencies | 204.9625 MHz |
| Frequency Range | 204.9625 MHz - 204.9625 MHz |
| Mode | NFM |
| Modulation | — |
| ACF | — |
| Location | Scotland |
| Short Description | 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 MHz in Aberdeen, Scotland. |
| I/Q Raw Recording | — |
| Audio Sample | |
Description[edit]
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.
It's FSKFrequency-Shift Keying, not NOAA APT. Not sure about format and decoding however. --Cartoonman (talk) 16:15, 27 January 2017 (NZDT)
Decoding[edit]
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) :
aaaaeb2304ff00460800e803b80000606d85000000008007000000000000000000000000000000000000000000000000000000000000f984
aaaaeb2304ff007f0111060fbb00857e0000000000000000000000000000000000000000000000000000000000000000000000000000e3dc
aaaaeb2304ff0047be008082718600000000000000000000000000000000000000000000000000000000000000000000000000000000c4d8
aaaaeb2304ff00470700401484b40000000000000000000000000000000000000000000000000000000000000000000000000000000024fc
aaaaeb2304ff0047c400001e093704ff0047a900004495a004ff00473700002a3ba404ff00472e0040a88d5904ff00471900804252a2f1e6
aaaaeb2304ff00470400c06ce51204ff003f04d101a004e5f000000000000000000000000000000000000000000000000000000000002bb6
aaaaeb2304ff00478700c0c38cea04ff00471d008066538904ff0047230000917e2704ff00475500806785e900000000000000000000b546
aaaaeb2304ff00471200404a014004ff00473300c05a6b7004ff00478b00409bef8004ff003f041d012004bb60000000000000000000ab94
aaaaeb2304ff000b005200ad77597e7d5f435a7d65436a4f4056435e705a4c78507f7b744f5a58434b445a4c4044426f674075524750ffee
aaaaeb23504e54505f40777972577c757b697940767d4f784171616f407d7a716540637d437b6f7c7f7f7867a0000000000000000000aace
aaaaeb2304ff0047d6008053adba04ff00471e000040b3d704ff004853006018d94004ff00477c000023ec4604ff00475d00001fe66b870b
aaaaeb2304ff0047680040da183404ff00470d00803e56b304ff0047130000c3f0da04ff0046090000004c0100a8228500000000e2d6e5ba
aaaaeb2304ff00470f004002071a04ff00478900c06f8e7f00000000000000000000000000000000000000000000000000000000000090ca
aaaaeb2304ff00476400c06d3ad204ff00471c00c07fa27f000000000000000000000000000000000000000000000000000000000000b6ba
aaaaeb2304ff0047b100009c935a04ff0047a60040cfe71304ff004749004037d24504ff0047620000e7ebfd000000000000000000009280
aaaaeb2304ff0047820040022c7604ff00476d004054989c04ff0047760080ad0e3a04ff00484a000000f61604ff0047a10040aca64e470a
aaaaeb2304ff003f041d012004bb6000000000000000000000000000000000000000000000000000000000000000000000000000000075a4
aaaaeb2304ff00489000a01a34c5000000000000000000000000000000000000000000000000000000000000000000000000000000008512
aaaaeb2304ff004738004032097a04ff00475e004091578b0000000000000000000000000000000000000000000000000000000000007c54
aaaaeb2304ff00472000009cbfa60000000000000000000000000000000000000000000000000000000000000000000000000000000031c4
aaaaeb2304ff0047390080e8d91d00000000000000000000000000000000000000000000000000000000000000000000000000000000ac06
aaaaeb2304ff007f0111060fbb00857e0000000000000000000000000000000000000000000000000000000000000000000000000000e3dc
aaaaeb2304ff00475700809645d504ff0047830040ba2df804ff00474b00402c93f604ff0047750000b4ae7400000000000000000000763c
aaaaeb2304ff004625003b02a00100802285000000000d7204ff00465400e803a00100c8228500000000764104ff00473500c0552bfc13d8
aaaaeb2304ff0047400080fa404c0000000000000000000000000000000000000000000000000000000000000000000000000000000027c2
aaaaeb2304ff0047a800805d345600000000000000000000000000000000000000000000000000000000000000000000000000000000714e
aaaaeb2304ff00460800ea017c0000586585000000008e1a04ff0047f200c092571a04ff00472800003a3dbc04ff00473e0040fa0864de62
aaaaeb2304ff00476600c018fa8d04ff00479600005fd9bf000000000000000000000000000000000000000000000000000000000000905a
aaaaeb2304ff0047b00000bc937e04ff0047a30040bfe63b04ff0047d3008014ed4404ff00476c0080fa48dc04ff0047580040d156f3f725
aaaaeb2304ff00470c00c077a77904ff00476b00c018f82104ff003f04b203c00333b600000000000000000000000000000000000000bcf2
aaaaeb2304ff0047b700004e138f00000000000000000000000000000000000000000000000000000000000000000000000000000000fa9e
aaaaeb2304ff0047700040149f000000000000000000000000000000000000000000000000000000000000000000000000000000000014fa
aaaaeb2304ff00477800c07bbc8c04ff00471800804f929b04ff0047a5008094f6ac0000000000000000000000000000000000000000bc90
aaaaeb2304ff0047c1008005283000000000000000000000000000000000000000000000000000000000000000000000000000000000caa6
aaaaeb2304ff007f0111060fbb00857e0000000000000000000000000000000000000000000000000000000000000000000000000000e3dc
aaaaeb2304ff000b005200ad77597e7d5f435a476c43604f40566d4f505b4c78587f7b7e4b4358434b447f737c777d6d67407554506f7ac3
aaaaeb23524e5478504078735468434a44736543767d54784171667b507d7a717d40437b7d40504340404709d20000000000000000000fe2
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
