Dear Maintainer,

Some GSM/UMTS Modems built into Notebooks like the Lenovo T420 have GPS abilities.

Previously it was possible to access the GPS via special MGM-GPSD Modules. But
those have been discontiunued a while ago and are not being supplied with
the Linux Kernel anymore, as the 'prefered' way to access the GPS not is via
Serial interface.

Those modems provide three, as far as I understand, identical serial interfaces.
So you can use one as GSM Modem and another one as GPS.

But you need to enable GPS function by issuing some AT commands:

http://www.thinkwiki.org/wiki/Ericsson_F3507g_Mobile_Broadband_Module#Using_the_card_as_a_GPS_receiver

AT*E2GPSCTL=1,1,1
AT*E2GPSNPD

does the trick on mine.

Unfortunately the modem resets itself when the serial device is closed. So you cannot use minicom or a
script to put the modem in GPS Mode and then start gpsd. Also when gpsd would close the connection
because no client is connected, this would reset the modem.

Idealy, native detection for the F5521gw GPS would be built in into gpsd (ATI returns F5521gw) so that
gpsd could initialize the GPS mode upon opening the serial device.

I have been trying to send the serial commands with gpsctl -x , but this does not seem to work either.

So my feature Request here is:

Please to add support for F5521gw GPS detection and initialization, or add a way to send an arbitary init string to
the serial gps device when opening the device.

Obviously, the best solution here is support from upstream gpsd. But I
have a couple of suggestions which may help you work-around that lack of
support.
opened the serial port before your script quits?

Something like this, in the sysvinit style:
script_to_initialize_modem &
sleep LONG_ENOUGH_FOR_INITIALIZATION
start-stop-daemon ... gpsd ...

script_to_initialize_modem does this:
  open the serial port
  send the data
  sleep LONG_ENOUGH_FOR_GPSD_TO_START

With systemd, you'd probably want to do something like:
1) A separate service for the initialize script, which is
WantedBy=gpsd.service
2) To stall gpsd's startup long enough for your script to have
initialized the device, create a drop-in like
/etc/systemd/system/gpsd.service.d/delay.conf with this:
    ExecStartPre=/bin/sleep N

Try passing the -n flag to gpsd by adding it to GPSD_OPTIONS in
/etc/default/gpsd. This should cause gpsd to keep the serial port open
even with no clients.

Dear Maintainer, dear Benoit,

I am an owner of an Ericsson H5321 gw module and experienced gpsd user. Since my last approach to finally make use of my gps receiver, there must have happend something with the debian configuration. The information from the thinkwiki.org pages were, as you already mentioned here, useful for me and turned out to make the gps receiver work for me. I already tested out functions of the F3507g receiver and posted a working solution on ubuntuforums about 7 years ago. Now I use a different receiver and when first tested everything seemed working well. This was about 3 years ago. Now I am confused that none of the previously working steps led to any output on my device port. When last tested I recognized that something had changed in the way gpsd can operate on the port. In the past it wasn't possible to directly read /dev/ttyACM2 because of permission issues. The necessary information are posted here: https://forum.ubuntuusers.de/topic/gpsd-mit-ericsson-f5521gw-mobile-broadband-mod/#post-6727147 .
For now I can only report that gpsd can't read from the pipe mentioned in this post. So for me it's not reproduceable anymore. Maybe I'm missing something. I searched the web again but didn't find a solution.
I turned the gps receiver on in the way I was able to remember, went outside, but couldn't get any output of the NMEA stream when reading from /dev/ttyACM2. I tried around with hard-resets and different ways connecting clients, reading directly from port, but nothing turned out to work for me.

Any further help would be appreciated,

Ben

Hi,

please note that this is not a forum and not a user help lines, its a
bug tracker. Please fix your device and permissions issues first, with
the help from a debian-user mailinglist for example, and if you can send
a proper report, do so.

what is a "device port"?

permission issues are not a problem that gpsd can fix for you. Use udev
rules or whatever else is necessary.

Which is just fine, because what you are doing there is sad sad
nonsense. Learn to fix device permissions.

Thas a LTE modem or something similar, you'll probably have to switch it
into gps mode first. Nothing gpsd will do for you.


So basically:

1. fix your permission issues (using a pipe is not a fix!), maybe using
udev or whatever else is necessary.
2. learn how to put your modem into a working mode
3. trigger gpsd to read from you device.


If you then run into bugs, run gpsd in debug mode...


Bernd