Randomly Out of memory errors precedeed by JsVarOverflow

Posted on
Page
of 2
/ 2
Next
  • So, I just have a problem which cause is very unclear to me.
    There are no memory leakage for hours and it suddenly appears, or most of the time, never happens.
    And that's without any change to the source code of course.

    Whenever it happens, it is immediately precedeed by Jsvar length problems...
    I do not see why it happens, except either some interpreter internal problem or some real time kind of problem.
    I suspect a serial buffer overflow as the serial speed is set to 115200 bauds and the ublox NEO-6M sends data in chuncks which can be fairly long (115 chars for PUBX,00 nmea sentence for instance).

    So, my code now reduces the types of nmea sentences that the ublox gps device can send. This is a ublox feature which allows to inhibate nmea sentences by sending some specific commands to the ublox. This greatly helps as the error did not showed again since this.

    Anyway, following @Gordon suggestions about debugging, I had the following uncoherent results.
    Specifically, the gps and Serial4 objects should not be that big and even fit to RAM if I don't misunderstand the figures.

    >for (var i in global) print(i+" : "+E.getSizeOf(global[i]))
    Chrono : 108
    ddmmyy : 37
    E : 1
    secn : 41
    lln : 40
    cks7 : 27
    nmea_checksum : 54
    start_stop_nmea : 84
    fieldsOfInterest : 31
    codeFieldOfInterest : 44
    posFieldsOfInterest : 26
    getFieldsPos : 8
    parseHandlers : 124
    estimate_dist : 25
    tfTimeout : 1
    tf : 66
    connect : 183
    gps : 1902
    Serial : 6
    Serial4 : 1903
    console : 1
    Number : 1
    Date : 6
    Error : 6
    seconds : 1
    i : 1
    =undefined
    >process.memory();
    ={ "free": 806, "usage": 1444, "total": 2250, "history": 479,
      "stackEndAddress": 536910664, "flash_start": 134217728, "flash_binary_end": 228576, "flash_code_start": 134449152, "flash_length": 262144 }
    >
    

    The source code file is joined.

    >reset();
    =undefined
     _____                 _
    |   __|___ ___ ___ _ _|_|___ ___
    |   __|_ -| . |  _| | | |   | . |
    |_____|___|  _|_| |___|_|_|_|___|
              |_| http://espruino.com
     1v80.346 Copyright 2015 G.Williams
    >echo(0);
    Handler of GPGGA defined as function (d) {this['hhmmss.ss']=secn(d[1]);this['lati­tude']=lln(d[2],d[3],'S');this['longitud­e']=lln(d[4],d[5],'E');this['mslAlt']=Nu­mber(d[9])}
    Handler of GPRMC defined as function (d) {this['hhmmss.ss']=secn(d[1]);this['stat­us']=d[2];this['latitude']=lln(d[3],d[4]­,'S');this['longitude']=lln(d[5],d[6],'E­');this['sogKn']=Number(d[7]);this['ddmm­yy']=ddmmyy(d[9])}
    Handler of GPZDA defined as function (d) {this['hhmmss.ss']=secn(d[1])}
    Handler of GPGLL defined as function (d) {this['latitude']=lln(d[1],d[2],'S');thi­s['longitude']=lln(d[3],d[4],'E');this['­hhmmss.ss']=secn(d[5]);this['status']=d[­6]}
    Handler of GPVTG defined as function (d) {this['sogKn']=Number(d[5])}
    Handler of GPGRS defined as function (d) {this['hhmmss.ss']=secn(d[1])}
    Handler of GPGBS defined as function (d) {this['hhmmss.ss']=secn(d[1]);this['std_­lat']=Number(d[2]);this['std_alt']=Numbe­r(d[4])}
    Handler of GPGST defined as function (d) {this['hhmmss.ss']=secn(d[1]);this['std_­lat']=Number(d[6]);this['std_long']=Numb­er(d[7]);this['std_alt']=Number(d[8])}
    Handler of PUBX00 defined as function (d) {this['hhmmss.ss']=secn(d[2]);this['lati­tude']=lln(d[3],d[4],'S');this['longitud­e']=lln(d[5],d[6],'E')}
    Handler of PUBX04 defined as function (d) {this['hhmmss.ss']=secn(d[2]);this['ddmm­yy']=ddmmyy(d[3])}
    Now stopping the GPS from sending the following messages
    Time fix from serial at 1442570315.18200206756
    GPS position fix from serial at 1442570315.18380546569
    Received a TimeFix event with parameter GPRMC,095836.00,A,4540.02704,N,00624.519­71,E,0.625,,180915,,,A
    Internal clock was only 348.32958984375 ms from GPS epoch Fri Sep 18 2015 09:58:35 GMT+0000 so no changes were made.
    We have a GPS position fix!
    Stopping GPGSV nmea sentence send by ublox gps with $PUBX,40,GSV,0,0,0,1,0,0*58
    Stopping GPGSA nmea sentence send by ublox gps with $PUBX,40,GSA,0,0,0,1,0,0*4F
    Stopping GPDTM nmea sentence send by ublox gps with $PUBX,40,DTM,0,0,0,1,0,0*47
    Stopping PUBX03 nmea sentence send by ublox gps with $PUBX,40,03,0,0,0,1,0,0*19
    Stopping PUBX40 nmea sentence send by ublox gps with $PUBX,40,40,0,0,0,1,0,0*1E
    Stopping GPTXT nmea sentence send by ublox gps with $PUBX,40,TXT,0,0,0,1,0,0*42
    Now stopping the GPS from sending the following messages
    =undefined
    Stopping GPZDA nmea sentence send by ublox gps with $PUBX,40,ZDA,0,0,0,1,0,0*45
    Stopping GPGLL nmea sentence send by ublox gps with $PUBX,40,GLL,0,0,0,1,0,0*5D
    Stopping GPVTG nmea sentence send by ublox gps with $PUBX,40,VTG,0,0,0,1,0,0*5F
    Stopping GPGRS nmea sentence send by ublox gps with $PUBX,40,GRS,0,0,0,1,0,0*5C
    Stopping GPGST nmea sentence send by ublox gps with $PUBX,40,GST,0,0,0,1,0,0*5A
    Stopping PUBX04 nmea sentence send by ublox gps with $PUBX,40,04,0,0,0,1,0,0*1E
    Stopping PUBX00 nmea sentence send by ublox gps with $PUBX,40,00,0,0,0,1,0,0*1A
    >gps.chrono.info()
    674 leaps (mean time 0.01794492031 s). Measured duration/Total duration 5.47%
    =undefined
    > 
    

    1 Attachment

  • Ahh, ok - so the reason GPS and Serial4 are so big is because they're linking to each other... So I guess Serial4 has a callback that references GPS, and vice versa.

    What about trying:

    function show(d) {
      for (var i in d) print(i+" : "+E.getSizeOf(d[i]))
    }
    console.log("--------- gps");
    show(gps);
    console.log("--------- Serial4");
    show(Serial4);
    

    ... and maybe drill down with show(gps.whatever); to try and find out which part of them is taking all the memory?

  • Very interesting. When I worked with a ublox 6M moudule, I had irregularities too: sometimes some values in a sentence were missing and lead to errors in conversion to a number. I used the standard Espruino GPS moudule after it was minimally modified to allow to have custom handlers. I did not think of stripping down the output scope in ublox moudule.

    Glancing over the GPS_ext12.js code I wondered about the extra arguments in setTimeout() invocation in start_stop_nmea(), ~ line 110. Can you explain?

    Btw, I like the function/method-creation approach by using the sentence attribute name as the signature and then have a content type addressed detail handling. The not so liked part is the eval()... but the heck: if code can create programmatic code based on declarations, why not go for it! Did you consider to run the function generation in a preprocess step and output the source, and then use that source explicitely?

  • I wondered about the extra arguments in setTimeout()

    see this - you can now pass a function in, and have setTimeout pass arguments through.

  • @Gordon, thanks... I'm obviously damaged by working for too long for too much in lowest-common-(browser-)denominator settings... ;)

    With these extra parameters, a plain, naked function reference can be used. If this is needed in it, a myFunction.bind(thisContext) eliminates the need for an extra anonymous functions ...

  • Well, the eval part is doing programmaticaly what i found cumbersome. The real goal is to minimise any computation done in the serial.on loop and still provide any data of interest in a naturally javascript suitable for further computations and efficient data storage. It's still in progress.
    The ublox device can be programmed from its usb interface directly with u-center and saved to its integrated flash memory. This would allow for a no time and no memory used on the espruino.

    As a matter of fact, I prefer to pre-process on launch as much as possible and then delete any no more usefull functions or objects. This reduces the dependancy of this program to predefined gps board behaviour.
    I found elsewhere something like 90 different nmea sentences...........

    About incomplete sentences. from the device, it just drops any outdated sentence even if it is beeing send through the serial link, with no eol, just the $ before the next sentence. I ended with a systematic checksum verification, discarding any unvalid sentence before any further computation.

  • I was thinking about preprocessing even before the launch - I assume you refere with launch to connect and what it does: I separate step, the source generation is run, and it's output is used as part of the .js file. The muting of unwanted sentences - or config which sentences - the gps modules has to send, can still happen when connecting. Doning so does not need the pre-config the device seperately. On the other hand, if memory get's tight, this will be a nice option. I have experienced memory shortages quit quickly, and resorted to similar aproaches: have the config info not in well structured objects, but as single string(s) with comma (or space) separation of the individual values. Processing with a *.split(",") uses only temporary memory. My example was the description of a pac-man board/maze, drawing it on a 320x240 ILI#### controled display , and boundary checking for the 'moving parts', etc... In the end I had even to come up with an encodeing to keep the code/data still readable but using up only one byte.

    Finding out 'quickly' what to spend processing time on and what to drop is a nice approach. Do you have figures/stats how much - %-wise - is dropped?

    Even with the good data, I had to optimize more: a) only changed data I did render and send to the display, and b) building up of the display is parts by parts to stay 'within the loop' of 1 update/second. Using your approach of 'quieting' the module would have been a great help. Enjoyed very much 'listening' to your code and its style - like a good piece of music!

  • Yes, you are probably right and I have to understand something like 'this' in event context...

    Here is the result of your proposition. Note on the last commands that I failed to list the event handlers defined with gps.on and Serial4.on...
    Sorry for the curious display induced by sharp characters in event names.

    >    show(gps);
    serial : 1943
    GPGGA : 1943
    GPRMC : 1943
    GPGBS : 1943
    line : 1
    enabled : 1
    log : 1
    debug : 1
    chrono : 127
    lagTime : 1
    status : 1
    hhmmss.ss : 1
     [#onGPSFix](http://forum.espruino.com/se­arch/?q=%23onGPSFix) : 1943
     [#ongpsdata](http://forum.espruino.com/s­earch/?q=%23ongpsdata) : 1943
    latitude : 1
    longitude : 1
    sogKn : 1
    ddmmyy : 1
    mslAlt : 1
    std_lat : 1
    std_alt : 1
    epoch : 1
     [#onTimeFix](http://forum.espruino.com/s­earch/?q=%23onTimeFix) : 66
    =undefined
    

    And

    >    show(Serial4);
    _baudrate : 1
    _options : 5
     [#ondata](http://forum.espruino.com/sear­ch/?q=%23ondata) : 1951
    =undefined
    >show(Serial4.#ondata)
    Uncaught SyntaxError: Got '#' expected ID
     at line 1 col 14
    show(Serial4.#ondata)
                 ^
    

    Digging inside failed due to events handlers names...

    >show(Serial4.'#ondata')
    Uncaught SyntaxError: Got String:'#ondata'ID expected ID
     at line 1 col 14
    show(Serial4.'#ondata')
                 ^
    >show(Serial4['#ondata'])
    =undefined
    >show(Serial4[#ondata])
    Uncaught SyntaxError: Got '#' expected EOF
     at line 1 col 14
    show(Serial4[#ondata])
                 ^
    >show(gps[#onGPSFix])
    Uncaught SyntaxError: Got '#' expected EOF
     at line 1 col 10
    show(gps[#onGPSFix])
             ^
    >show(gps[onGPSFix])
    Uncaught ReferenceError: "onGPSFix" is not defined
     at line 1 col 10
    show(gps[onGPSFix])
             ^
    >show(gps['onGPSFix'])
    =undefined
    >show(gps['#onGPSFix'])
    =undefined
    > 
    
  • 'this' represents the default runtime context from within a function is invoked - event or otherwise. If the function is bound though to an object before invocation with .bind(contextObject), this in the function will refere to the bound contextObject and - according to @Gordon - it is even faster then an anonymous function. On the other hand, binding takes away the freedom to use the function on/in/for different contexts (objects). Im talking about simple invocation because .apply() and .call() can help to keep the flexibility and provide different ways to pass the arguments: as array or individually, respectively. All these language elements/constructs help with (meta) data driven code / logic / algorithms.

  • Yes, I have memory shortages in sight and actually, the main problem seems to be in the events handlers Serial4.on and gps.on. cross referencing each other....
    That said, it is fairly simple to execute the functions at launch time, wipe out any thing no more usefull, and save() a completely pre-processed gps object.
    The thing is that I want to run the GPS at 10Hz during some circumstances, say a car in motion, and back to 1Hz or 1/3 Hz in others conditions, say a car parked during the last few minutes, and finally physically shut-it off by controlling some power regulator from the STM32, changing that dynamically and resetting the gps parameters on the fly at reboot.

    Which is still more a hope than a fact.

    About figures, this is the 12th iteration of code.
    So now, there are some basic considerations:

    1. The predefined setup of the NEO-6M sends 10 nmea sentences per second. There is no way to shorten any of those, you just can mute whichever you want. This is chipset dependant.
    2. not using try { } catch(e) { } and using explicit tests everywhere takes 45 ms per nmea sentence without any control of the checksum. This resulted in a loop too slow to process all sentences. Then I discovered that the NEO-6M would drop transmission right in the middle of a sentence without any warning.
    3. using try { } catch { } and going in appropriate treatments of exceptions and adding the checksum control of all nmea sentences, reduced to timing to 25 ms per nmea sentence. 50% of this time was spent in the checksum computation alone.
    4. compiling basic conversion functions and furthermore the computation of checksum, it went done to 12 ms per nmea sentences.
    5. shutting off unused sentences directly from the NEO-6M reduced the number of sentences from 10 to 3 usefull and increased to time of treatment to 18 ms. However, the previous figure implied to 7 sentences were consumming some time for nothing too. Net result is very positive (3*18<<10*12)

    Finally, I used, and adapted, my Chrono prototypes to get the processor charge in % of the time: that is rather than looking at individual timing of a nmea sentence, look at the global timing of the treatment of all of them.
    Basically, now the processor charge is around 5.5% to process all 3 usefull sentences, while this was about 12% to process all sentences with some redundant fields.
    I still have to simplify the nmea sentences handlers so as to not take in account more than once the fields I need (hhmmss.ss for instances is read and converted 3 times now while it is always the same figure as long as you have it from the first sentence in a given sequence of sentences).

  • Hmm, that's hard to narrow down. Could you try trace(Serial4)? It's not as easy to read, but it does output everything.

    edit: actually forget that - it was the input buffer overflowing because of the time taken to execute the constructor.

  • I haven't yet used it on the pico. However, except for the serial pins definitions it should run all the way...
    Yes, I forgot, you have to send with throttle otherwise, it becomes totally unpredictable.

    Ok, now the trace(Serial4) really prints everything. Let's hope we can understand what's going on from that.
    It is too big to fit in a Reply so I joined it as a text file.

    edit: Reading further this trace, I was wondering:

    1. Is it normal that the values of the parameters of gps.connect are still keept?
    2. Again, is it normal that the comments at the top level are keept too?

    1 Attachment

  • Is that trace from when it has the memory leak? I don't see anything obvious in there (but it's hard to see!) - although E.getSizeOf is definitely getting pretty confused by the references back in the functions.

    Perhaps outputting the data from trace() (without the Serial4) before and after the memory leak might help, as we could then diff them.

    Also, do you get the memory leak with non-"compiled" code? It could be it's a memory leak in the interpreter caused by a bug in the compiler.

  • Is it normal that the values of the parameters of gps.connect are still keept?

    Yes, because of the scope chain from functions that you have defined in gps.connect.

    You could:

    • Define the functions outside, and just add them to the listeners by name
    • Set the parameters to undefined when you're done with them

    Again, is it normal that the comments at the top level are keept too?

    Yes, they're in history - the second Espruino runs low on memory it'll delete those.

  • Yes, you are right.
    After reading this tutorial, I still have to correctly understand the real closure/implicit or explicit definition(s) of this: This is a beginner's problem in Javascript any way.
    The tutorial seems to be slightly out of date, on the other hand I nearly understood the difference between binding and late binding.
    Still have to experiment that anyway.

  • Ok, that's clear now: I have to review the connect function and make it much more memory and time savy.
    The trace has no identified memory leak so far.
    It has been running for a few hours and the free memory is just changing by a few 10s of JsVar back and forth: I guess this is induced by the length of the nmea sentences.

    So far, the "compiled" functions have not been a problem since you solve the webide getting confused about the order of returned compiled function last week.

    edit: Here is a memory status taken from just after the trace(Serial4) to now.
    Apparently the size of gps and Serial4 are slowly changing, and getting smaller. I think this could be the result of some garbage collection...
    edit2: Actually, it is because the GPS lost its position fix and thus some properties of gps went to NaN and so on...
    edit3: It is worst than that: Serial4 is no more defined, I create a new psot about that

    >process.memory();
    ={ "free": 791, "usage": 1459, "total": 2250, "history": 569,
      "stackEndAddress": 536910664, "flash_start": 134217728, "flash_binary_end": 228576, "flash_code_start": 134449152, "flash_length": 262144 }
    >for (var i in global) print(i+" : "+E.getSizeOf(global[i]))
    Chrono : 108
    ddmmyy : 37
    E : 1
    secn : 41
    lln : 40
    cks7 : 27
    nmea_checksum : 54
    start_stop_nmea : 84
    fieldsOfInterest : 31
    codeFieldOfInterest : 44
    posFieldsOfInterest : 26
    getFieldsPos : 8
    parseHandlers : 124
    estimate_dist : 25
    tfTimeout : 1
    tf : 66
    connect : 183
    gps : 1997
    Serial : 6
    Serial4 : 1998
    console : 1
    Number : 1
    Date : 6
    Error : 6
    seconds : 1
    i : 1
    process : 1
    myInterval : 1
    ReferenceError : 6
    show : 10
    SyntaxError : 6
    =undefined
    GPS position fix from serial at 1442595640.43765068054
    We have a GPS position fix!
    GPS position fix from serial at 1442595666.95421600341
    We have a GPS position fix!
    GPS position fix from serial at 1442595752.85040473937
    We have a GPS position fix!
    >process.memory();
    ={ "free": 811, "usage": 1439, "total": 2250, "history": 283,
      "stackEndAddress": 536910664, "flash_start": 134217728, "flash_binary_end": 228576, "flash_code_start": 134449152, "flash_length": 262144 }
    >
    Disconnected
    >
    Connected
    >
    =undefined
    >
    =undefined
    >for (var i in global) print(i+" : "+E.getSizeOf(global[i]))
    Chrono : 108
    ddmmyy : 37
    E : 1
    secn : 41
    lln : 40
    cks7 : 27
    nmea_checksum : 54
    start_stop_nmea : 84
    fieldsOfInterest : 31
    codeFieldOfInterest : 44
    posFieldsOfInterest : 26
    getFieldsPos : 8
    parseHandlers : 124
    estimate_dist : 25
    tfTimeout : 1
    tf : 66
    connect : 183
    gps : 1719
    Serial : 6
    Serial4 : 1720
    console : 1
    Number : 1
    Date : 6
    Error : 6
    seconds : 1
    i : 1
    process : 1
    myInterval : 1
    ReferenceError : 6
    show : 10
    SyntaxError : 6
    JSON : 1
    =undefined
    >
    Disconnected
    > 
    
  • So, as said in edit3 above, the Serial4 object is no more at work without any warning.
    The dump() seems Ok.
    dump(), trace(Serial4) and trace() are joined.
    The previous post trace(Serial4) was before the problem...
    Thanks for your time on that, I still have to improve connect function and eliminate cross referencing of the objects anyway.

    edit: Unplugging the GPS and repluging it restarted the transfers of data on the Serial4 link and logs show that the Espruino was not out of order. I will check the configuration of the GPS board with u-center tomorrow. There are so many parameters that I want to make sure about that.
    So for this post, it is not a memory leak hidden somewhere but a gps board problem/configuration.


    3 Attachments

  • 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...).

  • 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!

  • 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.

  • ...with 0 length, you would actually toss the value or the whole measurement... or you should not even get there, because the chechsume failed it? ...or did the gps assume the sentence to be correct? - I assume the information may get lost in transmission and not in generation/calculation in GPS... because why would the other values show?

    N-copters use these GPS for their flight navigation and consume 10 sentences/sec. May be to offload Espruino from parsing and getting the proper values - and then tranferred as binaries into typed arrays, one needs to think of having a slave processor, such as a tiny85 or so... will just do the job... Espruino would still monitor what's going on and also control the power of that device. @DrAzzy went down a similar route with some of his RF and other projects... Eventhough Espruino gives compiled and is fast (32 vs 8 bit etc), but certain apps are just not its ballpark. The challenge though to find that limit, push the envelop, and (may be) still make it, is what is the driving force and excitement!

  • I have been watching this discussion but I am not sure what you are trying to calculate. Is the checksum for the nema string? Is it parsing the NMEA sentence that you are trying to improve?

  • Using try catch is indeed to stop any further computation when checksum fails...
    Nmea sentences should never be assumed to be correct.
    At 10 hz, depending upon ublox parameters, you could have a 100 nmea sentences to analyse per second. And a lot of duplicated data...
    There is, of course, the thrill of the challenge. I could do that natively in bare metal C😉
    Now, I think, getting down to multi processors's system, which is the case here, shows how tricky it can be.
    Now, my last observations of failures cases has shown that the neo-6m is resetting on its own.
    The usual suspects are: power supply (very plausible on the Espruino board), heat and hardware.

    Approaches are:
    a- use another power regulator to feed the gps
    b- attempt to evacuate this by software as it should not be critical

  • Hi, all calculations are working correctly. This discussion helped greatly to make it fast and reliable.
    The trouble now comes with real world randomness and handling it in real time at no cost...
    So checksums are correct and yet, after hours, it fails: See my post above.
    Now, about the challenge, it is amazing to see how a language, designed to handle the unordered tcp/ip answers in a web browser, can also handle real world unexpected failures in almost real time context on such a small device.

    The final goal is to have a battery operated device with gps, 'smart' logging of data on sd card and occasionnal wifi transferts through the web (mqtt or so). In fact I still have not abandonned the idea to have a 3 months autonomy on the base of an inactive device most of the time. Reactivating it would be done by some shacking sensor.

    I know I could do that in bare metal C. However, the hardware diagnostic would be much more painfull.
    Espruino's interpreter is well worth the effort to make it better and that kind of project: time, memory and energy constrained are definitly something for small platforms like the Espruino boards.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

Randomly Out of memory errors precedeed by JsVarOverflow

Posted by Avatar for asez73 @asez73

Actions