Receiver

Receiver Module

The receiver module is comprised of two main components: an Arduino Uno microcontroller with an attached WiFi shield and a radio modem.


Data Transmission

The first step in the receiving process is the actual receiving of the data via the radio modem. The radio modem will automatically receive any serial data transmission from a transmitting radio modem on the same frequency. The receiver modem will relay this serial data via the provided RS-232 line out to the microcontroller. The Arduino microcontrollers used in this project use a Transistor-Transistor Logic (TTL) at the serial ports while the radio modem uses RS-232 serial communication. The incompatibility between the two stems from their operating voltage ranges. TTL operates from 0 volts to approximately +5 volts while RS-232 operates from -15 volts to +15 volts. To alleviate these differences in logic voltage levels, a TTL to RS-232 converter is used in between the two devices. This convertor will step down the voltages received from the RS-232 line on the radio modem so that the transmitted/received data can be passed to the microcontroller and be processed.

Packets

The term Packet in this project is used in a computer science sense. A packet is simply a group of bits that represent a set of information. Packets were chosen to transmit data from each shuttle because they provide a very fixed structure. This makes for easy transmission, re-transmission and processing. The packets for this project are made up of ten ASCII characters, which are easily transmitted via serial communication. All packets follow a fixed format: the first character of a packet is an exclamation point ‘!’; the next 4 characters make up the Shuttle ID and are numbers ‘0-9’; the following 4 characters make up the Checkpoint ID and are capital letters ‘A-Z’; the last character is a pound symbol ‘#’. A diagram of the anatomy of a packet is shown in Figure 5.

a packet
Figure 5: An example of a packet sent from shuttle 1 passing checkpoint C

This packet format was chosen for multiple reasons. The first bit, the start bit, allows our receiver to determine when to start “paying attention” to data. The reason that four of the same characters are used for each shuttle ID and checkpoint ID is to allow for transmission error correction. In our tests, using the radio modems to transmit serial data will occasionally result in a single or a few characters being incorrectly received. For example a packet that was transmitted as ‘!1111CCCC#’ might be received as !11h1CCCD#’. By having multiple ID values to compare against, our receiver can detect that the ‘h’ and the ‘D’ don’t belong in that packet, and correct the received packet to its initial value of ‘!1111CCCC#’.

The last bit, the stop bit, indicates to the received that it can now “stop paying attention” because all of our data has been transmitted. This packet design allows for future expansion as a packet is not made of 10 characters. Rather any number of characters can be used in between an exclamation mark and a pound symbol; e.g. ‘!this could also be a valid packet in future implementations#’.

ETA Calculation

The ETA is calculated by the receiver using three pieces of information: recently received data about the shuttle’s location, previously calculated ETA data, and a fixed table of average trip data. On the receiver, each shuttle has separately kept records. When the receiver obtains a new checkpoint packet, it updates the appropriate shuttle’s record. This record includes the last checkpoint passed, and the time it was passed. From this, the receiver can calculate how long it takes the shuttle to get from the previous checkpoint to the checkpoint it just passed.

Ideally, the checkpoint that the shuttle just passed is the next physical checkpoint on the route from the previous checkpoint passed. If the shuttle, for whatever reason, misses a checkpoint, the ETA calculation will be unaffected. An offset is obtained by comparing the average time it takes to get from the previous checkpoint to the current checkpoint. This offset is added to the average ETA from the current checkpoint to the end of the route, which produces the up-to-date ETA. The receiver uses the equation shown in Figure 6 each time an ETA is calculated.

eta calculation
Figure 6: ETA calculation formula

Once the ETA is calculated, the module uploads the ETA to the web server so that shuttle riders can check the wait time for the next shuttle on our provided ETA website. This entire process is repeated for each valid, received packet.

receiver flowchart
Figure 7: Campus Receiver Flowchart

Figure 7 explains the logic of the receiving module on campus. After successfully connecting to a Wi-Fi signal, the receiving module simply waits to receive a data packet from a transmission module on a given shuttle. It then checks to see if the packet begins with ‘!’. If it does, the program proceeds with checking the validity of the data packet. If the packet does not begin with ‘!’, it registers it as erroneous and waits for a new packet to arrive. If the packet is valid, it decodes the packet to obtain the following information: the shuttle the packet was sent from and the checkpoint the shuttle just left. From this, the receiving module calculates an ETA to update and post to the server.

Comments are closed.