Modem Manager GPS issue

@izavits @shaunmulligan Oke i have installed the latest resinOS: Resin OS 2.9.6+rev1 (prod) and tried the following commands without new results:

mmcli -m 0 --location-status
mmcli -m 0 --location-enable-gps-raw
mmcli -m 0 --location-enable-gps-nmea

mmcli -m 0 --location-get

/org/freedesktop/ModemManager1/Modem/0
  -------------------------
  3GPP location   | Mobile country code: '204'
                  | Mobile network code: '*'
                  |  Location area code: '****'
                  |             Cell ID: '*******'
  -------------------------
  GPS NMEA traces | Not available
  -------------------------
  Raw GPS         | Not available
  -------------------------
  CDMA BS         | Not available

@RDB , the on thing you can try is to set the GPS in unmanaged mode, using --location-enable-gps-unmanaged flag and then you can send AT commands to the modem using the following:

mmcli -m 0 --command="AT+CGPSINFO"

You will obviously also need to pass all the commands mentioned in the link above. You should then be able to read the GPS nema sentences from the /dev/ttyUSB* ( Not sure which number port it will be)

I would also encourage you to raise this question on the modemManager mailing list the lead developer there is very responsive and helpful.

@shaunmulligan Thnx for the suggestion. I will subscribe to the mailing list and see if i can get some help from there. Also i will try to do a manual GPS connection with the AT commands to see if that works.

@shaunmulligan I tried to add this line to the docker file:

### copy custom udev rules to container
COPY udev-rules/ /etc/udev/rules.d/

and then run:

$ udevadm trigger

Then the modem rules are triggered and visible:

lrwxrwxrwx    1 root     root             7 Jan 23 13:47 modemS3 -> ttyUSB3
lrwxrwxrwx    1 root     root             7 Jan 23 13:47 modemS2 -> ttyUSB2
lrwxrwxrwx    1 root     root             7 Jan 23 13:47 modemS1 -> ttyUSB1
lrwxrwxrwx    1 root     root             7 Jan 23 13:47 modemS0 -> ttyUSB0
lrwxrwxrwx    1 root     root             7 Jan 23 13:47 modemPPP -> ttyUSB3
lrwxrwxrwx    1 root     root             7 Jan 23 13:47 modemGPS -> ttyUSB1
lrwxrwxrwx    1 root     root             7 Jan 23 13:47 modemAT -> ttyUSB2

But the downside is that the host OS is losing the modem connection and not recovering from it. So the best thing would be to add the custom udev rules to the hostOS, but i havent seen a solution on how to do this.

Is there a way to add it to the hostOS? So it won’t lose the modem on a restart of the container but still keeps the udev rules. I think i really need those to be sure to always find the right ttyUSB* for the GPS, since they can shuffle on a reboot.

Hi @RDB.
I’m also trying to get an embeddedpi to work with modemmanager, however not with the same modem as you. I’m using the Quectel EC20 mini-PCi modem @shaunmulligan mentioned. I can see it listed as an usb device, but not with “mmcli -L”. Did you do anything special to get modemmanager to recognise it?

@rytterlund what image are you using? I think i did got it working with Resin OS 2.7.8+rev1but not with the versions before. But iam not sure.

And do you have a app container running? Maybe you can try to put it in Localmode. Then no app container is running. Because of the base img containers running on start the command: udevadm trigger and this is making the modem manger not to recognize the modem anymore. This is the problem iam running into.

So i think what you can do is to run localmode or run a really basic app. And then try if modem manger is recognizing the modem on the HostOS.

@RDB, you are right. I got modemmanger to recognise the modem when I’m not starting or installing anything in the container. The GPS is working as well, at least the NMEA.

@rytterlund Oke nice!
But how do you get your GPS readings available in your container?

@RDB We use https://github.com/pyserial/pyserial to read the raw GPS messages from the right ttyUSB* device.

Using the udev rules from the embeddedPI website we found that the right udev rules can be got with this snippet of code:

GPS_DEVICE="/dev/$(ls /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4/1-1.4\:1.1 | grep ttyUSB)"
AT_DEVICE="/dev/$(ls /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4/1-1.4\:1.2 | grep ttyUSB)"

The last number in the path corresponds to the bInterfaceNumber defined in the udev rules.

@sdehaes Thanks, i have a slightly different udev rules file so i had to adjust them a bit.

What i also noticed is that when i run the command udevadm trigger with a 10 sec delay the custom rules are triggered and added correctly and the device keeps hold of the modem. I still have to test this some more, but it might be a working solution.

Edit: I have tested some more but i don’t think adding the delay it is stable enough.

@RDB, since the modem is not working when using the container I cannot read the GPS from there.
However, when I use a standard RPi3 with a usb GPS attached, I install gpsd and python-gps packages inside the container, and use a small python script to get the readings.

@rytterlund what version of resinOS are you working with. I know the Quectel EC20 had some kernel issues with earlier versions, so I would recommend trying with the latest 2.9.6+rev1

@RDB, One thing I could suggest trying is to add some of the modemManager udev rules into your container aswell. I have done something similar before for Huawei modems as seen here: https://github.com/shaunmulligan/soracom-resin-modemAT/blob/shauns-branch/Dockerfile.template#L37

If you add the correct rules for your modem (look in the modemManager repo) then in theory the container udev will correctly ignore the modem device on restart.

@shaunmulligan i have a similar rule in my docker file.
It is copying the custom udev rules of the modem to the container.
But they will not work without the udevadm trigger command.
But the thing is that command makes the modem sometimes disappear. I tried adding a delay on this trigger command of 30 sec or so and that looked like it worked. then tried with 10 sec delay and that wasn’t stable.
Now iam not sure anymore if adding a delay on the trigger is stable at all.

@shaunmulligan Indeed the modem is passing me on default all the NMEA messages without having to enable it. When running the command I do get results from the modem:

$ mmcli -m 0 --command="AT+CGPSINFO"
response: '+CGPSINFO: ,,,,,,,,'

When adjusting the antenna a bit closer to the window, the result was much better:

$ mmcli -m 0 --command="AT+CGPSINFO"
response: '+CGPSINFO: **********,N,***********,E,260118,082556.0,45.2,0.0,288.8'

So now I was also able to get the data in the container from the serial port /dev/ttyUSB1 and parse the data into a lat long without having to do much configuration after all.

@RDB that is awesome news, glad you got it all worked out. It should also be possible to install the mmcli tool in your container (The repo I linked to earlier in the thread actually does that) this has the advantage not having to worry about which tty the NMEA sentences are on, but would require you to do polling instead of just ingesting GPS events as they come out.

How quickly does your SIM7100 get a GPS fix, I used to have the older SIM5360, but it would take a minute or so to get a fix with an active antenna. Also out of interest, what kinda application are you building, I am always very curious about GSM and GPS based projects :slight_smile:

@shaunmulligan you where right. I do have to send at least one time the command: AT+CGPSCOLD after a reboot. Otherwise the modem is nog going to stream the data to ttyUSB1.

I can do this manually with the mmcli command in the hostOS, but i would like to send this command one time to the ttyUSB2 within my docker file. Do you know what line i can use to send the command to the serial port?

I tried something like this on command line in the container, but i don’t see it changing:

echo -ne "AT" > /dev/ttyUSB2
echo -ne "CGPSCOLD" > /dev/ttyUSB2

Maybe you have an idea how to trigger the serial and get the stream started without having to add mmcl to the container? Maybe with a bash script and a docker file rule?

@shaunmulligan, I’m using the latest 2.9.6+rev1, and I’m also copying custom udev rules of the modem to the container. But It’s not working. @RDB, how did you get it to work?

@rytterlund did you get the host to recognise the modem with mmcli -L? And did you add a good cellular network manager file in the systems-connections folder? Mine has only the basics. Just APN, name of the connection, type gsm and autoconnect.

And did you comment out the udevadm trigger in the base img of the container? You dont nessesarily need the udev rules. Since you cannot use the udevadm trigger command anyway.

@RDB, I think the problem with the snippet you shared there is that you are sending the AT commands to the NMEA port, you need to send it to the ttyUSB that is for AT commands. So probably something like:

echo -ne "AT+CGPSCOLD" > /dev/ttyUSB3

Would be what you need. Personally I would just toss mmcli in the container, its a statically compiled C binary, so it basically adds very little size to the container and gives you a lot more control :slight_smile: