stratux
stratux copied to clipboard
cyoung
Evaluate impact of removing BU-353 support
How many people are using it?
Support was added as experimental but no conclusion was ever made. The VK-162 has come up as a competitor to the BU-353 where it had been previously overlooked - it's about half as expensive, apparently more sensitive, and based on a u-blox chip which we can support uniformly across different receivers (VK-172, VK-162, RY835AI, RY836AI, etc.) U-blox receivers seem like a much better value for these reasons, what would be a good reason to keep support for anything else?
Skypuppy,
Instead of demanding other people do work (for free!), why don't you give it a go?
I actually looked into implementing gpsd support last fall and quickly found myself severely lacking in both skill and time to pull it off.
While I agree that on paper gpsd does sound like a great solution to the bring-your-own-gps problem, I'm happy enough just to take advantage of the work Chris, avsquirrel, jpoirier, and others have done and use a ublox receiver and call it a day.
So, skypuppy, I sincerely hope that the next mention of gpsd I see from you is in the form of a pull request. Good luck, and please let me know if I can help in any way.
On Wed, Aug 24, 2016, 16:32 skypuppy [email protected] wrote:
Just f'ing use gpsd. Many Problems Solved.
On 08/24/2016 03:50 PM, cyoung wrote:
How many people are using it?
Support was added as experimental but no conclusion was ever made. The VK-162 has come up as a competitor to the BU-353 where it had been previously overlooked - it's about half as expensive, apparently more sensitive, and based on a u-blox chip which we can support uniformly across different receivers (VK-172, VK-162, RY835AI, RY836AI, etc.) U-blox receivers seem like a much better value for these reasons, what would be a good reason to keep support for anything else?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/482, or mute the thread < https://github.com/notifications/unsubscribe-auth/ANAzoaKiE2UK3Mjjs8jw1exXvvNzApFMks5qjK58gaJpZM4JscF6 .
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/482#issuecomment-242215307, or mute the thread https://github.com/notifications/unsubscribe-auth/ANN_wELaOx_leWSVkUJi09H4MlA3DmC3ks5qjLiLgaJpZM4JscF6 .
I tried to do the gpsd thing. However, I lack skills in that obscure
programming language called "golang," and was unsuccessful in getting a
complete mod. In fact, I couldn't get my head around golang AT ALL. I
am not the only person, by far, needing support for a person's chosen
GPS hardware. And as I said, gpsd solves more problems than one.
Further, for those that use the MTK3339, it solves more than one
problem. (Like the PPS output, just for example.)
David
On 08/24/2016 05:13 PM, Kris Knigga wrote:
Skypuppy,
Instead of demanding other people do work (for free!), why don't you give it a go?
I actually looked into implementing gpsd support last fall and quickly found myself severely lacking in both skill and time to pull it off.
While I agree that on paper gpsd does sound like a great solution to the bring-your-own-gps problem, I'm happy enough just to take advantage of the work Chris, avsquirrel, jpoirier, and others have done and use a ublox receiver and call it a day.
So, skypuppy, I sincerely hope that the next mention of gpsd I see from you is in the form of a pull request. Good luck, and please let me know if I can help in any way.
On Wed, Aug 24, 2016, 16:32 skypuppy [email protected] wrote:
Just f'ing use gpsd. Many Problems Solved.
On 08/24/2016 03:50 PM, cyoung wrote:
How many people are using it?
Support was added as experimental but no conclusion was ever made. The VK-162 has come up as a competitor to the BU-353 where it had been previously overlooked - it's about half as expensive, apparently more sensitive, and based on a u-blox chip which we can support uniformly across different receivers (VK-172, VK-162, RY835AI, RY836AI, etc.) U-blox receivers seem like a much better value for these reasons, what would be a good reason to keep support for anything else?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/482, or mute the thread <
https://github.com/notifications/unsubscribe-auth/ANAzoaKiE2UK3Mjjs8jw1exXvvNzApFMks5qjK58gaJpZM4JscF6
.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub
https://github.com/cyoung/stratux/issues/482#issuecomment-242215307, or mute the thread
https://github.com/notifications/unsubscribe-auth/ANN_wELaOx_leWSVkUJi09H4MlA3DmC3ks5qjLiLgaJpZM4JscF6 .
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/482#issuecomment-242225074, or mute the thread https://github.com/notifications/unsubscribe-auth/ANAzobymTp6UKSJrsp5DE5XHd8sw3Rp1ks5qjMIdgaJpZM4JscF6.
Obviously, I'm getting frustrated with my attempts on this project.
On 08/24/2016 05:13 PM, Kris Knigga wrote:
Skypuppy,
Instead of demanding other people do work (for free!), why don't you give it a go?
I actually looked into implementing gpsd support last fall and quickly found myself severely lacking in both skill and time to pull it off.
While I agree that on paper gpsd does sound like a great solution to the bring-your-own-gps problem, I'm happy enough just to take advantage of the work Chris, avsquirrel, jpoirier, and others have done and use a ublox receiver and call it a day.
So, skypuppy, I sincerely hope that the next mention of gpsd I see from you is in the form of a pull request. Good luck, and please let me know if I can help in any way.
On Wed, Aug 24, 2016, 16:32 skypuppy [email protected] wrote:
Just f'ing use gpsd. Many Problems Solved.
On 08/24/2016 03:50 PM, cyoung wrote:
How many people are using it?
Support was added as experimental but no conclusion was ever made. The VK-162 has come up as a competitor to the BU-353 where it had been previously overlooked - it's about half as expensive, apparently more sensitive, and based on a u-blox chip which we can support uniformly across different receivers (VK-172, VK-162, RY835AI, RY836AI, etc.) U-blox receivers seem like a much better value for these reasons, what would be a good reason to keep support for anything else?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/482, or mute the thread <
https://github.com/notifications/unsubscribe-auth/ANAzoaKiE2UK3Mjjs8jw1exXvvNzApFMks5qjK58gaJpZM4JscF6
.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub
https://github.com/cyoung/stratux/issues/482#issuecomment-242215307, or mute the thread
https://github.com/notifications/unsubscribe-auth/ANN_wELaOx_leWSVkUJi09H4MlA3DmC3ks5qjLiLgaJpZM4JscF6 .
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/482#issuecomment-242225074, or mute the thread https://github.com/notifications/unsubscribe-auth/ANAzobymTp6UKSJrsp5DE5XHd8sw3Rp1ks5qjMIdgaJpZM4JscF6.
I'll be sad to see BU-353 support go, since that's the only GPS I have for the Stratux. But, from following the developers, I realize that the 353 is problematic with its bridge chipset. I can always buy a VK if I have to after BU support stops. Please be sure to post in the Release Notes when the BU is no longer supported. (And, of couse, I can always hang back at the last version of Stratux that worked for me.)
It poses something of a problem for me as I have about 90 users who received BU-353s. If we do chose to pull support, I'll need a way to check for a BU-353 (or for a Prolific USB device) and cancel the upgrade. Otherwise I'll have some very angry customers.
(Yes, this is my problem and not the projects, but I suspect there are plenty of Stratux users out there who would feel the same.)
If the problem is the potential for multiple, indistinguishable USB/serial devices with the Prolific chipset, perhaps the better answer is to standardize on a different chipset for the general purpose serial I/O interface? Options include FTDI and Silicon Labs.
On Thu, Aug 25, 2016 at 9:55 AM, Ergonomicmike [email protected] wrote:
I'll be sad to see BU-353 support go, since that's the only GPS I have for the Stratux. But, from following the developers, I realize that the 353 is problematic with its bridge chipset. I can always buy a VK if I have to after BU support stops. Please be sure to post in the Release Notes when the BU is no longer supported. (And, of couse, I can always hang back at the last version of Stratux that worked for me.)
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/482#issuecomment-242418192, or mute the thread https://github.com/notifications/unsubscribe-auth/AAVYPOhcNANn3HstGT05m7Pl01WtgEB4ks5qjazvgaJpZM4JscF6 .
Steven Sokol 408 Camelot Drive Liberty, MO 64068
mobile: +1 816-806-8844 fax: +1 816-817-0441
I wonder if gpsd were adopted that it could handle the BU-353 as well?
On 08/25/2016 10:58 AM, Steven Sokol wrote:
It poses something of a problem for me as I have about 90 users who received BU-353s. If we do chose to pull support, I'll need a way to check for a BU-353 (or for a Prolific USB device) and cancel the upgrade. Otherwise I'll have some very angry customers.
(Yes, this is my problem and not the projects, but I suspect there are plenty of Stratux users out there who would feel the same.)
If the problem is the potential for multiple, indistinguishable USB/serial devices with the Prolific chipset, perhaps the better answer is to standardize on a different chipset for the general purpose serial I/O interface? Options include FTDI and Silicon Labs.
On Thu, Aug 25, 2016 at 9:55 AM, Ergonomicmike [email protected] wrote:
I'll be sad to see BU-353 support go, since that's the only GPS I have for the Stratux. But, from following the developers, I realize that the 353 is problematic with its bridge chipset. I can always buy a VK if I have to after BU support stops. Please be sure to post in the Release Notes when the BU is no longer supported. (And, of couse, I can always hang back at the last version of Stratux that worked for me.)
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub
https://github.com/cyoung/stratux/issues/482#issuecomment-242418192, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAVYPOhcNANn3HstGT05m7Pl01WtgEB4ks5qjazvgaJpZM4JscF6 .
Steven Sokol 408 Camelot Drive Liberty, MO 64068
mobile: +1 816-806-8844 fax: +1 816-817-0441
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/482#issuecomment-242441229, or mute the thread https://github.com/notifications/unsubscribe-auth/ANAzoeLaBVdXVSbkgV4fWUdiGfe7uNQFks5qjbvAgaJpZM4JscF6.
It would, but fragmenting the supported hardware always creates extra maintenance and reliability costs.
"fragmenting the supported hardware?" If gpsd were incorporated, you vastly broaden the hardware (and user) base for very little effort. And an entirely different group is dedicated to maintaining gpsd. It seems like a win/win situation all around as it allows most modern and legacy GPS's to be supported, again, at no cost to us stratux developers.
"creates extra maintenance and reliability costs?" For whom? Converting one small gps section in stratux greatly relieves gps overhead (and probably gives better handling) in one fell swoop.
The decision to drop this one particular model, BU-353 of Steve's customers alone, will serve to potentially anger and alienate 80+ existing users. And it's not even necessary.
On 08/25/2016 11:53 AM, cyoung wrote:
It would, but fragmenting the supported hardware always creates extra maintenance and reliability costs.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/482#issuecomment-242461609, or mute the thread https://github.com/notifications/unsubscribe-auth/ANAzoQ0s-NPbPh3hcC8PUeVFUI5i2zMsks5qjcifgaJpZM4JscF6.
Silly question Steve - but why sell a GPS unit that was not one of the reference hardware? Was it that much cheaper? (I don't have one of those)
A more basic question - any way to get the units to dump hardware configuration as part of the update process? Be nice to know what is getting used in the field.
We've never dropped support for any of the recommended hardware. We've gone through this discussion many times over, especially in the context of Wi-Fi adapters when it was relevant. Many people wanted to use many different Wi-Fi adapters. It turned out to be a wise choice to stick with support for one single adapter. It's not as if it is more expensive or there is any chance that a monopoly form around this piece.
The BU-353 was a nice stepping stone to finding something more cost effective and available. It filled a perceived void that existed for a very short time. If users adopt hardware that is not recommended/supported, we can't even make a best-effort promise to keep support for it. I am trying to figure out the smoothest way to transition out support for this device, which is the purpose of this issue.
If we want to try to segue the current experimental BU-353 / generic NMEA support into an (also experimental) gpsd implementation, that sounds like a plan. There has to be some value proposition above "it supports lots of hardware". Can anyone tell me why the BU-353 is any better than the VK-162? Is there any suggestion for a GPS module that should be recommended hardware but is not because it's not based on a u-blox chipset?
If we decide to go the gpsd route, I'm not able to contribute much on this at the moment. We do need someone that is willing to evaluate this system. If there are any systemic issues above the zero issues we currently have with u-blox integration, we'll have to finally put an end to it.
What's coming down the pike, USB-wise, that makes using the BU problematic? If the reason for removing support is simply to unfragment supported hardware, then could the exsisting BU code be left in as commented code? (Instead of deletion.) That way, special needs users could uncomment the code at their own risk. (Or perhaps Steve could write a script to enabled the code for special users.)
That could be as much or more hassle than simply implementing gpsd. And gpsd solves a wealth of problems, including BU.
On 08/25/2016 02:06 PM, Ergonomicmike wrote:
What's coming down the pike, USB-wise, that makes using the BU problematic? If the reason for removing support is simply to unfragment supported hardware, then could the exsisting BU code be left in as commented code? (Instead of deletion.) That way, special needs users could uncomment the code at their own risk. (Or perhaps Steve could write a script to enabled the code for special users.)
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/482#issuecomment-242503104, or mute the thread https://github.com/notifications/unsubscribe-auth/ANAzobt977P6IlMDblFGhOpTsRoUspRYks5qjefBgaJpZM4JscF6.
It's just using the PL2303, which is a generic USB-to-Serial device. Most of the USB-to-RS232 dongles are using this chipset, and there's no good way to distinguish the two without adding some GPS detection code. @skypuppy - before you say it again, I know that gpsd "solves" this "problem".
I don't see myself ever needing serial out for EFIS. I assume there would be a cable involved? If so, then it sounds less portable than the initial Stratux. Perhaps a separate product? Stratux Interface Unit, with its own code?
@cyoung If/when you remove SIRF support from Stratux, don't forget to remove the check mark for SIRF in the stratux.me page.
I've only run two series of tests today, comparing the VK-162 with the BU-353. But since Chris said he got the same results, I'm calling it in favor of the VK. It tracks more satellites and reports better accuracy than the BU. (I'll report here if that ever changes.) And, as Chris points out, the VK costs half as much as the BU. Perhaps Steve can incorporate a custom script to keep BU support alive for his 90 BU users?