Digital X-Ray

Signal Transmission


We have created a guide to using all the software that we have set up.

Because the nature of our project was to create a demonstration of the x-ray communication technology, we wanted an interface that easily allows people to send and receive data via RS232. We considered using proprietary software, but eventually decided to program this interface from the ground up, because we needed the ability to easily debug the signal, and have precision control over what the computer was sending. We tried to start with the simplest transmission we could get, and incrementally increase the complexity of the transmissions, squishing bugs when we came to them one at a time, as opposed to shooting directly for a lofty goal and trying to debug everything at once. Thus, we created...

Custom digital communication

Modern digital communication protocols can be quite complex because data is easily lost—out of the billions of bits that are sent, it is likely that some will be read incorrectly, which creates the need for elaborate error control and complicated handshaking. These digital protocols, while making the connection between computers more robust, can impede our ability to control and understand the signals at the bit-level.

In order to have complete control over the signals we transmit, we created a simple digital communication protocol by programming two microcontrollers to talk to each other without any error control. We used three wires to connect them, which we refer to as:

  • High
  • Low
  • Confirm

This protocol was unidirectional. A single bit was sent in 5 stages.

  1. Microcontroller A raises voltage on the high pin
  2. Microcontroller B sees that this voltage has been raised, and responds by raising the confirm pin.
  3. A sees the confirm pin has been raised, and responds by lowering the high pin
  4. B sees that the voltage has been lowered once again, and responds by lowering the confirm pin.
  5. A sees that the confirm pin has been lowered, and thus decides it is safe to send another bit (repeat from beginning)

The same process can be used to send a low bit. The high and low bits correspond to 1s and 0s. It functions irrespective of speed of transmission. Even if a single signal takes ten years to reach microcontoller B, microcontroller A will wait for the confirmation signal before it proceeds. In this way, we insure that the signal can survive being sent x-ray transmission, because we are unsure of the signal delay we will have

Serial UART signal between microcontrollers

We used the built in UART in the microcontrollers we were using to send serial data to another microcontroller. This was extremely easy to set up due to the Arduino microcontroller libraries. We simply hooked the transmit pin of one microcontroller to the receive pin of another and were able to send bytes of data at a specified baud rate using the Serial.write() and functions. This approach was used as a proof of concept: we could transmit data (in the RS232 protocol) via a microcontroller.

RS232 signal between microcontroller and computer

It was slightly more difficult on the hardware side to achieve a connection between the microcontroller and the computer, because the output voltages of the microcontroller were not within the RS232 range and had to be inverted and amplified with a MAX232 chip before fed into the computer.

It was also more difficult on the software side. We knew that the microcontroller could send a signal, but we didn't know how to receive it on the computer. Because RS232 is a protocol established in 1962, it is deeply rooted in Unix. The settings for transmissions between computers running a Unix based system were originally controlled using the stty command. The computer must know what baud rate to use, which characters indicate the end of a line or a file, etc. and in order to communicate with another computer, these settings must match up. We established base settings to always use on our devices. In addition, we used a Unix shell to receive data from the microcontroller by running cat /dev/ttyS0, which output the characters coming in to the serial port to the shell display.

RS232 signal from one computer, back to itself

In order to insure that the computer could send a signal, we tested it by connecting the transmit/receive pins. We then ran echo A > /dev/ttyS0 while simultaneously listening in with cat /dev/ttyS0.

RS232 signal from one computer to another

We insured that all the settings were the same with stty and then ran echo A > /dev/ttyS0 while running cat /dev/ttyS0 in another.

Chat client between computers

We wrote a short bash script to automate the communication between to computers. It automatically insured the settings were the same, then started listening to the other computer while allowing the user to input text to be sent.

Part of this script would take a users input, and direct it to the serial port stream, like so read input; echo "${input}" > /dev/ttyUSB0

Remote Terminal

We used getty on the host computer (running as an upstart service) as the server. We then connected, via RS232 from another computer running minicom. Some challenges in connecting included:

  • Configuring getty correctly
  • Running getty continuously as an upstart service
  • Configuring minicom to match the getty

By connecting via a remote terminal, we had full control over one computer via a unix Shell in another computer, all running through RS232.

File Transfer

File transfer proved easy because minicom directly interfaces with common file transfer protocols. We used the ZMODEM protocol to transfer files from one computer to another through the minicom remote terminal.

File transfer speeds were fast enough to transfer an image, but too slow to transfer a 70 MB file within a reasonable amount of time (it would take a day).