Detecting power loss and saving data

[FFMan]

I want to add a cumulative function to my zx40n based trip computer that I made for the motorbike some years back.

The problem is I tend to forget to shut the engine off via the kill switch, I tend to turn off the ignition which kills power to the zx and I lose the trip data.

Ideally I'd like to install some battery or supercap that could power the zx for a couple of seconds and trigger a variable save routine to persistent memory.

does anyone have any advice, experience or recommendations for this ?

[GTBecker]

Some time ago, odometers and a Hobbs-like hour meter were discussed on the BasicX Yahoo group:

https://groups.yahoo.com/neo/groups/bas ... ages/21136
https://groups.yahoo.com/neo/groups/bas ... ages/21605

I posted some BX-24 code that emulated a Hobbs meter, but it used a trick that I suspect only works on BX-24s, not ZXs, which offset the RTC timer by two days to avoid an
automatic rollover at midnight. It's unlikely you'd be riding for more than 24-hours, though, so you might not need that 'feature'.

You might build a brown-out detector that raises an interrupt that would allow you to save some variables in Persistent memory before the processor goes dark. Unfortunately, the brown-out detector that's built in the -644P on the ZX-40p doesn't appear to be available as an interrupt; it just cleanly kills the machine, I think. You might be able to use the processor's comparator.

You can also write to persistent memory's Flash a million times or so before some fixed location burns up, so if you routinely write your vars every 10 seconds while running the data would probably be safe for ~2800 hours of cumulative operation - and you can multiply that many times by using a circular buffer.

Code: Select all

' Hobbs-like Running Time Meter on BX-24
'    0.001 hour resolution (or 0.01)
'    Resettable ~1165 hour maximum count (11650)
'    12000 hour minimum endurance (120000)
 
'    2006-03-28  Tom Becker  GTBecker@RighTime.com
 
 const Pin_Input_Reset_Count_Not as byte = 10
 const ilenCircularBuffer as integer = 120
 dim laCircularBuffer(1 to ilenCircularBuffer) as New PersistentLong
 dim iXMax as integer
 const lThousandthHourInTicks as Long = 1843    '0.001hr = 3.6seconds * 512ticks = ~1843 (0.01% error)
 const lTwoDaysInTicks as long = 88473600        'RTC T0, well beyond 24 hours; won't reset at midnight
 
sub Main()
    call PutPin (Pin_Input_Reset_Count_Not, bxInputPullup)    'reset switch pin
    if FirstTime then
        call Reset
    end if
    iXMax = iGetLargestRunningTimeIndex    'find index of largest in ring, resume
    call SetRTCTicks(laCircularBuffer(iXMax) * lThousandthHourInTicks)    'start timer from there
    call ShowRunningTime    'show start time
 
    do    'endless
        if &#40;lGetRTCTicks \ lThousandthHourInTicks&#41; <> &#40;laCircularBuffer&#40;iXMax&#41;&#41; then
            iXMax = iXMax mod ilenCircularBuffer + 1    'next in ring
            laCircularBuffer&#40;iXMax&#41; = lGetRTCTicks \ lThousandthHourInTicks    'store each 0.001 hour
            call ShowRunningTime
        end if
        if GetPin&#40;Pin_Input_Reset_Count_Not&#41; <> 1 then
            call Reset
            call ShowRunningTime
        end if
    loop
end sub
 
function lGetRTCTicks&#40;&#41; as long
    lGetRTCTicks = register.RTCTick - lTwoDaysInTicks    'RTC count is offset to avoid midnight
end function
 
sub SetRTCTicks&#40;byval lTicks as long&#41;
    register.RTCTick = lTicks + lTwoDaysInTicks
end sub
 
sub ShowRunningTime&#40;&#41;
    debug.print strRunningTimeInHours&#40;laCircularBuffer&#40;iXMax&#41;&#41;
end sub
 
function strRunningTimeInHours&#40;byval lT as long&#41; as string    '1165.210hr max; &#40;2^31-1/512/3600&#41;-48hrs
    dim strH as string*5, strF as string*4
    strF = cStr&#40;lT mod 1000 + 1000&#41;    'hour fraction
    lT = lT \ 1000    'discard fraction
    strH = cStr&#40;lT + 10000&#41;    'hours
    strRunningTimeInHours = mid&#40;strH, 2, 4&#41; &"."& mid&#40;strF, 2, 3&#41;
end function
 
sub Reset&#40;&#41;
        call ResetRunningTime    'zero ring
        call SetRTCTicks&#40;0&#41;    'zero RTC
end sub
 
sub ResetRunningTime&#40;&#41;
    dim iX as integer
    debug.print " Reset"
    for iX = 1 to ilenCircularBuffer    'this takes about four seconds
        laCircularBuffer&#40;iX&#41; = 0
    next
end sub
 
function iGetLargestRunningTimeIndex &#40;&#41; as integer
    dim iX as integer
    debug.print " Resume"
    iGetLargestRunningTimeIndex = 1
    for iX = 1 to ilenCircularBuffer    'get index of largest value
        if laCircularBuffer&#40;iGetLargestRunningTimeIndex&#41; < laCircularBuffer&#40;iX&#41; then
            iGetLargestRunningTimeIndex = iX
        end if
    next
end function

Code: Select all

[Don_Kirby]

The wear-leveling method does work well to extend the lifespan of the memory locations, but when used as the sole method of commulative data recording, can suffer from a gradual loss of data points. For example, if you are writing the time to memory once per minute and the processor shuts down at 59 seconds, you've effectively lost that minute. The same issue would arise when recording odometer mileage. The severity of the loss in most cases is dictated by the granularity of the measurement being written to memory, so the total error may or may not be an issue in any given application.

A better method (that can be used together with wear-leveling) for performing a graceful shutdown in a vehicle environment is to provide constant power to the processor, connect the switched ignition circuit to an input, and monitor the switch to see if the processor should be on or off. This allows your code to completely control how the processor handles shutdown events. If there are enough available inputs, you can differentiate between various shutdown conditions (e.g. kill switch vs. ignition switch). There's obviously a parasitic power draw penalty with this method that should be considered.

[FFMan]

thanks for the replies - some useful points.

On a motorbike there is no intermediate key position, but there is a kill switch. However just having completed a 1000 mile tour, I can honestly say most of the time I forgot to kill the engine on the kill switch, mostly due to fatigue a sore rear end.

Given 'trip' (accumulate data) mode will only be activated for long trips, and I would have thought over a long weekend of motoring there was only 15 hours of driving spread across say 10 stop/starts, then I can update the persistent memory every 10 seconds and not worry too much about loss of granularity. wear levelling will I think give me 80 slots to store trip data, and given expected journey rates etc this will see the life of the bike (or rider) out.

s/w solution easier in this case to implement.

[jay]

I used i2c flash to store over power cycles.. but that would require changes to your hardware (and a little to the SW) ..

..jay