Raspberry Pi + SIM800 for GPRS

I have tried the following with both a Raspberry Pi 1 and RPi 3, using Resin OS 2.

My goal is to get the Raspberry Pi to use a SIM800 GSM module to get internet for Resin.io to work.

I tried two methods as described below. In both cases I enabled the UART on the RPi’s gpio header, and disabled the Linux console on the UART. The SIM800 module is connected and powered correctly. The hardware setup was proven to work using PPPd under a Raspbian install.

Method 1:
Resin OS 2 makes use of Network Manager, and therefore Modem Manager for PPP connections. I tried configuring modem manager to us the modem on the uart of the RPi. This however seems impossible as the RPi’s UART is blacklisted in Modem Manager. Any udev configs to force modem manager to scan the uart was fruitless.

After this I tried connecting the SIM800 via a USB-uart module to the RPi. In this case the modem was detected by modem manager, but only after a manual scan. This is because the USB-uart is graylisted in modem manager.

There is no way I know of to convince modem manager to automatically use the modem on either the RPi’s uart, or the USB-uart during headless bootup of the RPi.

Method 2:
Then I decided to try the same method I used to get internet under Raspbian, by following this tutorial: https://learn.adafruit.com/fona-tethering-to-raspberry-pi-or-beaglebone-black/setup
After this tutorial, it seems like the /etc/network/interfaces file is ignored by ResinOS, so I added the pppd to systemd to start my gprs connection at startup. This seems to provide an internet connection to ResinOS at startup of the RPi.

However the Pi does not show up on resin.io. After plugging in ethernet, I ssh’d in and saw that the gprs/ppp connection was up. I removed the default route via ethernet, while the default route via the ppp connection was still in place. I was able to ping towards the internet, and resin.io suddenly started seeing the Pi.

It seems that the resin.io service on the Pi is only started when Network Manager says there is an internet connection. The gprs connection that is set up using pppd does not trigger the resin services.

Sy my question is two fold:

  1. How can I convince Modem Manager to use my gsm modem that is connected to the UART?
  2. How should I get the resin services to start after my ppp connection is up?

Hi @jpmeijers,

In our docs, we have a guide for GSM based connections https://docs.resin.io/deployment/network/2.0.0/#cellular-modem-setup. I think you’re missing a configuration for your modem. Please follow the guide in our docs and let us know if you need further support.

Hi @nghiant2710

Your guide is exactly where I started. The problem is you can not specify a specific port for the GSM modem in the /resin-boot/system-connections/my-gprs-connection configuration file. This makes sense because Modem Manager auto detects the port on which a modem is connected.

As I describe in my original post, Modem Manager does not consider a Raspberry Pi’s UART as a valid port to scan during auto detection of modems. This is because the Pi’s SOC’s UART is blacklisted in the Modem Manager code.

Hey @jpmeijers

This issue looks like it could be helpful for your first question.

For your second question, the resin supervisor starts when the device is booted up irrespective of the connection status. I am not sure why the /etc/network/interfaces file changes are ignored, how did you apply them?

Hope that helps
Joe

I think I finally figured it out after reading ModemManager’s source code. It seems like ModemManager goes and look at the physical device at the root of the uart. Therefore not /sys/devices/platform/soc/20201000.uart/ but /sys/devices/platform/soc/.

Therefore this udev rule (I tried multiple including this one before starting this thread) did not work:

ACTION=="add", KERNEL=="20201000.uart", ENV{ID_MM_PLATFORM_DRIVER_PROBE}="1"

Adding the following udev rule and restarting the Pi allowed ModemManager to detect the modem correctly.

# vi /etc/udev/rules.d/98-modemmanager.rules
ACTION=="add", KERNEL=="soc", ENV{ID_MM_PLATFORM_DRIVER_PROBE}="1"

ModemManager now sees:

# mmcli -L

Found 1 modems:
	/org/freedesktop/ModemManager1/Modem/0 [SIMCOM_Ltd] SIMCOM_SIM800L

I now added a system-connection file as from here to the boot partition and restarted the Pi. After a few minutes the light on the GSM module starts to flash in the pattern that signals a GPRS connection. I however still do not see the Pi reporting to the resin.io dashboard.

Next step will be to burn a clean resinOS image to the SD card, add the UDEV rule, add the system-connection file, and restart. I’ll report back with my findings.

1 Like

Hey @jpmeijers, I guess you were saying that you’ll add that udev rule to the host OS? If so, I’d would probably recommend trying the udev rule within the container, see if that would work (ie. connecting to normal network let’s say over ethernet, pulling the application and then disconnecting the network/rebooting). Just thinking, because if that works, you are in a better position. Modifications to the hostOS basically force you not being able to update the hostOS remotely afterwards.

@agherzan, what do you think about this udev rule change, is it something general, that would be beneficial in general?

Hi, in order to see why it is not connectiong to the resin dashboard, could you please check the output of:

journalctl --no-pager -u openvpn-resin

(maybe leave out the private stuff if you want to paste it here :slight_smile: )

Hey @jpmeijers,

Sorry for bumping this old thread but I’m at a loss right now. I’m running into the same issue using the SIM808. Did you happen to find anything else out about this issue?

I added the udev rule and used the system-connection file provided.

I can’t seem to get the modem to show up no matter what I do.

Thanks
Nick

@Bioto is there any info in the logs, as mentioned above? What OS version are you running now / what device type?

Would it be possible enable support access and share with us a device with the connected modem that is in that state? Maybe we can take a look and advise better then. Thanks!

OS: balena-cloud--raspberry-pi-2.24.0+rev1-dev
Device: raspberry pi zero w

cat /var/log/messages

Nov 8 05:35:06 localhost authpriv.warn login[1202]: invalid password for ‘UNKNOWN’ on ‘/dev/ttyS0’
Nov 8 05:35:09 localhost authpriv.warn login[1202]: invalid password for ‘UNKNOWN’ on ‘/dev/ttyS0’
Nov 8 05:35:12 localhost authpriv.warn login[1202]: invalid password for ‘UNKNOWN’ on ‘/dev/ttyS0’
Nov 8 05:35:15 localhost authpriv.warn login[1202]: invalid password for ‘UNKNOWN’ on ‘/dev/ttyS0’
Nov 8 05:35:18 localhost authpriv.warn login[1202]: invalid password for ‘UNKNOWN’ on ‘/dev/ttyS0’
Nov 8 05:35:18 localhost authpriv.crit login[1202]: REPEATED login failures on ‘/dev/ttyS0’
Nov 8 05:35:24 localhost authpriv.warn login[1243]: invalid password for ‘UNKNOWN’ on ‘/dev/ttyS0’

udevadm info /dev/ttyS0

P: /devices/platform/soc/20215040.serial/tty/ttyS0
N: ttyS0
S: serial0
E: DEVLINKS=/dev/serial0
E: DEVNAME=/dev/ttyS0
E: DEVPATH=/devices/platform/soc/20215040.serial/tty/ttyS0
E: ID_MM_CANDIDATE=1
E: MAJOR=4
E: MINOR=64
E: SUBSYSTEM=tty
E: TAGS=:systemd:
E: USEC_INITIALIZED=18260778

systemctl status ModemManager

Nov 08 05:45:08 09a6c99 systemd[1]: Starting Modem Manager…
Nov 08 05:45:08 09a6c99 ModemManager[1465]: ModemManager (version 1.8.2) starting in system bus…
Nov 08 05:45:08 09a6c99 systemd[1]: Started Modem Manager.
Nov 08 05:45:11 09a6c99 ModemManager[1465]: Couldn’t check support for device ‘/sys/devices/platform/soc/20300000.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1’: not supported by any plugin

I enabled support access for my device and i’ll leave it online. I do have a couple specific questions about my setup regarding networking but I’m trying to get this working before continuing. If you need any more info let me know how I can get it to you.

Thanks
Nick

@imrehg Hey, was just checking in.

What’s your device’s UUID (so we can check the logs)?

Also checking with our device support team, whether we have ever tried SIM808 and whether it’s expected to work as of now.

@imrehg

09a6c99dbc6bf4e117f6bd47d237d808

That should be the uuid.

I never got this to work, so I decided to move on and use different hardware. I tried with a Huawei USB 3G dongle, which worked, but disconnected at least once a day. And then I had to manually restart the Raspberry.

Stability is crucial, so I decided to split the concerns and use a dedicated LTE router and plug the Raspberry Pi into it using ethernet. It’s a stable solution, but sad, as a Raspberry Pi with GSM/3G/LTE module can be much more compact.

Well shoot thank you for the info. When I was using raspian to test my code before moving it over to balena I also had to manually restart the pi once a day. It turned out however that I could still ping out using IP’s directly just not using DNS. I’m not sure if its a DNS issue specifically with the PI or something else entirely.

I’m hoping I can get this working on balena. I love the fleet management aspects of the platform and I think it would be perfect for the project I’m working on.

If I can figure anything out I’ll reply to this thread @jpmeijers

And so after more than a year I happen to have the same issue again. This time I am trying to make Balena work on a RAK Wireless Pilot Pro gateway with an LTE module. The platform is a Raspberry Pi 3 with a shield for LTE and a shield for LoRa.

I finally figured out which udev rules to apply, and how to apply them in the correct manner. On the SD card in the boot partition there is a config.json file. Add an os element with a udev element in it. Example below.

{
   "apiEndpoint":"https://api.balena-cloud.com",
   "appUpdatePollInterval":"600000",
   "applicationId":"<retracted>",
   "applicationName":"GatewaysTest",
   "deltaEndpoint":"https://delta.balena-cloud.com",
   "deviceApiKey":"<retracted>",
   "deviceApiKeys":{
      "api.balena-cloud.com":"<retracted>"
   },
   "deviceType":"raspberrypi3",
   "listenPort":"48484",
   "mixpanelToken":"<retracted>",
   "pubnubPublishKey":"",
   "pubnubSubscribeKey":"",
   "registryEndpoint":"registry2.balena-cloud.com",
   "userId":"<retracted>",
   "username":"<retracted>",
   "vpnEndpoint":"vpn.balena-cloud.com",
   "vpnPort":"443",
   "uuid":"<retracted>",
   "registered_at":<retracted>,
   "deviceId":<retracted>,
   "os":{
      "udevRules":{
         "98":"ACTION==\"add|change|move\", KERNEL==\"soc\", ENV{ID_MM_DEVICE_PROCESS}=\"1\"\nACTION==\"add|change|move\", KERNEL==\"soc\", ENV{ID_MM_PLATFORM_DRIVER_PROBE}=\"1\"\nACTION==\"add|change|move\", KERNEL==\"3f201000.serial\", ENV{ID_MM_PLATFORM_DRIVER_PROBE}=\"1\"\n"
      }
   }
}

With these udev rules in place ModemManager is more than happy to scan the /dev/ttyAMA device. In my case it however does not yet detect the Quectel module on the RAK gateway. I still need to figure out which serial port the module is connected to and debug further from there.

Seems like one need to enable/power-on the modem before the serial connection becomes available:

Awesome! Thank you for the precious feedback, it’s always very welcome