Topic | Logging problems – delayed start and lost records

Home Forums Mooshimeter Support Logging problems – delayed start and lost records

This topic contains 2 replies, has 2 voices, and was last updated by  PeterJ 9 months, 3 weeks ago.

  • Author
    Posts
  • #21203 Reply

    PeterJ
    Participant

    I’m trying to do some logging (at 1s rate) with my Mooshimeter running firmware 1522204715 and have run into a variety of problems:

    • Logging doesn’t seem to start until several minutes after turning logging on in the App. There’s no obvious feedback in the App and it seems that the only way to check is to look at the way the LED is flashing.
    • The logged timestamps appear to be 12-15 seconds slow and drift by about 4 seconds in 20 minutes.
    • There are irregular multi-minute gaps in the logged timestamps.
    • I’ve found cases where the log header is repeated inside a logfile. Carefully examining one example of this shows that whilst the timestamps on either side of the header are 220 msec apart, the logged meter readings suggest a gap of about 110 seconds. Interestingly, prior to the duplicated header, records were logged on average every 1.34s but after the header, they were logged at exactly 1s for about 6 minutes after which there is a 106s gap.

    Has anyone seen similar issues?

  • #21204 Reply

    ville
    Participant

    Only repeated headers with their other side effects seem familiar to me. I have not tried to clock those, but there are several reasons for crashes, so there would not be one right answer anyway. Those could appear when mooshimeter resumes after crashing and tries to continue logging, to minimize problems. Some early versions just crashed and if they managed to reboot after that, they would just sit there doing nothing. Much better this way, as many logging needs are not really time critical and gaps in time are fine, or at least way better option than total crash in 2 hours, to be found after a week.

    Like always, first thing to try are fresh batteries. I would recommend lithiums, as alkalines will leak and ruin your toys when you least expect it.

    I have been thinking about what went wrong in mooshimeters battery-level indicator and my guess is that as it only uses some direct battery voltage -> percent value conversion, lowest operational voltage must have be tested with desk power supply. In doing so, there would have been enough current for mooshimeter to operate, but with almost empty batteries at the same voltage level, it would just brownout when writing to memorycard or doing something else power intensive. If you are using alkalines, somewhere around 50% should be a warning sign and you should already replace batteries. Lithium-AA:s will work longer in any case, but i yet have no idea if it would be possible to see when they go empty with that same indicator or not.

  • #21222 Reply

    PeterJ
    Participant

    The batteries were reporting 85% but replacing them fixed the missing samples and repeated log file headers.

    Whilst there’s no schematic publicly available, I’ve had a close look at my Mooshimeter and I can’t find any bulk bypass capacitors. My guess is that the design assumes that batteries will always have a very low ESR, which isn’t true. The actual SD card writes are relatively power intensive and could easily cause brownouts if the batteries are feeling a bit poorly. I might consider adding a capacitor across the battery terminals and see if that helps.

    I’m still seeing about some time drift – about 2ms/s with 1s logging. That’s well outside what I’d expect even with really cheap crystals and I wonder if there’s a bug in the timekeeping code.

    And I’m still seeing a delay of several minutes between enabling logging and the first entry in the logfile.

    That said, I’m now confident that I have a complete enough set of logs and can correlate them with logs from the data generation I was doing.

Reply To: Logging problems – delayed start and lost records
Your information: