Tuesday, January 5, 2016


Unlike D-Star and System Fusion which are relatively straightforward, DMR being a TDMA based system has raised some interesting challenges in its implementation. It is not that the transmitter at the repeater end (hereafter called a BS, that’s DMR spec speak) needs to quickly go from TX to RX and back again in less than one millisecond, that’s the domain of the user radio (MS in DMR spec speak). The BS TX stays on all the time, pumping out data continuously just like the other data modes mentioned.
The challenge is more subtle, and it concerns the receiver side of the BS. In fact there are two challenges, but they are related:
When the BS TX is off, the MS TX will send wake up messages. Unlike D-Star and System Fusion, all MS TX messages have no bit synchronisation, they just start transmitting their data immediately and embed a nice synchronisation pattern in the middle of their 27.5 millisecond transmission, which is good of them. Therefore the challenge is to find this pattern without much warning, and do so accurately. I had one solution, the problem is it the Due ran too slowly to be usable, oops. My second solution meant that I stored 27.5 ms worth of undecoded data and looked for the synchronisation pattern in the middle of it. I then went back to the beginning of the buffer and decoded all of it. It seems to work too. That is what I call the DMRIdleRX as it’s only used when the BS TX is off and the modem is in the idle mode. This means that it is listening for all data modes simultaneously.
Once the transmitter is on, all transmissions from the MSs (two slots, up to two MSs) are going to be contained within a 28.5 ms window, and not all of them will contain any form of synchronisation pattern either. The trick is now one of accurate timing, of the receiver knowing where it is relative to the transmitter and that is the problem. I use queues between the protocol engines (DMR in this case) and the bit that actually puts the data out to the electronics and onto the radios. These queues (implemented as ring buffers) can have more or less data in them depending on the speed of the protocol engine. Hopefully on transmit they don’t run out of data as that would cause the transmitter to go silent, and on receive it’s big enough to handle the delays in later processing. Therefore the synchronisation between what is being transmitted and being received has to established, however it won’t be a simple time delay of so many microseconds, it could be variable.
My answer was to have a separate set of queues parallel to the ones mentioned above, that are the same length, and contain synchronisation information. Every time a sample is transmitted, it is taken from its queue and sent out, and a receive sample is read and put into another queue at the same time. My synchronisation queues go through the same process, although the data doesn’t appear to the outside world, so that the synchronisation data has the same delay as the combination of the transmitted and received samples. That way I can establish an accurate timing mark, it doesn’t matter where it is, as long as it is completely consistent. The job of finding the incoming transmission is a simplified version of that used for the DMRIdleRX above, but with a more restricted range. When there is no synchronisation pattern then the timing information is used to work out where the signal is, luckily a frame with synchronisation data is received every six frames so it can’t drift too far.
Did you notice a sleight of hand above? I mentioned 27.5 ms and then 28.5 ms. This is because a DMR transmission is 27.5 ms in length, but can be up to one millisecond late before being ignored, giving an overall window of 28.5 ms to receive it. This extra one millisecond is made up of any inaccuracy in the MS, and propagation delay. Assuming the MS is accurate, then it would all be propagation delay, so what does that mean? Radio waves travel at the speed of light in free space, about 300,000 kms/s. That’s 300 kms in one millisecond. This delay affects the transmission from the BS to the MS as well as the MS to the BS, so in order for the one millisecond limit to be reached, the MS can only be 150 kms away from the BS. I am sure most BS implementations allow a bit more than that, but ultimately there is a limit somewhere in the BS. It is for this reason that GSM mobile phones also have a range limit even though the base station is still audible. DX operating via DMR is going to be a limited pastime.

No comments:

Post a Comment