-
That's an interesting point of vue.
Well the processing of data doesn't have to be realtime.
The report could be delayed by hours or evens days. But writing, on a SDcard, a summary of the gps data will take hundreds of ms, if not seconds. So this has to be done only a proper instants which imply ram based intermediate buffer and an in-flux stream analysis.
The data stream of the GPS is still around 185 chars / second which will saturate fairly quickly the remaining available memory on the Espruino if no almost real time analysis is done.
Also, the battery operated goal implies a minimum of time spent so as to save energy.
So, all in all, even at 115200 bauds, 185 chars needs 16 ms to be transfered which is 1/3 of the processing time itself.
Now what remains could be buffer overflows.And 'Never lost' implies to give you instruction before the cross road, not after you went across it... This is another reason to try to measure at more than 1 Hz without spending all of the available time in primary reception of gps data!
You are reading a single comment by @allObjects and its replies.
Click here to read the full conversation.
asez73
@allObjects
Catching up what was going brings something to my attention: do you need to process the data real time? I have no clue what your overal project has to achieve, but I wondered if data could be collected and just stashed away and when the 'report is needed', the data is processed... or, when there is nothing going on, the processing happens? Almost like gps feeds a FIFO - first in, first out - from which processing pulls and puts it into a 'LOST'... LastOut, Still There (just kidding... reminds me of Hertz's Never Lost... you are talking car and gps...).