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 dimensions and placement draft, most component selection including symbols & footprints
Anthony Luo digital device selection, IOC verification, firmware & software lead
Kenny Na finalized placement and complete layout
Anthony Lazar adding various components and a few calculations
Meghan Dang CAN circuit components initially added for https://uwarg-docs.atlassian.net/wiki/spaces/EL/pages/2524119043/ESC+CAN+Adapter?search_id=f4b1fc6e-e7b0-40e2-b3b0-d59a4cfe139f&additional_analytics=queryHash---6d1bec809cddeb3bd829865f767aad016b21b36990406a7993e865185d7ea8a4
Nathan Green architectural reviewer
Sahil Kale architectural reviewer
Where
https://warg.365.altium.com/designs/AA237602-825E-4CD7-BE7B-1078E9369164#design
TODO: Add github link when done
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
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 https://uwarg-docs.atlassian.net/wiki/spaces/ARCHS22/pages/2669412363/Autonomy+Compute+Integration+2025?search_id=fe948f35-631d-416c-b4d9-095d8cab5e37.
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.
Digital IC Selection
EG915NEAAC-N05-SNNSA
Supports NA
Supports max mavlink datarate
no external camera features keeps cost down
~$30 bucks
Optional GPs port that is uses. Will use a u.fl connector and an onboard antenna we can choose between.
STM32F415RGT6
has USB FS support and a ton of UARTs
$18 is a lot but it’s the cheapest we gonna get
somewhat discussed in LTE Breakout
STM32 pinout given in Discord conversations
First Buck Stage Component Searching
Super glad there’s a lot of options in this voltage range, seems to be getting better with time as automotive bus voltages are rising.
Best from MPS
I kinda wanted to use MPS here, but doesnt seem like any of their stuff solves
Searching Digikey
I like these microchip and Vishay options, the analog devices ones are hella overpriced (as usual).
Microchip options are slightly cheaper and support higher input voltage so will let one of these ride.
Plenty in stock, super cheap, https://www.digikey.ca/en/products/detail/microchip-technology/MIC28516T-E-PHA/13175035 seems like the way to go here! Size doesn't really matter that much for me. Way smaller then having external FETs so I’ll take it.
MIC28516T-E/PHA
Datasheet Rev D: https://ww1.microchip.com/downloads/aemDocuments/documents/APID/ProductDocuments/DataSheets/MIC28516-Data-Sheet-DS20006315.pdf
Setting output voltage to 5.05V target, calculating using https://github.com/UWARG/hardware/tree/master/Scripts.
Modem Re-Selection
We initially selected the EG915N-EA, which only includes bands optimized for usage in Europe and Asia.
This model has band 7 but is missing 12, 13, and/or 71 (as per discussion from Nathan in #rpi-interface-rev-c). Band 7 is (1) limited to certain networks and (2) is 2600MHz, which is fast, but limits ranged performance. 12, 13, and 71 are lower frequency channels and will provide more channels to switch into, as well as better range.
To watch for when selecting a new modem: We want a pin compatible model with the EG915N, as we have already done extensive layout considerations around this footprint, and we want to maintain the 2 supported SIMs. We want bands 7, 12, 13, and 71.
Model/Specs | EG915N-EA (original model) | BG95M3 Series | EG915Q-NA Series |
---|---|---|---|
LTE Bands | LTE-FDD: 1 / 3 / 7 / 8 / 20 / 28 | Cat M1: 1 / 2 / 3 / 4 / 5 / 8 / 12 / 13 / 18 / 19 / 20 / 25 / 26 / 27 / 28 / 66 / 85 Cat NB2: The above and 71, without 26 and 27 | LTE-FDD: 2 / 4 / 5 / 12 / 13 / 66 |
# of SIM Interfaces | 2 | 1 | 2 |
Screenshot |
Layout
Collection of hardware design guideline excerpts from various component datasheets.