Enhanced GPS detection and MTK3339 support #315
Comments
ghost
added
the
On second thought, that doesn't really make sense. The UBX configuration routine opens ttyAMA0 at 9600 baud, writes a bunch of binary messages to set up message rate, message configuration, dynamic model, and finally, a message to set the GPS bitrate to 38400 baud. The ttyAMA0 port is then closed and reopened at 38400 baud to start reading messages. As long as the binary messages don't mess things up, any device that's hardcoded to 38400 should work on existing code. |
|
AvSquirrel, some of us have run out of USB ports when keyboard and mouse One huge advantage of the Adafruit version is you can add a battery to I have written small pieces of software testing these very things I also have a USB (sirf? I forget) gps from an old Micro$loth Streets Most of my time right now is trying to get the BNO055 AHRS to play nice Skypuppy On 03/08/2016 11:52 PM, AvSquirrel wrote:
|
|
Increasing hardware support increases the code maintenance cost - so what would be the benefit of supporting MTK3339 over the Vk-172? The only boards I'm finding are breakout boards and they're even more expensive than the Vk-172. |
|
I believe I enumerated the benefits, mainly, the battery backup rtc to
On 03/09/2016 07:30 AM, cyoung wrote:
|
|
Not sure, looks like everything is extra with these breakout boards. The Vk-172 gets a pretty fast lock (unlike the RY835AI in certain situations). We're dealing with GPS time whenever we get it and any "real time" dependent functions for us are just informational, so the rtc isn't worth much at this point in time. Given the fact that it's a breakout board for twice the cost of a reliable USB device, I'd say that this product is inferior for our uses. Vk-172 or BU-353-S4 offer the same things for less, and the only benefit the BU-353-S4 has AFAIK is the ability to place it remotely. |
|
The BU-353 has a super-capacitor inside. I don't know if it keeps a clock running, but it does keep something alive for a day or so that allows acquisition in a few seconds. Even when it forgets and has to do a cold start, it takes only a few minutes. (Not the hours some were reporting with the RY835ai.) I don't have a VK-172 to compare to, but I would like to think that the BU-353 pulls signals in better due to it's large ground plane/shield for its antenna. |
|
Thanks for the feedback, guys. Prototype support for the Adafruit Ultimate GPS (MTK3339) over UART is in my experimental branch as of commit https://github.com/AvSquirrel/stratux/commit/31872c23a6722745d550b34de4d825907196242d . Since I don't have the Adafruit hardware, I'm going exclusively by the MTK NMEA protocol guide. (In theory, it should work if I didn't mess anything up, but it would be nice to have hardware to test on.) Upgrade package: Usual caveats about my new / experimental features apply. For now, I'll keep things simple with support for the following:
Additionally, the following devices should be compatible:
@cyoung -- not disagreeing with you that the VK-172 is a better deal, but the Adafruit hardware seems to be relatively common in the RPi community. The Mediatek chipset uses NMEA commands for configuration, and it can be positively identified by using a NMEA query. Building the prototype was relatively easy. I'm mindful of scope creep, but the added complexity for that receiver was minimal. The MTK support code coexists peacefully with my u-blox M8N, I've come around on the VK-172 in a big way the last couple of months. It's a very competent implementation of a very capable chipset. I see better than 2 meter accuracy in the air, with position acquisitions from cold start (i.e. after clearing almanac and RTC) in under two minutes. Clock gets set within 15 seconds of cold start. Warm starts (unplugging / replugging) are faster. To be honest, I've found that the backup battery doesn't really matter at startup, as long as you have a clear view of the sky and keep the antenna away from any noise emitters. For $20, it's an incredible value. Moreover, it's a dream to develop for. The u-blox documentation is clear and complete, the extended NMEA sentences give us all of the position and state information we'd ever need, using the binary protocol to issue commands is reasonably easy to use, and it has native USB support! There's no bridge chip: it actually identifies itself to the system as "u-blox", and it autobauds! All that said, these little units went scarce for a while, and folks like @Ergonomicmike bought up the BU-353-iv since it was available on Amazon, could be remote-mounted easily, and since it had a pretty solid reputation for its RF selectivity. @Helno shared some teardown pictures on reddit and Slack that showed excellent shielding -- although this video teardown shows a bare green board with a tiny patch antenna. |
|
Yeah, these two work pretty well. It's not just scope creep but making the hardware profile further fragmented is just not a good move. Some people might get the idea that Stratux is an ADS-B receiver that you make out of components that are laying in your spare parts bin. A lot of people complained that Pi B+ or other WiFi controllers were not supported. Can you imagine figuring out the WiFi issues, some of the system reboot/lockup issues we've encountered and fixed in the past, or even routine code issues if we don't know which of the four configurations of the core system they are using? Or even care, because I personally will not be running tests on four different Raspberry Pis to get things working. It adds unnecessary complexity for no value. The only selling point on this GPS is that more people have it in their spare parts bin. Well, I don't and you don't. This is a more expensive chip that offers nothing above the two completely acceptable options we have. |
|
I would at least have a few options available for out of stock and discontinued products. I believe the project has done a great job of that! Keeping it open source means if they want ala carte they can do it themselves. |
|
AvSquirrel, I have a (larger) proto board with the Adafruit Utimate GPS on iit that you could borrow to play with but I'd want it back. Where on Earth are you? (you have to be on Earth to get GPS.) Alternatively, we could go to private email or phone to do some of the test here on my machine. Skypuppy |
|
Hi Guys, |
|
In jessie with 0.8r1, you can run "minicom" or better, "cutecom" and : "Cutecom" has a much easier UI than "minicom. Do y'all know of any other gps watcher besides "gpscon" that tries to I STILL cannot figure out that u-blox thang, to be able to autodetect Skypuppy On 03/12/2016 09:05 PM, aerojoe wrote:
|
|
Also, to stop (almost) all of stratux, use "service stratux stop" and Skypuppy On 03/12/2016 09:05 PM, aerojoe wrote:
|
|
Skypuppy, Yes, I've seen the same behavior with NMEA over ttyAMA0. I'm using cutecom to do diagnostics. I think some other events outside of stratux are causing the serial port to close once it's opened. I also saw that the stratux log would show continual opening of the ttyAMA0 device, which might mean it's being closed more than once. Additionally, with version .8r1, I see that with both the RX and TX lines connected between the Pi and Adafruit, Stratux will not boot up with Wifi or Ethernet working. This was the same issue I saw on v .7r3 I'll dig some more tomorrow. |
|
aerojoe, re not working with other hardware powered-up indicates a power supply re stratux log: were you running cutecom at the same time you were I will try again here at home and insert another computer/rs232-checker Skypuppy On 03/13/2016 12:43 AM, aerojoe wrote:
|
|
skypuppy, Thanks for the input. I did not know that I could use cutecom to access AMA0 at the same time that Stratux was using it. Now I've tested the AMA0 device both with stratux running and gdl90 killed and the results are similar. When I ran tests on .8r1, more messages seem to get through. In fact, the GPS status page showed 3D position for a brief time. However a short time later some data was lost and then the port was reconfigured to another baud rate, so the messages were garbled. I have the Adafruit set at 38k, and it does not look like any autoconfiguration is taking place on the Adafruit. Regarding your comment on the bootup problem being related to the power supply, I'm not so sure about this. What I see is that if I disconnect one of the TX or RX lines to the GPIO only (power to the Adafruit is still on), then the Stratux boots correctly. If you don't see the same issue, then it might be an issue with my Pi. I am using the AC/DC power supply and not battery power. Lastly, I'm not trying to change the direction of the stratux roadmap. You all have done such great work. My motivation to use the Adafruit was largely to have a compact (no USB or external antenna) and ubiquitous GPS module. The VK-172 and RY835, while robust don't seem to be easily available. I also think that modularity and portability are important. Rather that do all of this autoconfiguration for features, perhaps one day the user could configure Stratux options via the web interface. For example, pick your GPS/attitude module, pick your preferred EFB application, etc. I realize the team has to get stability in the basic features first, so these things would be lower priority, nice-to-have features. |
|
Update. I stopped stratux and ran my tests again using Cutecom. Again I see the port being closed. I blindly kept opening the port about 10 times and viola, the NMEA sentences starting flowing consistently. Now to find out who or what is closing the device. |
|
Sorry, I reread my statements and did not mean to imply the VK-172 is not available. My desire is to have an easily available module that does NOT require USB. The only issue I see with the 172 is that the USB attachment, while compact does not seem to be robust (admittedly solved with some epoxy). |
|
Just so I'm not misunderstood, I am an avid supporter of using the On 03/13/2016 11:26 AM, aerojoe wrote:
|
|
check solder joints, broken wires, etc. On 03/13/2016 11:32 AM, aerojoe wrote:
|
|
To clarify, are you on the v0.8r1 release (build 796d0a2), or on one of the experimental builds? Can you make sure that you have "Record Logs" turned on and post copies of stratux.log and one of your nnnn-gps.log files to review? GPS config on /dev/ttyAMA0 goes through the following steps as of the v0.8r1 release:
First thing I'd want to check is if the MTK3339 is "holding" the 38400 baud setting when you connect it. If it actually powers on at 9600 baud, it will just loop through the initialization every five seconds on the v0.8r1 796d0a2 release. If you're running an experimental build, it's also possible that I don't have something set right in the configuration. WITHOUT Stratux running, my usual diagnostics for quick connections checks has been to use stty to set baud rate, and cat to read the connection. E.g. to read the port at 9600 baud: With two SSH sessions open, I've been able to run cat in one and iterate through different stty settings in the other. You could even run stty in a second console while gen_gdl90 is running (e.g. immediately after GPS initialization) to force the port to a specific baud rate. |
|
By the way, this:
sounds like a possible hardware problem. I agree with @skypuppy -- check your wiring for shorts! |
That would be very helpful. (I'm in Minnesota.) Send me a PM on reddit and we can work out the details. |
|
@skypuppy Lastly, I did shutdown stratux and let Cutecom monitor AMA0. I saw a nice stream of NMEA messages for about 5 minutes. Then mysteriously the baud rate changed and I saw garbage output. Are you able to see any NMEA sentences with the Adafruit on AMA0? I'll check my wiring and grounds, but it's only 4 wires and the soldered pins, which on the Adafruit are the same ones used in the TTL-USB connection. |
|
Yes, standard NMEA sentences come through just fine from the Pi, with Ideally, they will all show zero dropped sentences and then we can Skypuppy On 03/13/2016 02:03 PM, aerojoe wrote:
|
|
I've been playing with the Adafruit for about a week now (thanks again @skypuppy !) and I'm getting a better handle on its idiosyncrasies. Likes:
Dislikes:
Disappointments:
|
|
@aerojoe, @cyoung -- the leap second is about the corneriest of corner cases that we'd ever deal with on this project. It happens once every 12-36 months, and to what effect -- the time is off by a second? The Parallax appears to be yet-another-u-blox-7 module. Overpriced at $50, when you can pick up a VK-172 for $10-20 -- or if you have to have a serial connection, an RY725AI (or generic equivalent) for $20 shipped. |
|
I know, I know. It's just code smell to me. |
|
I get the same sensitivity as the Sirf III USB (the gold standard for Skypuppy On 03/31/2016 11:03 PM, AvSquirrel wrote:
|
|
Is this an MTK3339 or compatible? http://amzn.com/B00N32HKIW |
|
It has the same specs as the 3339, but found this while searching the Since it is an MTK3339 and USB and only $14, thought I'd pass it along. On 04/02/2016 01:06 PM, cyoung wrote:
|
|
@AvSquirrel @skypuppy |
|
@AvSquirrel @skypuppy |
|
Please verify and/or set your baud rate to 9600 explicitly upon each Then, check your NMEA sentences. On 04/07/2016 05:07 PM, aerojoe wrote:
|
|
@skypuppy My next step is to move this to Pi3 |
|
@skypuppy @AvSquirrel I got a Adafruit Ultimate GPS Pi HAT how can i get start to test this? Thanks, |
|
Adafruit says it is currently incompatible with he RPi3, but someone says they have made it work (with unspecified changed.) So you might only want to use it on a -2. Now, for use in a Stratux, the mainstream production image does not currently support this GPS. AvSquirrel has some branches that do but I'm not sure how they gel with all the other changes made to the stratux software. AvSquirrel will have to answer that one. His branch worked GREAT on 0.8r1 but a lot has changed since then. |
|
@skypuppy I have figured out the reason why not working on Pi 3 is the UART changes I have disabled the bluetooth and remapping the UART port to get it work for my NTP Server so GPS itself works great as on Pi 2 I did a git clone on his repo https://github.com/AvSquirrel/stratux.git Maybe I gonna try 0.8r1 commit and hope the best |
|
Btw, Adafruit has come through again! On their "learning" pages, they now discuss how to implement gpsd, the GPS daemon that gives programmers a single library that hooks to most of the major GPS equipment, including ublox and MTK's. You have a choice of several methods. They even give some example code, as does the gpsd docs. There are some requirements to stop a service that Debian sets up in default, but it looks really easy. This could be the golden mousetrap we've been looking for. |
|
Great work, ytwytw, and thanks for letting us know! |
|
@skypuppy Thanks! My GPSd works fine I would like to see how to feed it to Stratux now |
|
Using gpsd is not supported currently in stratux software. I've been playing with it but nothing worth posting as a branch. You might consider getting the data in "raw" mode as changes that large (using gpsd) must be done by stratux coders unless you're willing to make a branch... Where I start screwing up so badly I don't take the time/effort to fix it is at the gps code in the stratux source where it feeds the data into the message builder that forwards to the EFB. |
|
I know GPSd will not work for stratux, but its a good test to check the GPS HAT is working yeah i'm still trying to digging more how @AvSquirrel made it work |
|
If you find out, please let me know! :) Hahahaaha Golang is pretty much a sthow-stopper for me. (and several others.) |
|
After couple tweaking I can confirm @AvSquirrel 's gpsattitude branch does work perfectly with Adafruit GPS HAT Unfortunately, I dont know how to setup Hotspot wifi on the pi yet so cant test outside my home (I built from source with clean Debian image)
|
|
If you're interested using the MTK3339 on stock Stratux (v0.8r2, or any of the commits in @cyoung 's master branch), I wrote an interactive shell script that will configure the receiver to use 38.4 kbps, 5 Hz position refresh, with WAAS enabled, and to output all of the needed NMEA sentences: https://github.com/AvSquirrel/stratux/blob/mtk-setup-script/test/mtk_config.sh Run this script before starting gen_gdl90. If you have a backup battery installed in your Adafruit boards / hats, these settings should persist across power cycles. The autodetection routine in my gpsattitude branch is still a little rough around the edges, and not ready to pull into the main branch. (Among other things, I need to get my hands on a BU-353 to verify that I won't mess it up.) |
|
Also note that if you're trying to run with the latest commits, there is an incompatibility with GPIO serial on the RPi 3 (#393) that will prevent any serial device from connecting. |
|
You da man, @AvSquirrel! |
That involves the following line to You still need to comment out the references to ttyS0 in ry835ai as shown in #393 / #394. |
|
@skypuppy @AvSquirrel |
|
@AvSquirrel |
|
Great place to put other sensors, like the IMU. |
|
Unable to add this at this time. U-blox receivers are ubiquitous, cheap, and come in every conceivable form. From what I'm seeing here and looking elsewhere, the MTK3339 based receivers are less common, more expensive, and less sensitive. |
Stratux version: v0.8r1 https://github.com/AvSquirrel/stratux/commit/fd936e7e1b71429abb4e853f8a7116078a3da718
Stratux config:
SDR
[ ] single
[X] dual
GPS
[X] yes
[ ] no
type: u-blox, MTK, or SIRF
AHRS
[X] yes
[ ] no
power source: Wall-wart
usb cable: Fixed
EFB app and version: N/A
EFB platform: N/A
EFB hardware: N/A
Description of your issue:
Multiple users are using or have requested support for MTK3339-based GPS receivers (e.g. Adafruit Ultimate GPS). These receivers will work on current builds if connected through a USB-to-UART bridge since ttyUSB0 is assumed to be SIRF IV (BU-353), which only outputs standard NMEA sentences.
Devices that connect as ttyACM0 (u-blox native USB interface) or ttyAMA0 (onboard UART) are assumed to be u-blox, and are configured to use UBX-proprietary NMEA sentences for efficiency and improved quality / resolution of data over standard NMEA. However, this means that Stratux tries to configure any device on ttyAMA0 as if it were a u-blox device, and this makes UART connections incompatible with any other type of GPS receiver.
This is a tracking request for improving the GPS configuration routine to better autodetect these alternate receivers. I'm starting to lay this out in my development branch but have a few open questions:
The text was updated successfully, but these errors were encountered: