Besides being far more work to process since reading 1 number is 1 memory copy machine code in binary versus 5 subtraction followed by multiplications and 5 more additions per number and besides the longer transfer time over serial port of the longer variable length frames, the real problems are less visible. It is very hard to know which position and altitude belong together as they are sent in different messages, every receiver sends things in different order so a Driver might work for one receiver but not for another. There should be driver variants for various brands. Look into gpsd code to have an idea about the difficulty of making a generic driver. NMEA is not recommended for agile planes where delay is critical.
On Mar 1, 2012 11:44 PM, "Andre Devitt" <
address@hidden> wrote:
Additionally, NMEA support is currently broken in pprz 4_0 beta branch
(think head as well) as indicated my my 19-D GPS fix the other day. I
was only going for 2-D or 3-D. Not sure if it was just flavor of NMEA
my MTK 3329 was spitting out or in general. I have a working driver
will try to submit a pull in the next week.
Andre.
On Thu, Mar 1, 2012 at 3:25 PM, Stephen Dwyer <address@hidden> wrote:
> Hello,
>
> Another nice thing about binary is you are guaranteed messages of a
> specific length. With NMEA if all fields are 0 or something like that,
> you might get a message of only 20 or 30 bytes in length, but with all
> values populated to near maximums, you will get closer to the limit,
> up to perhaps 70 or 80 bytes in length. This is much less predictable
> than being able to specify the same number of bytes and the same value
> in the same offset location in a binary message, and varies the
> timing. This in addition to the fact it takes more effort to convert
> numbers from text representation to binary representation, which takes
> more time than either using the value raw or doing a simple operation
> like scaling the value.
>
> And NMEA sucks, as mentioned several times before. :)
>
> Thanks,
> -Stephen Dwyer
>
> On Thu, Mar 1, 2012 at 12:48 PM, Roman Krashanitsa
> <address@hidden> wrote:
>> Chris, you still sort of have to match the binary frames to the message
>> types but you dont have to convert textual representation of numbers into
>> binary form. Some may argue, but I think this is not the main reason why
>> NMEA is not good compared to proprietary ublox binary protocol. NMEA is just
>> a poor standard, it is not robust and the minimum spanning set of commands
>> is too small. I think wiki will do a better job than me explaining this.
>>
>> Roman
>>
>> 2012/3/1 Chris Wozny <address@hidden>
>>>
>>> All,
>>>
>>> I was wondering if someone had a technical explanation as to why the
>>> UBX protocol is faster than NMEA parsing. I know in the past people
>>> have said NMEA sucks and binary protocol's are faster, but I just want
>>> to make sure I understand the technical reason. I know parsing ASCII
>>> strings requires more CPU cycles, but don't you still have to parse
>>> the UBX output as well?
>>>
>>> Best,
>>> Chris
>>>
>>> _______________________________________________
>>> Paparazzi-devel mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>
>>
>>
>> _______________________________________________
>> Paparazzi-devel mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>
>
> _______________________________________________
> Paparazzi-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel