Makersnake

Makersnake

Software writing, 3D printing, hardware hacking and all-round geekery

rb-indent

Satellite communication with RockBLOCK

The RockBLOCK Mk2 is one awesome module. It literally houses everything you need to send and receive data from anywhere on the planet (Iridium satellite modem, compact antenna and power circuitry) in a module smaller than the Raspberry Pi (the de facto measuring implement for these kind of things) at an equally micro price of £159/€199/$269 – available to buy online from Rock 7

This product has already been widely adopted by the Arduino community, with many happy RockBLOCK’ers thanks to Mikal Hart’s C++ IridiumSBD library; but I couldn’t find anything specifically for the many Python Raspberry Pi users… Fear not, inspired by Mikal’s library, and copious amounts of Columbia’s finest, coffee that is, I’ve created… pyRockBLOCK. The super-simple library that makes sending and receiving messages via satellite as simple as: sendMessage(“Hello World”) and requestMessageCheck().

pyRockBLOCK will work on pretty much anything that runs Python; so you’ll be up and running with just a few lines of code, which will give you plenty of time to 3D print your very own Raspberry Pi X RockBLOCK case or create all manner of crazy UAV’s, High Altitude Balloons and Ocean Sensing Buoys using your RockBLOCK!

Related Makersnake Projects/Guides:

Part 1 – Raspberry Pi Setup (Software)

I’ve started off with a fresh installation of Raspbian – if you’re new to Raspberry Pi (where have you been hiding?) here’s a great starter guide to get your RPi up and running.

The first thing we’ll do is install some dependencies and a couple of useful tools; needless to say, ensure that your RPi has an internet connection so that these can be downloaded!

From the command line (running as root/sudo):

That’s everything installed – next we’ll clone the latest version of pyRockBLOCK from GitHub (https://github.com/MakerSnake/pyRockBlock)

 

Part 2 – Raspberry Pi Setup (Wiring)

We’ve got two options when it comes to connecting the RPi to the RockBLOCK – via USB (using a USB to UART cable) or directly to the GPIO pins. Both are technically the same, so really just depends on your project or what cables you have laying around!

FTDI USB to UART cable converts 5V USB signals to 3.3V UART as well as providing 5V power to the module. 

The inline 6-way connector should be connected as below (Black to GND, Green to RTS)

wireWe ain’t got the power captain!

When the RockBLOCK is powered via USB at 5V it will draw a maximum of 450mA – it’s therefore important that your host (RPi) is itself connected to a good quality power supply that is capable of providing a reliable source of power.

Another important point, that caught me out, is that it’s essential that the FTDI USB to UART cable is configured to supply the required current (who knew you could configure a cable!). The FTDI cable used has an accompanying programming utility for setting the required current value.

After connecting the USB cable to the RPi it may take a few seconds for it to be detected; you can see if it has been recognised using: ls /dev/tty*

Screen Shot 2015-02-12 at 17.25.25

The device handle for your cable will vary depending on your cable/system – but typically if you’re using a USB/UART converter as described, it will normally include “USB” somewhere in the name (e.g. /dev/ttyUSB0 or /dev/tty.usbserial-FTH9I1S5)

If you’re not sure, or your’ve got multiple USB peripherals attached – try running the command with/without the peripheral connected and compare the results.

[checklist]

  • Make sure you make a note of your device handle, this will be required later!

[/checklist]

Another useful command is lsusb, which lists the USB peripherals connected to your device:

Screen Shot 2015-02-12 at 17.27.56

You can request more information, including the MaxPower value for your cable, using the following command: lsusb -v -d VENDOR:PRODUCT

Screen Shot 2015-02-12 at 17.30.51

The RPi can also be connected to the RockBLOCK directly using the GPIO pins, which is perfect if you need to use the USB ports for something else, or if you’re trying to reduce space. To make the connection between the two modules, you’ll need 4 or 5 jumper leads.

rock-pinsThe connections are fairly self-explanatory; simply connect 5V power (Red & Black) and the UART (Green & Blue) – if you wish to utilise the “Ring Alert” capability, make a final connection between GPIO 18 (or any you like) and the RI connection on the RockBLOCK.

When your RockBLOCK is permanently powered and undertaking regular satellite communications (at least once a day) it’s possible to receive “Ring Alerts”. This is a fantastic feature that will indicate when new messages are available, avoiding establishing a satellite session just to see if there are new messages. The RockBLOCK will set the “Ring Indicator” pin ON when a Ring Alert has been received from the satellite.

That’s the wiring complete, the final steps involve making some software configuration tweaks to your RPi.

Using your favourite editor (running as root/sudo), you’ll need to edit /boot/cmdline.txt to remove this text: console=/dev/ttyAMA01,115200 and kgdboc=ttyAMA,115200.

After editing your file should look something like this:

dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

Next we need to edit /etc/inittab to comment out (add # at the start) the line that reads:

T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt10 (For me this was the last line in the file)

Finally, reboot your RPi (using reboot command)

Your device handle for the RockBLOCK whilst connected via the UART will always be: /dev/ttyAMA0

  • Make sure you make a note of your device handle, this will be required later!

The Iridium modem requires a considerable amount of current whilst transmitting, that’s why you’ll notice the large “super capacitor” on the RockBLOCK. As such, it will take a while for the RockBLOCK to power up and begin to respond to commands (typically 60 seconds) whilst the capacitor is charging.

For more detailed information on the power usage profile of the RockBLOCK, and some pretty graphs, check out the official developer guide.

Before we start looking at the library, let’s first check that we can talk to the RockBLOCK; like most modems, the Iridium 9602 modem on the RockBLOCK has a plethora of AT commands to control it’s functionality. We’ll use the screen command (if you’re using a PC you can use PuTTY) to send commands to the modem and assess the response.

screen DEVICE HANDLE 19200 (e.g. screen /dev/ttyUSB0 19200 or /dev/ttyAMA0 19200)

NB: 19200 is the baud rate of the RockBLOCK

Now if you type AT and press [Enter], you should should see an OK response. If you don’t get any response, wait 30 seconds and try again – as mentioned above it may take 60 seconds for the RockBLOCK to fully power up and respond to commands.

To get out of screen press [Ctrl] + a, then press k, then press y (Not totally obvious – I had to Google it!)

 

Part 3 – Software Setup

Now that we’ve connected the RockBLOCK and confirmed that we can talk to it, we can start writing some code…. Unfortunately, there’s not much code to write, pyRockBLOCK does all the hard work for you and has been rigorously tested (it’s been hanging out my window, running my Remote Controlled Weather Station for the last three weeks!).

pyRockBLOCK provides super-simple commands enabling you to send and receive messages with just a few lines of code; without having to worry about the nitty-gritty of messing around with Serial Ports, AT commands, signal strength, calculating checksums, retry strategies or making the perfect coffee (only joking, it doesn’t do the latte, err doesn’t do the latter!).

If you are happy to embrace this black-box, skip the next few paragraphs and jump to the good stuff – else, if you’d like to know how all this magic works, grab a coffee and read on…

Mobile Originated (MO) messages (Sent from the RockBLOCK via Satellite)

Given that your RockBLOCK is tiny and has to communicate with a satellite up in space (781km away) that is zipping across the sky (at 27,000km/h) – it’s not always possible to get a reliable connection first time, as such the library facilitates an element retry.

When you try to and send a message the library will first query the signal strength from the modem (AT+CSQ). The signal strength is expressed on a 0 to 5 scale, where 0 is no signal, and 5 is perfect signal – just like the signal bars on your mobile/cell phone.

The signal strength is only updated every few seconds and is approximate, so even with a signal strength of 5 transmissions can still fail, conversely a signal strength of 1 can be acceptable for transmission. So really its just an approximate guide, that may, or may not be correct (insert pinch of salt here)!

For the library, i’ll consider that a signal strength of 2 to be acceptable to attempt to establish a satellite session – if the signal strength is less than this, we’ll go to sleep for a bit and then retry, this will occur a maximum of 10 times before permanently failing.

After verifying the signal strength, we’ll write the message to the modem’s output buffer (AT+SBDWB) and attempt then to initiate the satellite session (AT+SBDIX). If this fails, it often does, it will try again a maximum of 3 times automatically before permanently failing.

It will typically take 20-30 seconds to establish a satellite connection, but given the various levels of retry, I would only start to panic if this process takes more than a couple of minutes!

Mobile Terminated (MT) messages (Sent to the RockBLOCK via Satellite)

To receive a message on your RockBLOCK you’ll firstly need to request it from the satellite – messages will not be automatically “pushed” you need to “pull” it (like a cracker). 

When you request the library to check for messages, it will undertake the signal strength check (AT+CSQ) and attempt to establish a satellite session (AT+SBDIX) – if successful, your message will be downloaded (only one message can be downloaded in each satellite session).

The response from the satellite will indicate if there are additional messages to download; if there are additional messages “in the queue”, you’ll need to check for messages again; this will establish another satellite session, this should be repeated until there are no further messages in the queue.

pyRockBLOCK is built around a single module called rockBlock which is instantiated by providing a device handle string (e.g. /dev/ttyUS0) and a reference to your callback object. The callback object should extend the rockBlockProtocol class and implement the applicable methods (e.g. rockBlockConnected, rockBlockDisconnected, rockBlockMessageReceived etc).

Messages from the Raspberry Pi to RockBLOCK (MO)

This simple example connects to the RockBLOCK and attempts to send a message – rockBlockTxStarted is called to mark the start of the process,  and when the message has been successfully sent rockBlockTxSuccess will be called along with the “MOMSN”.  This is a unique message identifier for the transmission, you can search for this in the Rock 7 Core system. Alternatively, if the message fails to transmit rockBlockTxFailed will be called. Make sure that you call close to disconnect from the RockBLOCK.

 

Messages to the Raspberry Pi from RockBLOCK (via Space) (MT)

Receiving messages on your RockBLOCK is equally as simple – after you’ve queued a message with the satellites (using the Rock 7 Core, or the accompanying web-service) your message can be requested by the RockBLOCK by calling requestMessageCheck. This will attempt to establish a satellite session – if you’ve got a message, you’ll see a callback to rockBlockRxReceived with the unique message identifier (mtmsn) and the message payload (data) as a byte array.

You’ll also receive a callback to rockBlockRxMessageQueue, this will tell you how many (if any) additional messages are available to download. Remember, that you can only download one message per satellite session. Therefore, to get additional messages, you’ll need to call requestMessageCheck until count in rockBlockRxMessageQueue is zero. Make sure that you call close to disconnect from the RockBLOCK when you’re done.

 

That’s it – you can now send and receive messages from anywhere in the world!

To see pyRockBLOCK in action have a look at the Remote Controlled Weather Station project.

36 Comments

  1. Pablo

    Very Good project, I have a question about the requestMessageCheck(), I think have another name in the rockBlock.py library: messageCheck().

    and another thing using the RockbBlock+ is important to disable the FlowControl with the 3 wires serial connection using the command AT&K0.

  2. br

    I’m having an issue reading messages off the device with the SBD node.js library provided by Rock7 (http://www.veri.fi/iridiumsbd.tar.gz). It seems to work fine when using the USB to TTL cable, however when wiring directly to the GPIO header on the PI (following the steps in the above tutorial) I can’t seem to read the messages. The connection to the modem seems OK. I can initiate, send messages, and receive ring alerts and signal quality, but once the message is downloaded, I can’t seem to read it.

    http://cloud.ndmweb.com/sbd-nodejs-output.txt
    The full output and error I’m receiving with the node.js library using direct header connections.

  3. Anton

    Hi there! Not sure if you saw our e-mail. I’m new to classes and wondering how best to adapt the call to our existing code. Also looking forward to RTC capabilities!

  4. Makersnake

    Hey – Didn’t see your e-mail; do post any questions on here and I can answer the question for everyone ;-)

  5. Makersnake

    Hi Anton,

    Sorry for the delay in getting back to you, i’ve been busy on other projects…

    Your RockBLOCK code looks good; note the sendMessage function may take a minute or so to conclude (make sure your RockBLOCK is outside!).

    If you are using the RockBLOCK+ you may need to disable flow-control, you should complete these steps (only need to do this once) using a terminal application (like screen).

    AT&K0\n
    AT&W0\n
    AT&Y0\n
    AT*F\n

    After issuing these commands, remove power from the RockBLOCK for about 5 minutes (required to let the capacitor discharge, and reset the RockBLOCK) – then give your code a test again and it should work.

    Again a function to do these commands for you will make it into the library soon!!

    MS

  6. Anton

    Thanks for the pointers. I had previously disabled flow control.

    I had to change self().emit(payload) to rocket().emit(payload) and take a sneaky whitespace out of part of the class definition and all seems to be working well now.

    As my report times are few and far between (and testing shows the window of opportunity to send a message is small) is there (or what is) a clever way of returning a send pass / fail status so I can have my software take a short sleep and then have another shot?

    [To clarify for those interested – I take a temperature reading every minute and log to SD card, if an hour has elapsed since the last SBD report (and the “network available” hardware line is high) my software attempts to send a report, if it fails I’m hoping to keep checking (the hardware line) and trying every minute until successful then waiting another hour to start again]

    TIA, Anton.

  7. Makersnake

    Getting a RockBlockException at this point would suggest that the library cannot connect to the serial port or the RockBLOCK.

    Check that everything is wired correctly and you’ve not got another instance of your script running (and therefore blocking the serial port)

  8. steve

    I am also receiving an error from the requestMessageCheck() line in the receive software. The output is:

    pi@iridium1:~/pyRockBlock $ python MtExample.py
    Traceback (most recent call last):
    File “MtExample.py”, line 29, in
    mtExample().main()
    File “MtExample.py”, line 11, in main
    rb.requestMessageCheck()
    AttributeError: ‘rockBlock’ object has no attribute ‘requestMessageCheck’

    any ideas?

  9. Bart

    Hi

    I have the RockBloc+ with 15m cable with stripped wires. I am trying connect to it using RaspberryPi 2 through exact same USB to UART cable ( yes, I have checked with lsusb -v -d 0403:6001 ).

    Tx and Rx connected (tried to cross connect as well, nothing)
    ground connected
    External 24VDC power supply connected (red diode on)

    Once i run sudo screen /dev/ttyUSB0 ‘screen’ window pops up and …. silence, nothing for long minutes …. I can’t type in, the window it’s just there.
    At this stage does the RB+ need’s to be outside?
    I prefer to check before I get permission get up on the roof

    Could you give more details about PuTTY set up?
    Is it possible that RB+ have different baudrate?

    Regards

  10. Dail

    Hi MakerSnake,

    First I want to say thanks for putting together this information and making it publicly available to help the rest of us out there. I’m new to Python and indeed the rockBlock but I’m using both in research project as the RPI2 and rockBlock are integral components. My question is however that while i can run the code you posted (sending and receiving) and it completes cleanly with no errors i do not see any messages received in rock7 or in the run tool window (in pycharm) the proces finishes with exit code 0 as it should but no messages (I sent from the rock 7 site successfully).

    If I query the RB directly using “screen” and type AT+SBDIX i receive a message in rock7 with no payload so the transmission works that way buy cant get ti to work using the code. What am I missing here? DO you have an email I can reach you on to discuss other elements of the project “off-line”?

    Thanks

  11. Brandon

    I should have added I am using a raspberry pi 3. I am thinking that file is no longer used. My question however is; do I need to worry about the step covered in commenting out this line in inittab “T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt10″? I skipped this step but now I am having the same issue as Bart
    March 24, 2016 at 06:46 pm
    But he does not mention how he resolved the issue….

  12. Brandon Hardin

    Why was my question deleted? The Rock7 site is directing support to this page. I just want to get my rockblock working….

  13. Brandon

    Thanks Logan

    I bought the cable too and now I can see it! e.g. I get info back when I run lsusb. Still getting the hang problem when I run screen but at least I know it is there..

  14. Ryne

    Hi Snake,

    I made a post earlier (which is now taken down) and wanted to follow up with the problems I was experiencing. It turns out that the cable I was using was indeed the problem. Here is a link to the cable I was using for reference: https://www.amazon.com/gp/product/B004LBXO2A/ref=oh_aui_detailpage_o02_s00?ie=UTF8&psc=1

    I purchased the cable you suggested from SparkFun and it is working fine.

    However, I have ran into a few other problems. When running your first example (message from RPi to RockBlock (MO)), I could not get it to work until I indented the ‘rb.close()’ line to be in-line with the other ‘rb’ lines. I’m not sure why this is, but I thought I would share. Once the ‘rb.close()’ line was indented, everything worked as it should.

    When I tried to run the second example (message to RPi from RockBlock (MT)), I can not get it to work at all. After entering in what you have in the example above, I receive the following error:

    Traceback (most recent call last):
    File “”, line 2, in
    mtExample().main()
    File “”, line 4, in main
    rb.requestMessageCheck()
    AttributeError: ‘rockBlock’ object has no attribute ‘requestMessageCheck’

    Any help would be greatly appreciated. Thanks again for all that you do!

  15. Emma Lehman

    Thanks for sharing, this is very useful! Quick note – your example on this page calls rb.requestMessageCheck but should call rb.messageCheck.

  16. Grant

    I had a very similar problem to Bart, that is, the ground, 5V, and TX/RX cables are all connected correctly, the connections are seen when I run lsusb with the same cable, and then when I run screen /dev/ttyUSB0 19200 I get a blank screen that doesn’t respond. I was wondering if you had any insight as to why this is.

  17. Makersnake

    Hi Grant,

    I’d check the voltage across the large super-capacitor and confirm that you’re providing a solid 5V; remember that it can sometimes take up to 30 seconds for the RockBLOCK to respond from a cold-start (whilst the capacitor is charging). The other thing to try is a different FTDI cable – this is normally always the problem!

  18. Pascal

    Hello Makersnake,
    thanks for this wonderful work you did. Am using the rockblock to send data from sensors to the satellite. But now am having issues implementing the ring alert notification. I was able to tell the ISU to listen for (enable) SBD Ring Alerts using the AT+SBDMTA=1 . But in my code I don’t have any clue to listen for the +SBDRING from the ISU. How do you techinically do that, when the ring alert comes you use the command AT+SBDIXA to retrieve the message. Thanks in advance for your reply.

    Pascal

  19. Makersnake

    Hey Pascal,

    The library doesn’t currently support Ring Alerts; so you’d need to extend it to support this feature (I hope to add it myself in the future!).

    Some general advise, regarding this:

    Firstly, your RockBLOCK needs to be continuously powered with a clear view of the sky and undertake “regular” communications (e.g. once a day) to stay registered on the satellite network; otherwise they won’t know where your device is notifications won’t be sent. Secondly, a notification will only be sent once, so if you miss it for what ever reason, you’ll not receive another notification.

    Assuming you’ve followed the above; when receiving a new message, you’ll receive an unsolicited +SBDRING (my library has this disabled); so you’ll will need to be prepared to receive that (even if you’re in the middle of doing something else). Alternatively, you can disable the unsolicited notifications (AT+SBDMTA=0); and manually (but regularly) query the status using AT+CRIS; I think the latter is the better approach.

    In terms of extending the library (feel free to send me a pull-request): add a method to query AT+CRIS (every few seconds), if the response indicates that a RI has been received, you should fire off an AT+SBDIXA command (_attemptSession could be extended to issue AT+SBDIXA (instead of AT+SBDIX) depending on mode.

    Hope that helps!

  20. Aaron

    Greetings MakerSnake,

    When running your code i get a message back saying that the rockblock successfully sent a message, however, when checking for the message on the Rock7 website it never arrives. Do you have any suggestions? Thanks in advance!

  21. Makersnake

    Hello,

    Are you sure that you’ve got active line-rental and credits?

    Also, make sure that you’re correctly reviewing the response from sendMessage (True = Success).

  22. Aaron

    Thank you for your response! Yeah we have a line with 100 credits. Before i send a message i test the signal and on average it ranges from 2-5. The momsn returns an incremented value upon each success. Right now the momsn has a value of 4 so i am certain our messages are being sent. However, as i mentioned before, our messages do not show on the Rock 7 Core website.

  23. Makersnake

    That’s a strange one! Have you only just activated it? It can sometimes take a little time before it’s fully active on the Iridium network.

    An incrementing MOMSN means that it’s been successfully transmitted; but these will be discarded (and never appear in your console) if your device is not active on the network.

  24. Aaron

    Great news! I was able to successfully send a message and it now shows up in the Rock Core website. As you said, i probably had to wait a little bit until the device was fully registered. Thanks again for the help and providing an awesome api. Take care!

Leave a Comment

Your email address will not be published. Required fields are marked *