ChatGPT with Garmin Inreach

Why would you need that?

I expect this post to get obsolete quickly, as there’s a lot changing in both AI and satellite communication fields. However, making ChatGPT (AI chatbot) work with a satellite communicator, was a fun little side project I did, and perhaps these notes could be interesting to some.

In 2023 I went on a trip into the Amazon rainforest. This area had no network coverage, so I decided to buy the Garmin InReach Mini device, just in case. Roughly at the same time I have been playing with AI chatbots, and enjoying this activity quite a lot.

And so, I thought:

• This 2-person Amazon trip I am going for, is not something I usually do. It could be pretty boring. I will really miss Internet access!
• I could imagine a situation where some basic Internet access could save my life. That’s a stretch given that satellite devices have the SOS button, but, well, Internet access could significantly reduce the probability of me pressing that SOS button.
• And finally, it just seemed like a fun little side project to spend some time on.

About Garmin InReach Mini

From the device side

Some practical information about the device (in 2023):

• It allows you to send and receive messages of up to 160 bytes long (UTF-8 encoded). You can send them to an email address or a phone number.
• Typing and reading messages on the device is not practical. You can use the Earthmate app on Android to speed things up, although the app is crappy. (It seems to require a constant, stable Bluetooth connection to your device, otherwise it will just silently skip some messages, and you need to resync from scratch.)
• With a wide, clear view of the sky (e.g. middle of the Napo river) sending or receiving a message usually took me around 1 minute. In a city (outside of my window), this took around 20 minutes. In the jungle, it took me 3-60 minutes.
• I sometimes received messages in batches (e.g. 3 at a time), but then needed to wait a lot for the fourth one, even though all 4 messages were ready to be received.
• Messaging costs you money, but there are different plans. If you expect to send a lot of messages, you can get an unlimited plan.
• Interesting fact: I noticed that messages always arrived in the same order they were sent. Not sure why that is, but I imagine they use a protocol which makes the Iridium satellites transmit “previous” messages only, until they get an ACK from the Garmin device (after which they add newer messages to the pool). I didn’t know that when I was working on my project – if I knew, I could have skipped some numbers in message prefixes.

From the receiver’s side

Email

If you receive messages in the email inbox, it will look like this:

From: <Sender's name> (via inReach) <no.reply.inreach@garmin.com>
Subject: inReach message from <Sender's name>

<Message content>

View the location or send a reply to <Sender's name>:
<Magic link>

Do not reply directly to this message.

This message was sent to you using the inReach two-way satellite communicator with GPS. To learn more, visit http://explore.garmin.com/inreach.

The magic link sends to Garmin’s website which allows you to send a reply. Each reply is limited to 160 characters, but you can send unlimited number of replies from one such link.

Phone

If you receive messages on your phone:

• They will contain a shortened link to Garmin’s website, which will allow you to send the reply. The content of the received message may be truncated to make space for this link, but the full message will be available on the website.
• They will come from a random phone number, which may change in time. If you send a reply to this number, it may work, but – as far as I understood – it’s not guaranteed to, especially if a lot of time has passed (as the numbers may change).

How to handle automated replies?

At the time of writing this, Garmin does not have any API for that. The system was designed for humans only, not bots. How do we make it work with bots then?

It turned out, that responding to the message via email was pretty straightforward, so I went with that.

Why not SMS?

At first I tried sending replies via SMS:

• I registered a new phone number in ClickSend (clicksend.com), sent a message from my Garmin device to that number. The message got delivered fine.
• However, when I attempted to respond to this message via ClickSend, it did not work. The response was never delivered to my Garmin device.
• ClickSend customer support replied: We heard from the network and can confirm that no general degradation that could be linked to this. We highly suggest that this issue is isolated to this specific subscriber and we would therefore like to advise that the end-user reaches out to their service provider for further assistance.
• My conclusion was that either:
  • (a) Garmin somehow detects and blocks ClickSend messages, or
  • (b) ClickSend is not reliable with the sending process in general, or
  • (c) Garmin is not reliable with receiving SMS messages in general.
• Either way, SMS didn’t work well for me.

The “pipeline”

To summarize the entire process looked like this:

• As I am a Gmail user, I used Apps Script for detecting the email trigger. I send emails to myusername+chatgpt@gmail.com and I checked the existence of the +chatgpt suffix in my code. Then I just pushed it to a queue on my server with UrlFetchApp.
• On the server, I parsed the email, made sure it’s not a dupe, and stored it in a database. It’s an old PHP server of mine, and I don’t like PHP, so I just stored it (behind some simple authorization wall), and allowed my personal PC to retrieve it.
• Then I setup a cronjob on my personal PC which checked the queue every couple of minutes. It retrieved the next email from the queue, and parsed it. It’s format is easy enough for that (although it’s not an API, so it can always change). See example email above.
• In case when the parsed email looked like a part of the message (e.g. it had a 1/3: prefix), I waited with processing it until I got all the parts.
• Once I had all the parts, I removed the messages from the queue, and replaced them with a different item on a different queue – this one representing a request for a ChatGPT response.
• I used the OpenAI API to get the response, and stored it in yet another queue (“messages to sent”).
• I handled sending the message to InReach via WebDriver. At the time of writing this, there was no Captcha, nor any other anti-bot check on the site. Perhaps it might even work if you just send a prepared POST request at the form URL, skipping the website entirely, but I have not tried it. I decided to use WebDriver instead.

Some notes on this process:

• If this was a “real app”, I would probably attempt to use RabbitMQ or similar, but a simple pull-based queue of my own was enough for my needs. And I just didn’t feel that I had time to learn RabbitMQ at that point.
• Why not do the processing directly on my website (why involve my home PC)? Because my website is running on Amazon Lightsail and has very limited resources. In particular, it wouldn’t be able to run WebDriver. Also, it was running PHP, and I wanted to build the remaining parts in NodeJS.

Anyway, that’s it. Perhaps it might help some other crazy programmer who might plan to visit some areas with no network coverage in the upcoming months 😉 (Because probably in 2025 you will have Starlink everywhere, so yeah, that’s already an almost obsolete post.)