RFC 202302061040: Communication Between Systems

[dhaussecker]

Abstract

We need to come to a conclusion about a communication method for our systems to talk to each other. There are multiple serial communication methods that could be utilized: Some popular ones that always come up are I2C, SPI, and CAN. What's best and what should we choose?

Stakeholder(s)

Avionics Propulsion Aerostructure Systems

Problem(s)

We need to decide on a communication protocol to be used across systems in the rocket

Solution(s)

a) I2C Requires one specific device to be the master. Lines: 2 lines [SCK and SCL] Speed: 100kbps

b) SPI Requires one specific device to be the master Lines: 4 lines [MISO, MOSI, SCK, CS], Must add extra CS for each additional sensor Speed: up to 10Mbps

c) CAN In CAN each node can behave as Master or Slave. Has a device/message priority system. Lines: 2 Lines[TX and RX] Speed: up to 1 Mbit/s

d) Other Communication Methods (Ethernet, Fiber Optic, USB, UART)

• Make a proposal if you can think of any other options

Looking for feedback!

Difficulties and Risks

a) Need to decide what method will be best for us

b) I2C is not at all the way to go for long distances. CAN transceivers or RS485 used with normal UART is a robust solution. I2C is designed to be used in-PCB so max distance shouldn't exceed 50 cm. SPI's maximum distance is about 10m. CAN's max distance is about 1km

c) SPI wiring gets more complex for each new sensor you add in as each sensor requires one new wire, wire I2C and SPI don't.

d) SPI can't acknowledge that data has been successfully received (I2C and CAN have this)

c) Multiple student rockets are using CANbus for their systems, making it seem like a good way to go, but I don't want to just jump into it without other input.

Estimated cost(s) and timeline(s)

This system would be integrated in all board and software designs throughout this year.

Proof of Concept

Check references for Uwaterloo's CANbus architecture

Testing and Robustness Assurance(s)

Looking for feedback!

Reference(s)

https://drive.google.com/open?id=169TVnTIVYmfNrPiK4FvcD331LEPFN7fr&disco=AAAAm5xzJQI

[frroossst]

We have I2C and SPI sensors, how would we convert them to the CAN protocol? Are there sensors that are CAN compatible already which we can use? How complex is the process of converting from (I2C, SPI) to CAN.

Before making the decision, we should convert the basic groupings of sensor, (BMP280, KX134, FRAM) and use them over CAN with the Teensy as a proof of concept.

If CAN turns out to be expensive in terms of time, energy and code to implement, could we feasibly use CAN for sensors that require long distance communication and I2C for others?

[dhaussecker]

This discussion mainly revolves around communications between systems, and by between systems, I mean between our boards. Note, this does note include communications within each board.

All the sensors mentioned above will still use I2C or SPI, weather to use I2C or SPI within the board should come down to what is deemed the most critical, and could be a further discussion (SPI is faster than I2C). CAN-bus would only be used to communicate from board to board using a CAN transceiver hooked up to the microcontroller on the board.

See the photo of the proposed gps board as an example as it has the proposed CAN-transceiver:

[frroossst]

So, if I understand this correctly, then CAN would be used for let's say communicating between the microcontroller on the GPS board, the microcontroller on the RF board, and let's say the main microcontroller? Wouldn't this mean that a microcontroller is required on every individual/ modular board we add to the mix? Does this no unnecessarily raise the complexity of the system? Why add one more serial communication interface? (except maybe the distance issue with I2C and SPI)

[dhaussecker]

This is a 10 foot tall rocket we are talking about. There is going to be a need for some boards to be closer to one side of the rocket than the other.

Also it does not complicate the problem in my opinion, it simplifies it. All systems are now on their own individual board. It would be a nightmare if you had to redo a whole entire board when all you needed is to add one extra part. Also, one microcontroller for everything is not feasible for the amount of wires that would have to be running to it for every single sensor. Serial communication just simplifies the problem by allowing that data to be transferred over 2 wires instead of let’s say 100. A single microcontroller controlling every single subsystem would very quickly become an issue

[frroossst]

I think the different board and communication arguments make sense. I think the modularity would be a huge boon in the long term, it also allows some boards to be asynchronous if we have a datalogger board that just listens to I2C signals on a line then it wouldn't be "blocking" the main flight computer and doing this with other boards would also free up the main loop() and make it faster, just a few clarifying questions though, would we standardise what microcontrollers are used across different baords or would that be left to the board designers? I think it should be left to board designers, for example the GPS board would definitely need hardware float support, whereas the FRAM board doesn't necessarily need as powerful a computer on it's module board. Also, are we concerned about the delay that is added by introducing a microcontroller in the middle?

Current: main micro-controller -> sensor Planned: main micro-controller -> modular micro controller -> sensor

[dhaussecker]

I am not concerned with any sort of delays, sensors go to their mcu on the board then straight to CAN, that’s actually going to make things faster than using 1 mcu for everything. Mcu type would will likely be standardized (for example we will be testing out STM32’s) but particular mcu part numbers could be modified for certain applications.

[frroossst]

I only mention the slowdown because if you were building a self-driving card having a central powerful gpu is more faster and efficient than having multiple gpus process at the sensors before they reach the main micro-controller. Are we concerned about the costs? For some applications the standard mcu might be overkill and not worth the cost? Is there an actual difference in the amount of money these different mcus cost?

[dhaussecker]

Our standard mcu is only $5, so I’m not concerned about the cost (other options could range between $1-$20. We not planning to design the fastest system on the planet so there is no need to optimize the system to be as fast as possible, although I see no risk in slowing down speeds anyways.

[frroossst]

If that's the case then, I don't see any problems at least now, that might arise from this implementation.