On Mon, Nov 27, 2023 at 2:51 PM Andreas Kemnade <andreas@xxxxxxxxxxxx> wrote: > > Hi, > > On Mon, 27 Nov 2023 15:54:24 +0200 > Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > [...] > > > - Output at /dev/gnssX: > > > AI2 vs. NMEA > > > The chip can be configured into sending AI2-encapsulated NMEA, > > > or proving data in a binary format. > > > Some research has to be done yet for the details. > > > A pile of logs is waiting for further analysis... > > > > > > Arguments for/against NMEA: > > > + Userspace is prepared to handle it > > > + Power management can be easily done by the kernel > > > - Less functionality can be used. > > > > I'd go with NMEA format as the default setting :) > > > yes, that would also be my preference. > > > > Arguments for/against AI2: > > > + Full functionality can be accessed from userspace (incl. A-GPS, > > > maybe raw satellite data) > > > - Userspace has to behave to have proper power management > > > - No freely (not even as in beer) tool available to fully use AI2, > > > so there will be only a real advantage after long "French Cafe" > > > sessions. > > > > Seems AI2 could be optionally enabled as needed with some writes > > to /dev/gnss0 to change the mode? > > Hmm, we have > /sys/class/gnss/gnss0/type to get the mode, maybe we add some file > to change the mode? Or having it hidden behing a module parameter > and implement something better accessible if any need arrives? > > If we want NMEA output, probably some init commands will be sent at > open(), but userspace doing something with AI2 probably does not want > the device touched, so it should probably be already be set before open(). Is there another revision coming or should I try to test this one? I am not very familiar with the GNSS part of the module, but it sounds like there was some consensus as to which direction we should go. I should have a little time this weekend. thanks adam > > Regards, > Andreas >
