Skip to content

Rock7 RockBLOCK (Iridium)

Rock 7 Core is Ground Control's older RockBLOCK platform, the one before Cloudloop. Some Iridium modems are still registered there. The adapter receives their messages through a delivery group's HTTP endpoint and sends commands through the MT web service (decision D156). New modems belong in Cloudloop; this adapter is for the ones that stay.

Built from the RockBLOCK web services documentation (docs.groundcontrol.com, fetched 2026-09-09). The MT endpoint and the connection test were confirmed live with Smart Parks' portal login on 2026-09-10 (FAILED,16,No Data for the empty probe, so the login is checked before the message), and the first delivery arrived the same day: the OpenCollar Edge SP051890 (RockBLOCK 204514) in a delivery group with the dev server's address in HTTP_POST, decoded into a status message and a GNSS fix (fixture under tests/fixtures/payloads/rock7/).

Setup

  1. Under Server admin, Data sources: New data source, adapter Rock7 RockBLOCK (Iridium). Config: allowed_source_ips (Rock7 documents no addresses; leave the list empty), web_url for links. Credentials: username and password, the portal login, needed for commands only.
  2. Copy the webhook URL shown once after saving. It carries the source's token as ?token=... because Rock7 sends no authentication.
  3. At rockblock.rock7.com open Delivery Groups. Make a group (or use one) and add the RockBLOCKs to it from the list under the group's name. Under the group's Delivery Addresses paste the webhook URL, token included, in the Address field and choose the format HTTP_POST, then Add. HTTP_JSON works as well; HTTP_POST_GEOJSON, HTTP_THINGSPEAK, EMAIL_ROCKBLOCK and SBD_ROCKBLOCK are other shapes the server does not read, and HTTP_POST_INSECURE skips the certificate check and is not needed. There is no field for headers, which is why the token travels in the URL. A group can have several addresses, so an existing pipeline keeps its own. Rock7 expects HTTP 200 within three seconds and retries with a doubling backoff for fourteen attempts, almost six days.
  4. The IMEI of the modem is the device identity (type imei). Link it to the collar, or accept it from Needs attention when the first message arrives. A delivery carries no name, only the IMEI and the RockBLOCK serial, so a device created from Needs attention is named after the IMEI until renamed; better make the device with the collar's name first and link the identity to it. There is no device list to sync: Rock7 has no API for it.

Inbound

A delivery becomes one source event on the Iridium channel:

Rock7 field Smart Parks Protect
imei identity imei
serial identity attribute
data (hex) data_hex for the device driver, untouched
transmit_time (YY-MM-DD HH:MM:SS, UTC) satellite_delivered_at, provenance only
momsn, iridium_session_status, iridium_latitude, iridium_longitude, iridium_cep (km) the satellite session (ADR 0023); device_type stays provider metadata
a message without payload event type sbd_session, kept raw, nothing decoded

The OpenCollar driver reads the payload as stacked stored records, as over Cloudloop, so the record's own timestamp stays canonical.

Outbound MT

Commands over a Rock7 route call POST https://rockblock.rock7.com/rockblock/MT with the IMEI, the portal login and the frame [port][msg_id][len][data] in hex, at most 270 bytes. The answer OK,<id> reaches queued; the modem downloads the message at its next session, and a ring alert wakes a powered modem in coverage. FAILED,<code>,<description> is read by code: 10 is a wrong login (an authentication failure), 99 a Rock7 outage (retried), the rest (no such IMEI on the account, no line rental, no credit, bad hex, too long, empty) a rejected command with the reason. A command option flush clears the modem's queue first.

Connection test

Rock7 has no ping. The test sends an empty message to a placeholder IMEI and reads the failure code: 10 means the login is wrong, any other code means the login was accepted. Confirmed live on 2026-09-10: the right login answers FAILED,16,No Data.

What the session tells you

Every delivery carries the satellite session (ADR 0023): its outcome, the modem's session counter (MOMSN), the size, and the network's estimate of where the modem was with its error radius (CEP, in km). The traffic view shows them on the row, the source event dialog under Provenance, and the device's Connectivity tab keeps the last session with the sessions, bytes, missed sessions and redeliveries of the period, apart from the device's own health. An estimate the network stands by is also a position of type network with its radius as accuracy (ADR 0024): it draws as a circle on the live map ("Network locations" in the Coverage tab), joins tracks, records and exports when asked, and becomes the current position of a device or an entity only under its location source setting. An estimate the network calls poor is kept on the session but never becomes a position. A retry of a delivery the server did not acknowledge is stored as a duplicate, not processed twice. A fix far outside the estimate's circle is noted on the trace.

Troubleshooting

  • 401 on the webhook: the URL lost its ?token=; copy it again from the data source.
  • 422 Body is not valid JSON, or a failed source event without an imei: the delivery address has another format than HTTP_POST or HTTP_JSON.
  • Rock7 refused the login: the portal username or password is wrong or changed.
  • insufficient credit: top up the account; the command was not queued.