Hi, it would be very useful to have a mode where ModemManager can handle a "fake" GPS NMEA stream, instead a waiting for a real GPS device to get a fix, which usually requires outdoor conditions and a clear sky view. Shadowing the GPS data port of a modem-gps device, with data read from an existing file containing NMEA sentences at a given frequency is a possibility. This debug mode could open interesting perspectives, by creating for example a pipe between ModemManager and an application that can output such NMEA stream. FlightGear, the flight simulator, is such an application that can update the plane location live with a NMEA stream. This way, gnome-maps can be used to see the plane position in FlightGear.
Created attachment 114529 [details] [review] port-serial: add a fake mode to debug gps nmea traces This is an ugly proof of concept of the idea of a "fake" nmea mode hooked in ModemManager. Two environment variables FAKE_NMEA_FILE, and FAKE_NMEA_INTERVAL control the behaviour of the patch. For example, this can be used to masquerade a modem-gps device with NMEA data coming from another device, not accessible by modemmanager, like a bluetooth GPS device via /dev/rfcomm0.
If the target is to e.g. see the plane position reported by FlightGear in gnome-maps, it would be a much easier solution to setup geoclue to read from another GPS location provider in addition to ModemManager. Also, ModemManager has some setup to e.g. test GPS location without needing a real GPS fix, see e.g. this: http://cgit.freedesktop.org/ModemManager/ModemManager/tree/plugins/option/mm-broadband-modem-hso.c#n680 But I don't think ModemManager should be setup to gather location from other non-modem GPS providers. ModemManager does GPS positioning just because modems expose GPS location, and because controlling the GPS (start, stop, a-gps...) is done through the same control channels as other modem related features. ModemManager will not, for example, support GPS-only non-modem devices. ModemManager is just one provider of GPS location, not *the* GPS location provider... That said, I think there should be another component handling non-modem GPS devices like the one you target. That component should handle serial GPS devices, and should expose GPS NMEA traces over dbus just like ModemManager does. I'll close this as wontfix, as I don't think it's a bug for MM.
Would a patch similar to what's done is mm-broadband-modem-hso.c#n680 be accepted, if the code would be conditioned by an environment variable or an option switch ? By the way, the GGA traces generated by mm-broadband-modem-hso.c probably have a wrong checksum :) the last part of the string, after the "*"
(In reply to Fabrice Bellet from comment #3) > Would a patch similar to what's done is mm-broadband-modem-hso.c#n680 be > accepted, if the code would be conditioned by an environment variable or an > option switch ? > > By the way, the GGA traces generated by mm-broadband-modem-hso.c probably > have a wrong checksum :) the last part of the string, after the "*" I really don't see it as something useful at all... and you cannot test the gps tty alone, you need a modem object around. What you really need is to integrate another gps-only daemon with geoclue, not just use MM because it already has that support... :/
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.