Page 1 of 3 123 LastLast
Results 1 to 25 of 66

Thread: Exploring the Quantar V.24 modem interface

  1. #1
    Astro Spectra's Avatar
    Astro Spectra is offline T S - Moderator
    CS Forums $upporter
    Join Date
    Nov 22, 2012
    Posts
    836
    Thanks
    285
    Thanked 508 Times in 261 Posts
    Country: Great Britain

    Default Exploring the Quantar V.24 modem interface

    In this thread https://communications.support/threa...5-mode-Over-IP the discussion started heading off topic to discuss the interface used on the Quantar station to link them to infrastructure (such a DIU or AstroTAC) or, in the specific case of the post, linking two machines.

    The intriguing possibility exists of linking more than two Quantar stations together by pretending to each individual station that it is talking to just one other machine. As in the previous thread the idea is that each Quantar would be equipped with an IP interface emulating the V.24 modem circuit and, perhaps via a central server, packets received from one Quantar would be sent to all other similarly connected Quantars, a concept a bit like 'TRBO IP site connect.

    The Quantar’s V.24 modem interface can be either an actual V.24/RS-232 sync electrical interface implemented by attaching a TTN4010 Quantar V.24 daughter card to the station’s wireline board or by a modem that implements a 9,600 bps synchronous link over a four wire leased circuit. The V.24 boards are quite rare and the modems aren’t that much more common.

    This aim of this thread is to document the hardware and protocols of the Quantar V.24 modem interface present on J300 of the wireline board.

    The protocol used is known as high level data link (HDLC), a rather dated means to transfer data in a synchronous manner without start/stop bits. Unlike normal V.24/RS-232 serial comms information is sent synchronously, there are no start and stop bits. This makes the interface incompatible with almost every serial interface in use today. So some DIY is in order.

    An open Sorce HDLC stack is available:
    http://sourceforge.net/projects/opensourcehdlc/

    I've started with an old HP J2302 protocol analyzer to look at the Quantar interface.


    Wireline Board (CLN6955 used as reference) J300 interafce

    The 50 pin V.24 interface J300 is located towards the main card edge connector. Pin 1 is marked with a small arrow on the silk screen; pin 2 is the next pin across with pin 3 the next pin down. The locations of pins 49 and 50 are wrong on the wireline board parts locator diagrams in my version of the manual (68P81088E90-E).

    The Quantar is the DTE here and the signals are all TTL level on this connector:

    Pin 36 RXD1 to Quantar, pulled to +5 via 10k
    Pin 45 TXD1 from Quantar
    Pin 34 RDCLK1 to Quantar, pulled to +5 via 10k
    Pin 43 TDCLK1 to/from Quantar
    Pin 42 CTS1 to Quantar, pulled to +5 via 10k
    Pin 41 RTS1 from Quantar
    Pin 31 CD1 to Quantar, pulled to +5 via 10k

    Pin 33 SQ1 = high means Quantar is providing the clock on P43 (DTE timed TX), low means Quantar is expecting a clock (external TX timing) on P43, pulled to +5 via 10k

    Pins 1, 2, 49, 50 ground (there are other ground pins).
    Pins 44, 46, are +5V

    More when I have the chance to document proceedings. Any already known information welcome.
    Last edited by Number 6; Jul 23, 2016 at 08:56 AM. Reason: updated internal links


  2. #2
    Join Date
    May 12, 2012
    Posts
    530
    Thanks
    895
    Thanked 302 Times in 165 Posts

    Default

    Keep us posted, very interesting thread!!!

  3. #3
    Join Date
    Jun 08, 2012
    Location
    Old Continent
    Posts
    144
    Thanks
    267
    Thanked 30 Times in 16 Posts
    Country: Switzerland

    Default

    Any progress on this? Terrific subject!

  4. #4
    ev351 No Longer Registered

    Default

    Hmm, It would be interesting if it was possible to do something along the lines of the following:
    Buffer the data being sent from one quantar to the other, then have it sent accross a more doable link, like the internet, and then have it fed into the machine at the other end in a timely fashion, even it if it meant say generating a dummy clock at the other end. I mean, it would matter if overs were delayed a bit on the second quantar for most people especially hobbyists... Im sure im in the realm of fantasy, but it would be nice....

  5. #5
    Astro Spectra's Avatar
    Astro Spectra is offline T S - Moderator
    CS Forums $upporter
    Join Date
    Nov 22, 2012
    Posts
    836
    Thanks
    285
    Thanked 508 Times in 261 Posts
    Country: Great Britain

    Default

    OK to recap I'd previously stated that the trick for networking multiple Quantars together is to first lean down the HDLC traffic before sending over IP as UDP so you're not wasting bandwidth just keeping the link up necessary for linking over the Internet.

    Turns out Motorola has already thought of that as the Quantar sends short keep-alive packets over the V.24 Astro interface every three seconds or so when connected. These packets are HDLC Supervisory Frames (S-frames) or Unnumbered frames (U-frames) in the form of a short strings like 'fd 01 be d2' or 'fd 3f 43 0a' which in HDLC means Receive Ready (RR) or Set Asynchronous Balanced Mode (SABM). Translated these strings are:

    fd 01 be d2 =

    Address = 253, Frame Type = 0x01 (RR), Poll/Final = 0 (Poll), N(r) = 0, FCS = 0xbe-d2

    and

    fd 3f 43 0a =

    Address = 253, Frame Type = 0x3f (SABM), Poll/Final = 0 (Poll), FCS = 0x43-0a


    This first two bytes being the address and frame type, the last two the checksum, and no payload (information field in HDLC speak). There are variations, but this will do for the moment. Note that the address 253 is not related to the station ID or to the ID of the remote partner station or DIU.

    Note when talking here about HDLC we're omitting the layer one 7E flags and bit stuffing. See Wikipedia if you want to know more about HDLC here:

    http://en.wikipedia.org/wiki/High-Le...a_Link_Control


    Now investigating conventional P25 framed speech, it turns out that the Quantar sends unnumbered information frames (UI-frames) containing an information payload with the encoded voice. These frames vary between 18 and 34 bytes, a sample frame is:

    07 03 60 02 04 0c 0b 1b 51 1a 37 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 3a
    5d bf

    Which in HDLC speak is:

    Address = 007, Frame Type = 0x03 (UI), Poll/Final = 0 (Poll), FCS = 0x5bd-bf

    In this frame the sample payload is the 30 bytes 60 02 …. 00 3A. As before, the first two bytes being the address and frame type, the last two the checksum.


    So for simple repeater to repeater Quantar linking over IP all that is theoretically needed is to take these UI-frames and send them as User Datagram Protocol (UDP) over the Internet and then copy them directly back into UI-frames for sending to the Quantar over he V.24 interface. When the 'link' is idle each end will need to generate the appropriate keep-alive RR or SABM frames. For more inforamtion on UDP see:

    http://en.wikipedia.org/wiki/User_Datagram_Protocol


    So far this is the easy stuff. Now the next task is to understand the payload content of the UI frames. I am hoping it is directly related to the P25 standard CAI HDU/LDU/TDU structure.

    Why try to understand the payload? Well if we can understand the payload then a number of Quantars could be arranged to direct UDP packets to a central server that emulates a single DIU or Quantar and replicates the CAI HDU/LDU/TDU frames and reflects them back in the form of the Quantar UI-frames carried over UDP to each connected Quantar. With this arrangement each Quantar would think it was talking to just one other Quantar via the standard Quantar RT/RT configuration and would receive traffic from any other Quantar in the network. I'm dubbing this idea QuantiPHY™
    Last edited by Magnus; Jan 15, 2013 at 09:37 PM.

  6. #6
    Join Date
    May 12, 2012
    Posts
    530
    Thanks
    895
    Thanked 302 Times in 165 Posts

    Default

    Awesome,,,, keep up the work, wish I had a quantar that was not in service to play with! Good Job!
    Radio Referenced...Those who think they know it all are very annoying to those of use who do.

  7. #7
    ev351 No Longer Registered

    Default

    I think that you should definately patent the name... I like it. But i like where you are heading with this even more.. Nice work.

  8. #8
    Astro Spectra's Avatar
    Astro Spectra is offline T S - Moderator
    CS Forums $upporter
    Join Date
    Nov 22, 2012
    Posts
    836
    Thanks
    285
    Thanked 508 Times in 261 Posts
    Country: Great Britain

    Default

    Previously I mentioned that there are variations to the RR/SABM keep alive messages and that the address 253 is not related to the Quantar station (RT) or DIU ID. I’ll expand on this for clarity.

    When a station first starts it sends SABM frames until a response is received from the other end of the HDLC link (remember in this RT/RT or RT/DIU case these are point-to-point link connections). When the partner receives the message it responds with a single Unnumbered Acknowledgment (UA) and similarly the first station then confirms with a UA, all basic HDLC stuff. The address for this exchange is still 253.

    Next Exchange Identification (XID) frames are exchanged; these frames contain information fields as follows for an RT to DIU example:

    fd bf 01 05 c2 00 00 00 00 ff 93 30 =

    Address = 253, Frame Type = 0xbf (XID), Poll/Final = 0 (Poll), FCS = 0x93-30

    Info = 01 05 c2 00 00 00 00 ff


    The payload appears to be a message as follows: Message type 1, (station site number ID * 2) + 1, station type (Quantar = C2). The test Quantar was site 2 in this example. FF might indicate the end of the message string.

    Then in the DIU to RT direction:

    0b bf 01 1b 00 00 00 00 00 ff e6 69 =

    Address = 011, Frame Type = 0xbf (XID), Poll/Final = 0 (Poll), FCS = 0xe6-69

    Info field = 01 1b 00 00 00 00 00 ff


    Looks good since the DIU defaults to an ID 13 then (2 * 13) + 1 = 1b in hex and we’ll call station type 00 as infrastructure for the moment.

    Notice that for the first time in the set-up exchange we see an HDLC address that’s not 253.

    In the earlier post the RT ID was 1 and it used the HDLC address of 007 when it had something to say, in the examples in this post the RT was set to site number 2 and the HDLC address is 011. From other examples captured it appears the RT uses an HDLC address for XID and UI frames of (site number * 4) + 3. The DIU read the RT address 5 from the XID frame, calculated the site ID and then used that to calculate an HDLC address for the reply.

    Following the SABM, UA, and XID exchanges the stations then continue to send the previously mentioned RR messages as a keep alives. If the Quantar doesn’t receive a RR message after about 5 seconds it reverts to sending SABM messages, similarly for the DIU but with a longer timeout.


    Now I’m still working on the more interesting UI frames that carry the P25 traffic and relating them the to TIA standard.

    The first UI frame payload is always 10 bytes (from now on we’ll ignore the address and FCS bytes), typically:

    00 02 04 0c 0b 00 00 00 00 00

    The second UI payload contains the following:

    60 02 04 0c 0b 1b 57 1a 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 0a


    The third UI payload looks like this:

    61 00 01 17 14 2a 10 33 31 00 39 2a 22 04 23 12 11 0a 00 03 0c 02


    While the subsequent UI payloads look like this:

    62 02 04 0c 0b 1b 5a 1a 2e 80 04 0c fd 7b fb 7d f2 7b 3d 9e 44 02
    63 04 0c fd 7b fb 7d f2 7b 3d 9e 45 00 7a
    64 00 00 00 00 04 0c fd 7b fb 7d f2 7b 3d 9e 44 02
    65 00 00 01 00 04 0c fd 7b fb 7d f2 7b 3d 9e 45 02
    66 00 00 50 00 8c ce 59 0b d9 b2 00 0b 19 de 7c 02
    67 b7 4a af 00 80 da 89 bd 23 5b 80 08 2d d7 bb 46
    68 c4 68 30 00 18 e1 ac 6c 5d 80 05 1d 56 14 08 02
    69 68 cf a5 00 9c ca 8e 92 d8 b5 00 0d 45 c9 85 02
    6a 82 88 06 b8 a6 b0 b3 c5 d8 00 06 a9 27 b8 00
    6b 02 04 0c 0b 1b 58 1a 30 98 6c a5 3b 33 ef 8f 00 0a c9 c9 37 0a
    6c a8 d5 24 68 ee 65 00 08 11 1a f0 02 32
    6d 00 00 00 00 b4 a6 f0 27 4e 88 00 08 8d 2c 07 02
    6e 00 00 00 00 98 dc 2b 59 8a 59 80 0b 7d 03 a6 02
    6f 00 00 00 00 a0 c5 99 9c b4 06 80 0b 31 9e 6f 02
    70 80 00 00 00 98 ad 83 80 d9 bf 80 09 ec af 54 02
    71 ac b8 a4 00 98 b1 59 7d 1b e2 00 09 51 61 e5 02
    72 9b dc 75 00 a8 f4 51 b3 08 28 80 04 92 ce 58 02
    73 f1 70 06 90 a3 df 19 fd 19 00 08 d5 b2 65 00


    After the 73 record the cycle repeats from 62 to 73 again for as a valid signal is on the repeater input. In the above examples the NAC is 293 and the RID is 80.
    Last edited by Magnus; Jan 15, 2013 at 09:36 PM.

  9. #9
    Join Date
    Apr 09, 2012
    Location
    Australia
    Posts
    910
    Thanks
    255
    Thanked 634 Times in 240 Posts
    Country: Australia

    Default

    Hi Astro Spectra,

    I had a chance to look through the captures that you emailed and the IMBE voice vectors seem to stand out quite well. For example, the silence frames that start and end each P25 transmission appear in the right places:-

    The IMBE vocoder breaks voice up into 20ms slices and encodes them into digital format. Each 20 millisecond frame consists of 88 bits of data when there is no Forward Error Correction applied. With FEC (as is applied before going over the air) each vector becomes 144 bits. Here is the code for a single 20 millisecond slice of silence that:-

    static uint8_t silence[] = {
    0x04, 0x0c, 0xfd, 0x7b, 0xfb, 0x7d, 0xf2, 0x7b, 0x3d, 0x9e, 0x45
    };


    You can see this pattern appears in the stream above, this represents a 20 millisecond chunk. From the research done in the OP25 project, we know from practice that transmissions in P25 start with *at least* 4 silence frames. This is evident in UI's 62, 63, 64 and 65. This at least tells us that the V.24 transport is NOT using any error correction on these frames and that they are sent in raw form. Now that we can see where the voice frames go, OP25 can be used to line up where each voice frame is in each UI so we have an understand of the structure.

    The fact that it repeats between 62 to 73 lines up with the fact that each P25 superframe (ie LDU1 + LDU2) contains 18 voice vectors (ie 0x73-0x62 = decimal 18)

    I think the best way to transport this traffic is to encapsulate each UI into a single UDP packet, pad it out and fire it off...

    Time to get the hardware rolling eh
    Last edited by MattSR; Feb 19, 2013 at 11:33 PM.

  10. #10
    Astro Spectra's Avatar
    Astro Spectra is offline T S - Moderator
    CS Forums $upporter
    Join Date
    Nov 22, 2012
    Posts
    836
    Thanks
    285
    Thanked 508 Times in 261 Posts
    Country: Great Britain

    Default

    Hi Matt,

    Almost exactly, here is where I was upto (click for a closer view) when you posted:

    working hypothesis 1.png

    You can see I'd marked the alternating 04 0c fd 7b fb 7d f2 7b 3d 9e 44 and 04 0c fd 7b fb 7d f2 7b 3d 9e 45 (with he last byte alternating to eliminate DAC bias?).

    I'm thinking the Astro V.24 is a kind of Moto XML that broadly follows (actually proceeds to be historically accurate) the TIA standard.

    Last edited by Astro Spectra; Jan 14, 2013 at 04:42 AM.

  11. #11
    Astro Spectra's Avatar
    Astro Spectra is offline T S - Moderator
    CS Forums $upporter
    Join Date
    Nov 22, 2012
    Posts
    836
    Thanks
    285
    Thanked 508 Times in 261 Posts
    Country: Great Britain

    Default

    Oh and the hardware has arrived (I bought two, click for a close-up):

    uCEval_full.jpg

    STM32F107 microcontroller with 256k FLASH and 64k ram, Ethernet, SD card, USB OTG, RS-232 (to bring the RSS port back from the remote site), and prototyping area (Quantar Astro V.24 or TTL to 3V buffer). The STM32 series have full HDLC controllers on board more here:

    http://www.st.com/internet/mcu/product/221020.jsp

    It's complete overkill for this job really but it's hard these days to find a MCU with an HDLC controller built-in.
    Last edited by Astro Spectra; Jan 13, 2013 at 11:37 PM.

  12. #12
    Join Date
    Apr 09, 2012
    Location
    Australia
    Posts
    910
    Thanks
    255
    Thanked 634 Times in 240 Posts
    Country: Australia

    Default

    Can you capture a transmission when you just "bounce" the PTT on your radio?

    I discovered that this will transmit a single LDU1 packet that consists totally of silence frames. That will at least confirm the structure for the LDU1.

    Cheers,
    Matt

  13. #13
    Join Date
    May 12, 2012
    Posts
    530
    Thanks
    895
    Thanked 302 Times in 165 Posts

    Default

    This is Awesome! Dumb question will this allow direct connection to the Quantar without v.24 boards. The v.24 boards are hard to find these days?
    Radio Referenced...Those who think they know it all are very annoying to those of use who do.

  14. #14
    Join Date
    Apr 09, 2012
    Location
    Australia
    Posts
    910
    Thanks
    255
    Thanked 634 Times in 240 Posts
    Country: Australia

    Default

    Correct. The controller above could easily interface directly to the Wireline card, eliminating the need for the (rare) V.24 daughterboard. The V.24 daughterboard really doesn't have much on it anyway, a few line drivers and other bits and pieces and a pair of RJ45's.

  15. #15
    Astro Spectra's Avatar
    Astro Spectra is offline T S - Moderator
    CS Forums $upporter
    Join Date
    Nov 22, 2012
    Posts
    836
    Thanks
    285
    Thanked 508 Times in 261 Posts
    Country: Great Britain

    Default

    Yes Matt's right. You can actually 'network' two co-located Quantars right now using the pin connections in the first post here and Mar's proven hook-up here: https://www.p25.ca/threads/1491-Link...3226#post13226 this is what's called the RT/RT configuration.

    You can safely connect at TTL using shielded cable no more than 3' (1 metre) long. Cat-6E cable will be fine and you can use a right angle box header to connect to J300 (solder carefully and heat shrink each wire to avoid shorts):

    box hdr.png

    I couldn't find a right angle 50 way RA header so I used a straight one and soldered a strip of pad-per-hole protoboard to the back of it and just soldered my cable to that. For this testing work I'm using an outboard TTL to V.24/RS-232 level shifter, something anyone can bud on a bit of perf board. You do need to check the height above J300 to avoid shorts to the card cage divider with whatever solution you use.

    This project will avoid the Astro V.24 board as it is just too hard to get these days by connecting at TTL. The intention is to fit the adaptor board on to the WL card and power it form the +5VDC avaialble on J300.
    Last edited by Astro Spectra; Jan 14, 2013 at 03:43 AM.

  16. #16
    Astro Spectra's Avatar
    Astro Spectra is offline T S - Moderator
    CS Forums $upporter
    Join Date
    Nov 22, 2012
    Posts
    836
    Thanks
    285
    Thanked 508 Times in 261 Posts
    Country: Great Britain

    Default

    @MattSR, as requested @#12 a single PTT ping, one ping only Vasili:

    00 02 04 0c 0b 00 00 00 00 00
    60 02 04 0c 0b 1b 62 1a 26 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 3a
    61 00 01 17 14 2a 10 33 31 00 39 2a 22 04 23 12 11 0a 00 03 0c 02
    62 02 04 0c 0b 1b 63 1a 25 80 04 0c fd 7b fb 7d f2 7b 3d 9e 44 02
    63 04 0c fd 7b fb 7d f2 7b 3d 9e 45 04 7a
    64 00 00 00 00 04 0c fd 7b fb 7d f2 7b 3d 9e 44 02
    65 00 00 01 00 04 0c fd 7b fb 7d f2 7b 3d 9e 45 02
    66 00 00 50 00 04 0c fd 7b fb 7d f2 7b 3d 9e 44 06
    67 b7 4a af 00 04 0c fd 7b fb 7d f2 7b 3d 9e 45 02
    68 c4 68 30 00 04 0c fd 7b fb 7d f2 7b 3d 9e 44 02
    69 68 cf a5 00 04 0c fd 7b fb 7d f2 7b 3d 9e 45 06
    6a 82 88 06 04 0c fd 7b fb 7d f2 7b 3d 9e 44 00
    00 02 04 25 0b 00 00 00 00 00
    03 00 02 04 25 0b 00 00 00 00 00


    So as I hypothesized and you predicted 62 to 6a = LDU 1...

    Last edited by Magnus; Jan 15, 2013 at 09:34 PM.

  17. #17
    Join Date
    Apr 09, 2012
    Location
    Australia
    Posts
    910
    Thanks
    255
    Thanked 634 Times in 240 Posts
    Country: Australia

    Default

    Excellent, its nice when things work as expected. I know Astro Spectra can see this, but just for the sake of clarity for those that are using this thread to learn more, I have highlighted the 88 bit IMBE voice codewords here:- (9 of them per LDU as per the standard)

    62 02 04 0c 0b 1b 63 1a 25 80 04 0c fd 7b fb 7d f2 7b 3d 9e 44 02
    63 04 0c fd 7b fb 7d f2 7b 3d 9e 45 04 7a
    64 00 00 00 00 04 0c fd 7b fb 7d f2 7b 3d 9e 44 02
    65 00 00 01 00 04 0c fd 7b fb 7d f2 7b 3d 9e 45 02
    66 00 00 50 00 04 0c fd 7b fb 7d f2 7b 3d 9e 44 06
    67 b7 4a af 00 04 0c fd 7b fb 7d f2 7b 3d 9e 45 02
    68 c4 68 30 00 04 0c fd 7b fb 7d f2 7b 3d 9e 44 02
    69 68 cf a5 00 04 0c fd 7b fb 7d f2 7b 3d 9e 45 06
    6a 82 88 06 04 0c fd 7b fb 7d f2 7b 3d 9e 44 00

    I double checked the specs, and the least significant bit of the Voice codeword is actually used for synchronisation, it alternates between 0 and 1 on each codeword, including ones with actual voice traffic. Ref Page 36 of TIA 102.BABA (P25 standards)

  18. #18
    Join Date
    May 12, 2012
    Posts
    530
    Thanks
    895
    Thanked 302 Times in 165 Posts

    Default

    Cool! so 44=1000100 and 45=1000101
    Radio Referenced...Those who think they know it all are very annoying to those of use who do.

  19. #19
    Join Date
    Apr 09, 2012
    Location
    Australia
    Posts
    910
    Thanks
    255
    Thanked 634 Times in 240 Posts
    Country: Australia

    Default

    Yeah correct, Its most evident in the silence frames because they are consistent, however if you look at the voice traffic posted earlier, the same pattern is there:-

    62 02 04 0c 0b 1b 5a 1a 2e 80 04 0c fd 7b fb 7d f2 7b 3d 9e 44 02
    63 04 0c fd 7b fb 7d f2 7b 3d 9e 45 00 7a
    64 00 00 00 00 04 0c fd 7b fb 7d f2 7b 3d 9e 44 02
    65 00 00 01 00 04 0c fd 7b fb 7d f2 7b 3d 9e 45 02
    66 00 00 50 00 8c ce 59 0b d9 b2 00 0b 19 de 7c 02
    67 b7 4a af 00 80 da 89 bd 23 5b 80 08 2d d7 bb 46
    68 c4 68 30 00 18 e1 ac 6c 5d 80 05 1d 56 14 08 02
    69 68 cf a5 00 9c ca 8e 92 d8 b5 00 0d 45 c9 85 02
    6a 82 88 06 b8 a6 b0 b3 c5 d8 00 06 a9 27 b8 00

    The first 4 codewords here are silence with the usual 44/45 pattern. If we take the least significant byte of the all of the codewords including the last 5, the least significant bit still alternates between 0 and 1

    44 - 01000100
    45 - 01000101
    44 - 01000100
    45 - 01000101
    7c - 01111100
    bb - 10111011
    08 - 00001000
    85 - 10000101
    b8 - 10111000

    Cheers,
    Matt


  20. #20
    Astro Spectra's Avatar
    Astro Spectra is offline T S - Moderator
    CS Forums $upporter
    Join Date
    Nov 22, 2012
    Posts
    836
    Thanks
    285
    Thanked 508 Times in 261 Posts
    Country: Great Britain

    Default

    Moving forward to resolve a few more missing pieces of the puzzle we need to find the basics such as RID and TGID. Previous testing had the RID as 80 decimal or 50 (hex). More tests were done with a RID of 5921370. Why this number? Well that’s 5A5A5A in hex and so easy to spot in the dumps here. As before the IMBE voice is in red and we'll use blue for the RID:

    00 02 04 0c 0b 00 00 00 00 00
    60 02 04 0c 0b 1b 5a 1a 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 3a
    61 00 01 17 14 2a 10 33 31 00 39 2a 22 04 23 12 11 0a 00 03 0c 02


    62 02 04 0c 0b 1b 5b 1a 2d 80
    04 0c fd 7b fb 7d f2 7b 3d 9e 44 02
    63
    04 0c fd 7b fb 7d f2 7b 3d 9e 45 00 7a
    64 00 00 00 00
    04 0c fd 7b fb 7d f2 7b 3d 9e 44 02
    65 00 00 01 00
    04 0c fd 7b fb 7d f2 7b 3d 9e 45 02
    66
    5a 5a 5a 00 04 0c fd 7b fb 7d f2 7b 3d 9e 44 02
    67 b5 75 2d 00
    04 0c fd 7b fb 7d f2 7b 3d 9e 45 02
    68 45 62 ec 00
    04 0c fd 7b fb 7d f2 7b 3d 9e 44 02
    69 5d 1e d4 00 0
    4 0c fd 7b fb 7d f2 7b 3d 9e 45 02
    6a 82 88 06
    04 0c fd 7b fb 7d f2 7b 3d 9e 44 00

    6b 02 04 0c 0b 1b 5a 1a 2e bc
    04 0c fd 7b fb 7d f2 7b 3d 9e 45 02
    6c
    04 0c fd 7b fb 7d f2 7b 3d 9e 44 00 7a
    6d 00 00 00 00
    04 0c fd 7b fb 7d f2 7b 3d 9e 45 02
    6e 00 00 00 00
    04 0c fd 7b fb 7d f2 7b 3d 9e 44 02
    6f 00 00 00 00
    04 0c fd 7b fb 7d f2 7b 3d 9e 45 02
    70 80 00 00 00
    04 0c fd 7b fb 7d f2 7b 3d 9e 44 02
    71 ac b8 a4 00
    04 0c fd 7b fb 7d f2 7b 3d 9e 45 02
    72 9b dc 75 00
    04 0c fd 7b fb 7d f2 7b 3d 9e 44 02
    73 f1 70 06 04
    0c fd 7b fb 7d f2 7b 3d 9e 45 00

    00 02 04 25 0b 00 00 00 00 00
    00 02 04 25 0b 00 00 00 00 00

    If you have been following along so far you note that in the RID location previously was 00 00 50 in record 66 which was the RID of the original test radio.


    Going forward it would be tedious to look at these blocks of hex, so I'll only show records that are different. To recap records 62 to 6a are derived from LUD 1 and 6b to 73 from LDU 2. Next up the P25 conventional talk group ID, this was set to 43690 or AAAA in hex and it showed up in record 65 coded pink:

    65 00 aa aa 00 04 0c fd 7b fb 7d f2 7b 3d 9e 45 02



    Next we go secure. The first 00 record remains the same as does the last two 00 records. We can ignore the red enrypted IMBE voice frames. The encrypted records are below the unencrypted equivalent. The differences are in yellow:

    60 02 04 0c 0b 1b 5b 1a 2d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 00 0a 3a
    60 02 04 0c 0b 1b
    60 1a 28 0a 03 05 2b 1e 35 32 01 00 14 32 14 00 00 08 10 00 00 00 0f 3a

    61 2a 2a 23 2a 18 17 01 12 00 00 0f 19 05 02 0c 1e 2f 00 0c 30 02
    61
    3f 3f 2e 08 3d 29 05 37 00 34 0c 15 38 25 39 12 16 00 01 0f 02

    62 02 04 0c 0b 1b 5b 1a 2d 80
    04 0c fd 7b fb 7d f2 7b 3d 9e 44 02
    62 02 04 0c 0b 1b
    60 1a 28 80 59 74 6d 95 14 cc 55 5b d8 7a 74 02

    The structure of record 63 is unchanged (nothing other than encrypted voice frame)


    64 00 00 00 00 04 0c fd 7b fb 7d f2 7b 3d 9e 44 02
    64 00 00 40 00 1e 7a f1 c0 ed 5e 2f 21 71 81 3a 02


    The structure of The structure of record 65 and 66 are unchanged (RID is still plaintext).

    67 da 47 87 00 04 0c fd 7b fb 7d f2 7b 3d 9e 45 02
    67
    30 10 d5 00 80 9d a4 ad 41 a4 39 93 12 cf fb 02

    68 d4 50 c1 00
    04 0c fd 7b fb 7d f2 7b 3d 9e 44 02
    68
    08 4a c3 00 6e 09 8e a9 0c 9e 4c 05 c0 4b d5 02

    69 0b bf d4 00
    04 0c fd 7b fb 7d f2 7b 3d 9e 45 02
    69
    a7 6d 7d 00 43 fa a3 bc 39 3d bf 4a 22 2a e9 02
    6a 82 88 06 04 0c fd 7b fb 7d f2 7b 3d 9e 44 00
    6a 52 e4 0e b7 0d ea 93 0d e5 55 3b 98 b6 5f 00



    What we know is the ALGID here is x84 and it would have been x80 in the clear records. So still some work needed.

    Last edited by Astro Spectra; Jan 15, 2013 at 09:21 PM. Reason: Changed text color to default and changed font

  21. #21
    Join Date
    Nov 22, 2012
    Posts
    101
    Thanks
    16
    Thanked 49 Times in 27 Posts
    Country: United States

    Default

    Thanks for your efforts with this. I've been meaning to do some playing around with the Quantar's V.24 interface myself, but never really had the time...

    If anyone is working on something to send this V.24 traffic over IP, I'd like to point out the P25 standard for the Fixed Station Interface that was released in the last few years: TIA 102.BAHA. It would be great if there was an external IP interface for the Quantar that would support this standard, where practical. This way, if someone had some console equipment, gateway/patch, or base station from another manufacturer that complied with 102.BAHA, it would have a chance at being able to work with a Quantar in some fashion, without double vocoding.

  22. #22
    Join Date
    Apr 09, 2012
    Location
    Australia
    Posts
    910
    Thanks
    255
    Thanked 634 Times in 240 Posts
    Country: Australia

    Default

    Excellent point tbiggums, I have checked that document and guess what - page 54 of TIA 102.BAHA looks very similar to what Astro Spectra has posted above.

    Of course there are extra metrics and things added in, and it might not compare with exactly but we continue looking and investigating!

    Cheers,
    Matt

  23. #23
    Join Date
    Dec 12, 2011
    Location
    Avalon
    Posts
    1,211
    Thanks
    299
    Thanked 332 Times in 161 Posts
    Country: United States

    Default

    Guys, this is a project I'm following closely. Nice work.

    @Astro Spectra when you change your text colors, and are going back to black/white depending on your theme, pick Automatic instead of a color. I can tell you must use the VB dark theme, because your text has been showing up a white on my white background with the vb Blue theme.

  24. #24
    Astro Spectra's Avatar
    Astro Spectra is offline T S - Moderator
    CS Forums $upporter
    Join Date
    Nov 22, 2012
    Posts
    836
    Thanks
    285
    Thanked 508 Times in 261 Posts
    Country: Great Britain

    Default

    Hi Magnus, I see what you're saying in setting white when I do corrections - it will be automatic going forward. But what I can't understand is the fixed vs proportional fonts. On IE 9 this thread looks fine. On Firefox the hex dumps look a complete mess except where MattSR has copied and pasted. I was choosing Fixedsys font for the stuff I want as a fixed pitch font. While I think he is using Courier, any thoughts?

    P.S. I just went and changed the fonts to Courier New and that's fixed it on both browsers. @Magnus maybe you could change the font on the green hex block (just the multi-line block would be OK) in posts #8 and #16 please?
    Last edited by Astro Spectra; Jan 15, 2013 at 09:25 PM.

  25. #25
    Join Date
    Dec 21, 2011
    Posts
    4,545
    Thanks
    3,879
    Thanked 6,740 Times in 1,930 Posts
    Country: Canada

    Default

    @ Everyone

    Keep in your mind you can use the CODE tags (with [ and ] brackets) to keep formatting intact, even with colors.