cyoung / stratux

Aviation weather and traffic receiver based on RTL-SDR.
BSD 3-Clause "New" or "Revised" License
1.06k stars 363 forks source link

udev rules for GPS units #416

Closed cyoung closed 8 years ago

cyoung commented 8 years ago
  1. Stratux version: v0.8r2
  2. Stratux config:

    SDR [ ] single [x] dual

    GPS [x] yes [ ] no type:

    AHRS [ ] yes [x] no

    power source: AC adapter

    usb cable: any

  3. EFB app and version: N/A

    EFB platform: N/A

    EFB hardware: N/A

  4. Description of your issue:

Need udev rules to identify different GPS units and/or serial output ports.

cyoung commented 8 years ago

@AvSquirrel - Are you using the Prolific 2303 for the your FLARM branch? 067b:2303.

ghost commented 8 years ago

Yes. Both the Trendnet TU-S9 adapter and the BU-353-S4 identify as 067b:2303.

Unsurprisingly, devices based on u-blox 8-series chipsets (Neo M8N, e.g. RY835/6) identify as 1546:01a8 when connected over USB.

  idVendor           0x1546 U-Blox AG
  idProduct          0x01a8
  bcdDevice            3.01
  iManufacturer           1 u-blox AG - www.u-blox.com
  iProduct                2 u-blox GNSS receiver
cyoung commented 8 years ago

TU-S9 is what you are using for FLARM, then? On May 16, 2016 10:56 PM, "AvSquirrel" notifications@github.com wrote:

Yes. Both the Trendnet TU-S9 adapter and the BU-353-S4 identify as 067b:2303.

Unsurprisingly, devices based on u-blox 8-series chipsets (Neo M8N, e.g. RY835/6) identify as 1546:01a8 when connected over USB.

idVendor 0x1546 U-Blox AG idProduct 0x01a8 bcdDevice 3.01 iManufacturer 1 u-blox AG - www.u-blox.com iProduct 2 u-blox GNSS receiver

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/416#issuecomment-219607038

Ergonomicmike commented 8 years ago

This has been suggested before (IIRC): should there be radio buttons for Advanced users in the Web UI to select Auto-Detect, BU-353, TU-S9; etc. for intractable cases?

skypuppy commented 8 years ago

Maybe gpsd is a solution, Mike.

cyoung commented 8 years ago

Even gpsd needs to be "told" what GPS to expect, doesn't it?

kdknigga commented 8 years ago

No, gpsd autodetects pretty much everything besides the serial port to use.

On Tue, May 17, 2016, 18:04 cyoung notifications@github.com wrote:

Even gpsd needs to be "told" what GPS to expect, doesn't it?

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/416#issuecomment-219880124

kdknigga commented 8 years ago

http://www.catb.org/gpsd/hacking.html#autoconfiguration

skypuppy commented 8 years ago

and: http://www.catb.org/gpsd/client-howto.html

cyoung commented 8 years ago

udev rules set up, we'll assume that all pl2303 are SirfIV temporarily and revisit gpsd.

Ergonomicmike commented 8 years ago

Yep, sounds like a good plan. It does seem like gpsd is the more "elegant" solution. But that can wait for later, especially since it's expected that users are using the recommended hardware. (And so can't legitimately complain if they are using an unsupported GPS. (And can always write their own branch if they want support for an unsupported GPS.))

Ergonomicmike commented 8 years ago

It might be too that gpsd fixes https://github.com/cyoung/stratux/issues/400. But why would users be hotswapping one GPS and inserting another in flight?

skypuppy commented 8 years ago

For one thing, stuff breaks.

Ergonomicmike commented 8 years ago

True. But like when the landing gear won't come up after takeoff, I don't troubleshoot in flight. My backup plan for loss of Stratux GPS (which I've had to use in the past) is to use the internal GPS in my tablet. Besides, how many Stratux users are going to have two different GPS's with them to hotswap?