• If you take FRAM/MRAM - or battery backed SRAM, you can write with up to 40Mb/s SPI... I do not know Espruino's SPI speed limit... Asuming you just go with 1[Mbit/s] SPI speed and simplified calc: (194+6)[Bytes] * 8[bits/Byte] = 1600[bits] data, 1600[bits] / 1[Mbit/sec] = 1600 / 1000000[sec] = 0.0016[sec] = 1.6[msec] for transfering to the memory... w/ 10[Mbits/sec] SPI: 0.16[mSec]... neglectable... The more relevant question is: is there enough space? 32768[B] / 185[B/msg] = ~177[msg]... 10[msg/sec] yields just 17 seconds... Larger FRAM/MRAMs aren't that cheap... 512KB (524,288B): 2883msg, 288s are barely 5 minutes; 2MB (2,097,152): 11335msg, 1133s, ~19min.

    Regarding the announcement of an event: there is a ongoing predicting calculations going on ahead of the time also taking accelerations into consideration and verified by the GPS... It's not just the GPS information of two to a few consecutive measurments that are used to determine the cars position.

    Btw, in calculation of checksume, what is the reason to use the bitwise OR (|) for the length (number of bytes) calculation / assignment: var l = 0 | m.length;?

  • Checksum calculation was actually rewritten by @Gordon during some attempt to make it compiled and really fast. I had reach a 5 ms computation time whiel he reached a 2.7 ms. 0 | NaN gives 0 which allows for exceptionnal case were m has no length property.
    This is actually one of the numerous hidden problems with the GPS nmea sentences. They can provide empty fields, text or numbers somehow randomly in spite of the specifications and taking care of this took twice the time of everything else.
    For instance, right now, I face some time fix problems with an empty time field so split gives "". However isNaN("") is false. Again adding some checks to correctly care for GPS signal problems is time and ressource consumming.

    About gps integrated calculations, you spotted it: they have a real integrated computation power and perform very tricky computations. So I think using the resulting fields in the nmea sentences is a wise and fast decision: So sog, std_latitude, std_longitude, std_altitude, cog are probably more precise than any formula I might design in my own simple approach of precise positionning / speed / heading. Spending twice the ressources (time, complexity and energy) is not a wise approach.

    FRAM, MRAM and other NVRAM's are expensive, add some complexity to hardware and software to use them as a buffer and finally might cost more ressources than benefits.
    I am precisely getting out of RAM more than time with the last improvements...

    A high sensitivity sensor is a good solution to the non moving car problem which I expect to face one day. GPS provides data pretending some movements happened while this is just a random radio problem.

About

Avatar for allObjects @allObjects started