home > resume > mwgp > serial
about::resumé::elysian::projects::personal::contact
About MWGP
Research
People
Responsibilities
Serial Networking
Microcontroller
Interface Board
Post-RF Amp
Thermal Control
Digital Upgrade
FPGA Programming
Integration
Power
Photos
TMRS-3: Radiometers
TMRS-3: In-Field
U of F: C-band
MWGP Website
Official University Site

Serial Networking Specification

One of the first tasks to implementing the microcontroller for a radiometer was to determine which tasks were the responsibility of the microcontroller, and which were for the master computer. It was important for the microcontroller to be self-sustaining in the event of a crashed master computer or a power loss. Furthermore, the system had to support multiple radiometers and multiple microcontrollers. Everything had to interoperate with some type of network

After determining which tasks were to be given to the microcontroller, a communications protocol and system had to be determined. An RS-485 two-wire serial bus was chosen for its noise immunity and presence in all of our hardware. RS-485 allows data to be sent over two wires in both direction with multiple devices on the line. It uses differential signaling, giving it a high immunity to noise. It is easy to install, fault tolerant, and the Z-world microcontrollers have RS485 transceivers built in.

In order to use the RS-485 bus, a serial protocol needs to have a standard command structure so that devices can talk to each other. Because there will be over six RS-485 based microcontrollers on the line, it was important to reduce the possibility of jabber caused by multiple devices talking at once. Therefore, the serial protocol is a master-slave based system, where no device talks unless the master computer gives it a command it can reply to. In order to enforce this, devices are given a numerical address and the destination and source address prefixes all serial messages.

The final communications protocol uses ASCII plain-text over RS-485. It is similar to the original DSDR specification. However, because of the different functions, it needs new commands. Each command is formatted in a specific way and has a return message. The send and return formats are shown below, with an example of the "VER?" command.

Send Format:
prefix command [parameters] suffix
STX$89$12VER? CR LF ETX
Return Format:
prefix command datetime [parameters] chksum suffix
STX$89$12VER^10312002$0905$00$10$18ZZCR LF ETX

The first field, the prefix starts all transmissions. It includes a start transmission character (STX = 0x02), and the source and destination address, delimited by a dollar sign ($). The next field is the command which tells the microcontroller what to do with the message. Commands are either instructions ending with a '!' or queries ending with a '?'. The return message command ends with a '^' so as to not confuse any other devices in the event of an error.

The datetime field is one of two fields unique to the return message. It is a time stamp of when the microcontroller sent the message back to the host, with the time local to the microcontroller. This way, any clock skew can be detected and corrected for. The format (again separated by '$') is month/day/year/hour/minute/second in the format mmddyyyy$hhmm$ss$.

The parameter field is optional and depends on if the command requires any additional information or returns any information. Its use is determined per command but if there are multiple values, they are separated by '$'.

The checksum field is currently not being used actively, instead the value 'ZZ' is always transmitted. At some future time, a checksum could be added. The suffix signifies the end of transmission. The ETX character is used by the serial receiver to separate messages and clear the buffer.

The serial protocol has been named RadiCL for Radiometer Control Language. The current RadiCL specification is document 088-0021.