Back in September after the launch of STARLIGHT, I began conceptualizing and designing a second board – MOONLIGHT. After reading through tons of comments & advice, I began work on the second iteration of STARLIGHT.
I didn’t want to stop selling my original STARLIGHT board – it’s a cheaper option, and keeping it on the market would allow me to truly make a pro-level product without having to worry about cutting corners.
Sensors
One place where STARLIGHT had some trouble was in acquiring gyroscope & accelerometer data. This was because of the ICM-42605 on-board which would spit out raw data, forcing the RP2040 to do the grunt work and run sensor fusion. This lead to less-than-optimal response times & even some inaccuracies in measurements. MOONLIGHT is equipped with a BNO085 9-axis IMU (the ICM-42605 was only 6-axis!). Furthermore, the BNO085 can run sensor-fusion on the chip & give the RP2040 usable data much quicker! This allows for much quicker response times & simpler code.
One of the biggest concerns I noticed was with the accelerometer – the ICM-42605 could only read up to +16g of acceleration. Because a lot of model rockets flown exceed this rating, I needed a different accelerometer on the board for these occasions. I decided to include the ADXL375 200g accelerometer, which allows for accurate altitude and velocity determinations, even with the strongest of rockets.
A few comments I got mentioned that the BMP388 on STARLIGHT was deprecated and the BMP390 was strictly better. Because of this, I decided to switch out the BMP388 with a BMP390 on MOONLIGHT.
GPIO
Servos are confusing. Simple 9g servos run off of 4.5-6.0VDC, while HV93i servos and other, more powerful servos run off of 6.0V+. Because of this, it wouldn’t make sense to have a fixed voltage regulator like I had on STARLIGHT.
I decided that for MOONLIGHT, I’d beef up my voltage regulator from a simple 5 volt regulator to an adjustable regulator. This allows for much more versatility in what kind of servos are used for thrust vector control!
Due to the smaller footprint of this board, I was unable to fit any extra IO pins for miscellaneous use. However, I was able to place four pyro channels onto this board! After a lot of feedback, I decided to double the amount of pyro channels on the board to allow for more intricate deployment and staging systems.
Software
STARLIGHT is a development board – it doesn’t come with any software already built for it. I got a lot of complaints about this, as many commercial flight computers already have code written and ready to use. For MOONLIGHT, I decided to take a more conventional approach and begin designing flight software for MOONLIGHT. Once released, MOONLIGHT will have fully-fledged flight software with all sorts of customizations to allow for easy use without needing to know how to write your own code.
What’s next?
As of right now, I’m still prototyping and conceptualizing MOONLIGHT. You’ll see the board is still very empty on the bottom left side. This area is reserved for the voltage regulator and hardware to control it.
I’ve been working hard on getting MOONLIGHT to a production-ready standard, with code to back up the hardware. This was one of the biggest things I was told to include with STARLIGHT. The reason I’m not writing code for STARLIGHT is because I want to keep STARLIGHT as a development board. After looking around, I wasn’t able to find any other model rocket development boards with just hardware. Sure, you could buy a board with software included and write your own code for it. The downside to this is you’d be hacking an already working system, and paying a premium for software you wouldn’t even use! STARLIGHT is meant as a development board for makers and software engineers to write their own code for. MOONLIGHT will be different.
Until next time.
