[Ovmsdev] SIM808/SIM908 GPS accuracy

Michael Balzer dexter at expeedo.de
Fri Feb 3 02:40:08 HKT 2017

Example GPS log excerpt from the SIM908:


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.


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>

More information about the OvmsDev mailing list