AmbaSat is a DIY “SpriteSat”, essentially a 3.5 mm circuit board with a solar cell on its back side. AmbaSat plans to launch 200 SpriteSats at a time in Extreme Low Earth Orbit (ELEO), where they will transmit for 3 months before burning up in the atmosphere. These Arduino based systems use LoRa (a low power, long range radio protocol) and utilize the existing 5000+ LoRa gateways to The Things Network.
Since the AmbaSat board does not contain a battery nor a storage capacitor, it relies solely on its solar cells for power. I wondered how the system and software would perform in space should the AmbaSat be tumbling in and out of sunlight. Would the microprocessor be constantly rebooting?
Not wanting to damage the AmbaSat’s supplied solar cells, I decided to use an external solar cell. This has the added benefit of enabling the light sensor to measure the sunlight falling on the solar cell. I mounted both the circuit board and solar cell on cardboard as shown below.
(shown in “flight” configuration)
In the AmbaSat forum, user Mfalkvidd computed the power output of the AmbaSat solar cells to be 73ma. He measured the power draw at 125ma when transmitting, thus questioning the realism of the power budget. Not wanting to be drawn into that issue, I purchased a 3V, 150ma panel from Amazon assuming its output would be adequate to power the transmitter: www.amazon.com/gp/product/B06XCKBZXJ
I used a modified version of Michael Kamprath’s flight software. My version sends 2 packets and then delays 56 seconds. The first packet reports the system status, reboot count and voltage in millivolts. The second packet reports the light sensor levels: visible, IR and UV. The packets were received by my TTN gateway application and sent to my Tago.io dashboard. Both are documented elsewhere on this website.
Placing the card stationary in full sunlight (here in Palm Desert, CA, US) with the panel pointed directly into the sun (at 90 degrees), the system performed as designed. However, as the sun moved off-axis over a 2 hour period, the system went into a reboot loop – rebooting and transmitting one status packet every 4 seconds. Interestingly, the status packet showed the voltage to be nominal, and the packet was received by the TTN gateway. But the system rebooted immediately afterwards. I suspect the transmission momentarily dropped the voltage below the microprocessor’s threshold, causing the reboot.
Next, I “flew” the AmbaSat on a wire in a slight breeze as shown in the photo. As one might expect based on earlier results, the system would reboot each time it lost direct sunlight. After 15 minutes, I returned the AmbaSat to a stationary position to re-establish a baseline. The results are shown in the screenshot below.
The screen shows 1 hour of observations, roughly one every minute. For the first 15 minutes, the sat was stationary, pointing directly into the sun. It was “in flight” for the next 15 minutes, then placed in a stationary position again at 10:00 am for 30 minutes.
Notice during the 15 minutes of flight, 6 light measurements were successfully received, while the system boot count increased from 473 to 647. The voltage fluctuations between 2495 and 2485 millivolts occurred more often. The packet number graph remains mostly flat.
The light levels during the first 15 minutes are noticeably lower than the later measurements. I suspect the sensor was off-axis from the sun during this period.
The TTN Console shows the packets as received by The Things Network during the period of transition from “flight” to stationary at 10:00 am. Before 10:00:20, the system is in a reboot cycle, sending status messages (on port 1) every 4 seconds. The good messages are received from 10:00:23 onwards at the proper intervals.
Outstanding Questions:
Ignoring the power budget issue, my experiment raises several questions:
- Do the AmbaSat solar cells perform better off-axis than the Amazon cell?
- Will the AmbaSats be ejected from their carrier in such a manner that the solar cells will be in consistent sunlight when not in the Earth’s shadow?
- Should the flight software pack as many values as possible in one packet, instead on multiple packets? Note: Small packets are less likely to experience CRC errors and are thus more robust.
- What is the optimal delay between transmissions?
- Is there a way to throttle back the reboot messages? Perhaps by adding a random delay in the startup routine before transmitting the first packet? (200 Ambasats rebooting every 4 seconds generates a lot of packets.)
Fredric Raab 