SSUlt Project – 4th Entry
I am still debugging stuff here and there. While I am waiting better time to be able to share more about the capability of the SSUIt prototype, this post will go deeper into the technical details.
Fasten your seat belt, let’s go!
As I said, or as I should have said already, the purpose is to make our EVA more realistic in term of technology interaction while on the field. I thought that a small computer, some sensors and a screen would do the trick.
My choice for the computer, the Raspberry Pi, was arbitrary. Still the community is wide spread around the world and I knew that if I was stuck somewhere, I would be able to find a lot of resources to help me moving forward. But nowadays, there is a lot more small computers. And maybe another one would have been better than the Raspberry Pi v3 I am currently using.
Let’s review some of the RPi features.
The board has standard USB ports. It is good to plug mouse, keyboard, flashdrive etc. While, I never expected to use a mouse or a keyboard on the field, it is still handy for debugging back into the Hab.
It has a Display and Camera Serial Interface ports (DSI and CSI). The DSI was never meant to be used. But the CSI could have been used for a 5Mpx camera. That would have add a nice feature for in situ reporting with pictures.
It has HDMI port. We can plug in HD screens but also smaller ones like the one intended to carry on the arm.
It has General Purpose Input/Output (GPIO) that come as a 40 pins header. Some of the pins are dedicated to special buses:
- 2 pins for the I2C bus,
- 5 pins for the SPI bus and
- 2 pins for the UART serial bus.
These buses are very helpful to communicate with external devices, such as the sensors.
One drawback of the RPi is that it does not come with Analog Digital Converters (ADC). And there is not built-in several UART serial buses. That would have saved me the pain of adding another layer into my project…
Most of my sensors are communicating through the I2C bus. This bus is a half-duplex synchronous protocol for communication. The master (here is the RPi) is issuing a clock signal (1st wire) on which all the bits send or received must be synchronized (2nd wire). Many devices can be connected to this bus. Each sensor has a different 7-bits address so that when the master calls one, the others stay quiet. Most of the sensor have a factory set address, and cannot be changed. When you have two sensors with the same address (likely to happen if you need 2 or more same sensors on different places), as I did, you must find a way around. Which, in my case consisted in muting the clock wire that goes to the first sensor when I want to communicate with the second one and vice versa.
The GPS chip I found communicate through the UART serial bus. This bus is a full-duplex asynchronous protocol for communication. It is suited to connect 2 devices (only) with 2 wires. The first wire is used to send data from the 1st device to the 2nd one. The second wire is used to send data from the 2nd device to the 1st one. There is no master/slave relationship on this protocol, so that each device can communicate to the other one at any time. The drawback is that you cannot connect more than one device per bus. In my case I could have used one more since my radio ship communicate through the same bus. So I needed to find a way to add one UART bus.
And then I have the heartbeat sensor that is a one wire analogue signal. Without an ADC, it is not possible to exploit numerically the signal. Also the battery voltage is a good indicator to have while on EVA. That also requires an ADC converter (in addition of a voltage divider).
As I was learning programmable electronic for this project, I have also been in touch with the Arduino world. The Arduino Nano board comes with the same buses as the Raspberry Pi plus some pins for ADCs. So the ADC pins I was seeking for and the additional UART serial bus are available on this 1$ micro board. I just needed a way to communicate with it from the RPi.
The I2C bus will not be fast enough to transfer all the data, without taking into account that the RPI I2C bus is already very busy with the other sensors. Furthermore, programming the Arduino to be an I2C slave device (while it is commonly used as a master) is just a pain.
There is a USB port that is usually used for programming the board but can be used also as a serial interface for transferring data.
Instead I choose to go for the SPI bus which is full-duplex synchronous protocol. The master issue a clock signal (1st wire) on which all the bits send or received must be synchronized (2nd and 3rd wires). Since it is a full-duplex communication one wire serves to receive data from the slave by the master (called MISO: Master In, Slave Out) while the other wire serves to send data from the master to the slave (called MOSI: Master Out, Slave In). The other wires, 4th and so on, are used to control several peripherals on the same bus as an On/Off switch. Since the bus is totally controlled by the master (the RPI) the slave cannot send data whenever it wants. So any data that is collected by the slave (the Arduino Nano) must be stored into a buffer while waiting for the master to call in and authorize communication. Another difficulty is that the Arduino is not multitasking. It is either ADCing the signal or sending the data out. It needs to be sure that sampling the ADC pin will not have to occur during sending the data out.
Below find the schematic of the hardware architecture. The SPI line between the Arduino Nano and the Raspberry Pi is stroke because currently, the software is not ready for reading data on this bus (everything is wired though). Each part belong to the SSUIt prototype except for the battery that belongs to the backpack.
Next time I will present the software architecture.
Stay tuned!