[Ovmsdev] SIM808/SIM908 GPS accuracy

[Michael Balzer]

Example GPS log excerpt from the SIM908:

2,142452,5118.427633,N,723.060952,E,1,4,2.862085,41.881016,M,47.558514,M,,0000
64,79.84,T,,M,0.00,N,0.00,K,A
2,142454,5118.427617,N,723.060236,E,1,4,2.863321,41.924519,M,47.558521,M,,0000
64,28.72,T,,M,2.84,N,5.25,K,A
2,142456,5118.428416,N,723.057457,E,1,4,2.864882,43.029949,M,47.558483,M,,0000
64,289.11,T,,M,3.24,N,6.01,K,A
2,142458,5118.423982,N,723.060985,E,1,5,1.995852,50.477901,M,47.558537,M,,0000
64,289.11,T,,M,0.00,N,0.00,K,A
2,142500,5118.421071,N,723.063434,E,1,5,1.996306,54.801235,M,47.558567,M,,0000
64,289.11,T,,M,0.00,N,0.00,K,A
2,142502,5118.421071,N,723.063434,E,1,5,1.995406,54.801235,M,47.558567,M,,0000
64,289.11,T,,M,0.00,N,0.00,K,A


Regarding testing without hardware, there is a PIC simulator built into
the MPLAB X IDE, that also emulates some PIC18 CPUs. Haven't used it
though, and I doubt it will be able to run the complete OVMS firmware,
but it should be usable to test single functions.

Regards,
Michael


Am 02.02.2017 um 08:52 schrieb Edward Cheeseman:
> Oh, can someone send me a DIAG capture (or confirm) that the SIM908
> lat/long outputs are (D)DDMM.MMMM format, rather than (D)DDMM.MMMMMM?
> I’m error checking so either will work, just don’t want to leave data
> behind :)
>
> Edward
>
>> On 2/02/2017, at 7:59 PM, Edward Cheeseman <cheesemanedward at gmail.com
>> <mailto:cheesemanedward at gmail.com>> wrote:
>>
>> Hi Mark,
>>
>> I only found this out because I read the C18 user manual.
>> Something it has that I haven't seen before is a “long short” - a
>> 24bit signed integer type! (also an unsigned long short too)
>>
>> I’ve made a spreadsheet which was the basis for the math.
>> I will try with Mac gcc. Part of the fun is gcc (64bit) will have a
>> vastly different idea of what an int is compared to C18 (8bit)!
>> I’ll have to change data types between the two compilers.
>> The “uint8_t” style declarations don’t seem to work - I haven’t found
>> a C18 stdint.h header. I prefer these to remove this sort of ambiguity!
>>
>> I’ll let you know how that step goes.
>>
>> Edward
>>
>>> On 2/02/2017, at 7:23 PM, Mark Webb-Johnson <mark at webb-johnson.net
>>> <mailto:mark at webb-johnson.net>> wrote:
>>>
>>> Edwards.
>>>
>>> First I’ve heard of this, but it doesn’t surprise me.
>>>
>>> Testing this sort of stuff is not particularly easy. What we have
>>> done in the past is put in a DIAG mode command to allow this
>>> function to be called with a given string parameter, and then to
>>> print the result. Then, we can script up something to feed in a
>>> bunch of input and see what the output is like. But, that does
>>> require physical hardware.
>>>
>>> Perhaps also the function could just be run in a standalone C
>>> program on the mac? So long as the type sizes are the same, the
>>> results should be equivalent (perhaps with some float rounding
>>> differences in the original version).
>>>
>>> Regards, Mark.
>>>
>>>> On 2 Feb 2017, at 4:38 AM, Edward Cheeseman
>>>> <cheesemanedward at gmail.com <mailto:cheesemanedward at gmail.com>> wrote:
>>>>
>>>>
>>>>> On 23/01/2017, at 8:12 PM, Edward Cheeseman wrote:
>>>>> I’ve started rewriting gps2latlon() to use a long long (64bit)
>>>>> integer multiply and divide.
>>>>> I see reference to SIM808 and 908 on an arduino shield, so I might
>>>>> have a look to see what they have done.
>>>>
>>>> I totally overestimated the pic18F capability.
>>>> So it turns out the C18, and for that matter, the XC8 compilers
>>>> treat long long the same as long - 32bit.
>>
>
> Edward Cheeseman
> Electrical Engineer
> cheesemanedward at gmail.com <mailto:cheesemanedward at gmail.com>
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20170202/3ce8d3d2/attachment.htm>