Bi-directional satellite communication and messaging!

You know that moment in the Kingsman movie when Merlin tells Eggsy hes looking good and in reply, Eggsy replies “Feeling good, Merlin?” I totally feel that way not because of my clothes, but because of my success in integrating the Rockseven Rockblock Naked modem into LOCARBs electronics suite!

Why did it take so long?

Since my last little update (which was a month ago), I was letting my mind wander from LOCARB programming, and waiting for the logic level shifters and KST servos to come in the mail. About a week after the update, I received the servos and was able to give them a quick test. Everything looked great and despite being high voltage servos, they still ran undervolted at 5.5v (with a 1.69 amp stall current – at 8v, the servos had ~3amps stall current) which gave me some flexibility as to how to power them depending on my desired power requirements.

I then put the servos to the side, and waited for the logic level shifters to arrive…and waited…and waited, and waited. It might have been my fault for buying in bulk from China for the amount less than getting them from Adafruit or Sparkfun, but most things I buy off Ebay only take about 2 weeks to arrive. Anyways, about 3 days ago, I got tired of waiting and hooked up my 74AHCT125 – Quad Level-Shifter I had from an old Neopixel project and got to work (and yes, after I hooked up the 74AHCT125, the Ebay shifters came in the mail the next day, sigh…).

LOCARB with Sat modem and various sensors

The Process

During the time I was waiting for the logic level shifters to come in, I was doing a little thinking about how to handle the data being sent to and from LOCARB. I realized I needed to create my own coded message which would need to be formatted in a way which could be consistently parsed by LOCARB into usable commands and data. For sending, I just created a comma separated string of all the variables, which I could then receive and sort out later. But for receiving I didn’t really know how to go about parsing the data (I didn’t even know what the data would look like after being received) so I was a little intimidated. I also needed to think about what circumstances would necessitate me to send messages to LOCARB; which ends up being only in the event I need to recover from malfunctions, handle a low power event, or a issue a course correction.

This is what I came up with:

To further elaborate, the first 6 bytes of the message contain the commands, with each byte being able to control multiple states. The message is formatted without any delimiters except in the event GPS coordinates are involved. This is because of the tokenizing which is required to split a string apart for processing. I could have just used one byte to control all the states, but breaking them up into more bytes allows multiple states to be controlled in one message and helped to simplify debugging.

The processing code

I’ve included a code snippet of what I use to process the incoming message. The IridiumSBD Arduino library specifies the incoming buffer for a send & receive to be an integer. When a TEXT message is sent from the RockSeven CORE dashboard, it will arrive as decimal values which represent the ASCII character. Because of this I needed to do some math in order to obtain the correct ASCII value for what I was sending in the TEXT message, hence the “-48” in the if (inBuffer[x] – 48 == 1) statements. As you’ll also see, I am directly accessing each byte manually, and not running any for/while loops to parse the data, pretty simple.

The only time I do not access an address of the buffer manually is when there are GPS coordinates to tokenize. I knew nothing of tokenizing prior to this stage in programming, so i’m not even sure I have the correct usage implemented. All I know is that it works reliably.

The Latitude strtok function searches for a “,” and sets a pointer there. Then it will continue until it finds another “,” and tokenizes the data between the two as a string. I then convert the string to a float and store it in a variable to be uploaded to the Pixhawk via a Mavlink message. The same is true of the Longitude strtok function but using a “:”, since the strtok function finishes when it hits a null character, I don’t need to specify an end character.

In my testing, I realized that there could be a stray new GPS waypoint flag sent in event of a typo or other error, so I added a simple error check to make sure both Latitude and Longitude are present before a waypoint update is sent to the Pixhawk.

Some other considerations

There are some other considerations related to this entire deal with satellite communications, I’ve listed them below.

Timing of the first message sent:

  • I’m using a standalone watchdog timer from freetronics which by design, requires a HIGH signal sent to it before 5 minutes, otherwise it will send a reset signal to the Arduino. I have this in case the Arduino locks up and needs to be reset. By design, the little watchdog timer is supposed to be reset before every 5 minute counter, but after some testing I realized that it is not so consistent. On first reboot without sending a HIGH, it will wait approximately 6:20 seconds before it sends its reset signal. After that initial 6:20, it then will only wait 3:20 seconds before sending another reset signal.In the event the watchdog has an error and constantly resets the Arduino, i’ve added the ability to send a constant HIGH to the watchdog and disable it completely (using a sat message). I also tweaked my sat comm messaging to use an initial boot send/receive of 1 minute, then switch to any other desired frequency value afterwards. This is to allow for obtaining a command from a satellite message prior to the watchdog resetting the Arduino. I’m considering taking it a little further and implementing a MOSFET to completely disconnect the watchdog from power.

Timing and other functions:

  • The Rockblock modem seems to take 4 minutes before it times out in the event a send/receive failure occurs. This can happen because there isn’t always a satellite flying above the modem all the time or there’s too much interference (signals, line of sight, etc). Testing shows signal quality rising and waning as the satellites pass overhead. The IridumSBD library is blocking code which means that when the Arduino is running the send/receive function, it will prohibit any other code from running. This isn’t a major problem for my application as the navigation is handled by another independent controller, but it could cause some trouble with any other function which needs to be run/updated. Because of my watchdog timer, and the likely event several failed attempts at communication would block the code longer than the HIGH signal is sent to reset the watchdog, I need to make sure I send a constant HIGH to the watchdog until the Sat modem send/receive function is completed, and return the watchdog to its normal state afterwards.