Final Project
TLDR VERSION
What does it do?
The system lights up LEDs based on if spacecraft are talking to the Deep Space Network, showing which location they are talking to and from where in the solar system they are.
Who's done what beforehand?
What sources did you use?
- TFT Driver
- Pulse of Exploration MINI
- Micropython libraries (Neopixel (built in), xmltok) through Thonny IDE
- Step Response
What did you design?
- Acrylic Backing
- Electronics Casing
- Satellite Dish
- Button
- Main PCB Board
- Single LED Boards
What materials and components were used?
- Black Acrylic
- Single sided FR1 PCB boards
- Wires
- PLA for 3D printers
- PI PICO W
- Neopixel WS2812B LEDS
Where did they come from?
EDS and class inventory
How much did they cost?
Already in inventory
What parts and systems were made?
- Acrylic Backing
- Electronics Casing
- Satellite Dish
- Button
- Main PCB Board
- Single LED Boards
What tools and processes were used?
- Laser Cutter
- PCB Mill
- Solder
- 3D Printer (Prusa, Bambu)
What questions were answered?
Questions Section further down
What worked? What didn't?
- API request size: Need block out specific memory section to avoid fragmentation
- LED strip: check for shorts :| (destroyed one board)
- Features on 3D printed objects should ideally be thicker than .1 inches: some features on the satellite dish snapped off
- Pi Pico W pins only have specific pins open for SPI protocols: Board V1 did not have the right pins for the TFT screen
- Capacitance sensor much more stable when connected by a resistor to GND
- Pi Pico W pins (not using the Pin Class) is slightly different than a Pi Pico: destroyed a wifi chip on a Pi Pico W board by writing to the wrong pins during sun_button testing
How was it evaluated?
- the system can get what spacecraft are talking to the DSN periodically
- The button reacts touch with changing brightness of an LED
- The system outputs all active spacecraft when button is pressed
- The system can switch between the different states without impeding the other functions
What are the implications?
Cool light show :D
THE SOLAR SYSTEM GRAND TOUR
I was thinking about possibly making an orrery, which is a small scale model of the solar system that can rotate. Most orreries out there are very expensive, so I thought it would be cool to make one myself.
Then I remembered The Pulse of Exploration by Dan Goods and thinking it was really cool. Then I thought about merging the two, and thought it would make a good project.
Instead of a traditional upright orrery, I was thinking about making it more clock-like, where the system is more compressed into (somewhat) the same plane. In between the planets, I would add rings of LEDs that would light up when a spacecraft in the vicinity of the planet is receiving or sending data. In the outer ring, antennas from each of the 3 DSN stations would light up as well when sending or receiving data. This would be pulling data from DSN Now for realtime updates.
As a fun addition, pushing the sun sends out a "pulse" that lights up active missions.
DSN API
For connecting to the DSN API, I knew of a friend who had done something similar. Adapting to Micropython with its own request module, I was able to save down a text of the request onto the Pico, as Micropython has a tendency to run out of program memory.
However, since Micropython doesn't have a good xml parser, I had to write my own. Fortunately there were only a couple of things I needed from the request, so I only needed to pull out the dish name, spacecraft, and uplink or downlinking.
I was able to get the uplinking and downlinking spacecraft mapped to the antenna.
However, when integrating with system, where I had to periodically poll the site, I kept running into memory errors. This was likely due to the Pico not having enough RAM (as micropython also takes up a lot). I started with gc.collect(), but the error persisted.
What was likely happening was that there was free space, but it was fragmented, which meant that there wasn't enough continous space in the program memory to intake new requests. To solve this, I allocated a large chunk of continuous memory beforehand, only releasing it before the get request, then clearing the get request and reallocating it after I was done with the request. This ensured I always had a continous portion of memory for the request.
Sun Button
Using the capacitance step response from the class, I wanted to try running the example code. However, when I did, the Pi Pico W complained and aftwards, whenever I was running code, I would see [CYW43] error: hdr mismatch. This error occurs when the microcontroller is trying to talk to the wifi chip. What likely happened was that I had accidentally written something to a port from the RP2040 to the wifi chip, creating communication issues.
After changing the pins to the Pin class, it works as intended.
I also designed and 3D printed a button that would cover the LED, allowing it to glow. In order to get it to interface with the capacitance sensor, I added copper tape onto the button to extend the capacitance sensor.
Main Board
I first designed a main board. This included breaking out 12 pins for each of the LED strips I had planned to add, then 8 for the TFT screen. I also added a pin for the button, an Neopixel, and capacitance sensor. There was also a port for TX and RX wires to connect to the Pico W.
After testing the various systems, I ended up redesigning the board. I shifted some pins around such that the TFT screen had the right SDA and SCK pins, and removed the RX/TX lines. I also added a resistor from capacitance sensor to GND.
TFT Screen
Using a package for TFT for Micropython and the wiring from this video, I ran the graphics test to check if it works after wiring it to the main board. However, I would get a bad sck pin error.
Going back to the Pi Pico schematic, I realized the pins I had wanted to use (20, 21) did not support SPI protocols.
Connecting them to the original video pins allowed it to work, then when I redesigned by board to connect to pins with SPI capability.
Structure
Board
For the backing board of the system, I decided to cut it out of acrylic. I also wanted to etch the circles in for the planets, so I changed the linewidth and color in the laser cutter software. This allowed it to rasterize, but it took way longer. I did a cardboard test, then tried it on the black acrylic.
Antenna
For the antenna, I ended up modelling an antenna based off the 70 m antennas at the DSN, then printed it 50% size in the Bambu.
Electronics Casing
For the casing, I wanted a place for the TFT screen to stay in, so I modelled a box that would attach to the board, cover the electronics (except for the sun button), allow for connections outside of the board, and have a place to secure the TFT screen. I ended up 3D printing it on the Prusa with supports.
LEDs
I had 2 boards for LEDs: the DSN, and the planet LEDs. The DSN LED ports matched the configuration on the main port.
I finished the DSN LEDs first, and used it to test out my code
For the planet LEDS, I first tried to solder a ring of them. However, I forgot to check for shorts, so when I did, I immediately shorted my board and killed the Pico :(
Later I made another strip and made sure to check for shorts. There weren't any, but there were a couple loose joints that I fixed.
Integration
I decided to run a state machine, where there are 3 states:
- IDLE: Just runs the sun button, runs an idle animation. Checks for button press, has a timer for polling.
- POLLING: Polls DSN periodically. Gets a list of all active spacecraft and whether there's up or down signals from the dishes. For all newly active spacecraft, it runs the uplink and downlink routine. Goes back to IDLE once done.
- ACTIVE: When the button is pressed. Shows all currently active spacecraft with corresponding planet LED lit. goes back to IDLE once done.
I ended up using a for loop to count towards polling, which pauses when running the active state and reset during the polling state.
Resources
Progress
Designing and manufacturing cool PCB (and playing with LEDs) test
Sun ButtonBoard to Board Communication and API
Decided to drop planetary gear aspect.
Decided to split up one big board into smaller ones to maximize modularity.
DSN API working, able to get dictionary of current spacecraft working.
Decided to drop spinning orrery portion.
Uplink and Downlink LEDs working.
DSN API polling working, however was testing late at night and no spacecraft was showing up :(.
State machine between button and idle working, could not test polling atm.
Decided to just 1 LED per planet.
Materials Needed
- Acrylic (acquired)
- LED strips or lots of rgb addressable LEDS (acquired)
- PCB boards (main board and stepper motor board acquired)
- TFT screen (acquired)
- Stepper motor (acquired)
Completed tasks
- Calculate gear ratios
- Get API working
- Main board milled and full system coded up. Will remake board, but current board is as a backup.
- Stepper Motor board completed and controllable
- 3D print Sun
- Get Sun button working
- Get TFT screen working
- 3D print antenna
- 3D model system
- Lay out Planet LEDs
- Integrate all parts together
Tasks to be completed
- None :3
Schedule
- Week of 11/11: Calculate gear ratios and 3D model gear system. Start design and making LED circuit board.
- Week of 11/18: Get one planet system working. Get API working. Get TFT screen working.
- Week of 11/25: Keep adding planets, add sun?
- Week of 12/2: Free space
- 12/18: Presentation :3
Questions
- How do intermediate gears affect gear ratio?
- How do planetary gears work?
- Cool simulation: https://www.thecatalystis.com/gears/
- Tried to find ratios of the planets with respect to Mercury, but found it hard to create. Most likely will go with a regular orrery design.
- How big should I make this thing?
- Gears: Max 12 inch in diameter
- PCB: Breaking up big board into main board, LED boards, and stepper motor boards.
- How to break up large PCB design into smaller ones for the mill?
- Answered above
- Can Pi Pico connect to wifi for API requests, or would I need an ESP32?
- Pi Pico W