|
pilotmatt
|
|
|
Group: Forum Members
Posts: 13,
Visits: 81
|
I'm a recent user to Skydemon. It has worked perfectly for navigation with my old GPS receiver, an Emtac BTGPS III. No issues at all. However, I've recently upgraded to a new receiver (here: http://www.gns-gmbh.com/index.php?id=79&L=1). It offers some benefits as it has a faster refresh, support for more constellations than just GPS, and SBAS. And also has a longer battery life. The new receiver works flawlessly with Memory Map both on my PDA and my laptop, as well as with my Android phone. However, Skydemon will not work with it. When entering Navigation mode, it simply says "Seeking Satellites, 'n' found ('x' out there)". It never gets past that and never gets a fix, even though it often 'finds' as many as 15 or 16 satellites. I'm not entirely sure why when Memory Map still works perfectly with the same Bluetooth COM port settings. The old receiver continues to work.
Anyone have any thoughts? Is it because Skydemon will not support GLONASS/SBAS NMEA messages or something?
Cheers
running SD 2.7.0.0
|
|
|
|
|
Admin
|
|
|
Group: Administrators
Posts: 48,
Visits: 212
|
As long as your receiver outputs standard NMEA messages, there's no reason SkyDemon wouldn't work with it. Perhaps it is failing to emit the fix accuracy messages, which would cause SkyDemon to not process the data received.
|
|
|
|
|
pilotmatt
|
|
|
Group: Forum Members
Posts: 13,
Visits: 81
|
Hmm, ok. The supporting datasheet suggests it does comply fully with NMEA-0183. I just linked both receivers to my laptop and did a quick data capture of the NMEA messages. Sorry to geek out for a moment but I'm searching for a better explanation of why this isn't working. The older receiver received: 8 GPGGA messages 8 GPGSA messages 23 GPGSV messages 8 GPRMC messages Note they're all GP messages, as one would expect with a receiver based only on the NAVSTAR GPS system. The newer receiver obtained, in a similar timeframe: 6 GLGSV messages 9 GNGLL messages 17 GNGSA messages 8 GNRMC messages 9 GPGGA messages 8 GPGSV messages 8 GPVTG messages Here we can see a mix of GPS (GP), GLONASS (GL) and 'blended solution' messages (GN).
Seems to be a perfectly adequate source of navigational messages unless you can spot something I can't...? I suspect the problem might lie more in Skydemon's inability to parse NMEA messages it isn't expecting. Perhaps unable to substitute the GPGSA/GPRMC messages with GNxxx ones?
If raw data would help, I can post it.
I really like Skydemon and want it to work but if it won't, whilst other software packages demonstrably do, I'll have to revert to the competition.
|
|
|
|
|
Tim Dawson
|
|
|
Group: Forum Members
Posts: 7.8K,
Visits: 8.4K
|
Any normal GPS receiver should output the standard group of NMEA messages that all software can parse: GPRMC, GPGGA, GPGSA, GPGSV. These are basic messages and SkyDemon parses them all. Just because your device is sending all those messages doesn't mean that there's useful information in all of them. Again, I would suspect that it isn't sending accuracy information (in GSA/GGA) and without accuracy information SkyDemon will not use the position information (by design).
Other software may well not impose the minimum accuracy thresholds that we do.
|
|
|
|
|
pilotmatt
|
|
|
Group: Forum Members
Posts: 13,
Visits: 81
|
Hi Tim, thanks for the reply. Sad to say, though, that I have to disagree with you on this. I've captured NMEA output from both my old and new GPS units, and run both of them through several different mapping packages and GNSS positional analysers. For the sake of example, one such package was VisualGPSView, available for free at http://www.visualgps.net/VisualGPSView/default.htm. The NMEA capture tool I used shows perfectly valid data from both units, complete with accuracy messages. VisualGPSView showed an accuracy for my older, GPS-only receiver as 2.0 PDOP, 1.4 HDOP and 1.5 VDOP. Over the same time period, the newer GNSS unit detected usable signals from GPS, WAAS and GLONASS and produced a solution with 1.1 PDOP, 0.7 HDOP and 0.9 VDOP, both tracking and viewing more satellites. This would seem somewhat difficult to achieve if, by your suggestion, it wasn't outputting valid NMEA messages including accuracy. The apparent conclusion is that SkyDemon either isn't NMEA-compliant, in that it either doesn't understand messages from anything other than the $GP talkers, or it filters out non-$GP messages by design - meaning that it doesn't support GLONASS or SBAS. Something that those using such receivers - or about to select one for use with SD - perhaps ought to consider. I'm willing to stand corrected but certainly, on the basis of my own findings, SD is the only one of several packages I've used that won't garner a valid GPS position from my new receiver. Pity.
|
|
|
|
|
Tim Dawson
|
|
|
Group: Forum Members
Posts: 7.8K,
Visits: 8.4K
|
Feel free to upload a log of sentence output from your receiver here and I'll step through it to see why SkyDemon is having a problem with it.
You're absolutely right that SkyDemon ignores non GP sentences, as the vast majority of apps will. It should NOT be necessary for individual apps to process GLONASS or SBAS messages in order to gain the benefit from them. Any increased accuracy can and should be incorporated into the standard GP messages. We would only implement specific handling for extra messages to report extra information which isn't directly useful to GPS navigation.
Also, bear in mind that on iOS and Android we never even see the original GPS sentences. Both platforms offer a location services abstraction which detach location and navigation information from the underlying sentence stream.
|
|
|
|
|
pilotmatt
|
|
|
Group: Forum Members
Posts: 13,
Visits: 81
|
Thanks Tim I will send you the NMEA logs when I'm next home - currently working away for a few days. And now I'm sensing the reason why my new receiver does not work with SkyDemon, as it ignores non-$GP sentences. I agree with your philosophy but perhaps disagree with the method. At this point, I should probably 'fess up and state that I work as a professional pilot within the aerial survey industry; consequently, I've also been involved in the processing of survey data, including GNSS data used to georeference the datasets acquired in the air. And also had a bit of experience of aircraft avionics insofar as GNSS signals are concerned. So whilst most high-end survey GNSS systems are proprietary, we have and do use NMEA-format data for certain things, especially diagnostics. You say that the vast majority of apps will ignore $GP sentences. Perhaps that's right in this narrow sector of the market but it is not the case broadly speaking. In fact, most apps in my experience do exactly the opposite - they ignore the 'talker' completely and process every accuracy, position and in-view message on merit; much as you said, the software will ask 'does this make sense? does it meet my accuracy specs?' and if so, will include it. It generally does not care if it's from a GPS ($GP), GLONASS ($GL), blended ($GN) or even LORAN ($LC) source. Unless the end-user specifically opts not to include a source. So it'll ignore the $xx talker and process each GSA, GGA, GSV, RMC, GLL etc message according to the NMEA standard prescribing them. (For example, in Saudi Arabia GPS is regularly jammed by the military in the vicinity of military installations. For that reason, we filtered out GPS and used only GLONASS data to achieve high-quality results when on survey. Previously the degraded GPS signal was ruining our PDOP. Ok, SkyDemon is not marketed at that part of the world or that particular application, but the MoD here in the UK do conduct GPS jamming trials in some parts of Wales and northern England from time to time.) So when you say any increased accuracy should be incorporated into the standard $GP messages, I could not disagree more. Receivers should not be offering 'blended' positional information as 'spoofed' $GP messages - they should quite correctly use the $GN prefix for those, and the $GL prefix for GLONASS-only messages. To do any differently would actually contravene the NMEA standard and thus be very bad practice. This would explain why my receiver - outputting e.g. $GNGSA and $GLGSV messages - doesn't work with SkyDemon, as it will just ignore them. Create an alpha version of SD just for me which actually ignores the talker field and process messages only according to their suffix, and I bet it would work both flawlessly and instantly.  Hope I've not overtalked this and I'd be pleased to see SD move from strength to strength if it became compatible with more than just the plain, old GPS constellation. 'True' GNSS, whereby GLONASS and Galileo are added to the mix, can only offer a more precise output, especially in respect of altitude. Best wishes Matt
|
|
|
|
|
telhek
|
|
|
Group: Forum Members
Posts: 7,
Visits: 46
|
@tim could the reason be that the gps2000 provides up to 10 positions Per second ?, as does the garmin glo, I read in an other forum that other tracking software had simuler issues.
Brg
Peter
|
|
|
|
|
Tim Dawson
|
|
|
Group: Forum Members
Posts: 7.8K,
Visits: 8.4K
|
10hz update is no problem at all. SkyDemon works great with the Garmin GLO.
Matt, if you're interested in working with me more on potentially incorporating higher accuracy signals into SkyDemon's sentence parser, drop us an email via the website. I can't promise anything but I am interested.
|
|
|
|
|
tbflyer
|
|
|
Group: Forum Members
Posts: 6,
Visits: 62
|
Hi, I got in touch with the producer of the GNS2000 asking them why their GPS receiver does not work properly with Skydemon. From their point of view the reason is that Skydemon is only able to support the 10 years old NMEA 0183 V3.01, instead of the current one. That is why Skydemon is only capable to process talker_ids with “$GP…” of the NMEA data records. Maybe it would be a good idea that both parties talked to each other…? Regards
|
|
|
|