In my last post I wrote about a strange situation where packet with a length of 248 bytes was received by application layer.
Today I propose a possible fix or rather workaround to that situation.

Cause

This issue happens because error detection in rfxlink layers is not very effective. The problem I was experiencing was caused by incorrect ACK packet. Correct ACK packet must have following fields: fcf and dsn. First bit In fcf field must be set and dsn field must contain the same dsn number that original packet had.
ACKs are handled in SoftwareAckLayerC.nc in the following way:

tasklet_async event message_t* SubReceive.receive(message_t* msg)
{
    RADIO_ASSERT( state == STATE_ACK_WAIT || state == STATE_READY );

    if( call Config.isAckPacket(msg) )
    {
        if( state == STATE_ACK_WAIT && call Config.verifyAckPacket(txMsg, msg) )
        {
            call RadioAlarm.cancel();

TinyOS is operating system that is used for developing applications for distributed wireless sensor networks. That is what academics used it for. However in these days it is more popular to call it operating system for Internet of things (IoT). TinyOS abstractions are quite nice to use if everything works as expected, however if you have to check under the hood hell breaks loose.

The problem

The problem with my application is that occasionally it receives a packet where payload length is claimed to be 248 bytes long. However application TOSH_DATA_LENGTH is just 86 bytes and Atmega128RFA1 radio buffer is 127 bytes long. Therefore it is impossible that this kind of packet can be received from air.
Fortunately there were asserts in the module where problematic packet reception was caught.

event message_t* Radio.receive[uint8_t id](message_t* msg, void * payload, uint8_t len) {

For some reason I like MSP430 microcontrollers and I always put them into my new designs. This time I decided to use MSP430FR5739 as painting chamber thermostat controller. This board has 2.2" TFT screen with touch controller, 2 NTC thermistors and 4 power MOSFET outputs for controlling actuators like relays and pneumatic solenoids.

Libraries

Eagle schematic and layout can be found here. I have not tested yet if this fancy Linear LT1161 high-side MOSFET driver works properly. I am more interested in getting TFT to work. The display I am using uses HX8340 display driver.

At glance there seems to be 2 ways to get it to display something rather quickly:

• UTFT Arduino library
• 43oh Universal Color LCD Graphics Library

There are pros and cons with both solutions. UTFT is meant for Arduino which does not know nothing about MSP430, however recently Energia project has matured quite a bit...

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...