On the 12v filtering, all I can think is to average it,
perhaps over a minute, or for a set number of readings. Or
perhaps require 2 readings higher than the current reading
before increasing it (or generally 2 readings before it is
changed). This could be done in the function to handle reading
the value.
For example, say we kept a total, a count and the last
value. Then, input_voltage() would read the value, add it to
the total and increment the count. If count > 5 (say), set
last value = total / count, then reset total,count=0. It would
return last value as the result.
Do you have any historical list of the values reported
from the function? Does it go 11.5, 11.6, 11.5, 11.5, 13.2,
11.5, 11.6, etc? Of stay falsely high for multiple readings?
Regards, Mark.
On 28 Apr, 2013, at 11:06 PM, Michael Balzer wrote:
I just checked
in my fix for the USSD reply handler. My tests with
streaming enabled did not produce any more crashes, so I
think that was the problem.
My tests show there still is an issue with streaming
enabled: if I let a client open (perl / App), very few
GPS points now get through, both to the App and to the
GPS log. Could be due to the modem not getting the per
second GPS requests or due to some msg queue issue. I'll
debug that ASAP.
I also reactivated the 12V input filtering as the false
peaks still occur and I've got no more ideas for the A/D
conversion. Any hint on this is appreciated.
Regards,
Michael