-
Well, you spotted it : To my opinion and so far identified needs, I would say that the "low level" realtime layer separates the gps data stream from the use of these data.
You could just use these data to display them or produce much more dynamic computations and finally store only the results of these...
Yet, all considered, those computations have to be real time too. As far as no other delaying hardware impose its own pace.
By dynamic computations I mean data values based complexity.
As it happens with the big data world it can just be impossible to do some post treatments either due to the data size (mb) or to the volume of data to get of the storage support per time unit (mb/s) .
Do we pretend that the espruino has to solve any real time need? I would n't
You are reading a single comment by @asez73 and its replies.
Click here to read the full conversation.
asez73
That's right, It all depends.
There are the layers... such as the comm layer byte by byte, bytes by bytes, sentence by sentence, processing sentence by sentence, etc. I think the solution is optimal to have each layer to be as efficient as possible. I see your point that you actually could even start to process a single value from a sentence as soon as available. For certain things that can make sense. On the other hand, to make a "final" decision, you nead 3 things in a 3D world.
I think your approach to tailor first which sentences and then do the same for which values in the remaining sentences, that gets you where you want to be: as realtime as possible, realtime as to the point: as soon as the information is available.
For storing the values? Do you already have a solution? If you can process the pertine data in time, how much time do you have left to store it?... for example: in sequences of deltas? reduced granularity? encoded to use minimal space? Any processing requires additional time before storing. 100ms is not much the get everything done... Your app may become the first multi-PICO solution... or you switch over to the Propeller.