The first real Turbo Dispatch jobs were sent at the end of 1995. Green Flag and Delta Rescue were the first to get involved. Back then, all communication was done using the Mobitex radio network, except for the clubs who used X25.
Customers who were out of radio coverage had to make do with a dial-up service for a number of years. An Internet gateway (IAS) was later added, and the dial-up service was dropped. X25 is still in use, but is not the default choice any more.
The diagram above is a typical Turbo Dispatch configuration as used by the Recovery operators.
Incoming messages are dropped into a folder on the hard disk, called "Inbox" (or GPSData for gps messages). Messages that are to be sent, are dropped into the "Outbox".
Turbo Dispatch has been a huge success, and changed the UK recovery industry forever. Long gone are the days when jobs were written down on scraps of paper over the phone. There is an article on Wikipedia about how it was formed.
It hasn't been without it's problems, and below is list of things developers should know when devloping or maintaining Turbo Dispatch applications. If you use our free .NET connector, then it will take care of some of these issues for you.
Turbo Dispatch – things a developer should know.
512 character limit
When the Turbo Dispatch protocol was being drafted, little thought was given to the packet size limitation, and thus was not designed to be as compact as it should have been. The specification requires a minimum of 7 characters to describe each field, followed by a minimum of 8 characters at the end of each message (which is arguably redundant). A further 2 extra characters per field are also wasted if CRLF characters are used at the end of each field (see Gotcha's below).
The specification also fails to specify how you send more than 512 characters of data. This is typically done by sending another packet, repeating the message type field (9100) and the Job number (1004), a further ~30 characters. Some clubs also insist on an agent number in each message, that pushes the overhead up further still.
Since jobs were having to be split into multiple messages, the order in which they were arriving was invariably not the same order as they were being sent. The mobitex network does not guarantee the order of packets. The DOS Garage Manager at the time would only handle one message at a time, and if the bulk of the job information wasn't received in the first packet, the operator would have to accept or reject a job based on only what they could see. The solution was to introduce a ~2 second time delay in sending each message, and send the most important information in the first message. The operator would still only get part of the information, but it was at least more relevant.
The Windows version of Garage Manager would later fix this by merging all the information together as it came in, regardless of order. However even today, the time delay is still in use.
The jobs are more compact now, but at one time, jobs would be sent in 7 or more packets, with 2-3 second intervals. The operator would have to wait 20 or so seconds to get the full message.
These days, with the internet, keeping computer clocks accurate is not a problem. But back then, the time and date was set by hand. Computer's internal clocks usually drift a lot, even on modern hardware, so it was not uncommon for ETA times being calculated wrongly. In 2004, additional time-lapsed fields were added.
The Turbo Dispatch standard fails to standardise on one co-ordinate format. Arguments between the clubs led to them all being supported, which led to various client software problems. The Turbo Dispatch client software tried to solve this, by converting the co-ordinates into one WGS84 decimal latitude and longitude format (field 1213). However, this would often push the message sizes over the 512 character limit causing messages to fail! Operators that use Night Controller have to enable an option that drops all co-ordinates that are not sent using the 1213 field, thus loosing this information from some clubs.
Carriage return, line feed
The specification does not specify how new lines (carriage returns) are handled (inside and outside) of the field data. The sample messages in the specification show each field to be on a separate line. Developers wrongly assume that this is required, but its a waste of 2 characters per line. There seems to be an unwritten rule that the ^ character is used as a new-line symbol inside of the field data, but this is not always the case.
Never use them in field data.
The original version of Turbo Dispatch had what are now dubbed “Magic Numbers”. A single digit number, at the beginning of every inbox message. These were to aid DOS Garage Manager in determining what to do with each message. They still exist today.
“Psub numbers” are virtual mobitex identification numbers (MAN numbers) independent of the hardware, or access point your connecting to. If a message is sent to a Psub number, a reply message may come from the physical number of the connection. Applications have to specifically send messages out of the correct number. This can confuse the sending party.