So I've been dabbling with decoding MDC1200 with a sound card off and on for the past year or so. At this point I've got the following figured out and working in realtime on both my FreeBSD system and a very rudimentary prototype that works under Windows...
It is 1200 bps MSK, bit-xored. 1 cycle of 1200 Hz means "same bit as before", 1.5 cycles of 1800 Hz means "change".
There's the typical M 40-bit sync word of 0x07092a446f at the header, and then 112 bits of data. (Hint: look for inverted sync too, and flip the bit polarity if you see it)
The 112 data bits are interleaved using a 16x7 array.
Once deinterleaved, the data looks something like this (in hex):
1008 2143 e2e3 00 56088a26dd8880
Reversing the nibbles within each byte is then required for this to make sense...
The "1008" is really "0180", or "function 01, argument 80", or "PTT ID"
a "STS" message is function 46 (I believe the 4 means "ack required"), and a "MSG" message is function 47. (And the argument part is the status or message number) Post-ID is 01,00 instead of 01,80.
The "2143" is the unit ID, in this case "1234".
I believe the "e2e3" is a 16-bit CRC (M likes the CCITT CRC), but I can't figure out a CRC algorithm that makes sense given the data. The remaining data is some sort of parity or convolutional coding... other M protocols use a 1/2 rate K=7 code, but I haven't gotten that far yet. The following decodes shed some light on this:
PTTID Unit 0001 = 1008 0010 12ef 00 5608 23 56 5ca432
PTTID Unit 0002 = 1008 0020 abcc 00 5608 23 ac 297492
PTTID Unit 0004 = 1008 0040 c89a 00 5608 23 49 d3d5d3
Note how the 00 stays the same, 5608 appears to be the parity for the 1008, the 23 stays the same, because it is the parity for the 00 part of the unit ID, and then the next byte varies depending on the low byte of the unit ID.
So, that's what I've gotten so far... anyone else done any work on this and want to post or PM me with hints as to where I should go next? I could use the other possible function codes, as well as info about the CRC and convolutional or parity coding.
Also, it looks like the MDC-600 patents are expired or expiring soon, but I don't know what the patent status on MDC-1200 is.
MDC decoding - info and info request
Moderator: Queue Moderator
You have gotten farther with your MDC project than anyone else that I am aware of - i.e. several people have posted here that they were working on decoding MDC but you are the first to have posted real success.
I assume you found some of the info that was posted here in previous threads, such as these bits I have snipped from previous threads:
"The signaling is encoded at 1200 baud using FFSK (MSK) @ 1200Hz/1800Hz. First there is a 56 bit preamble, then a 40 bit word sync, and then either 1 or 2 112 bit codewords for a packet length of 173 ms for one codeword or 267 ms for two codewords.
The 112 bit codeword starts as 32 bits of data (the actual MDC data payload) this is expanded from 32 to 112 bits with error detection and correctional algorithms (rate 1/2 convolutional threshold decoder and 16 bit inverted-CCITT CRC respectively). "
"Actually, the CRC16 is appended to the original 32 bits plus 8 status bits. Now you have 56 bits for the rate 1/2 encoder. "
"Assuming the same interleave as MDC4800, the only "unknown" is the convolutional encoder."
"Reference to the term opcode is found is some motorola manuals. Actually the 'opcode' is comprised of 3 flag bits that determine data/command, direction, and ack/no ack, followed by an operation code specifing the particular operation (ID, status, message, emergency, etc) and then an arguement (which might for example contain the status number in a status packet) "
"Once you get your decoder working, you can reverse engineer the opcode table by recording the data sent by various units. Program radio #1234 to send emergency and you will see 00801234. Program RTT (Request To Transmit) and you get 40011234, etc. "
_____________________________________________________________
Some time ago I conducted some experiments encoding and decoding MDC using a BSC-II as an MDC modem. I felt pretty good about just having determined how to master the protocol between the BSC and it's host [since I never had access to a host or I would have just figured it out with a protocol analyzer].
Once I got that working, I could see the MDC payload for each received packet. In other words, the BSC sends its host a message [with its own protocol and checksum] that contains the information being transmitted in the MDC packet.
You have succeeded in deriving the MDC payload directly, for example,: 01801234 = PTT ID pre from unit 1234.
I can get that from the BSC, so at one time I started compiling a 'dictionary' of the MDC opcodes that different radios send for different functions. I also have a little Motorola information that sheds some light on how those opcode bits are defined. You are correct that the 4 in the status & message means an ACK is required.
I will try to dig out what I have and see if I can put it in a format that makes some sense. [I probably won't have time to get to it till next week]
In the meantime, if you have a radio that can send RAC, would you capture the MDC payload from some sample programming?
The BSC-II never sends the RAC MDC data to its host - I have assumed this is so because it is a fixed end device and its firmware must tell it to ignore that since it is of no use to the host.
I assume you found some of the info that was posted here in previous threads, such as these bits I have snipped from previous threads:
"The signaling is encoded at 1200 baud using FFSK (MSK) @ 1200Hz/1800Hz. First there is a 56 bit preamble, then a 40 bit word sync, and then either 1 or 2 112 bit codewords for a packet length of 173 ms for one codeword or 267 ms for two codewords.
The 112 bit codeword starts as 32 bits of data (the actual MDC data payload) this is expanded from 32 to 112 bits with error detection and correctional algorithms (rate 1/2 convolutional threshold decoder and 16 bit inverted-CCITT CRC respectively). "
"Actually, the CRC16 is appended to the original 32 bits plus 8 status bits. Now you have 56 bits for the rate 1/2 encoder. "
"Assuming the same interleave as MDC4800, the only "unknown" is the convolutional encoder."
"Reference to the term opcode is found is some motorola manuals. Actually the 'opcode' is comprised of 3 flag bits that determine data/command, direction, and ack/no ack, followed by an operation code specifing the particular operation (ID, status, message, emergency, etc) and then an arguement (which might for example contain the status number in a status packet) "
"Once you get your decoder working, you can reverse engineer the opcode table by recording the data sent by various units. Program radio #1234 to send emergency and you will see 00801234. Program RTT (Request To Transmit) and you get 40011234, etc. "
_____________________________________________________________
Some time ago I conducted some experiments encoding and decoding MDC using a BSC-II as an MDC modem. I felt pretty good about just having determined how to master the protocol between the BSC and it's host [since I never had access to a host or I would have just figured it out with a protocol analyzer].
Once I got that working, I could see the MDC payload for each received packet. In other words, the BSC sends its host a message [with its own protocol and checksum] that contains the information being transmitted in the MDC packet.
You have succeeded in deriving the MDC payload directly, for example,: 01801234 = PTT ID pre from unit 1234.
I can get that from the BSC, so at one time I started compiling a 'dictionary' of the MDC opcodes that different radios send for different functions. I also have a little Motorola information that sheds some light on how those opcode bits are defined. You are correct that the 4 in the status & message means an ACK is required.
I will try to dig out what I have and see if I can put it in a format that makes some sense. [I probably won't have time to get to it till next week]
In the meantime, if you have a radio that can send RAC, would you capture the MDC payload from some sample programming?
The BSC-II never sends the RAC MDC data to its host - I have assumed this is so because it is a fixed end device and its firmware must tell it to ignore that since it is of no use to the host.
Some additional details after a night of hacking at this:
Assume that one treats the deinterleaved data in the following form (obtained by a 16x7 deinterleave followed by bit reversal of each byte (I had just been reversing each nibble previously, so convert values from my previous posting accordingly)):
PTTID for Unit 1234 is:
(hexidecimal) 01 80 1234 2E3E 00 6580A862DD8808
01 is the command opcode
80 is its argument
1234 is the unit ID
2E3E is presumably the CRC (though the "inverted CCITT-CRC" hint seems reasonable, I haven't successfully found the exact algorithm/input data ordering that works)
00 is an unknown field (it is 00 for PTTIDs, 76 for STS and MSG)
and 6580A862DD8808 is the FEC (convolutional code) bits
Now, for the successful hacking of the evening...
To generate the convolutional code bits, perform the following operation:
1. reverse the bit order for each byte of the first 7 bytes (to undo the reversal performed for display, above)
2. feed those bits into a shift register which is preloaded with all zeros
3. for each bit, calculate the modulo-2 sum: bit(n)+bit(n-2)+bit(n-5)+bit(n-6)
4. then for each byte of resulting output, again reverse those bits to generate the values listed above (for display)
Note that because of the constraint length and lack of trailer of this convolutational code, it does not protect (most of) the final "unknown" field.
Other than bit ordering issues, this is the same convolutional code that is used by MDC4800. Note that if you plan to use the error correction routine that is in some available MDC4800 decoder source code, it is slightly wrong, but fixable.
I don't have a radio that can generate any of the other messages or a channel I can monitor for ACKs at this time, so I'm a bit limited in where I can go next.
Assume that one treats the deinterleaved data in the following form (obtained by a 16x7 deinterleave followed by bit reversal of each byte (I had just been reversing each nibble previously, so convert values from my previous posting accordingly)):
PTTID for Unit 1234 is:
(hexidecimal) 01 80 1234 2E3E 00 6580A862DD8808
01 is the command opcode
80 is its argument
1234 is the unit ID
2E3E is presumably the CRC (though the "inverted CCITT-CRC" hint seems reasonable, I haven't successfully found the exact algorithm/input data ordering that works)
00 is an unknown field (it is 00 for PTTIDs, 76 for STS and MSG)
and 6580A862DD8808 is the FEC (convolutional code) bits
Now, for the successful hacking of the evening...
To generate the convolutional code bits, perform the following operation:
1. reverse the bit order for each byte of the first 7 bytes (to undo the reversal performed for display, above)
2. feed those bits into a shift register which is preloaded with all zeros
3. for each bit, calculate the modulo-2 sum: bit(n)+bit(n-2)+bit(n-5)+bit(n-6)
4. then for each byte of resulting output, again reverse those bits to generate the values listed above (for display)
Note that because of the constraint length and lack of trailer of this convolutational code, it does not protect (most of) the final "unknown" field.
Other than bit ordering issues, this is the same convolutional code that is used by MDC4800. Note that if you plan to use the error correction routine that is in some available MDC4800 decoder source code, it is slightly wrong, but fixable.
I don't have a radio that can generate any of the other messages or a channel I can monitor for ACKs at this time, so I'm a bit limited in where I can go next.
Have you tried zero stuffing
Have you tried zero-stuffing the shift register at the end of burst, to see if that fixes your CRC?
This is my opinion, not Aeroflex's.
I WILL NOT give you proprietary information. I make too much money to jeopardize my job.
I AM NOT the Service department: You want official info, manuals, service info, parts, calibration, etc., contact Aeroflex directly, please.
I WILL NOT give you proprietary information. I make too much money to jeopardize my job.
I AM NOT the Service department: You want official info, manuals, service info, parts, calibration, etc., contact Aeroflex directly, please.
Re: Have you tried zero stuffing
I wouldn't expect the CRC to include the convolutional code at all, actually. It should just be over the data portion, or perhaps the data plus the extra unknown byte.Wowbagger wrote:Have you tried zero-stuffing the shift register at the end of burst, to see if that fixes your CRC?
.wav files should work. Easiest for me if you record at a nice high sample rate like 48000 Hz (48000 turns out to be especially easy on the MSK decoder because it is a multiple of 1200), but I only need one channel (mono) at 8 bits. I can probably work with it down to about 22050 Hz sample rate if necessary.alex wrote:Would you be able to use .wav files to try and decode the data? I might be able to work on putting something together with most of the console features.
Depends if I can find my programming cable for the MC we have kicking around.
-Alex
Alternatively, I might be able to build up either a Windows or FreeBSD or Linux version of the code that just stuffs that raw output in a file, and you could just process the data there. The best-working code I have now is on FreeBSD, because I haven't moved the latest work to the Windows version.
Well, I do have 3 systems running FreeBSD in various area's, however, I lack sound cards in all 3 systems.ka6sqg wrote:.wav files should work. Easiest for me if you record at a nice high sample rate like 48000 Hz (48000 turns out to be especially easy on the MSK decoder because it is a multiple of 1200), but I only need one channel (mono) at 8 bits. I can probably work with it down to about 22050 Hz sample rate if necessary.alex wrote:Would you be able to use .wav files to try and decode the data? I might be able to work on putting something together with most of the console features.
Depends if I can find my programming cable for the MC we have kicking around.
-Alex
Alternatively, I might be able to build up either a Windows or FreeBSD or Linux version of the code that just stuffs that raw output in a file, and you could just process the data there. The best-working code I have now is on FreeBSD, because I haven't moved the latest work to the Windows version.
-
zhangyucheng
- Posts: 2
- Joined: Thu Aug 12, 2004 9:46 pm
I still can't get the correct code
I tried to encode them ,but failed
if g(x)=x^16+x^12+x^5+1
01801234 5E28
if g(x)=x^16+x^11+x^4+1
01801234 13CF
They are not 2e3e!
Am I wrong?
I have tested PTTID
outbound
0001 = BC264CC0FA33E4D1F0F77C27F906
inbound
0001 = B939FFF5FC30E2E7F6F17C22F53A
I write them into a 7*16 matrix row by row
then read them line by line, but I don't get the
data 1008 0010 12ef 00 5608 23 56 5ca432.
which kind is the above data?inbound or outbound?
I really don't know how to deinterleave them
if g(x)=x^16+x^12+x^5+1
01801234 5E28
if g(x)=x^16+x^11+x^4+1
01801234 13CF
They are not 2e3e!
Am I wrong?
I have tested PTTID
outbound
0001 = BC264CC0FA33E4D1F0F77C27F906
inbound
0001 = B939FFF5FC30E2E7F6F17C22F53A
I write them into a 7*16 matrix row by row
then read them line by line, but I don't get the
data 1008 0010 12ef 00 5608 23 56 5ca432.
which kind is the above data?inbound or outbound?
I really don't know how to deinterleave them
Re: I still can't get the correct code
Well, I tried looking at your data in binary, and I'm not sure what you're doing either. When I do it, I get what I posted before.zhangyucheng wrote:I tried to encode them ,but failed
if g(x)=x^16+x^12+x^5+1
01801234 5E28
if g(x)=x^16+x^11+x^4+1
01801234 13CF
They are not 2e3e!
Am I wrong?
I have tested PTTID
outbound
0001 = BC264CC0FA33E4D1F0F77C27F906
inbound
0001 = B939FFF5FC30E2E7F6F17C22F53A
I write them into a 7*16 matrix row by row
then read them line by line, but I don't get the
data 1008 0010 12ef 00 5608 23 56 5ca432.
which kind is the above data?inbound or outbound?
I really don't know how to deinterleave them
And yes, the CRC codes I'm not sure how to compute yet... none of the standard CRCs seem to make sense, in any bit order.
-
zhangyucheng
- Posts: 2
- Joined: Thu Aug 12, 2004 9:46 pm
Re: I still can't get the correct code
ka6sqg wrote: outbound
0001 = BC264CC0FA33E4D1F0F77C27F906
inbound
0001 = B939FFF5FC30E2E7F6F17C22F53A
Well, I tried looking at your data in binary, and I'm not sure what you're doing either. When I do it, I get what I posted before.
And yes, the CRC codes I'm not sure how to compute yet... none of the standard CRCs seem to make sense, in any bit order.
, i sent the codes by GP338, which model is your radio ?Maybe,different model has different codes in the same setting.
i tested the PTT ID
when i pressed PTT, i got the
inbound
0001 = B939FFF5FC30E2E7F6F17C22F53A
when i released PTT, i got the
outbound
0001 = BC264CC0FA33E4D1F0F77C27F906
i just posted the 112 bit.
would you like to give me the original data( including sys codes, and not deinterleaved ) of the 0001 PTT ID codes ?
i will share my researchs with you, if i succeed
I now have a small Windows application that dumps the received data. If you are willing to participate in a test and have what's needed, please send me a PM.
System requirements: Windows 2000 or Windows XP (I've tested it on Windows 2000 and it was built as a Win32 app), sound card or built-in sound input device that you can attach to a receiver
Test requirements: You must be familiar enough with Windows to set your recording input to the match the input you've hooked your receiver to. You must be able to send MDC1200 test sequences to the above receiver. I'm looking for anything OTHER than the basic PTT-ID/Post-ID messages. You'll need to transcribe part of what is displayed and get it back to me.
If you are not interested in participating in a test and just want a software/sound-card based MDC decoder, please wait until a more finished version is available.
System requirements: Windows 2000 or Windows XP (I've tested it on Windows 2000 and it was built as a Win32 app), sound card or built-in sound input device that you can attach to a receiver
Test requirements: You must be familiar enough with Windows to set your recording input to the match the input you've hooked your receiver to. You must be able to send MDC1200 test sequences to the above receiver. I'm looking for anything OTHER than the basic PTT-ID/Post-ID messages. You'll need to transcribe part of what is displayed and get it back to me.
If you are not interested in participating in a test and just want a software/sound-card based MDC decoder, please wait until a more finished version is available.
another breakthrough...
The CRC field is as follows:
It is approximately the CCITT 16-bit CRC, with the following changes:
The input data bytes are the first 32 bits of the message, presented in reverse bit order to the algorithm
The initial value is 0x0000 instead of 0xFFFF
The final result is bit-reversed and then complemented (xor with 0xFFFF)
Then the two bytes of the result are swapped
That yields the 16-bit CRC field.
For an example, try going to http://www.gpfn.sk.ca/~rhg/csc8550s02/crc.html or a similar CRC calculator page. Set the order to 16, polynomial to 1021 (hex), initial CRC value to 0000 (hex), the XOR value to 0000 (hex), set "reverse CRC result", set "reverse input data bytes", and enter %01%80%12%34 as the input data sequence. Hit "compute CRC" and you'll get 3E2E. Swap those to get 2E3E...
The actual MDC1200 PTT ID for unit 1234 is:
0180 1234 2E3E 00 6580A862DD8808
I believe that now covers the decoding of the MSK, the XOR, the deinterleaving, the calculation of the CRC and the calculation of the convolutional code, so we're done, except for learning what all the possible operations and arguments are.
Now that the CRC is known, I should be able to create a program that also generates arbitrary MDC1200 messages through a sound card which should facilitate further analysis of the messages.
ps. Is someone reading this who can move all the useful data to the batlabs MDC1200 page?
The CRC field is as follows:
It is approximately the CCITT 16-bit CRC, with the following changes:
The input data bytes are the first 32 bits of the message, presented in reverse bit order to the algorithm
The initial value is 0x0000 instead of 0xFFFF
The final result is bit-reversed and then complemented (xor with 0xFFFF)
Then the two bytes of the result are swapped
That yields the 16-bit CRC field.
For an example, try going to http://www.gpfn.sk.ca/~rhg/csc8550s02/crc.html or a similar CRC calculator page. Set the order to 16, polynomial to 1021 (hex), initial CRC value to 0000 (hex), the XOR value to 0000 (hex), set "reverse CRC result", set "reverse input data bytes", and enter %01%80%12%34 as the input data sequence. Hit "compute CRC" and you'll get 3E2E. Swap those to get 2E3E...
The actual MDC1200 PTT ID for unit 1234 is:
0180 1234 2E3E 00 6580A862DD8808
I believe that now covers the decoding of the MSK, the XOR, the deinterleaving, the calculation of the CRC and the calculation of the convolutional code, so we're done, except for learning what all the possible operations and arguments are.
Now that the CRC is known, I should be able to create a program that also generates arbitrary MDC1200 messages through a sound card which should facilitate further analysis of the messages.
ps. Is someone reading this who can move all the useful data to the batlabs MDC1200 page?
-
a.steggall
- Posts: 47
- Joined: Wed Sep 25, 2002 8:27 am
I have been collecting MDC information for a long time. The following is a list of MDC call types and the packets I have determined to be associated with them. I have incorporated one I did not have, remote monitor, 118A, from ka6sqg's list. Otherwise, these were obtained by monitoring various radio products. I am also working on a document of definitions of the various call types.
_______________________________________________________________
XMO'S MDC PACKET LIST BY CALL TYPE
* UNIT ID [From originating unit 1234]
0180 1234 [PRE]
0100 1234 [POST]
* EMERGENCY ALARM [From originating unit 1234]
0080 1234
0081 1234 [XTS3000]
* EMERGENCY ALARM ACKNOWLEDGE
2000 1234 [ack from console to originating unit 1234]
* REPEATER ACCESS
Undetermined
* REMOTE RAC ENABLE
Undetermined
* REMOTE RAC DISABLE
Undetermined
* RADIO CHECK [Fixed end to target 5678]
6385 5678
* RADIO CHECK ACKNOWLEDGE [response from target 5678]
0300 5678
* CALL ALERT [Double packet - 2 codewords, 1234 places call to 5678]
3589 5678 830D 1234 [Spectra, Astro Saber "PAGE", Maxtrac "CA" w/Ack Expected=Y]
3589 5678 810D 1234 [Maxtrac "CA" w/Ack Expected=N]
* ENHANCED CALL ALERT
Undetermined
* VOICE SELECTIVE CALL [Double packet - 2 codewords, 1234 places call to 5678]
3589 5678 8205 1234 [Spectra "CALL"]
3589 5678 8015 1234 [Maxtrac "SC", Astro Saber "CALL"]
* CALL ALERT ACKNOWLEDGE [Double packet - 2 codewords, 5678 acks the call from 1234]
3589 1234 A000 5678
* SIMPLE STATUS [unit 1234 transmits status number X]
460X 1234
* SMART STATUS
Undetermined
* EXTERNAL SENSOR STATUS
Undetermined
* STATUS ACKNOWLEDGE
2300 1234
* STATUS REQUEST [i.e. unit 5678 report your last status]
2206 5678
* STATUS RESPONSE [from target 5678 when interrogated]
060X 5678
* INBOUND MESSAGE
470X 1234 [ack expected]
070X 1234 [ack not expected CDM1550]
* INBOUND MESSAGE ACKNOWLEDGE
2300 1234
* REMOTE MONITOR [No MDC response from target unless it has PTT ID]
118A 5678 [118A per KA6SQG]
* SELECTIVE RADIO INHIBIT [Fixed end inhibits target 5678]
2B00 5678
* SELECTIVE RADIO INHIBIT ACKNOWLEDGE [5678 acks the inhibit]
0B00 5678
* SELECTIVE RADIO INHIBIT CANCEL [Fixed end enables target 5678]
2B0C 5678
* SELECTIVE RADIO INHIBIT CANCEL [5678 acks the enable]
0B0C 5678
* REQUEST TO TALK [Unit 1234 asks fixed end for permission to PTT]
4001 1234 [CDM1550 dedicated button]
4101 1234 [CDM1550 slaved to mic PTT]
* REQUEST TO TALK ACKNOWLEDGE
2300 1234 [general ack - not same as permission to PTT]
* REQUEST TO TALK GRANT [Permission to PTT]
Undetermined [Feature is a Gold Elite Option]
_______________________________________________________________
XMO'S MDC PACKET LIST BY CALL TYPE
* UNIT ID [From originating unit 1234]
0180 1234 [PRE]
0100 1234 [POST]
* EMERGENCY ALARM [From originating unit 1234]
0080 1234
0081 1234 [XTS3000]
* EMERGENCY ALARM ACKNOWLEDGE
2000 1234 [ack from console to originating unit 1234]
* REPEATER ACCESS
Undetermined
* REMOTE RAC ENABLE
Undetermined
* REMOTE RAC DISABLE
Undetermined
* RADIO CHECK [Fixed end to target 5678]
6385 5678
* RADIO CHECK ACKNOWLEDGE [response from target 5678]
0300 5678
* CALL ALERT [Double packet - 2 codewords, 1234 places call to 5678]
3589 5678 830D 1234 [Spectra, Astro Saber "PAGE", Maxtrac "CA" w/Ack Expected=Y]
3589 5678 810D 1234 [Maxtrac "CA" w/Ack Expected=N]
* ENHANCED CALL ALERT
Undetermined
* VOICE SELECTIVE CALL [Double packet - 2 codewords, 1234 places call to 5678]
3589 5678 8205 1234 [Spectra "CALL"]
3589 5678 8015 1234 [Maxtrac "SC", Astro Saber "CALL"]
* CALL ALERT ACKNOWLEDGE [Double packet - 2 codewords, 5678 acks the call from 1234]
3589 1234 A000 5678
* SIMPLE STATUS [unit 1234 transmits status number X]
460X 1234
* SMART STATUS
Undetermined
* EXTERNAL SENSOR STATUS
Undetermined
* STATUS ACKNOWLEDGE
2300 1234
* STATUS REQUEST [i.e. unit 5678 report your last status]
2206 5678
* STATUS RESPONSE [from target 5678 when interrogated]
060X 5678
* INBOUND MESSAGE
470X 1234 [ack expected]
070X 1234 [ack not expected CDM1550]
* INBOUND MESSAGE ACKNOWLEDGE
2300 1234
* REMOTE MONITOR [No MDC response from target unless it has PTT ID]
118A 5678 [118A per KA6SQG]
* SELECTIVE RADIO INHIBIT [Fixed end inhibits target 5678]
2B00 5678
* SELECTIVE RADIO INHIBIT ACKNOWLEDGE [5678 acks the inhibit]
0B00 5678
* SELECTIVE RADIO INHIBIT CANCEL [Fixed end enables target 5678]
2B0C 5678
* SELECTIVE RADIO INHIBIT CANCEL [5678 acks the enable]
0B0C 5678
* REQUEST TO TALK [Unit 1234 asks fixed end for permission to PTT]
4001 1234 [CDM1550 dedicated button]
4101 1234 [CDM1550 slaved to mic PTT]
* REQUEST TO TALK ACKNOWLEDGE
2300 1234 [general ack - not same as permission to PTT]
* REQUEST TO TALK GRANT [Permission to PTT]
Undetermined [Feature is a Gold Elite Option]
Also, can anyone tell me what kind of software one uses to actually demodulate the received data? I would like to try playing with this stuff as well, but don't know where to get started in terms of extracting the raw binary from the audio. If anyone knows please email me at sscheinfe@aol.com.
)so is it finished?
William Hayes
Inland Empire, CA
In Loving Memory; We miss you DAD!
http://iaff935.org/index.cfm?section=8&pagenum=264
Inland Empire, CA
In Loving Memory; We miss you DAD!
http://iaff935.org/index.cfm?section=8&pagenum=264
Is it finished?
I've been too busy on another software project for the last few months, but I hope to put in a bit of time to improve the software modem a bit, add the capability to decode two-part messages, and add a translation table.
For anyone working on their own... I'm having fairly good success with a noncoherent zero-crossing based MSK demodulator. The two things that make it work better than the basic implementation are: 1) using the research work that shows what the most likely received bit was for other zero-crossing counts than the expected ones and 2) running two demodulators in quadrature and taking the output of the first one that gets a CRC match. The packets are short enough that coherent demodulation performs no better than the quadrature approach, and there's more than enough CPU, even on a PIC microcontroller, to run two.
For anyone working on their own... I'm having fairly good success with a noncoherent zero-crossing based MSK demodulator. The two things that make it work better than the basic implementation are: 1) using the research work that shows what the most likely received bit was for other zero-crossing counts than the expected ones and 2) running two demodulators in quadrature and taking the output of the first one that gets a CRC match. The packets are short enough that coherent demodulation performs no better than the quadrature approach, and there's more than enough CPU, even on a PIC microcontroller, to run two.
demodulation -
I would really really like to attempt to do some MDC decoding, but I am getting stuck at the demodulation phase (i.e. step 1). I would REALLY appreciate it if someone here could give me a clue as to how to demodulate the FSK (or MSK, as it were), perhaps via modem or other hardware...once I have the raw binary, I can proceed on my own, but I am missing that crucial step that those of you who have been working on it have apparently had little problem with.
PLEASE, I would VERY MUCH appreciate just some idea of where to look. I would prefer not having to attempt the nightmare and co$t of demodulating it via expensive DSP software, nor do I have the energy to sit for a year studying VB DSP coding (another nightmare, even as a relatively fluent VB "speaker").
PLEASE, Any help would be GREATLY APPRECIATED
-sscheinfe@aol.com
a.k.a. KC2AUF[/b]
PLEASE, I would VERY MUCH appreciate just some idea of where to look. I would prefer not having to attempt the nightmare and co$t of demodulating it via expensive DSP software, nor do I have the energy to sit for a year studying VB DSP coding (another nightmare, even as a relatively fluent VB "speaker").
PLEASE, Any help would be GREATLY APPRECIATED
-sscheinfe@aol.com
a.k.a. KC2AUF[/b]
If you're not up for investing the time to write the code to use a PC sound card as a modem, you might look into the MX429A 1200/2400 baud MSK Modem chip from MX*COM, Inc.
The really lazy man's way is to let someone else do the hard part - just buy a decoder from CSI, Cimmaron, or Midian. Otherwise - on the cheap - watch for a Motorola desktop MDC console B1666 or B1667. They have been sold at hamfests and on ebay for anywhere from $5 to $50
The really lazy man's way is to let someone else do the hard part - just buy a decoder from CSI, Cimmaron, or Midian. Otherwise - on the cheap - watch for a Motorola desktop MDC console B1666 or B1667. They have been sold at hamfests and on ebay for anywhere from $5 to $50
We are are using MDC-compatible hardware in our digital signalling products.
PM me a valid shipping address to send you a radio modem board w' 9-pin RS-232 interface.
Let me know if this is OK, or you need another kind of interface.
Get some discriminator audio and off you go... (you can also transmit, if this is also desirable)
Paul SV2US
PM me a valid shipping address to send you a radio modem board w' 9-pin RS-232 interface.
Let me know if this is OK, or you need another kind of interface.
Get some discriminator audio and off you go... (you can also transmit, if this is also desirable)
Paul SV2US
There are 10 kind of people: Those who understand binary and those who don't.
Re
Im sorry, was that message for me, Paul? Please let me know at sscheinfe@aol.com, if you can...thanks, 73
Hi, I was able to get reasonably good data using just the simple 741 data slicer. Perhaps you can give it a try, as it is very cheap.
If you refer to the schematic diagram of any Motorola MDC-capable radio, a simple op-amp data-slicer is all you need for MDC decoding. You can try to make a similar one. The rest is up to the decoding and calculation power of the processor, which is really an interesting part
. Good luck!
If you refer to the schematic diagram of any Motorola MDC-capable radio, a simple op-amp data-slicer is all you need for MDC decoding. You can try to make a similar one. The rest is up to the decoding and calculation power of the processor, which is really an interesting part
. Good luck!Love is in the air...
-
Flatbush97
- Posts: 87
- Joined: Tue Sep 04, 2001 4:00 pm
source code
As I've posted in a new thread, so it is easier to find:
http://www.matthew.at/mdc/
Source code for my 1200 BPS MSK encoder and decoder which appear to be compatible in format with MDC1200. GPL license, so free to use in any software that also complies with the GPL and has freely distributed source code. If you want to incorporate the source code into a closed-source or non-GPL project, contact me.
http://www.matthew.at/mdc/
Source code for my 1200 BPS MSK encoder and decoder which appear to be compatible in format with MDC1200. GPL license, so free to use in any software that also complies with the GPL and has freely distributed source code. If you want to incorporate the source code into a closed-source or non-GPL project, contact me.
Re: MDC decoding - info and info request
Does anyone on here have a manual for the Motorola B1666A MDC1200 Console? I recently purchased 5 of them at a hamfest and I need connector pinouts and jumper settings. I would greatly appreciate anything you can provide. Thanks.
Dan
Dan
Re: MDC decoding - info and info request
Hello All,
I know it is a very old post.. But I could not find any other place to discuss my issue.
I have been trying to work on MDC1200 Decoding for some time.. i have already gone through the MDC 1200 Protocol available on batlabs and the discussion going on here.
I have used software based Demodulation with 1200 baud.. for freq 1200 and 1800 Mhz.. from my audio samples.
I have got the sync bits and the 5 Header bits of 0x07 0x09 0x2A 0x44 0x6F... but data after that is not correct... i took 112 bits after the header and interleaved them to get my bytes..
I have interleaved the data in 16x7 matrix..
I have many audio samples for same ID.. but after header.. none of the data matches...
could anyone help me please.
or Has a new MDC Protocol has come into place after MDC1200 due to which i am not able to get the data correctly??
regards
deepak madan
I know it is a very old post.. But I could not find any other place to discuss my issue.
I have been trying to work on MDC1200 Decoding for some time.. i have already gone through the MDC 1200 Protocol available on batlabs and the discussion going on here.
I have used software based Demodulation with 1200 baud.. for freq 1200 and 1800 Mhz.. from my audio samples.
I have got the sync bits and the 5 Header bits of 0x07 0x09 0x2A 0x44 0x6F... but data after that is not correct... i took 112 bits after the header and interleaved them to get my bytes..
I have interleaved the data in 16x7 matrix..
I have many audio samples for same ID.. but after header.. none of the data matches...
could anyone help me please.
or Has a new MDC Protocol has come into place after MDC1200 due to which i am not able to get the data correctly??
regards
deepak madan
Re: MDC decoding - info and info request
Deepak,
MDC1200 is still the standard for analog signaling, so I don't think you're missing anything there.
MDC1200 is still the standard for analog signaling, so I don't think you're missing anything there.
Re: MDC decoding - info and info request
d119,
i guess i am having issue with demodulation.. it is probably getting sync out after 5-6 bytes... so a single bit error is causing whole interleaved data to come about wrong.
do you have any codes for demodulation??
or can i have the data after 07 09 2A 44 6F ??? for PTT Pre ID: 1234 and 1111... without interleaving
presently i am getting data for PTT Pre ID : 1234 as below:
07 09 2A 44 6F (8E 94 2A 2E 06 82 E2 C2 00 0E 0C 51 16 44)
Data after 5 bytes header has not been interleaved.. it is written just after the demodulation.
in most of the samples.. 8E 94 2A are coming at the beginning..
i have the Radio with me.. so i can make any number of samples with any ID.. can you assist me how to go about this.. ??
i guess i am having issue with demodulation.. it is probably getting sync out after 5-6 bytes... so a single bit error is causing whole interleaved data to come about wrong.
do you have any codes for demodulation??
or can i have the data after 07 09 2A 44 6F ??? for PTT Pre ID: 1234 and 1111... without interleaving
presently i am getting data for PTT Pre ID : 1234 as below:
07 09 2A 44 6F (8E 94 2A 2E 06 82 E2 C2 00 0E 0C 51 16 44)
Data after 5 bytes header has not been interleaved.. it is written just after the demodulation.
in most of the samples.. 8E 94 2A are coming at the beginning..
i have the Radio with me.. so i can make any number of samples with any ID.. can you assist me how to go about this.. ??
Re: MDC decoding - info and info request
I don't have anything useful to contribute, I was merely indicating that you aren't wasting your time, as MDC1200 is still the common analog signaling protocol.