| Message ID | 20231126191840.110564-1-andreas@kemnade.info (mailing list archive) |
|---|---|
| Headers | show |
| Series | bluetooth/gnss: GNSS support for TiWi chips | expand |
* Andreas Kemnade <andreas@kemnade.info> [231126 19:18]: > So the main questions I see: > - is the approach right to abandon drivers/misc/ti-st? Yes. > - 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 :) > 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? Regards, Tony
On Sun, Nov 26, 2023 at 1:47 PM Andreas Kemnade <andreas@kemnade.info> wrote: > > Some of these chips have GNSS support. In some vendor kernels > a driver on top of misc/ti-st can be found providing a /dev/tigps > device which speaks the secretive Air Independent Interface (AI2) protocol. > Implement something comparable as a GNSS interface. > > With some userspace tools a proof-of-concept can be shown. A position > can be successfully read out. Basic properties of the protocol are > understood. > > This was tested on the Epson Moverio BT-200. Can you tell me which WiLink chip this uses? I'd like to try it on the WL1283, but I want to understand which WiLink chips you're targeting. adam > > This is sent out as an early RFC to ensure I am going onto the right > track: > > So the main questions I see: > - is the approach right to abandon drivers/misc/ti-st? > > - 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. > > 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. > > More detailed tings: > - Some live cycle management is left out. Since it depends > on the decisions above, I have not put much thought into it. > - Should some pieces go into drivers/gnss? > - detection for GNSS availability: For now the node name is > used. But the device should be there if the chip supports it > and things are wired up properly. > > Andreas Kemnade (3): > gnss: Add AI2 protocol used by some TI combo chips. > bluetooth: ti-st: add GNSS support for TI Wilink chips > drivers: misc: ti-st: begin to deorbit > > drivers/bluetooth/hci_ll.c | 154 ++++++++++++++++++++++++++++++++++++- > drivers/gnss/core.c | 1 + > drivers/misc/ti-st/Kconfig | 2 +- > include/linux/gnss.h | 1 + > 4 files changed, 156 insertions(+), 2 deletions(-) > > -- > 2.39.2 > >
On Mon, 27 Nov 2023 08:03:24 -0600 Adam Ford <aford173@gmail.com> wrote: > On Sun, Nov 26, 2023 at 1:47 PM Andreas Kemnade <andreas@kemnade.info> wrote: > > > > Some of these chips have GNSS support. In some vendor kernels > > a driver on top of misc/ti-st can be found providing a /dev/tigps > > device which speaks the secretive Air Independent Interface (AI2) protocol. > > Implement something comparable as a GNSS interface. > > > > With some userspace tools a proof-of-concept can be shown. A position > > can be successfully read out. Basic properties of the protocol are > > understood. > > > > This was tested on the Epson Moverio BT-200. > > Can you tell me which WiLink chip this uses? > > I'd like to try it on the WL1283, but I want to understand which > WiLink chips you're targeting. > I think, it is a WL1283 here, too. If you want to play around with it now: - set the devicetree node name to bluetooth-gnss - for testing you can use the read-gps program at https://github.com/akemnade/bt200tools Regards, Andreas
Hi, On Mon, 27 Nov 2023 15:54:24 +0200 Tony Lindgren <tony@atomide.com> 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(). Regards, Andreas
On Mon, Nov 27, 2023 at 2:51 PM Andreas Kemnade <andreas@kemnade.info> wrote: > > Hi, > > On Mon, 27 Nov 2023 15:54:24 +0200 > Tony Lindgren <tony@atomide.com> 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 >
On Mon, Nov 27, 2023 at 09:51:08PM +0100, Andreas Kemnade wrote: > On Mon, 27 Nov 2023 15:54:24 +0200 > Tony Lindgren <tony@atomide.com> 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... Can you say something more about what the protocol looks like? Is there some common framing that can/should be stripped by the driver in both modes? > > > > > > 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? The 'type' attribute is intended to reveal the GNSS receiver type (class) as a hint to user space to avoid having to detect it at runtime using heuristics. It does not reflect which mode is currently active for receivers that provide both a vendor specific protocol and NMEA (e.g. u-blox receivers). User space can currently switch modes at will by writing to /dev/gnss0 as Tony mentioned. It may or may not make sense to make sure a particular mode is set during probe, for example, if there's no real use for the proprietary protocol and everyone would just switch away from it immediately. Johan
Hi, On Fri, 8 Dec 2023 08:39:21 -0600 Adam Ford <aford173@gmail.com> wrote: > On Mon, Nov 27, 2023 at 2:51 PM Andreas Kemnade <andreas@kemnade.info> wrote: > > > > Hi, > > > > On Mon, 27 Nov 2023 15:54:24 +0200 > > Tony Lindgren <tony@atomide.com> 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. > Progress is only in my test program. No more checksum errors, I have made some progress in protocol reverse engineering. So make sure you do a git pull for https://github.com/akemnade/bt200tools Regards, Andreas
On Fri, 8 Dec 2023 17:25:27 +0100 Johan Hovold <johan@kernel.org> wrote: > On Mon, Nov 27, 2023 at 09:51:08PM +0100, Andreas Kemnade wrote: > > On Mon, 27 Nov 2023 15:54:24 +0200 > > Tony Lindgren <tony@atomide.com> 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... > > Can you say something more about what the protocol looks like? Is there > some common framing that can/should be stripped by the driver in both > modes? > The frames (which can be fragmented into multiple gnss_recv_frame() calls) consist of: - some kind of start marker - one or more tlv structures (start marker is escaped here) - checksum - end marker In case of NMEA reporting we have with this patchset at /dev/gnssX or at /dev/tigps found in the bt200 vendor kernel e.g. 1000 d3 1800 82050000 244750474c4c2c2c2c2c2c2c562c4e2a36340d0a 9f05 1003 which is: 1000 = start marker, d3 = NMEA report 1800 = length (LE) 82050000 = ms from turning on GPS (LE). 244750474c4c2c2c2c2c2c2c562c4e2a36340d0a = NMEA sentence 9f05 = checksum 1003 = end marker. That is one report among others depending on what is enabled. So it is not like the situtation with Sirf where you send some magic to turn it into binary mode and some other magic turning it into NMEA mode and have no other stuff on the line. > > > > > > > > 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? > > The 'type' attribute is intended to reveal the GNSS receiver type > (class) as a hint to user space to avoid having to detect it at runtime > using heuristics. > > It does not reflect which mode is currently active for receivers that > provide both a vendor specific protocol and NMEA (e.g. u-blox > receivers). > > User space can currently switch modes at will by writing to /dev/gnss0 > as Tony mentioned. > Well, switching mode would in this case also mean configuring something in the driver to do something different as it would mean sending commands to enable NMEA reports and strip away the AI2 encapsulation in the driver. You usually do not configure drivers through write() but through some out-of-band means like ioctl(), sysfs, kernel compile options, module parameters. > It may or may not make sense to make sure a particular mode is set > during probe, for example, if there's no real use for the proprietary > protocol and everyone would just switch away from it immediately. > I would probably not do anything at probe time but turning on GPS and enable NMEA reports at open() time. With a lot of effort you can probably do interesting things with the proprietary mode. But given the fact that apparently nobody has done publicly so in the past years, I would not expect that anything arises suddenly. So in practice only NMEA would IMHO be useful and having raw AI2 might be something behind a module option or compile option to avoid introducing some new API before a real need is seen. Also as not everybody is using gpsd anymore, implementing any support for AI2 in userspace would not be at a single place. Regards, Andreas
Some of these chips have GNSS support. In some vendor kernels a driver on top of misc/ti-st can be found providing a /dev/tigps device which speaks the secretive Air Independent Interface (AI2) protocol. Implement something comparable as a GNSS interface. With some userspace tools a proof-of-concept can be shown. A position can be successfully read out. Basic properties of the protocol are understood. This was tested on the Epson Moverio BT-200. This is sent out as an early RFC to ensure I am going onto the right track: So the main questions I see: - is the approach right to abandon drivers/misc/ti-st? - 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. 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. More detailed tings: - Some live cycle management is left out. Since it depends on the decisions above, I have not put much thought into it. - Should some pieces go into drivers/gnss? - detection for GNSS availability: For now the node name is used. But the device should be there if the chip supports it and things are wired up properly. Andreas Kemnade (3): gnss: Add AI2 protocol used by some TI combo chips. bluetooth: ti-st: add GNSS support for TI Wilink chips drivers: misc: ti-st: begin to deorbit drivers/bluetooth/hci_ll.c | 154 ++++++++++++++++++++++++++++++++++++- drivers/gnss/core.c | 1 + drivers/misc/ti-st/Kconfig | 2 +- include/linux/gnss.h | 1 + 4 files changed, 156 insertions(+), 2 deletions(-)