The operator panel originally consisted of a single PCB, having a RS485 to TTL serial converter, a USB port for connecting with a host PC, and Phoenix Contact screw terminal headers for connecting our arming and e-stop inputs. After having issues with the USB connector on this PCB, we improvised an alternative. A USB TTL to RS485 serial converter was used for the main telemetry link with the control panel, and two other TTL to RS485 converters were used for the arming and e-stop inputs.

An Ethernet cable consists of 4 twisted pairs, each of which is capable of carrying an RS485 signal over a distance of up to 1000 meters. RS485 was chosen for the transmission length, and Ethernet cables were chosen due to having the twisted pairs required for long range RS485 transmission. One twisted pair carries the telemetry from control panel to operator panel, while another carries the arming signal, and another carries the e-stop signal. On the operator panel, the arming and e-stop signals are converted to a fixed logic-level voltage, and are used for hardware-enabling/disabling solenoid control.

We found out and/or decided later on in the design cycle, that it would be good to have a hardware ‘hot fire’ button, and so this was added by using an Arduino Nano, which reads the hot fire button’s state through a GPIO, and outputs either <HOT FIRE> or <RESET> over USB. This is then read by the ground station software running on the host machine, to determine whether or not to send the hot fire command to the control panel using the main telemetry link.

A major design flaw in the link between operator panel and control panel, is that the RS485 communication is half-duplex only, meaning that we cannot transmit and receive at the same time. This required that in firmware on the STM32, and software for the ground station, coordination was required; the ground station waits to receive from the STM32, where is then sends a command packet back. Command packets consist of new solenoid states, as well as the hot fire button’s state.

In the future, we should use wireless communication instead of a hard link. It appears that this is what most teams do, and it would enable us to send and receive much more, with less issues, than the current setup.