Module17 and OpenRTX Modifications (Part 2)

As promised here is part 2 of my blog concerning OpenRTX and the Module17 board. I have for now moved onto M17 itself. First I added Meta text to outgoing voice transmissions. Meta text is similar to D-STAR slow-speed text in that it is visible to the receiver on their radio display. D-STAR is limited to about 21 characters where as M17 allows up to 52. Having the capability of transmitting such long messages left me with the problem of how to show it on displays with a width limit of about 20 characters depending on font size. My solutions was to create a function to slowly scroll the text from right to left wrapping back to the right if needed. This works fairly well so long as the message is received in tact otherwise the text jumps around a bit. This is known as meta text because it is part of the LSF frame in M17 protocol. An LSF frame is the first frame in all M17 transmissions and in addition to meta text it contains the transmission type, and source and destination call-signs. It can also contain source and destination reflectors if used. The meta text field and can also be used for GPS data and others.

The second thing I did was add Packet data mode. The normal mode used on M17 is Streaming Mode used for voice calls. Packet mode allows for transmission of up to 821 bytes per super-frame and continuous transmission of data. The first byte of every transmission is used to indicate what the payload is. In this case it is 0x05 indicating that the following 821 bytes is an SMS message. SMS is similar to mobile phone messaging and allows sending up to 820 characters per message. The source call-sign indicates the sender and the destination call-sign the recipient. The text of the message is followed with a NULL byte and a 16 bit checksum. OpenRTX for the most part did not handle Packet mode, functions had to be added and some modified. Specifically I had to add packet decode and encode functions. This was relatively easy has they were just variations of the stream decode/encode functions. The more difficult part was modifying the demodulator to handle both stream and packet frames. There are four parts to an M17 transmission, the preamble, LSF, payload and end of transmission (EOT). There can be many payload frames per transmission. These can be either voice or packet frames. The LSF, voice, packet and EOT are identified by a unique sync burst pattern. The original demodulation function only looked for voice frames. One would think you would look for the LSF first as it is the first frame in a transmission and contains important data about the following frames. However, voice frames actually contain pieces of the LSF and with enough voice frames you can rebuild the whole LSF. So even though the demode function was only looking for the voice frames it could still build the rest of transmission data with in a few milliseconds. Packet data, however, does not contain LSF data so it was necessary for the me to look for the LSF first then the packet or voice frames. This presented a problem because for whatever reason the radio would not always see the LSF frame and since I was using that frame to start the receive process missing it meant missing the whole transmission. This lead me to looking for both the LSF or a voice frame to start the process. This helped with voice transmissions but not packet. This problem seems to be RF related as my Module17 setup using a Motorola mobile would see the LSF at least 95% of the time but my hacked TYT MD380 was more like 70% of the time. I couldn't really figure out a way around this problem so I move on to decoding and storing the SMS messages. I used the checksum to verify that I have received a valid message otherwise it is rejected. Once validated it is stored in a queue along with the source call-sign. I limit the number of messages to 10 because most radios have limited memory. If the queue is full when a new message is received the oldest message is purged to make room. Also, back to back duplicate messages are rejected. When there are messages in the queue I display an envelope icon in the upper left part of the display.

I added a user interface screen (UI) to manage and view the messages. You can scroll through each message seeing the senders call-sign. You may also delete the currently viewed message. For the transmit side the UI allows you enter the message in normal hunt and peck mode or using a method called T9 which attempts to guess the word you are typing to speed up entry. Pressing send will encode and transmit the message. The send function uses the default destination call-sign as the recipient.

That's it for this section. Next I will discuss the creation of the Module17 Host software used to enable D-STAR and P25 transmissions.

73's

Rick KD0OSS