Live Telemetry was designed as an uplink-downlink system using the LoRa protocol at 915MHz. It is a SRAD PCB with a central microcontroller, CAN transceiver, USB-C connection, 3.3V LDO, and SX1276 LoRa transceiver. Its purpose is to take data from various sensors on the CAN bus and transmit it to the ground-station unit, where it will be parsed and displayed on its own flask website. Additionally, a 915MHz center band circularly polarized Yagi antenna was designed to be used in conjunction with the ground-station unit.
The goal with this design was to have a robust telemetry system that could maintain connection up until apogee at 12km. Unfortunately, poor testing and rushed development meant that the ground-station unit was not prepared in time, and the air unit had a poor Tx path. The substitute was to modify the Tx path, and replace the ground unit with the FeatherM0, which already had code for it. This increased the range from 2m to $\approx$200m. This is clearly not enough for our expected apogee, but it shows that utilizing RF tuning instruments could potentially improve the range to the predicted range.
This project was attempted first in 2024, but it was cut short early in the design. From this however, we already had a decent problem definition. We wanted an ultra high frequency radio board to communicate telemetry during flight, and the protocol of choice was LoRa, as it uses the robust modulation method of chirp spread spectrum. The previous year had struggled on what IC to use for its LoRa transceiver, and ultimately they decided on a transceiver that was embedded in an STM32. We felt this was a poor decision, as documentation was very sparse on the transceiver in this chip, so after some deliberation we decided on using an external LoRa IC, which ended up being the SX1276. We also chose the STM32L452CE as our controller of choice, as it had an integrated CAN controller. This paired with an external transceiver allowed for CAN communication between boards. Lastly, this was designed with the SRAD Power Distribution system in mind, so it’s primary power connection is simply a two pin 3.3 V in, although we prepared for the worst and added an LDO to step our 3.7 V LiPo’s in the event that Power Dist didn’t end up working.
We had learned from programming the FeatherM0, and so we had the idea to have a simple packet→ack system for transmission. Each packet would be a fixed length, with metadata at fixed locations. Each reception would be accompanied by a acknowledgement transmission, and upon successfully ACK reception the packet would be discarded on the air unit and the next packet would be prepared for Tx. How we achieved simple packet loading was by storing fata sent through CAN in a large ring buffer, and loading the most recent data into our packet whenever an ACK signal has been detected. Utilizing a fixed length packet meant we didn’t need to manually clear any data, and generally simplified the process.
We decided on a 4 layer design, utilizing a reserved ground and power layer as our 2nd and 3rd layer respectively. All board programming was done through ST-Link, and the communication protocol used by the SX1276 was SPI. The Tx and Rx paths were separated with an RF switch, which was controlled automatically by the SX1276. External oscillators were utilized, but unfortunately they did not work very well, only enough to operate the SX1276 without error. This was during our triangular bay with panels era, and so it has M3 mounting holes.
We had purchased the empty board, solder stencil, and parts online. We then utilized a combination of homemade reflow over and heat gun to attach all the parts to the board. Unfortunately this opened the door for many problems. One notable problem was hovering pins on our microcontroller, which was fortunately spotted on both boards, but only seemed to resolve all issues on one of them. This is the point where we had abandoned the one board as it just seemed to not want to work and diagnosis was seeming like a dead end. For the future I would hope we get our boards assembled, as this seems to avoid many of the problems we faced.
Testing was sparse until we left for Launch Canada. Testing involved sending and receiving data from our board and the Feather M0. Unfortunately, we had tested this by plugging both boards into the same computer, which means we didn’t notice how poor the range was until much later. Upon discovering our range issue, we had attempted to remedy the problem by altering the Tx path of our SRAD board, but this only improved the 2m RSSI from $\approx$-120 to $\approx$-80, which is still quite poor.
For the future, much more time should be spent testing, ESPECIALLY on boards with SRAD RF paths. We should utilize network analyzers and high sample rate Oscilloscopes, and potentially add test points along our RF chain. This system might be obsolete soon as we try to shift to IoT on 5.8GHz, but the potential for fixing and reintegrating is there if anyone so chooses.