IridiumSBD

The Rock 7 RockBLOCK is a fascinating new communications module that gives TTL-level devices like Arduino access to the Iridium satellite network.  This is a big deal, because it means that your application can now easily and inexpensively communicate from any point on the surface of the globe, from the heart of the Amazon to the Siberian tundra.

This library, IridiumSBD, uses the RockBLOCK/Iridium’s SBD (“Short Burst Data”) protocol to send and receive short messages to/from the Iridium hub.  SBD is a “text message”-like technology that supports the transmission of text or binary messages up to a certain maximum size (270 bytes received, 340 bytes transmitted).

For more information, visit the Rock 7 website.

“3-Wire” Wiring

Rock 7 have made interfacing to the Arduino quite simple.  Each RockBLOCK ships with a 10-pin JST-terminated cable that snaps onto the RockBLOCK and conveniently exposes the various signal lines for the client device to connect to.  It’s actually only necessary to connect 4 or 5 of these to get your Arduino application up and running.   In our configuration we ignore the flow control lines and talk to the RockBLOCK over what Iridium calls a “3-wire” TTL serial interface.  In wiring table below, we assume that the RockBLOCK is being powered from the Arduino 5V power bus.

RockBLOCK Connection Arduino Connection
+5V (Power) +5V (Power)
GND GND
TX TX Serial Pin*
RX RX Serial Pin*
SLEEP +5V or GPIO pin*

A minimal “3-wire” connection to RockBLOCK

*The TX and RX lines are labeled on the RockBLOCK as viewed from the Arduino, so the TX line would be transmitting serial data to the RockBLOCK.  These lines support TTL-level serial (default 19200 baud), so you can either connect it directly to the/a built-in UART or create a “soft” serial on any two suitable pins.  We usually opt for the latter choice to free up the UART(s) for diagnostic and other console communications.  The active low SLEEP wire may be connected to a 5V line (indicating that the device is perpetually awake), but it’s a good power saving technique to connect it to a general-purpose pin,  allowing the library to put the RockBLOCK in a low power “sleep” state when its services are not needed.

Non-blocking Retry Strategy

The nature of satellite communications is such that it often takes quite a long time to establish a link.  Satellite communications are line-of-sight, so having a clear view of an unclouded sky greatly improves speed and reliability; however, establishing contact may be difficult even under ideal conditions for the simple reason that at a given time no satellite may immediately be overhead.  In these cases, the library initiates a moderately elaborate behind-the-scenes series of retries, waiting for a satellite to appear.

With a clear sky, transmissions almost always succeed after a few of these retries, but the entire process may take up to several minutes.  Since most microcontroller applications cannot tolerate blocking delays of this length, IridiumSBD provides a callback mechanism to ensure that the Arduino can continue performing critical tasks.  That is, if the library user provides a global C++ function with the signature

bool ISBDCallback();

(and this is highly recommended for all but the most trivial applications), then that function will be called repeatedly while the library is waiting for long operations to complete.  In it you can take care of activities that need doing while you’re waiting for the transmission to complete.  Simple example:

bool ISBDCallback()
{
   unsigned ledOn = (bool)((millis() / 1000) % 2);
   digitalWrite(ledPin, ledOn); // Blink LED every second
   return true;
}
...
// This transmission may take a long time, but the LED keeps blinking
isbd.sendSBDText("Hello, mother!");

Note: It is not permitted to call most IridiumSBD methods from within the callback.  Doing so will immediately return ISBD_REENTRANT.

Note: Your application can prematurely terminate a pending IridiumSBD operation by returning false from the callback.  Doing so causes the pending operation to return ISBD_CANCELLED.

Power Considerations

The RockBLOCK module uses a “super capacitor” to supply power to the Iridium 9602.  As the capacitor is depleted through repeated transmission retries, the host device’s power bus replenishes it.  Under certain low power conditions it is important that the library not retry too quickly, as this can drain the capacitor and render the 9602 inoperative.  In particular, when powered by a low-power 90 mA max USB supply, the interval between transmit retries should be extended to as much as 60 seconds, compared to 20 for, say, a high-current battery solution.

To transparently support these varying power profiles, IridiumSBD provides the ability to fine-tune the delay between retries.  This is done by calling

isbd.setPowerProfile(1); // For USB "low current" applications

or

isbd.setPowerProfile(0); // For "high current" applications

Construction and Startup

To begin using the library, first create an IridiumSBD object.  The IridiumSBD constructor binds the new object to an Arduino Stream (i.e. the RockBLOCK serial port) and, optionally, the RockBlock SLEEP line:

IridiumSBD(Stream &stream, int sleepPinNo = -1);

Example startup:

#include "IridiumSBD.h"
#include "SoftwareSerial.h"

SoftwareSerial ssIridium(18, 19); // RockBLOCK serial port on 18/19

IridiumSBD isbd(ssIridium, 10);   // RockBLOCK SLEEP pin on 10

void setup()
{
   isbd.setPowerProfile(1); // This is a low power application
   isbd.begin(); // Wake up the 9602 and prepare it to communicate.
   ...

Data transmission

The methods that make up the meat of the IridiumSBD public interface, are, naturally, those that enable the sending and receiving of data.  There are four such functions in IridiumSBD, two “send-only” functions (text and binary), and two “send-and-receive” functions (again, text and binary):

// Send a text message
int sendSBDText(const char *message);

// Send a binary message
int sendSBDBinary(const uint8_t *txData, size_t txDataSize);

// Send a text message and receive one (if available)
int sendReceiveSBDText(const char *message, uint8_t *rxBuffer,
   size_t &rxBufferSize);

// Send a binary message and receive one (if available)
int sendReceiveSBDBinary(const uint8_t *txData, size_t txDataSize,
   uint8_t *rxBuffer, size_t &rxBufferSize);

Send-only and Receive-only applications

Note that at the lowest-level, SBD transactions always involve the sending and receiving of exactly one message (if one is available).  That means that if you call the simpler variants sendSBDText or sendSBDBinary and there happen to messages in your incoming (RX) message queue, the first of these is discarded and irrevocably lost.  This may be perfectly acceptable for a “send-only” application that never expects to receive messages, but if there is some chance that you will need to process an inbound message, call sendReceiveSBDText or sendReceiveSBDBinary instead.

If your application is receive-only, simply call sendReceiveSBDText with a NULL outbound message parameter.

If no inbound message is available, the sendReceive* messages indicate this by returning ISBD_SUCCESS and setting rxBufferSize to 0.

Diagnostics

IridiumSBD provides two methods for performing self-diagnostics.  These are

void attachConsole(Stream &stream);
void attachDiags(Stream &stream);

These allow the host application to provide a Stream object (serial port) that can be used to monitor the RockBLOCK serial traffic and diagnostic messages, respectively.  The typical usage is to simply use the Arduino serial port to monitor both of these—assuming that it is connected to a PC serial console and not otherwise used:

isbd.attachConsole(Serial);
isbd.attachDiags(Serial);

Receiving Multiple Messages

After every successful SBD send/receive operation, the Iridium satellite system informs the client how many messages remain in the inbound message queue.  The library reports this value with the getWaitingMessageCount method.  Here’s an example of a loop that reads all the messages in the inbound message queue:

do
{
   char rxBuffer[100];
   size_t bufferSize = sizeof(rxBuffer);
   int status = isbd.sendReceiveText("Hello?", rxBuffer, bufferSize);
   if (status != ISBD_SUCCESS)
   {
      /* ...process error here... */
      break;
   }
   if (bufferSize == 0)
      break; // all done!
   /* ...process message in rxBuffer here... */

} while (isbd.getWaitingMessageCount() > 0);

Erratum Workarounds and other Tweaks

In May, 2013, Iridium identified a potential problem that could cause a satellite modem like the RockBLOCK to lock up unexpectedly.  In a product bulletin they stated that though future versions of the Iridium firmware would resolve this issue, current software should work around it by adding an “MSSTM” software query to the device.  IridiumSBD employs this important workaround by default, but you can disable it with:

isbd.useMSSTMWorkaround(false);

Similarly, Iridium recommend that transmission be deferred until the signal quality has reached at least 2 (on a scale of 0 to 5, as reported by getSignalQuality()).  However, there are times when it is advantageous to use a lower (or higher) value than 2 as this default minimum.  To change the default minimum from 2, use:

isbd.setMinimumSignalQuality(1);

Error return codes

Many  IridiumSBD methods return an integer error status code, with ISBD_SUCCESS (0) indicating successful completion.  These include begin, sendSBDText, sendSBDBinary, sendReceiveSBDText, sendReceiveSBDBinary, getSignalQuality, and sleep.  Here is a complete list of the possible error return codes:

#define ISBD_SUCCESS             0
#define ISBD_ALREADY_AWAKE       1
#define ISBD_SERIAL_FAILURE      2
#define ISBD_PROTOCOL_ERROR      3
#define ISBD_CANCELLED           4
#define ISBD_NO_MODEM_DETECTED   5
#define ISBD_SBDIX_FATAL_ERROR   6
#define ISBD_SENDRECEIVE_TIMEOUT 7
#define ISBD_RX_OVERFLOW         8
#define ISBD_REENTRANT           9
#define ISBD_IS_ASLEEP           10
#define ISBD_NO_SLEEP_PIN        11

Interface Documentation

IridiumSBD(Stream &stream, int sleepPinNo = -1);

Description:   Creates an IridiumSBD library object
Returns:            N/A [constructor]
Parameter:      stream – The serial port that the RockBLOCK is connected to.
Parameter:      sleepPin - The number of the Arduino pin connected to the RockBLOCK SLEEP line.
Note: Connecting and using the sleepPin is recommended for battery-based solutions.  Use sleep() to put the RockBLOCK into a low-power state, and begin() to wake it back up.

int begin();

Description:   Starts (or wakes) the RockBLOCK modem.
Returns:            ISBD_SUCCESS if successful, a non-zero code otherwise.
Parameter:      None.
Notes

  • begin() also serves as the way to wake a RockBLOCK that is asleep.
  • At initial power up, this method make take several tens of seconds as the device charges.  When waking from sleep the process should be faster.
  • If provided, the user’s ISBDCallback function is repeatedly called during this operation.
  • This function should be called before any transmit/receive message

int sendSBDText(const char *message);

Description:   Transmits a text message to the global satellite system.
Returns:            ISBD_SUCCESS if successful, a non-zero code otherwise;
Parameter:      message – A 0-terminated string message.
Notes

  • The library calculates retries the operation for up to 300 seconds by default.  (To change this value, call adjustSendReceiveTimeout.)
  • The maximum size of a transmitted packet (including header and checksum) is 340 bytes.
  • If there are any messages in the RX queue, the first of these is discarded when this function is called.
  • If provided, the user’s ISBDCallback function is repeatedly called during this operation.

int sendSBDBinary(const uint8_t *txData, size_t txDataSize);

Description:   Transmits a binary message to the global satellite system.
Returns:            ISBD_SUCCESS if successful, a non-zero code otherwise;
Parameter:      txData – The buffer containing the binary data to be transmitted.
Parameter:      txDataSize - The size of the buffer in bytes.
Notes

  • The library calculates and transmits the required headers and checksums and retries the operation for up to 300 seconds by default.  (To change this value, call adjustSendReceiveTimeout.)
  • The maximum size of a transmitted packet (including header and checksum) is 340 bytes.
  • If there are any messages in the RX queue, the first of these is discarded when this function is called.
  • If provided, the user’s ISBDCallback function is repeatedly called during this operation.

int sendReceiveSBDText(const char *message, uint8_t *rxBuffer, size_t &rxBufferSize);

Description:   Transmits a text message to the global satellite system and receives a message if one is available.
Returns:            ISBD_SUCCESS if successful, a non-zero code otherwise;
Parameter:      message – A 0-terminated string message.
Parameter:      rxBuffer – The buffer to receive the inbound message.
Parameter:      rxBufferSize - The size of the buffer in bytes.
Notes

  • The library calculates retries the operation for up to 300 seconds by default.  (To change this value, call adjustSendReceiveTimeout.)
  • The maximum size of a transmitted packet (including header and checksum) is 340 bytes.
  • The maximum size of a received packet is 270 bytes.
  • If there are any messages in the RX queue, the first of these is discarded when this function is called.
  • If provided, the user’s ISBDCallback function is repeatedly called during this operation.
  • The library returns the size of the buffer actually received into rxBufferSize.  This value should always be set to the actual buffer size before calling sendReceiveSBDText.

int sendReceiveSBDBinary(const uint8_t *txData, size_t txDataSize, uint8_t *rxBuffer, size_t &rxBufferSize);

Description:   Transmits a binary message to the global satellite system and receives a message if one is available.
Returns:            ISBD_SUCCESS if successful, a non-zero code otherwise;
Parameter:      txData – The buffer containing the binary data to be transmitted.
Parameter:      txDataSize - The size of the outbound buffer in bytes.
Parameter:      rxBuffer – The buffer to receive the inbound message.
Parameter:      rxBufferSize - The size of the buffer in bytes.
Notes

  • The library calculates and transmits the required headers and checksums and retries the operation for up to 300 seconds by default.  (To change this value, call adjustSendReceiveTimeout.)
  • The maximum size of a transmitted packet (including header and checksum) is 340 bytes.
  • The maximum size of a received packet is 270 bytes.
  • If there are any messages in the RX queue, the first of these is discarded when this function is called.
  • If provided, the user’s ISBDCallback function is repeatedly called during this operation.

int sendReceiveSBDBinary(const uint8_t *txData, size_t txDataSize,

uint8_t *rxBuffer, size_t &rxBufferSize);
Description:   Transmits a binary message to the global satellite system and receives a message if one is available.
Returns:            ISBD_SUCCESS if successful, a non-zero code otherwise;
Parameter:      txData – The buffer containing the binary data to be transmitted.
Parameter:      txDataSize - The size of the outbound buffer in bytes.
Parameter:      rxBuffer – The buffer to receive the inbound message.
Parameter:      rxBufferSize - The size of the buffer in bytes.
Notes

  • The library calculates and transmits the required headers and checksums and retries the operation for up to 300 seconds by default.  (To change this value, call adjustSendReceiveTimeout.)
  • The maximum size of a transmitted packet (including header and checksum) is 340 bytes.
  • The maximum size of a received packet is 270 bytes.
  • If there are any messages in the RX queue, the first of these is discarded when this function is called.
  • If provided, the user’s ISBDCallback function is repeatedly called during this operation.

int getSignalQuality(int &quality);

Description:   Queries the signal strength and visibility of satellites
Returns:            ISBD_SUCCESS if successful, a non-zero code otherwise;
Parameter:      quality – Return value: the strength of the signal (0=nonexistent, 5=high)
Notes

  • If provided, the user’s ISBDCallback function is repeatedly called during this operation.
  • This method is mostly informational.  It is not strictly necessary for the user application to verify that a signal exists before calling one of the transmission functions, as these check signal quality themselves.

int getWaitingMessageCount();

Description:   Returns the number of waiting messages on the Iridium servers.
Returns:            The number of messages waiting.
Parameter:      None.
Notes

  • This number is only valid if one of the send[Receive] methods have previously completed successfully.  If not, the value returned from getWaitingMessageCount is -1 (“unknown”).

int sleep();

Description:   Puts the RockBLOCK into low power “sleep” mode
Returns:            ISBD_SUCCESS if successful, a non-zero code otherwise;
Parameter:      None.
Notes

  • This method gracefully shuts down the RockBLOCK and puts it into low-power standby mode by bringing the active low SLEEP line low.
  • Wake the device by calling begin.
  • If provided, the user’s ISBDCallback function is repeatedly called during this operation.

bool isAsleep();

Description:   indicates whether the RockBLOCK is in low-power standby mode.
Returns:            true if the device is asleep
Parameter:      None.

void setPowerProfile(int profileNo);

Description:   Defines the device power profile
Returns:            None.
Parameter:      profileNo – 1 for low-current USB power source, 0 for default power
Notes

  • This method defines the internal delays between retransmission.  Low current applications need longer delays.

void adjustATTimeout(int seconds);

Description:   Adjusts the internal timeout timer for serial AT commands
Returns:            None.
Parameter:      seconds – The maximum number of seconds to wait for a response to an AT command (default=20).
Notes

  • The Iridium 9602 frequently does not respond immediately to an AT command.  This value indicates the number of seconds IridiumSBD should wait before giving up.
  • It is not expected that this method will be commonly used.

void adjustSendReceiveTimeout(int seconds);

Description:   Adjusts the internal timeout timer for the library send[Receive] commands
Returns:            None.
Parameter:      seconds – The maximum number of seconds to continue attempting retransmission of messages (default=300).
Notes

  • This setting indicates how long IridiumSBD will continue to attempt to communicate with the satellite array before giving up.  The default value of 300 seconds (5 minutes) seems to be a reasonable choice for many applications, but higher values might be more appropriate for others.

void setMinimumSignalQuality(int quality);

Description:   Defines the minimum signal quality needed to begin a send/receive transmission.
Returns:            None.
Parameter:      quality – The minimum signal quality on a scale of 0 (nonexistent) to 5 (superb) needed before the library allows a transmission to begin. (default=2)
Notes

  • Iridium recommend using 2 for this value, although there are occasions where 1 might be used.

void useMSSTMWorkaround(bool useWorkaround);

Description:   Defines whether the library should use the technique described in the Iridium Product Advisor of 13 May 2013 to avoid possible lockout.
Returns:            None.
Parameter:      useWorkaround – “true” if the workaround should be employed; false otherwise.  This value is set internally to “true” by default, on the assumption that the attached device may have an older firmware.
Notes

  • Affected firmware versions include TA11002 and TA12003.  If your firmware version is later than these, you can save some time by setting this value to false.

void attachConsole(Stream &stream)

Description:   Binds stream as the library output console.
Returns:            None.
Parameter:      stream – The stream object (typically a serial port) that will monitor the serial traffic to/from the RockBLOCK device.
Notes

  • This is a diagnostic routine.  Use it to monitor traffic on a PC console.

void attachDiags(Stream &stream)

Description:   Binds stream as the library diagnostic stream
Returns:            None.
Parameter:      stream – The stream object (typically a serial port) that will display library diagnostic messages.
Notes

  • This is a diagnostic routine.  Use it to monitor debug messages on a PC console.
  • If this functionality is no longer needed, you can recover system resources by recompiling the library source without diagnostics.  Change the line near the top of IridiumSBD.h to
#define ISBD_DIAGS             0

bool ISBDCallback()

Description:   This is not a library method, but an (optional) user-provided callback
Returns:            true if the operation should continue, false to terminate it.
Parameter:      None.
Notes

  • If this function is not provided the library methods will block.

License

This library is distributed under the terms of the GNU LGPL license.

Download

The latest revision of the library is 1.0. Download from GitHub.

Revision history

0.1   – Initial draft submitted to Rock 7 for review
0.2   – Added text about the AT-MSSTM erratum/workaround and changing the minimum required signal quality.  Also documented related new methods setMinimumSignalQuality()  and useMSSTMWorkaround().
1.0 – Posted initial version.

 

Page last updated on August 31, 2013 at 6:49 pm
106 Responses → “IridiumSBD”

  1. Mike

    4 years ago

    Hi,

    I’m just starting on a HAB project using the Rockblock and should really find the above work most helpful. Thanks!

    Although I already have a Rockblock, the plan is to start software development using the PC based emulator described at http://www.cnsp-inc.com/a-little-python-saves-big-on-iridium-sbd/. Have you any experience with this application?

    Regards, Mike.


  2. Mikal

    4 years ago

    Hi Mike–

    I’m pretty new to Iridium myself, so I’m afraid I haven’t encountered the software you refer to. But it looks interesting. Keep us posted on how your project turns out.


  3. Jakob

    4 years ago

    Hi MIke

    Faboulus!! What are the chances that I can get this to work on an Ardupilot APM 2.5?

    Regards
    Jakob


  4. Matt

    4 years ago

    Thanks for the great work Mikal. I am using a rockBLOCK for a world record setting attempt and you have made it 100% easier!

    Matt


  5. Mikal

    4 years ago

    @Jakob, I’m guessing it would be pretty high chance. What processor does the APM 2.5 use?


  6. Mikal

    4 years ago

    @Matt,

    Cool! World record in what?


  7. Dennis

    4 years ago

    Is it possible to modify the code from your Beacon sketch to initiate from a button press, ex: if digital input pin=HIGH (+debounce stuff) then transmit gps coordinates to rockblock and go to sleep (battery operated), else, do nothing? I am thinking along the lines of a distress signal for hunters, elderly, etc., or a check-in button for people in remote locations but am very new to programming, electronics, etc. Many thanks for your libraries, from my limited perspective, it doesn’t appear that the full impact of your work has been recognized!


  8. Mikal

    4 years ago

    Thank you kindly for the nice words, Dennis. I do think it would be pretty easy (and useful!) to do something like you suggest. Perhaps I’ll make another sketch called “Panic”.


  9. Matt

    4 years ago

    Thanks for the work that you have put into this great library.

    I have the data that I wish to send stored as a struct like this:

    struct message {

    uint8_t i_year;
    uint8_t i_month;
    uint8_t i_day;
    uint8_t i_hour;
    uint8_t i_mins;
    uint8_t i_secs;
    int32_t i_lat;
    int32_t i_lon;
    float i_alt;
    float i_speed;
    };

    How do I get this data sent via your library using sendSBDText?

    Thanks.


  10. Mikal

    4 years ago

    @Matt,

    I’d say use sprintf–except that sprintf doesn’t work with floating-point numbers in the tiny Arduino environment.
    So the solution I use is a hybrid of sprintf for the integers and my PString library to “print” floating point numbers to string. Here’s what we’re using in our weather balloon application:

    // Print the integral values into the string using sprintf
    char iridiumBuffer[60]; // note: don't overflow this buffer
    sprintf(iridiumBuffer, "%d%02d%02d%02d%02d%02d,",
        year % 100, month, day, hour, minute, second);
    
    // Then tack on the floating point lat/long like this
    int len = strlen(iridiumBuffer);
    PString str(iridiumBuffer + len,
        sizeof(iridiumBuffer) - len);
    str.print(latitude, 5);
    str.print(",");
    str.print(longitude, 5);
    str.print(",");
    str.print(altitude / 100);
    str.print(",");
    str.print(speed / 100);
    str.print(",");
    str.print(course / 100);
    
    int code = isbd.sendSBDText(iridiumBuffer);
    

    Yours will be similar, though obviously you’ll change the variable names.


  11. Matt

    4 years ago

    That works perfect.

    Thanks :)


  12. Mikal

    4 years ago

    @Matt–

    One additional thing: if you format your output exactly like I’ve shown above, the Rock7 core software will interpret it correctly as GPS data and draw it on their internal map.


  13. Paul

    3 years ago

    It’s a great library, and it didn’t take long to get the basic operations working.

    I have one question: is there any means of accessing the “Ring Alert” feature of the 9602? I’m sending messages, then waiting for a response. To repeatedly poll is expensive, and “Ring Alert” seemed like a good way around this.

    Do you have any thoughts?

    Thanks!


  14. Mikal

    3 years ago

    @Paul,

    You’re quite right about that expensive polling. We hope to do an update to the library soon that will support RING, but right now it’s not really available. Stay tuned.


  15. Paul

    3 years ago

    Hi Mikal,

    I addressed the RING issue by connecting the Ring line to pin 2, and attaching an interrupt to it. It works fine, up to a point (to avoid reentrancy, I don’t actually do anything in the interrupt routine except to set a flag). But it doesn’t work perfectly. When I try to retrieve the message using:
    isbd.sendReceiveSBDText(“”, rxBuffer, bufferSize)
    I always get an error 3 – protocol error. If I then retry, I retrieve the message successfully.

    Do you have any idea why this would be?

    Thanks,
    Paul


  16. Mikal

    3 years ago

    Nice work, Paul.

    The reason why you see the “protocol” error is that, in addition to bringing the “ring” line high, the satellite modem also generates the string “RING\r\n” in the serial stream. When the library begins to talk to the modem, and is answered by “RING\r\nOK\r\n” instead of the expected “OK\r\n”, it considers that a protocol violation. This will take some thinking about how to either disable that serial RING string, or filter it out. Thanks for your work.


  17. Mathew Bratland

    3 years ago

    Hi! I wonder if i it is possible to send gps coordinates directly to a server with the IridiumSBD?


  18. Mikal

    3 years ago

    @Mathew Bratland,

    Yes. If you read the Rock 7 configuration information you can route outbound messages to an email client or to a server via http get (I think). I know of one person who uses RockBLOCK to transmit weather balloon coordinates to a server so that his team can monitor the balloon’s progress.


  19. getoutside

    3 years ago

    Need help getting an ardupilot APM 2.6 to send telemetry via rock block every 12 hours
    telemetry to be sent would be a snapshot of readings. The readings needed would be three axis, barometric pressure, GPS, current speed over ground.

    I have tried and failed miserably to get things going properly between the two.

    I am willing to pay to make this happen.

    Mikal, if you have the time or inclination please let me know.

    Thanks


  20. Soren Kuula

    3 years ago

    This is superbly done.


  21. Mikal

    3 years ago

    @getoutside–

    I’ll contact you offline. Thanks.


  22. getoutside

    3 years ago

    Excellent!

    Thank you!


  23. Michael

    3 years ago

    Excellent!
    Thank you!
    Mikal


  24. Alex

    3 years ago

    @Mikal

    I would like to know if it can be possible to use Rockblock as datalink modem for receiving telemetry from an APM ArduPlane latest version. Probably same needs as getoutside but I need regular update of the telemetry data (every 30seconds).
    Please contact me.

    Thank you.


  25. russell cain

    3 years ago

    Hi,

    I’m currently working on a project using the rockblock at Oxford University. Do you know whether the code you’ve written would run on an Ubuntu system please?

    cheers

    Russ


  26. Jack

    3 years ago

    Hi. I’m trying to download the Iridium library but am having some trouble doing so. This is probably me being stupid, but could you tell me how I should load it into the arduino IDE. I have tried the two standard ways of copying the folder into the arduino Libraries folder, and also by automatically installing it from the IDE, but neither of these metheods seem to allow me to install the library.

    Thanks
    Jack


  27. Mikal

    3 years ago

    @russell,

    No, because it has dependencies on Arduino-specific constructs like millis(). But I bet it wouldn’t be too much work to port…


  28. Mikal

    3 years ago

    @Alex,

    Satellite modem is pretty dicey for sending or receiving data at precise intervals. There are just too many variables to say that a transmission could happen every 30 second with any precision.


  29. Mikal

    3 years ago

    Hi Jack—

    Yeah, it’s an unfortunate side effect of GitHub mechanism that it automatically puts a dash (-) into the archive/folder name, and dashes aren’t allowed in Arduino library names. If you rename the folder “Iridium” it should work…


  30. getoutside

    3 years ago

    @mikal

    Hey:

    The updates I am looking for would be every 8 hours. There is a new Autopilot called pixhawk which I have upgraded to. If you have time and are still interested, please ping me.

    Thanks!


  31. Greg

    3 years ago

    Just to give you a heads up, I found a “bug” in your code. In your description of sendSBDText() you state “The maximum size of a transmitted packet (including header and checksum) is 340 bytes.”

    While this is true, in your implementation you use is:

    AT+SBDWT=.

    This way of sending a text is limited to 120 bytes due to the length limit on the AT command line interface.

    To use the full 340 character limit, you have to use AT+SBDWT, wait for a READY response and then pass the message.

    It was an easy enough for me to fix, but I thought I’d let you know so you could update your code or your documentation.

    Cheers, and I love your work.


  32. Mikal

    3 years ago

    @Greg,

    Hey, thanks for that analysis and the kind words. Would you mind sharing your “fix”? It sounds like it would be a useful addition to the library.


  33. Greg

    3 years ago

    No problem, Mikal.

    in the file iridiumSBD.cpp in the function internalSendReceiveSBD() I changed the else block:

    else // Text transmission
    {
    send(F(“AT+SBDWT=”), true, false);
    if (txTxtMessage) // It’s ok to have a NULL txtTxtMessage if the transaction is RX only
    send(txTxtMessage);
    send(F(“\r”), false);
    if (!waitForATResponse(NULL))
    return cancelled() ? ISBD_CANCELLED : ISBD_PROTOCOL_ERROR;
    }

    To the following:

    else // Text transmission
    {

    send(F(“AT+SBDWT”), true, false);
    send(F(“\r”), false);
    if (!waitForATResponse(NULL, 0, NULL, “READY\r\n”))
    return cancelled() ? ISBD_CANCELLED : ISBD_PROTOCOL_ERROR;
    if (txTxtMessage) // It’s ok to have a NULL txtTxtMessage if the transaction is RX only
    send(txTxtMessage);
    send(F(“\r”), false);
    if (!waitForATResponse(NULL, 0, NULL, “0\r\n\r\nOK\r\n”))
    return cancelled() ? ISBD_CANCELLED : ISBD_PROTOCOL_ERROR;
    }


  34. Mikal

    3 years ago

    @Greg,

    Thanks for that! It’s going into a future release, duly credited!


  35. Mike

    3 years ago

    Hello Mikal

    I’m about to subject a Rockblock and GPS receiver to an environmental test at low pressure and temperature (for a balloon project), whilst running the ‘Tracker’ sketch from your recent Make article. This very useful code seems to be operating correctly, finds a GPS fix, exits sleep and transmits to the Rockblock.

    Please could you tell me if it is possible to receive some kind of response from the Rockblock (e.g. error message) without first purchasing credits?

    Thanks, Mike


  36. Mikal

    3 years ago

    Hi Mike–

    We are working with some fellows in England who have launched balloons with RockBlock and a derivative of the Tracker sketch. I think what happens with RockBLOCK is that if you don’t have any credits, or your account is inactive, it simply fails to send the message. I don’t know of any way to detect either condition from the RockBlock itself, although I’d be glad to be proven wrong.


  37. Mike

    3 years ago

    Mika

    Thanks for the very prompt response.

    It would have been very helpful if the Rockblock could have acknowledged an attempted transmission, even if a satellite link was not established. Although my pressure/temperature chamber should provide the GPS and Iridium antennas with a reasonable view of the sky, this may not be the case with environmental test rigs.

    Guess I’ll just have to register for the line-rental and credits before checking the basic configuration.

    Thanks again, Mike.


  38. Glenn

    3 years ago

    Mikal,

    I have some 9602′s available to me at work. I am looking to use one of them to send and receive messages when I am offshore deploying/recovering an AUV. Can you think of an easy way to be able to change the text message sent without having to re-compile and upload? I will have a laptop with me and connected hopefully by wifi or rf to the arduino. Also how is the received messages displayed?

    Thanks,
    -Glenn


  39. Ranga

    3 years ago

    Mikal
    I have a requirement for some satellite telemetry to hook the RockBlock to an arduino board to get some analog (pressure) readings. The sensor outputs 4-20mA over the range and it needs to report every 30 min from a remote location.
    Could you please contact me off-line?
    Regards
    Ranga


  40. Mikal

    3 years ago

    @Glenn–

    Sure! Will you have a laptop handy? It would be pretty easy to configure the software to read strings from the laptop’s serial port and transmit them on demand.


  41. Tom

    3 years ago

    Hello,

    I just connected my new Rockblock to an arduino Mega, and uploaded the example code SendReceive. I have the tx and Rx on 18 and 19, respectively, using 5 volts from Arduino (measured it with VOM), and sleep line either pin 10 or 5 volts steady. The code compiles, In the serial monitor I get “Waiting for Response OK” messages, then after about 9 or 10 messages (I think) I finally receive the message: ” <<NO modem Detected. Powering off RockBlOCK…!, SignalQuality failed:error 10"
    I tried two different MEGA2560 boards with same results. This is about as simple as could be. Any ideas? I had this set up with full sky view and antenna facing the sky. Is there some way I can do a simple querry of the RockBlock to see if I can get any response?


  42. Tom

    3 years ago

    As in my post above, there seems to be problems with the Arduino MEGA2560 board and this code. I have been talking with the support staff at RockBlock and they acknowledged that another user has had difficulty also. They are trying to recall the solution, and I have forwarded them the complete configuration I am using. They passed the problem to a technical guy, and hopefully he will be able to help. I can see the MEGA2560 transmitting, but we never get a response from RockBlock. We tested the RockBlock by interfacing to it with a usb cable and sending it AT commands using a serial terminal (TeraTerm). It responded correctly to those commands in that configuration. If anyone else has any ideas or experience like this, I’d appreciate receiving them, and so would RockBlock support, I’m sure.


  43. Mikal

    3 years ago

    Hi Tom–

    Arduino Mega doesn’t support pin change interrupts on 18 and 19; try one of the pins listed in http://arduino.cc/en/Reference/SoftwareSerial.


  44. Christopher

    3 years ago

    Hi,

    Is the RING feature expected to be imlemented ?

    Polling the rockblock is quite expensive. Thanks.


  45. Ralf

    3 years ago

    Hi, sounds very interesting. But i can´t find any dl-link to the library!!
    or am i blind?


  46. Ralf

    3 years ago

    Sorry for my blindness, found the link :-)


  47. Mikal

    3 years ago

    @Christopher. Someday. :) Yes. It’s still planned.


  48. Stephen

    3 years ago

    I’m trying to integrate the RockBlock into a project using a Arduino DUE. Unfortunately, it seems the IridiumSBD library does not support that board. Could you help me out with code that supports the Arduino Due with hardware serial?

    Thanks!
    Stephen


  49. Bobby

    3 years ago

    Can someone please post their code for sending and receiving messages?

    Here is the code I am using…

    //This one works every time but no receive (from globalbeacon)
    isbd.sendReceiveSBDText(outBuffer);

    Attempts at using this fail and I get a 0 on the serial monitor. It’s actually a distance ballooning beacon and I want to be able to do 2-way to it..

    int sendReceiveSBDText(const char *outBuffer, uint8_t *rxBuffer,
    size_t &rxBufferSize);

    After my receive (if I can get that working) I’m converting rxbuffer to new string and doing string parsing for commands in the received data.

    Thanks in advance for the help…


  50. Danny

    3 years ago

    Hi Mikal. Thank you so much for your libraries. PString, TinyGPS++, and IridiumSBD have been critical to my research work for a while!

    I am working on a new application for IridiumSBD where a fairly complex program polls about 10 sensors attached to a Mega 2560. The program averages the sensor values for three minutes and then sends about 300 bytes of data over SBD. In order to send 300 bytes, I had to implement the change to iridiumSBD.cpp suggested by Greg. While data is being sent using IridiumSBD, the sensor polling/averaging program runs in ISBDCallback(). In theory, the program runs along like this sending message every three minutes for about 4 hours, and if ever a message can’t be sent due to poor signal quality, it just gets thrown away.

    I am having a variety of challenges, but I was wonder if you could help with this main issue: I can usually send the first message without any problems, but issues arrive when sending subsequent messages. This issue has two flavors: 1) I cannot figure out a robust way to cancel sending message n-1 when message n arrives in the send buffer after 3 minutes of unsuccessfully trying to send message n-1. I have tried changing adjustSendReceiveTimeout to less than three minutes and I have also tried making ISBDCallback() return false once a new message arrives in the buffer. Neither seem to work and just give me “error 10.” The second problems is that 2) even when I do get the first message through, the SBD modem seems unresponsive to the subsequent messages. I just get <>AT on and on forever.

    Any ideas? Thanks so much.

    As an unrelated final note: I have found out that if a message includes a carriage return, lots of problems will happen, especially “Error 3.”

2 Trackbacks For This Post
  1. Talking to Satellites! | Arduiniana

    [...] IridiumSBD [...]

  2. RockBlock Configuration | The Official Skyence Blog

    [...] code online in a couple of weeks so stay tuned for that if you’re interested. It is based off this brilliant library which has cut out a lot of the hard work for [...]

Leave a Reply