search

cyoung / stratux

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

Enhanced GPS detection and MTK3339 support #315

Closed ghost closed 8 years ago

ghost commented 8 years ago
  1. Stratux version: v0.8r1 https://github.com/AvSquirrel/stratux/commit/fd936e7e1b71429abb4e853f8a7116078a3da718

  2. 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

  3. EFB app and version: N/A EFB platform: N/A EFB hardware: N/A
  4. 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:

ghost commented 8 years ago

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.

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.

skypuppy commented 8 years ago

AvSquirrel, some of us have run out of USB ports when keyboard and mouse are connected. :) Using a powered hub (while at home) helps that condition. However, the radios are soooo big, you can't hardly put anything else on those 4 ports, with the teeny wifi just barely fitting when you use 2 radios. So my mtk3339 gps is connected to the serial ports in all my tests. If you guys have determined the best/most reliable baud rate and it's not 9600 (default), I can look up the command to send to the GPS to change it's baud rate. Someone else already posted it, too. If you need the docs for it, there is a good link on the adafruit Ultimate GPS page.

One huge advantage of the Adafruit version is you can add a battery to the gps board and set the system clock from the rtc in the gps during the RPi bootup. That battery also helps the gps find itself very quickly provided it hasn't moved too far since it was shutdown. I have the battery on both of mine.

I have written small pieces of software testing these very things (except setting system time.) However, not being familiar with ublox, I have not tackled the current source code to NOT use ublox and to use standard nmea strings.

I also have a USB (sirf? I forget) gps from an old Micro$loth Streets and Trips package, but stratux does not like it either.

Most of my time right now is trying to get the BNO055 AHRS to play nice with current stratux software. Still having difficulty getting stratux source to compile and run.

Skypuppy

On 03/08/2016 11:52 PM, AvSquirrel wrote:

  1. Stratux version: v0.8r1 AvSquirrel@fd936e7 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

3.

EFB app and version: N/A
EFB platform: N/A
EFB hardware: N/A

4.

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:

  • Besides the Adafruit Ultimate GPS, the BU-353 (and other SIRF receivers), and the various u-blox devices, are there any other common receivers that should be supported?
  • What baud rates are these factory-configured to use? Should Stratux attempt to autobaud through other rates to handle user configuration / misconfiguration?
  • Should the UI provide for manual (specify type of device, port -- e.g. /dev/ttyUSB3, and baud rate) or semi-manual (specify type of device and method of connection -- e.g. GPIO or USB) overrides to speed up "difficult" cases?

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/315.

cyoung commented 8 years ago

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.

skypuppy commented 8 years ago

I believe I enumerated the benefits, mainly, the battery backup rtc to 1) set the RPi time -of-day and 2) much faster initial fixes.

On 03/09/2016 07:30 AM, cyoung 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.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/315#issuecomment-194296838.

cyoung commented 8 years ago

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.

Ergonomicmike commented 8 years ago

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.

ghost commented 8 years ago

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: update-stratux-v0.8r1-31872c23a6.sh.zip

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.

cyoung commented 8 years ago

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.

peepsnet commented 8 years ago

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.

skypuppy commented 8 years ago

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

aerojoe commented 8 years ago

Hi Guys, I've not tested the .8r1 version above with the Adafruit. But here is what I found with v .7b3. It seems that something is closing the AMA0 device on my Pi as soon as it's opened. This is why some NMEA messages get through, but most do not. I shutdown the gdl process on the Pi when doing this test, so I don't think there is anything in Stratux that is closing this port. I'll update to the version above tomorrow and repeat my tests and will report back. Joe

skypuppy commented 8 years ago

In jessie with 0.8r1, you can run "minicom" or better, "cutecom" and watch the mtk3339 (Adafruit Ultimate GPS) and see it is still producing data to the serial port, non-stop. It is really easy to watch with "cutecom." sudo apt-get update, sudo apt-get install cutecom. The power-up defaults on the mtk3339 are 9600, n81, on tty AMA0 (that is a zero.) Stratux code is NOT seeing the standard NMEA sentences from tty AMA0.
However, if you connect a SIRF chipset to it via USB, then stratux recognizes standard NMEA and works and, at least on the stratux web UI, shows DGPS (SBAS/WAAS) when you get enough sats in view (4 or more.)

: That works with or without gpsd running. So far, I've not gotten gpsd to cooperate whether stratux is running or not. "Cutecom" has a much easier UI than "minicom. Do y'all know of any other gps watcher besides "gpscon" that tries to present the NMEA strings in an interpreted form format? "Gpscon" doesn't cooperate on the Rpi2, either, with or without gpsd. I STILL cannot figure out that u-blox thang, to be able to autodetect which gps is running and configure for it inside stratux. Skypuppy On 03/12/2016 09:05 PM, aerojoe wrote: > Hi Guys, > I've not tested the .8r1 version above with the Adafruit. But here is > what I found with v .7b3. It seems that something is closing the AMA0 > device on my Pi as soon as it's opened. This is why some NMEA messages > get through, but most do not. I shutdown the gdl process on the Pi > when doing this test, so I don't think there is anything in Stratux > that is closing this port. I'll update to the version above tomorrow > and repeat my tests and will report back. > Joe > > — > Reply to this email directly or view it on GitHub > https://github.com/cyoung/stratux/issues/315#issuecomment-195861124.
skypuppy commented 8 years ago

Also, to stop (almost) all of stratux, use "service stratux stop" and "service stratux start" when you want to fire it up again.

Skypuppy

On 03/12/2016 09:05 PM, aerojoe wrote:

Hi Guys, I've not tested the .8r1 version above with the Adafruit. But here is what I found with v .7b3. It seems that something is closing the AMA0 device on my Pi as soon as it's opened. This is why some NMEA messages get through, but most do not. I shutdown the gdl process on the Pi when doing this test, so I don't think there is anything in Stratux that is closing this port. I'll update to the version above tomorrow and repeat my tests and will report back. Joe

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/315#issuecomment-195861124.

aerojoe commented 8 years ago

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. Joe

skypuppy commented 8 years ago

aerojoe,

re not working with other hardware powered-up indicates a power supply problem somewhere.

re stratux log: were you running cutecom at the same time you were running stratux? If cutecom showed good NMEA messages the whole time that stratux is showing open/close attempts, to me that indicates a problem in 1) stratux code, or 2) linux not setting the port as shared/shareable. If #2, that is one problem a daemon like gpsd would probably solve. However, that problem is only important during diagnostic times like now and is not needed for stratux in the airplane. :) But we still gotta get through this diagnostic and development time to --make it work!--

I will try again here at home and insert another computer/rs232-checker and see if #2 is the problem. That said, cyoung has indicated he is not in favor of changing the stratux code to accommodate more hardware due to the programmer overhead. I can respect that but I'm still going to make the mtk3339 work with my stratux box but use the SIRF via USB in the meantime. But, even with git, it is hard (for me) to maintain my little separate code while keeping all the other code up-to-date with everyone else's efforts. AvSquirrel is trying to do this as well but he doesn't have the mtk\3339 hardware. Hope we get it ironed out soon because I am convinced we need the actual time-of-day that the mtk unit can supply during the RPi2 boot procedure.

Skypuppy

On 03/13/2016 12:43 AM, 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. Joe

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/315#issuecomment-195893350.

aerojoe commented 8 years ago

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. aerojoe

aerojoe commented 8 years ago

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.

cyoung commented 8 years ago

@aerojoe - what issues are you having finding the Vk-172? http://www.ebay.com/itm/DIYMALL-Vk-172-Gmouse-G-mouse-Usb-Gps-glonass-Ublox-Windows-10-8-7-vista-xp-/271626061593 http://amzn.com/B00NWEEWW8 http://www.banggood.com/VK-172-GMOUSE-USB-GPSGLONASS-External-GPS-Module-With-USB-Interface-p-973820.html http://www.aliexpress.com/item/VK-172-GMOUSE-USB-GPS-Module-GLONASS-USB/1991146193.html

aerojoe commented 8 years ago

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).

skypuppy commented 8 years ago

Just so I'm not misunderstood, I am an avid supporter of using the Adafruit GPS in the stratux.

On 03/13/2016 11:26 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. aerojoe

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/315#issuecomment-195989778.

skypuppy commented 8 years ago

check solder joints, broken wires, etc.

On 03/13/2016 11:32 AM, aerojoe wrote:

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.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/315#issuecomment-195990755.

ghost commented 8 years ago

@aerojoe

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:

  1. Stratux determine if there is any device attached on /dev/ttyUSB0 (e.g. BU-353 receiver) or /dev/ttyACM0 (e.g. USB u-blox device)
  2. If not, Stratux assumes a u-blox device connected on /dev/ttyAMA0.
  3. /dev/ttyAMA0 is opened at 9600 baud
  4. Binary configuration for u-blox is sent, including a command to set the GPS buad rate to 38400 baud.
  5. /dev/ttyAMA0 is closed, then reopened at 38400 baud.
  6. If no valid NMEA messages are seen within five seconds, the GPS configuration routine is restarted.

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:

stty -F /dev/ttyAMA0 9600
cat /dev/ttyAMA0

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.

ghost commented 8 years ago

By the way, 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.

sounds like a possible hardware problem. I agree with @skypuppy -- check your wiring for shorts!

ghost commented 8 years ago

@skypuppy

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.)

That would be very helpful. (I'm in Minnesota.) Send me a PM on reddit and we can work out the details.

aerojoe commented 8 years ago

@skypuppy I have used the update posted above and the stratux status screen shows version 0.8r1. I do see the stratux trying different baud rates and see messages output that a valid NMEA sentence is recognized. This is only after I reopen AMA0 via cutecom about a dozen times. I know the Adafruit is set to 38.4k and does not change. I'll repeat the tests later today and then post some uncluttered log files so you can see the results. It will be easier to isolate this problem by removing the autorecognition/reconfig code on AMA0. I will also reinstall v0.7b3 (which does not modify the AMA0 baud) to see if that helps isolate the issue.

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.

skypuppy commented 8 years ago

Yes, standard NMEA sentences come through just fine from the Pi, with one exception: while stratux is running, I get garbage occasionally at 38.4 kbaud but never at 9600. Should not be a problem as long as when the checksum doesn't match, that "sentence" is discarded. This is still at the 1hz rate, so I need to test iit from 10hz to 0.10hz and see how many bad sentences come through. I'll have to write a small program to do that and check with and without stratux running. I should also vary the baud rates and record these things so I can make a graph. Then, run the same series of tests on the USB SIRF and see what happens. This will take a few days to write the program, then I'm guessing several days for the tests to run reliably. I don't have a ublox gps so can't test one of those. If anyone else wants to try it with their ublox just let me know and I'll send you the source, then we can put that data into the graph.

Ideally, they will all show zero dropped sentences and then we can confidently announce that the Pi can handle any baud rate with either interface. :)

Skypuppy

On 03/13/2016 02:03 PM, aerojoe wrote:

@skypuppy https://github.com/skypuppy I have used the update posted above and the stratux status screen shows version 0.8r1. I do see the stratux trying different baud rates and see messages output that a valid NMEA sentence is recognized. This is only after I reopen AMA0 about a dozen times. I know the Adafruit is set to 38.4k and does not change. I'll repeat the tests later today and then post some uncluttered log files so you can see the results. It will be easier to isolate this problem by removing the autorecognition/reconfig code on AMA0. I will also reinstall v0.7b3 (which does not modify the AMA0 baud) to see if that helps isolate the issue.

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.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/315#issuecomment-196021457.

aerojoe commented 8 years ago

Ah, I see. So the issues I'm having with AMA0 may be unique to my Pi. If you can see NMEA consistently over 38.4, I may have a flaky serial device. But I'll double check the wiring too.

skypuppy commented 8 years ago

Sorry I wasn't clear. Occasionally the sentences would get mangled at 38.4, with no observed mangles at 9600.

On 03/13/2016 02:34 PM, aerojoe wrote:

Ah, I see. So the issues I'm having with AMA0 may be unique to my Pi. If you can see NMEA consistently over 38.4, I may have a flaky serial device. But I'll double check the wiring too.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/315#issuecomment-196029094.

ghost commented 8 years ago

I'll repeat the tests later today and then post some uncluttered log files so you can see the results.

Sounds like a plan. My experimental branch is a couple of commits ahead of the build I posted a few days ago, but none of the changes involved the GPS handling. This also assumes the Adafruit is powering on at 9600 baud to do autoconfig, but I'd be interested to see how it handles both 9600 and 38.4 on startup.

You'll get the cleanest logs with the SDRs disabled, and Verbose Logs and Record Logs enabled:

image

aerojoe commented 8 years ago

@AvSquirrel @skypuppy Thanks for the advice in doing more debugging. My setup yielded some strange results. The recent gps logs are all empty when I run the Adafruit at 9600. I assume that if the Stratux cannot parse a message, than nothing is logged in the gps log file? But I do have the stratux log file that I can post. Here are the observations:

  1. I could not manually reset the Adafruit baud rate from its 38.4k setting. I used the USB dongle, sent some $PMTK commands, they were accepted but not implemented. I finally had to remove the battery and do a cold start to reset it to 9600. Then I used cutecom to do some more diagnostics and what I saw was mostly garbage, although some partial NMEA sentences came through on rare occasions.
  2. The stratux log file captured some of the events in trying to set up the port. I saw some strange messages like this: "Sent UBX and MTK ident commands at 552250". Was this supposed to be a baud rate? The number here was random in many cases and never was a multiple of 1200. See the stratux log for examples.
  3. When I disconnected the two SDRs, I was able to boot the stratux with the 4 GPIO lines connected to the Adafruit and wifi and ethernet worked fine. So maybe I do have some interference or power issue to examine.
  4. I've not tried to repeat my tests at 38.4k, but the one good GPS log I have that is larger than 10 bytes has a long, error free history of NMEA messages from AMA0. Note, this was only a result of constantly reopening the serial port via cutecom.
  5. In some cases, I do see $PTMKxxxx messages output from the Adafruit. It seems to mix these in with the NMEA sentences. Are these processed as NMEA and could they introduce any errors? aerojoe.

stratux.zip

ghost commented 8 years ago

Thanks. It's unfortunate that you don't have any GPS logs, but stratux.log still gives me some good information.

What I'm seeing is pointing to one of the following: Intermittent shorts between TX and RX, intermittent opens on the GPS TX / RPi RX, and/or multiple pieces of software trying to read the port at the same time.

I'd double check your wiring and soldering-- with the GPS connected to the Pi, but with Pi power unplugged, it wouldn't hurt to put a multimeter between the TX and RX leads and wiggle things a bit to check for shorts. Then, do the same between TX-GND, TX-PWR, RX-GND, RX-PWR.

The good news is that your GPS is outputting valid NMEA sentences at 9600 baud, and that it is responding to a "$PMTK605" with a (partial) PMTK705 ident message -- it's running a firmware whose version starts "AXN_2.31".

image

As to your questions:

The stratux log file captured some of the events in trying to set up the port. I saw some strange messages like this: "Sent UBX and MTK ident commands at 552250".

That's a debug timer (milliseconds since gen_gdl90 startup) that I'm using to calculate timing between the time I send a pair of vendor-specific NMEA messages to the device. In the picture above, these commands were sent at 168,700 milliseconds after start. A response containing a "PMTK705" message was received 800 milliseconds later.

In some cases, I do see $PTMKxxxx messages output from the Adafruit. It seems to mix these in with the NMEA sentences. Are these processed as NMEA and could they introduce any errors?

That's normal and expected. NMEA-0183 allows vendors to add their own proprietary messages, whose codes starting with "P". PUBX = u-blox, PMTK = MediaTek, PGRM = Garmin, and so on. As long as the sentences follow the NMEA rules for length, structure, and checksum, devices that don't understand them will just ignore them.

In this case, I'm using these to our advantage. Since both u-blox and MTK3339 receivers can easily be triggered into sending one of these messages, I can use them to positively identify a u-blox or MTK receiver to Stratux.

skypuppy commented 8 years ago

Woohoo! Btw, with 0.8r1, my stratux now takes input from the Adafruit GPS when it is connected and from the SIRF (Pharos 500 aka Microsoft branded) when it is connected. Double WOOHOO!

Thanks, AvSquirrel. (and I did send you pm's on reddit.)

Skypuppy

On 03/14/2016 12:54 PM, AvSquirrel wrote:

Thanks. It's unfortunate that you don't have any GPS logs, but stratux.log still gives me some good information.

What I'm seeing is pointing to one of the following: Intermittent shorts between TX and RX, intermittent opens on the GPS TX / RPi RX, and/or multiple pieces of software trying to read the port at the same time.

  • Multiple sentences are missing individual bytes or blocks of bytes (yellow highlighted sentences).
  • The string of NUL values would be seen if the serial port detects falling voltage, and then nothing happens.
  • GPS is not seeing any satellites (green highlighted sentences). This could just be because of where you're located, but I've also seen this happen on my u-blox receiver when shorted the RX and TX lines.
  • The "$PUBX,00*33" message (magenta highlight) is sent by the RPi to probe for u-blox. Its appearance in the received data could be a sign that the connection is looping back (TX/RX short). It's also followed by a bunch of garbage bytes.

I'd double check your wiring and soldering-- with the GPS connected to the Pi, but with Pi power unplugged, it wouldn't hurt to put a multimeter between the TX and RX leads and wiggle things a bit to check for shorts. Then, do the same between TX-GND, TX-PWR, RX-GND, RX-PWR.

The good news is that your GPS is outputting valid NMEA sentences at 9600 baud, and that it is responding to a "$PMTK605" with a (partial) PMTK705 ident message -- it's running a firmware whose version starts "AXN_2.31".

image https://cloud.githubusercontent.com/assets/14127245/13752927/f012e81e-e9de-11e5-9abf-b05dcc1848d8.png

As to your questions:

The stratux log file captured some of the events in trying to set
up the port. I saw some strange messages like this: "Sent UBX and
MTK ident commands at 552250".

That's a debug timer (milliseconds since gen_gdl90 startup) that I'm using to calculate timing between the time I send a pair of vendor-specific NMEA messages to the device. In the picture above, these commands were sent at 168,700 milliseconds after start. A response containing a "PMTK705" message was received 800 milliseconds later.

In some cases, I do see $PTMKxxxx messages output from the
Adafruit. It seems to mix these in with the NMEA sentences. Are
these processed as NMEA and could they introduce any errors?

That's normal and expected. NMEA-0183 allows vendors to add their own proprietary messages, whose codes starting with "P". PUBX = u-blox, PMTK = MediaTek, PGRM = Garmin, and so on. As long as the sentences follow the NMEA rules for length, structure, and checksum, devices that don't understand them will just ignore them.

In this case, I'm using these to our advantage. Since both u-blox and MTK3339 receivers can easily be triggered into sending one of these messages, I can use them to positively identify a u-blox or MTK receiver to Stratux.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/315#issuecomment-196438242.

aerojoe commented 8 years ago

Congrats Skypuppy! AvSquirrel, thanks for the diagnosis. When I read through your analysis, I had this sinking feeling in my stomach. I remembered when I bought the Adafruit that it was a 3.3VDC part. Naturally, I didn't read any directions I just hooked up power to the 3.3VDC pin (GPIO pin 1). The GPS would power up just fine, so I didn't think anything of it until now.

The 5VDC GPIO Pin 2 is the one I should use to power the Adafruit, correct?

If you say yes, you'll hear a gun go off.

I'll check this out tomorrow when I'm back home. Thanks and sorry for the distraction! aerojoe.

skypuppy commented 8 years ago

The Adafruit is a 3V part. You'd have to look on their website to see if it can do 5V as well. I just don't remember if it does. Mine is connected via the 3.3V line because there could be trouble with other hardware if the 5V breaks loose. :)

On 03/14/2016 04:16 PM, aerojoe wrote:

Congrats Skypuppy! AvSquirrel, thanks for the diagnosis. When I read through your analysis, I had this sinking feeling in my stomach. I remembered when I bought the Adafruit that it was a 3.3VDC part. Naturally, I didn't read any directions I just hooked up power to the 3.3VDC pin (GPIO pin 1). The GPS would power up just fine, so I didn't think anything of it until now.

The 5VDC GPIO Pin 2 is the one I should use to power the Adafruit, correct?

If you say yes, you'll hear a gun go off.

I'll check this out tomorrow when I'm back home. Thanks and sorry for the distraction! aerojoe.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/315#issuecomment-196524923.

ghost commented 8 years ago

@aerojoe -- I'd follow @skypuppy's advice here and stick with Pin 1 for power.

I looked at the spec sheet on the Adafruit website. The raw module is only rated for 3.0-4.3V, but there's additional power electronics on the Ultimate GPS Breakout that should let it run at 5V safely.

That gives the following pinout:

Adafruit Vin --> Pin 1 (3.3 V) Adafruit GND --> Pin 6 or Pin 9 (GND) Adafruit TX --> Pin 10 (RXD0) Adafruit RX --> Pin 8 (TXD0)

image

aerojoe commented 8 years ago

Thanks for feedback. This is exactly how I have it wired and I'll leave it that way. I did see a diagram on Adafruit's website that showed a connection to the 5VDC pin when connecting to the serial lines on GPIO. Since you all have it working on 3.3, my problems lie elsewhere. I'll do the wiring checks today to see if I can isolate the problem.

aerojoe commented 8 years ago

Folks, I did check all the wiring and interfaces and they check out. There don't appear to be any shorts or opens on the four pins. I'm fairly certain my issues do not lie in the Adafruit because when the TTL-USB cable is connected the NMEA messages work fine and Stratux can process those over USB. I think the problem lies in the GPIO on the Pi. When I test the port with Stratux shut down, it behaves the same way. I'm going to see if I can borrow another Pi and test it to see if the results change.

skypuppy commented 8 years ago

Have you put your multimeter on each end of each wire and flexed it to check for continuity?

On 03/15/2016 11:04 PM, aerojoe wrote:

Folks, I did check all the wiring and interfaces and they check out. There don't appear to be any shorts or opens on the four pins. I'm fairly certain my issues do not lie in the Adafruit because when the TTL-USB cable is connected the NMEA messages work fine and Stratux can process those over USB. I think the problem lies in the GPIO on the Pi. When I test the port with Stratux shut down, it behaves the same way. I'm going to see if I can borrow another Pi and test it to see if the results change.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/315#issuecomment-197142695

aerojoe commented 8 years ago

@skypuppy Yes, in fact I'm using wires from an Intel Galileo kit. I ran each one separately to ground to ensure continuity. Running both TX and RX to ground shows 5 ohms each and it never waivers regardless of movement. I'm stumped.

skypuppy commented 8 years ago

Well, the Pi's are cheap enough to have a spare to test with. :-) :-) I do, and I keep several versions of stratux SD cards, one vanilla version that has only the "production stratux" and several that have various code experiments on them.

Skypuppy

On 03/15/2016 11:33 PM, aerojoe wrote:

@skypuppy https://github.com/skypuppy Yes, in fact I'm using wires from an Intel Galileo kit. I ran each one separately to ground to ensure continuity. Running both TX and RX to ground shows 5 ohms each and it never waivers regardless of movement. I'm stumped.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/315#issuecomment-197148465

skypuppy commented 8 years ago

AvSquirrel, the vanilla 0.8r1-76blah "production release" of stratux does not have the MTK3339 working, in case you were not aware.

Update on above statement: I left it running overnight and when I got up this morning, the MTK3339 was being seen and used by the stratux system.

Either my hardware is getting flaky, or I am! I'll leave it to the reader as to which option is true.

ghost commented 8 years ago

@aerojoe, @skypuppy -- Getting real close. Had to work around a couple of unexpected quirks: 1) The MTK3339 just echoes back any unexpected commands. 2) Occasionally it throws gibberish after writing commands.

I also decided to switch over from 3.3V to 5.0V. Ethernet got really flaky whenever I plugged in on 3.3V.

2016/03/23 04:26:38 Configuring GPS
2016/03/23 04:26:38 Using /dev/ttyAMA0 for GPS
2016/03/23 04:26:38 Sent MTK ident command at [28400] msec since start. Listening for response.
2016/03/23 04:26:38 [28450] Raw data read from /dev/ttyAMA0: ����������������$�PMTK705,AXN_2.31_3339_13101700,5632,PA6H,1.0*6B
2016/03/23 04:26:38 Data was seen on /dev/ttyAMA0 seen during GPS probing, but not NMEA message.
2016/03/23 04:26:39 [28500] Raw data read from /dev/ttyAMA0: $PMTK705,AXN_2.31_3339_13101700,5632,PA6H,1.0*6B
2016/03/23 04:26:39 GPS detected: NMEA messages seen.
2016/03/23 04:26:39 GPS detected: MediaTek NMEA firmware message (AXN_2.31_3339_13101700) seen.
2016/03/23 04:26:39 Finished writing MediaTek GPS config to /dev/ttyAMA0. Opening port to test connection.
2016/03/23 04:26:42 NMEA messages last minute. Valid: 47. Position: 14. Invalid: 0.
2016/03/23 04:26:45 gpsSerialReader() scanner loop iteration i=100
2016/03/23 04:26:46 NMEA messages last minute. Valid: 119. Position: 35. Invalid: 0.
2016/03/23 04:26:50 NMEA messages last minute. Valid: 191. Position: 56. Invalid: 0.
2016/03/23 04:26:51 gpsSerialReader() scanner loop iteration i=200
2016/03/23 04:26:54 NMEA messages last minute. Valid: 259. Position: 76. Invalid: 0.

image

skypuppy commented 8 years ago

Nah, you soldered it wrong! Hahahahhhaha.

Are you sure you included the CRC at the end of the command string?

On 03/22/2016 11:53 PM, AvSquirrel wrote:

@aerojoe https://github.com/aerojoe, @skypuppy https://github.com/skypuppy -- Getting real close. Had to work around a couple of unexpected quirks: 1) The MTK3339 just echoes back any unexpected commands. 2) Occasionally it throws gibberish after writing commands.

I also decided to switch over from 3.3V to 5.0V. Ethernet got really flaky whenever I plugged in on 3.3V.

|2016/03/23 04:26:38 Configuring GPS 2016/03/23 04:26:38 Using /dev/ttyAMA0 for GPS 2016/03/23 04:26:38 Sent MTK ident command at [28400] msec since start. Listening for response. 2016/03/23 04:26:38 [28450] Raw data read from /dev/ttyAMA0: ����������������$�PMTK705,AXN_2.31_3339_13101700,5632,PA6H,1.0_6B 2016/03/23 04:26:38 Data was seen on /dev/ttyAMA0 seen during GPS probing, but not NMEA message. 2016/03/23 04:26:39 [28500] Raw data read from /dev/ttyAMA0: $PMTK705,AXN_2.31_3339_13101700,5632,PA6H,1.0_6B 2016/03/23 04:26:39 GPS detected: NMEA messages seen. 2016/03/23 04:26:39 GPS detected: MediaTek NMEA firmware message (AXN_2.31_3339_13101700) seen. 2016/03/23 04:26:39 Finished writing MediaTek GPS config to /dev/ttyAMA0. Opening port to test connection. 2016/03/23 04:26:42 NMEA messages last minute. Valid: 47. Position: 14. Invalid: 0. 2016/03/23 04:26:45 gpsSerialReader() scanner loop iteration i=100 2016/03/23 04:26:46 NMEA messages last minute. Valid: 119. Position:

  1. Invalid: 0. 2016/03/23 04:26:50 NMEA messages last minute. Valid:
  2. Position: 56. Invalid: 0. 2016/03/23 04:26:51 gpsSerialReader() scanner loop iteration i=200 2016/03/23 04:26:54 NMEA messages last minute. Valid: 259. Position: 76. Invalid: 0. |

image https://cloud.githubusercontent.com/assets/14127245/13975720/64790ae6-f086-11e5-87de-50b1a6ef1ed4.png

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/315#issuecomment-200177273

skypuppy commented 8 years ago

I don't have a scope hooked up but my best bet is that gibberish is comms timing mismatch between gps and Pi. Are you starting at 1 hz? I have seen it many times on the pi but never on the desktop.

On 03/22/2016 11:53 PM, AvSquirrel wrote:

@aerojoe https://github.com/aerojoe, @skypuppy https://github.com/skypuppy -- Getting real close. Had to work around a couple of unexpected quirks: 1) The MTK3339 just echoes back any unexpected commands. 2) Occasionally it throws gibberish after writing commands.

I also decided to switch over from 3.3V to 5.0V. Ethernet got really flaky whenever I plugged in on 3.3V.

|2016/03/23 04:26:38 Configuring GPS 2016/03/23 04:26:38 Using /dev/ttyAMA0 for GPS 2016/03/23 04:26:38 Sent MTK ident command at [28400] msec since start. Listening for response. 2016/03/23 04:26:38 [28450] Raw data read from /dev/ttyAMA0: ����������������$�PMTK705,AXN_2.31_3339_13101700,5632,PA6H,1.0_6B 2016/03/23 04:26:38 Data was seen on /dev/ttyAMA0 seen during GPS probing, but not NMEA message. 2016/03/23 04:26:39 [28500] Raw data read from /dev/ttyAMA0: $PMTK705,AXN_2.31_3339_13101700,5632,PA6H,1.0_6B 2016/03/23 04:26:39 GPS detected: NMEA messages seen. 2016/03/23 04:26:39 GPS detected: MediaTek NMEA firmware message (AXN_2.31_3339_13101700) seen. 2016/03/23 04:26:39 Finished writing MediaTek GPS config to /dev/ttyAMA0. Opening port to test connection. 2016/03/23 04:26:42 NMEA messages last minute. Valid: 47. Position: 14. Invalid: 0. 2016/03/23 04:26:45 gpsSerialReader() scanner loop iteration i=100 2016/03/23 04:26:46 NMEA messages last minute. Valid: 119. Position:

  1. Invalid: 0. 2016/03/23 04:26:50 NMEA messages last minute. Valid:
  2. Position: 56. Invalid: 0. 2016/03/23 04:26:51 gpsSerialReader() scanner loop iteration i=200 2016/03/23 04:26:54 NMEA messages last minute. Valid: 259. Position: 76. Invalid: 0. |

image https://cloud.githubusercontent.com/assets/14127245/13975720/64790ae6-f086-11e5-87de-50b1a6ef1ed4.png

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/315#issuecomment-200177273

ghost commented 8 years ago

Up and running on RPi3.

img_0649

image

Cold boot log:

2016/03/23 07:18:54 Stratux v0.8r2 (2b3f76a1b36a16be82b77d4c85eb92ad1394cfde) starting.
2016/03/23 07:18:54 Entered uatReader() ...
2016/03/23 07:18:54 read in settings.
2016/03/23 07:18:54 client connected: 192.168.10.11:4000 (raspberrypi).
2016/03/23 07:18:54 client connected: 192.168.10.11:49002 (raspberrypi).
2016/03/23 07:18:55 ===== ES Device Serial: 00000001 PPM 0 =====
2016/03/23 07:18:55 Entered ES read() ...
2016/03/23 07:18:55 Executed /usr/bin/dump1090 successfully...
2016/03/23 07:18:58 Configuring GPS
2016/03/23 07:18:58 Using /dev/ttyAMA0 for GPS
2016/03/23 07:18:58 Sent MTK and UBX ident commands at [4000] msec since start. Listening for response.
2016/03/23 07:18:58 [4050] Raw data read from /dev/ttyAMA0: $GPGGA,072055.086,,,,,0,00,,,M,,M,,*73
2016/03/23 07:18:58 GPS detected: NMEA messages seen.
2016/03/23 07:18:58 [4100] Raw data read from /dev/ttyAMA0: $GPGSA,A,1,,,,,,,,,,,,,,,*1E
2016/03/23 07:18:58 [4150] Raw data read from /dev/ttyAMA0: $GPRMC,072055.086,V,,,,,0.00,0.00,230316,,,N*43
2016/03/23 07:18:58 [4200] Raw data read from /dev/ttyAMA0: $GPVTG,0.00,T,,M,0.00,N,0.00,K,N*32
2016/03/23 07:18:58 [4250] Raw data read from /dev/ttyAMA0: $PMTK705,AXN_2.31_3339_13101700,5632,PA6H,1.0*6B
2016/03/23 07:18:58 GPS detected: MediaTek NMEA firmware message (AXN_2.31_3339_13101700) seen.
2016/03/23 07:18:59 Finished writing MediaTek GPS config to /dev/ttyAMA0. Opening port to test connection.
2016/03/23 07:19:02 NMEA messages last minute. Valid: 48. Position: 14. Invalid: 0.
2016/03/23 07:19:06 NMEA messages last minute. Valid: 116. Position: 34. Invalid: 0.
2016/03/23 07:19:10 NMEA messages last minute. Valid: 184. Position: 54. Invalid: 0.

Warm boot log (GPS already at 38.4 kbps during detection)

2016/03/23 07:19:15 Stratux v0.8r2 (2b3f76a1b36a16be82b77d4c85eb92ad1394cfde) starting.
2016/03/23 07:19:15 Entered uatReader() ...
2016/03/23 07:19:15 read in settings.
2016/03/23 07:19:15 client connected: 192.168.10.11:4000 (raspberrypi).
2016/03/23 07:19:15 client connected: 192.168.10.11:49002 (raspberrypi).
2016/03/23 07:19:16 ===== ES Device Serial: 00000001                                                                                                                                                                                                                                                          PPM 0 =====
2016/03/23 07:19:16 Entered ES read() ...
2016/03/23 07:19:16 Executed /usr/bin/dump1090 successfully...
2016/03/23 07:19:19 Configuring GPS
2016/03/23 07:19:19 Using /dev/ttyAMA0 for GPS
2016/03/23 07:19:19 Sent MTK and UBX ident commands at [4000] msec since start. Listening for response.
2016/03/23 07:19:19 [4450] Raw data read from /dev/ttyAMA0: Ä¡%¡…¥¬H!¡5±µHsÄ!¥1¥!!¥ !…%%¡5üÄ¡%¡…¥HsÄ!¥1¥!!¥ !…%%¡5üÄ¡%¡…¥
2016/03/23 07:19:19 Data was seen on /dev/ttyAMA0 seen during GPS probing, but not NMEA message.
2016/03/23 07:19:20 [5450] Raw data read from /dev/ttyAMA0: B”¥¥¥PHsÄ!¥1¥!!¥ !…%%¡5üÄ„¥%¥…5¬sÄ„¥1¥!!¥ !…%%¡5üÄ¡%¡…¥HsÄ!¥1¥!!¥ !…%%¡5üÄÇ%¡…ϬH!¡5±µHÅÄ!¥1¥!!¥ !…%%¡5üÄÇ%¡…¥HsÄ!¥1¥!!¥ !…%%¡5üÄ¡%¡…¥
2016/03/23 07:19:20 Data was seen on /dev/ttyAMA0 seen during GPS probing, but not NMEA message.
2016/03/23 07:19:21 [6250] Raw data read from /dev/ttyAMA0: B”¥¥¥PHsÄ!¥1¥!!¥ !…%%¡5üÔ„¥%¥…µ¬sÔ„¥1¥!!¥… !…%%¡5üÔ¡%¡…¥cHsÔ!¥1¥!!¥`!…%%¡5üÔ¡%¡…¥!±%%%HsÔ!¥1¥!!¥ !…%%¡5üÔ¡%¡…¥
2016/03/23 07:19:21 Data was seen on /dev/ttyAMA0 seen during GPS probing, but not NMEA message.
2016/03/23 07:19:22 [7250] Raw data read from /dev/ttyAMA0: HsÔ!¥1¥!!¥ !…%%¡5üÔ¡%¡…¥B”¥¥¥PHsÔ!¥1¥!!¥ !…%%¡5üÔ„¥%¥Õµ¬óÔ„¥C¥!!¥…`!…%%¡5üÔ¡%¡…¥HsÔ!¥1¥!!¥ !…%%¡5üÔ¡%¡…¥c!±%%%HsÔ!¥1¥!!¥ !…%%¡5üÔ¡%¡…¥
2016/03/23 07:19:22 Data was seen on /dev/ttyAMA0 seen during GPS probing, but not NMEA message.
2016/03/23 07:19:27 [12450] Raw data read from /dev/ttyAMA0: HsÔ!¥1¥!!¥ !…%%¡5üÔ¡%¡…¥B”¥¥¥PHsÔ!¥1¥!!¥ !…%%¡5üÆ„¥%¥…5¬sÆ„¥1¥!!¥ !…%%¡5üÆ¡%¡…¥HsÆ!¥1¥!!¥ !…%%¡5üÆ¡%¡…¥¬H!¡5±µHsÆ!¥1¥!!¥ !…%%¡5üÆç%¡…ÏHóÆ!¥C¥!!¥ !…%%¡5üÆ¡%¡…¥cB”¥¥¥PHsÆ!¥1¥!!¥ !…%%¡5üÆ„¥%¥…5¬sÆ„¥1¥!!¥ !…%%¡5üÆ¡%¡…¥HsÆ!¥1¥!!¥ !…%%¡5üÆ£%¡…ç¬H!¡5ñµcHÅÆ!¥1¥!!¥ !…%%¡5üÆ¡%¡…¥¬sÆ!¥C¥!!¥ !…%%¡5üÆ¡%¡…¥B”¥¥¥PHsÆ!¥1¥!!¥ !…%%¡5üÆ¥%¥Õ5¬sÆ„¥1¥!!¥ !…%%¡5üÆ¡%¡…¥¬sÆ!¥1¥!!¥ !…%%¡5üÆ¡%¡…¥!±%%%5¬sÆ!¥1¥!!¥ !…%%¡5üÆ¡%¡…¥¬sÆ!¥1¥!!¥ !…%%¡5üÆ¡%¡…¥¬@R¥¥¥%¬sÆ!¥1¥!!¥… !…%%¡5üÆ„¥%¥…5¬sÆ„¥1¥!!¥ !…%%¡5üÆ¡%¡…¥¬sÆ!¥1¥!!¥ !…%%¡5üÆ¡%¡…¥¬H!¡µ±µ¬sÆ!¥1¥!!¥ !…%%¡5üÆ¡%¡…¥¬sÆ!¥1¥!!¥ !…%%¡5üÆ¡%¡…¥B”¥¥¥PHsÆ!¥1¥!!¥… !…%%¡5üÆ„¥%¥…5¬sÆ„¥1¥!!¥ !…%%¡5üÆ£%¡…çHóÆ!¥C¥!!¥ !…%%¡5üÆ¡%¡…¥¬H!¡µ±µ¬sÆ!¥1¥!!¥ !…%%¡5üÆ¡%¡…¥HsÆ!¥1¥!!¥ !…%%¡5üÆ¡%¡…¥
2016/03/23 07:19:27 Data was seen on /dev/ttyAMA0 seen during GPS probing, but not NMEA message.
2016/03/23 07:19:27 No NMEA messages were seen at 9600 baud on /dev/ttyAMA0. Might be due to device at higher bitrate from warm boot. Opening port at 38400 baud to test connection.
2016/03/23 07:19:28 GPS detected: NMEA messages seen.
2016/03/23 07:19:31 NMEA messages last minute. Valid: 54. Position: 16. Invalid: 0.
2016/03/23 07:19:35 NMEA messages last minute. Valid: 122. Position: 36. Invalid: 0.
2016/03/23 07:19:39 NMEA messages last minute. Valid: 190. Position: 56. Invalid: 0.
2016/03/23 07:19:43 NMEA messages last minute. Valid: 258. Position: 76. Invalid: 0.
2016/03/23 07:19:45  - Last GPS fix: 30 seconds ago, GPS solution type: 0 using 0 satellites (0/0 seen/tracked), NACp: 0, est accuracy 0.00 m
2016/03/23 07:19:45  - GPS vertical velocity: 0.00 ft/sec; GPS vertical accuracy: 0 m
2016/03/23 07:19:47 NMEA messages last minute. Valid: 326. Position: 96. Invalid: 0.
2016/03/23 07:19:51 NMEA messages last minute. Valid: 394. Position: 116. Invalid: 0.
2016/03/23 07:19:55 NMEA messages last minute. Valid: 462. Position: 136. Invalid: 0.
2016/03/23 07:19:59 NMEA messages last minute. Valid: 530. Position: 156. Invalid: 0.
2016/03/23 07:20:03 NMEA messages last minute. Valid: 598. Position: 176. Invalid: 0.
2016/03/23 07:20:07 NMEA messages last minute. Valid: 666. Position: 196. Invalid: 0.
2016/03/23 07:20:11 NMEA messages last minute. Valid: 734. Position: 216. Invalid: 0.
2016/03/23 07:20:15 NMEA messages last minute. Valid: 802. Position: 236. Invalid: 0.
2016/03/23 07:20:19 NMEA messages last minute. Valid: 870. Position: 256. Invalid: 0.
2016/03/23 07:20:23 NMEA messages last minute. Valid: 938. Position: 276. Invalid: 0.
2016/03/23 07:20:27 NMEA messages last minute. Valid: 1000. Position: 294. Invalid: 0.
2016/03/23 07:20:31 NMEA messages last minute. Valid: 1000. Position: 294. Invalid: 0.
2016/03/23 07:20:35 NMEA messages last minute. Valid: 1000. Position: 294. Invalid: 0.
2016/03/23 07:20:39 NMEA messages last minute. Valid: 1000. Position: 294. Invalid: 0.
2016/03/23 07:20:43 NMEA messages last minute. Valid: 1000. Position: 294. Invalid: 0.
2016/03/23 07:20:45  - Last GPS fix: 1 minute ago, GPS solution type: 0 using 0 satellites (0/0 seen/tracked), NACp: 0, est accuracy 0.00 m
2016/03/23 07:20:45  - GPS vertical velocity: 0.00 ft/sec; GPS vertical accuracy: 0 m
2016/03/23 07:23:12  - Last GPS fix: now, GPS solution type: 1 using 3 satellites (3/3 seen/tracked), NACp: 9, est accuracy 19.92 m
2016/03/23 07:23:12  - GPS vertical velocity: 0.00 ft/sec; GPS vertical accuracy: 5 m
2016/03/23 07:23:42  - Last GPS fix: 1 second ago, GPS solution type: 1 using 6 satellites (6/6 seen/tracked), NACp: 9, est accuracy 10.16 m
2016/03/23 07:23:42  - GPS vertical velocity: 0.00 ft/sec; GPS vertical accuracy: 4.4 m
2016/03/23 07:34:12  - Last GPS fix: 1 second ago, GPS solution type: 2 using 7 satellites (7/7 seen/tracked), NACp: 10, est accuracy 4.96 m
2016/03/23 07:34:12  - GPS vertical velocity: 0.00 ft/sec; GPS vertical accuracy: 8.2 m
ghost commented 8 years ago

Are you sure you included the CRC at the end of the command string

Yep. It responds correctly to MTK commands, but I haven't fully probed out how it handles non-MTK NMEA commands with valid formatting, or how it handles random text on the port.

my best bet is that gibberish is comms timing mismatch between gps and Pi

Could be. I know I had some problems with the RY835AI with last-bit errors. This is a bit different, but adding some sleeps between the writes, and using extra "PMTK605" writes during probing seemed to help a lot.

uktris commented 8 years ago

@AvSquirrel I've also been tinkering with the MT3339 and have had it operating quite well with a good degree of overlap in command set. One of the main advantages to the chipset is support for EPO which improves cold start fix time enormously (though quite how you could have the pi update this frequently enough to be useful is another issue). Some very useful scripts here https://github.com/f5eng/mt3339-utils in case it helps.

One thought I had was that if the GPS and/or AHRS code was abstracted then feasibly separate parties could maintain the support for additional hardware without the burden being on the core developers. Hardware could then be configured in an advanced section of the UI. Not an insignificant task of course...

skypuppy commented 8 years ago

gpsd "might" be a good candidate for generalizing the gps control code and messages. That way, the stratux programmers load would be considerably lightened. I'm still investigating whether it is practical on the RPi or not. It is very useful for gps tasks in other software products.

I'm also tinkering with the idea of a "imud," or inertial measurement daemon, in the same vein as gpsd (gps daemon.) I'm tinkering with that idea using Qt for it's development but the target is a library with documented hooks, just like gpsd is. Qt has some basis for this already, with their C++ "sensor class." However, this won't happen in the next couple months for a bunch of reasons (mostly my limits.)
Meanwhile we have stuff that works (except I don't currently have an RY unit or a VK-172 due to reliability and functionality issues in my opinion only. Which is what open-source is all about.)

Skypuppy

On 03/26/2016 06:57 PM, uktris wrote:

@AvSquirrel https://github.com/AvSquirrel I've also been tinkering with the MT3339 and have had it operating quite well with a good degree of overlap in command set. One of the main advantages to the chipset is support for EPO which improves cold start fix time enormously (though quite how you could have the pi update this frequently enough to be useful is another issue). Some very useful scripts here https://github.com/f5eng/mt3339-utils in case it helps.

One thought I had was that if the GPS and/or AHRS code was abstracted then feasibly separate parties could maintain the support for additional hardware without the burden being on the core developers. Hardware could then be configured in an advanced section of the UI. Not an insignificant task of course...

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/315#issuecomment-201952519

aerojoe commented 8 years ago

@AvSquirrel I did download and try out .8r2. I see the same results as before when using TTYAMA0. It's just not consistently processing NMEA messages over serial. When I connect to TTYAMA0 using cutecom and constantly reopen the port, messages start getting through and the stratux shows 3D POS. When I close the port through cutecom, the stratux loses a valid position. I tried it both on the 5VDC pin and the 3.3 VDC pin with the same results. My wiring connection is identical to yours. What boggles my mind is that you can get consistent position data using the same set up and I cannot.

skypuppy commented 8 years ago

It works for me, too, Joe. And when it has SBAS (WAAS) fix, it is dead on accurate (while sitting still in my kitchen.) Good enough for a missile fix! :-)

Skypuppy

On 03/27/2016 12:17 PM, aerojoe wrote:

@AvSquirrel https://github.com/AvSquirrel I did download and try out .8r2. I see the same results as before when using TTYAMA0. It's just not consistently processing NMEA messages over serial. When I connect to TTYAMA0 using cutecom and constantly reopen the port, messages start getting through and the stratux shows 3D POS. When I close the port through cutecom, the stratux loses a valid position. I tried it both on the 5VDC pin and the 3.3 VDC pin with the same results. My wiring connection is identical to yours. What boggles my mind is that you can get consistent position data using the same set up and I cannot.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/315#issuecomment-202108374