Last touches to the ESTCube-1 communication module
Last months have been very busy time to all ESTCube-1 core developers, because deadline to really, really handover the satellite was closing quickly. It is over now.
History #
So it is time to do a little overview about what was happening on communication module (COM) side. The whole project started in 2008. I joined the team in the autumn of 2009. Steady development was going on 2 years. This period was not very active, all the stuff was new to us and actually we did not have single team member who had built cubesat before. Also there were couple of years to the actual deadline, students do not do anything unless they know that deadline is tomorrow. Rather more happened in diagrams and paper than in the lab. However by 2011 third COM subsystem prototype was made and I also defend my master’s thesis about developing this prototype. I was more involved in digital electronics and firmware side. RF parts were mainly designed by my brother Toomas who was supervised by experienced RF engineer Viljo Allik. I learned a lot about electronics design and RF during that period. There is nothing comparable to learn by doing.
PCB #
I am not going to describe early prototypes, they are too ugly for the Sun light. However I am going to describe briefly how latest boards look like and what are the main components.
I would say that there are 6 main components on that board:
- MSP430F2418 microcontroller that drives radios and communicates with other subsystems
- Analog Devices ADF7021 radiochip for uplink
- Analog Devices ADF7021 radiochip for downlink
- RFMD RFPA0133 power amplifier for downlink
- RFMD SGL0363 LNA for uplink
- Si570 VCXO that generates beacon signal
Quite frankly there is nothing special about that board and this was one of the design goals to keep it simple and stupid. It uses standard COTS components and amateur radio communication protocol called AX25. It means everybody equipped with standard TNC is able to receive signals from the satellite. It is quite common in cubesat field.
Firmware #
For me the most interesting part was writing firmware for the microcontroller and especially radio driver. Most obvious choice for the operating system was TinyOS. It is oriented for wireless battery powered devices just like cubesat and I had already done many projects with it. TinyOS always forces MCU to sleep if there are no tasks going on, also peripherals are shutdown if they are not used. It happens automatically from developer point of view. So power consumption is one thing less to worry about. There was also more egoistic reason - I wanted to learn it more deeply. Therefore creating radio driver for completely different protocol sounded like a good idea. It was based on rfxlink. People familiar with TinyOS radio architecture know what that really means. Rfxlink consists of tens of interconnected layers that form the basis of the radio driver. It was quite a pain to see at glance what layers actually make sense for AX25 protocol. TinyOS radio drivers are typically not built as generic and typically one platform could have only one radio instance. We had 2 of ADF7021 radios onboard, therefore whole driver structure was redesigned to support generic radio components. It is hard to describe it in words how it finally looked like. Maybe I could open source all the code if the mission is over. Looking the code makes much more sense than describing it in words. The point is that trying to smash AX25 into rfxlink was wrong idea, it complicated the whole driver too much. Low level radio driver was working in the summer of 2011 and this complicated AX25 implementation came in september of 2011. However this was not tested against real TNC, so I actually did not know if it was working correctly. It was only tested between 2 ADF7021 boards that shared the same driver.
AX25 #
We got TNC in November of 2012 and at this time I realized that of course my AX25 implementation did not work out of the box. 3 fixes were needed: CRC, NRZI and G3RUH scrambling. It is not easy to find out how to correctly implement CRC, NRZI and G3RUH for AX25. I finally did it, so take a look how they can be implemented. CRC16 is here: https://gist.github.com/4611897 and NRZI encoding with G3RUH scrambling is here: https://gist.github.com/4589178. Although these implementations are kind of common knowledge, they were obfuscated and they were hard to find from one place. It was little bit surprising because AX25 is such an old protocol.
Bootloader #
The next great hurdle was bootloader support. It was needed for two reasons. First of all working bootloader and reprogramming support would extend development and testing time by about 2 months, because satellite is actually delivered at least 2 months before launch. Although flight model is delivered, it is possible to continue testing on similar engineering model and new firmware can be uploaded just before launch using special access port only. Therefore working reprogramming support is a must have. Fortunately TinyOS has reprogramming module called Deluge, unfortunately it did not work with MSP430F2418. Creating custom bootloader and reprogramming module from scratch is not easy task (remember, all development was only happening in my fee time). Fortunately Defendec helped me out and provided their module. Although it was designed for AVR I managed to get it to work also with MSP430. Figuring this all out was more complicated than I first thought, it took many nights trail and error.
Debugging #
I do not remember why UART was chosen as “communication bus” between subsystems. If I could design it from scratch I would choose CAN bus instead. But here we are with our UART based implementations. There are many different architectures used by various subsystems: 16 bit MSP430, 8 bit AVR, 32 bit ARM and also 64 bit “PC”. Rather complicated protocol was developed to handle routing and errors between subsystems. I did not make sense to develop such a complicated protocol by each subsystem, although probably it would have been more efficient, but more error prone in the same time. Instead generic library was developed and development was done on Windows! The final version with all the bells and whistles was ready just a little bit before deadline. AVR and ARM guys had a chance to adopt it earlier and probably squash out some bugs specific to their platforms. But I was busy. I was so busy to finalize this reprogramming component, that I did not have time to test their library. I had a simpler version from that lib written from scratch and using all TinyOS goodies. It was working great, but it was not compatible with version 2.0 lib that was used by other subsystems. Finally I got time to start wrapping it into TinyOS interfaces. It was quite easy actually, only strange thing to do was to include whole .c file not just .h file, otherwise there were linking problems.
But things got bad, when I started to see very strange behavior on my micro if simple echo test was running. Clearly it was related to overwritten memory. Timers stopped and some random stuff happened. Have seen such stuff many times in my life. I am not going to describe how we finally managed to to find this bug in the middle of the night. It was off by one error in a buffer that corrupted data and therefore memcpy copied little bit too much. Above is a picture about how this board looked like during debugging this issue.