The keyword of the problem there is Iridium. Their SBD (short burst data) and in fact all their services are just extremely expensive. This reseller doesn't really seem to put much margin on it.

When I had a sat phone (needed to travel sometimes to questionable places for work) I used Thuraya which is much cheaper for airtime. 40€ gets you a whole year's worth of inbound service (airtime) and about 15 mins of call credit for outbound. With iridium that gets you about one month.

But Thuraya only had 2 active sats. One geostationary over the middle east and one over the far east. No service over the Americas. The Asian one failed early this year and the coverage for the region which can't be met by the other one is now inoperable.

The middle east sat is actually beyond its planned service life and if it goes down there's no immediate backup. Though a replacement is ready for launch according to Wikipedia. You also need visibility of the southern horizon (or northern, if you're in the southern hemisphere). So for hiking in valleys it's not a good bet. The same goes for Inmarsat for that matter. But they do have more sats.

Iridium in contrast is fully worldwide, has a robust constellation of many low earth orbit sats that move across the sky so you don't need to see a fixed point. It's more robust for emergencies. But the price is much higher. It's a trade-off. You get what you pay for.

As I no longer travel for work but do hike, I ditched the Thuraya and got a Garmin InReach which runs on iridium. But that costs more than Thuraya even though it can only send messages. Though with their latest cost increase I might just drop it and find something cheaper. Maybe Starlink direct to cell.

I've been wondering how Iridium costs are tallied.

Recently had two calls with an Iridium phone, one sent and one received, about 1 minute each. T-Mobile charged me $50 for those.

I found it very odd - it seemed like Iridium was somehow passing the call fees onto me, but I can't be sure because the T-Mobile rep I chatted with was unable to comprehend the situation (I suspect I was talking to an LLM, but it ultimately gave me a $30 rebate at least).

You can actually achieve this even with Iridium Go. I tried it years ago and it worked.

It isn't too documented, or let me say it isn't documented at all but you can write AT commands and start raw TCP connections and read and write to that socket.

And it is actually reasonably priced. I tried to open SSH connections and it was barely usable. You get a very small number of bits per second.

Edit: Found the private repo I had created back then in case anyone has any interest. It looks like I did something like this:

    func (sess *IridiumGoSession) ActivateDataWithCustomSettings() (*PerformTaskResponse, error) {
     return sess.PerformTask("2",
      MakeOption("set state", "true", "bool"),
      MakeOption("Firewall allow all traffic", "false", "bool"),
      MakeOption("Firewall exceptions", "XXX.XXX.XXX.XXX-all-tcp", "bool"),
      MakeOption("Enable DNS forwarding", "false", "bool"),
      MakeOption("Dial number", "0088160000330", "bool"),
     )
    }

Indeed - a Garmin InReach is about US $500 and already ruggedized and tested. I understand the DIY aspect of this project is the fun part, but it definitely isn't a way to save money.

Depending on how you look at it, Starlink can be incredibly cheap compared to Iridium. It’s still not cheap from where I’m sitting in my clapped out Honda Civic, though.

Edit: I think $250 for 50GB of truly global data. I can’t do the math right now, but it seems like a better deal at face value.

> Would be nice if there was an actually affordable, programmable Iridium device.

I remember reading about this a while back, but doesn’t SpaceX offer some kind of IoT modem for a low cost (not the Starlink dishes)

Where did you buy Iridium access for $17/month?

Hey Juan, this looks promising - using a pre-shared schema would allow you to reduce payload sizes in the same way using pre-shared dictionaries makes compression more efficient (such as with zstd or brotli). Having worked on exactly this space in the past (sending and receiving messages from a microcontroller that eventually go through an Iridium SBD modem), some feedback:

After spending a few minutes poking around your landing page, I'm not sure how JSON BinPack works. I see a JSON Schema, a JSON document and then a payload, but I'd be interested in the low level details of how I get from a schema to a payload. When I'm on a microcontroller, I'm going to care quite a bit about the code that has to run to make that, and also the code that's receiving it. Is this something I could hand-jam on the micro, and then decode with a nice schema on the receiving side? Understanding the path from code and data to serialized payload would be important to me.

One thing that was nice about using ProtocolBuffers for this was that I had libraries at hand to encode/decode messages in several different languages (which were used) - what is the roadmap or current language support?

I can understand how ProtocolBuffers handles schema evolution, but I'm still not sure how JSON Schema evolution would work with JSON BinPack. An example would move mountains.

Finally, if I were digging into this and found it had switched from Apache to AGPL, and required a commercial license, it would be a hard sell vs all the permissively licensed alternatives. At the end of the day, Iridium SBD messages are like 270 bytes and even hand rolling a binary format is pretty manageable. I think I could swing budget for support, consulting, maintenance or some other service. But if I were evaluating this back when I needed a serialization format, and ran into AGPL, I would bounce almost immediately.

> until they offered me a base salary of $135,000 in Phoenix

It's crazy to me that $11,250/month could be considered low for a comfy job like engineering manager, especially if the work is interesting. The cost of living in Phoenix must be through the roof?

Is it just me, or does the wording of this comment imply that you passed up the Iridium job to work somewhere else that underpays their engineers? Seems like you meant to imply the opposite.

[dead]

NTN seems to be only offered by geostationary satellite operators at this point, which unfortunately puts the use case from TFA out of coverage. See for example Inmarsat's coverage: https://www.inmarsat.com/content/dam/inmarsat/corporate/core...

I'm not even sure if Skylo is live with Inmarsat at this point, or if there are any other NTN providers covering oceans.

OP is using Iridium SBD according to the article, specifically this modem: https://www.groundcontrol.com/product/rockblock-9603-compact...