RPi Interface Rev C

Owned by Daniel Puratich
Last updated: 2024-09-27
4 min read

Introduction

  • Inspiration

  • Who

    • Notes

      • Given in order of involvement with project

      • Credits here include only hardware design credits, firmware and integration credits given elsewhere

      • Higher priority names here will be drawn on the silk of the PCBA

      • just being assigned to the project is not enough to be given credit

    • People

      • @Daniel Puratich schematic capture, power supplies and architecture, PCB layout, most component selection including symbols & footprints

      • @Anthony Luo digital device selection, IOC verification, firmware & software lead

      • @Anthony Lazar adding various components and a few calculations

      • @Meghan Dang CAN circuit components initially added for ESC CAN Adapter

      • @Nathan Green architectural reviewer

      • @Sahil Kale architectural reviewer

  • Where

  • Timeline

    • Desired for Competition in 2025 so ideally boards are fully assembled by end of Fall 2024.

    • Hardware design will be completed before midterms for midterm PCBA order in F24 term.

      • @Daniel Puratich is intend on fighting to make this happen and is encouraging anyone to help by breaking this down into green comments for subtasks in the schematic (if viewing in the future please see the version history in Altium 365 for how I did this).

  • Features we aren’t adding but considered

    • no ELRS

      • ELRS changes a lot quickly

      • could be saved for a future revision

      • can be done via a simple connector to any COTS module

    • no cameras

      • mounting a camera makes placement complicated

  • Features

    • Begin from RPI Interface Rev B

      • Keep the UART “killswitch” and one UART passthrough for the RPi to FC direct

        • Being implemented in the stm though instead of the hardware switch

        • This is being done to avoid running out of UARTs on the STM and to avoid hardware complexity

        • UART forwarding can be done with DMA so it can be fast and not very resource intensive.

        • Justification for this as a feature is given in RPI Interface Rev B .

      • Keep UART LED indicators

        • this is nice for debugging

        • costs some board space

        • could be DNPed in a final version

      • Keep CAN circuit

        • this can be used to control the lighting system if we wanted to?

        • Could also connect to pixhawk for mavlink over CAN if we’re able to do the required firmware to make this solve.

    • Add LED features

      • Some neopixels on the board might be nice.

      • Leds on the pwr rails since I have space.

      • IR detector so we could use one of those cheap remotes to control LEDs.

    • Analog Monitoring

      • STM has some spare analog pins so might as well use them

      • temperature and voltage monitoring

    • Add an LTE modem to RPi interface rev c

      • relevant discord chat & here

      • quectel module he put

      • Quectel gets USB into the RPi and the STM. RPi eill be used initially and is drawn below because it requires less custom firmwqre, but using the stm long term seems nice.

      • Selected to get maximum mavlink datarate out of the Pixhawk

      • This is not intended to be able to stream data for “groundside compute” for autonomy processing as explained in Autonomy Compute Integration 2025.

    • Change buck converter to support 48V input so we can connect VBATT

      • this makes architecture decisions and harnessing easier

    • Switch STM32

      • STM take in the three uarts form quectel

      • The other STM is smaller and doesnt have enough UARTs for this

      • STM will communicate with the RPi over SPI

    • Increase board size a bit

      • this turns the board into a full normal RPi hat

      • This is required for cooling for the LTE module and a simple USB connection for the LTE hat

  • Why

    • Unlimited range & unlimited datarate is really attractive even if it comes at the cost of some weight and some power consumption.

    • Maintaining C2 link is required for flight so full reliance on ELRS is scary even if we have overwhelming evidence for it’s reliability

    • This board is an RPi hat because there is good COTS software support for the Quectel that runs on the RPi. The presence of the STM allows us to experiment with using the embedded proccessor but this will take a lot of time to bring up.

    • Eventually this board can be used as a standalone without the RPi to save weight. We want the Pi for airside compute now, but could be cool to try it in the future

    • The reason for the STM is that it’s real time and guaranteed run time and low power operation. See here.

    • Dual bucks is done because it’s hard to find ICs that do up to 7 A without external FETs & compensation. I want this to work right off the bat though in theory higher efficiency is achievable

  • Standards

Block Diagrams

All Possible Configurations:

Component Selection

Trivially selected components aren’t really mentioned here, but some of the more complex stuff is noted here.