[Ovmsdev] Flashing Lights

Thu May 10 23:31:42 HKT 2012

The changes have been made. It took longer than I expected because I found a couple of edge cases that may cause GPRS to be locked up in areas of marginal cellular coverage (which I think explains the rare cases that have been reported to me), and I also tidied up the reception of SMS messages during GPRS establishment failures (in particular if the APN is incorrect).

For the LEDs, what I've ended up with is:

When first powered on, the red led stays on, and the green led blinks the version of firmware in the module (e.g.; 1, 2, 5). After that, it enters normal mode.

In normal mode, the green led is used to indicate the state, and the red led is used to indicate the last error.

If the modem needs to be reset, both red and green leds are turned on for the couple of seconds it takes to reset the modem.

The following states are defined:
// LED MODES
#define NET_LED_WAKEUP       10    // Attempting to wake up the modem
#define NET_LED_INITSIM1     9     // Checking SIM card insertion status
#define NET_LED_INITSIM2     8     // Checking SIM card PIN status
#define NET_LED_INITSIM3     7     // Initialising modem
#define NET_LED_COPS         6     // COPS initialisation
#define NET_LED_NETINIT      5     // GPRS NET initialisation
#define NET_LED_NETAPNOK     4     // GPRS APN is OK, final init
#define NET_LED_NETCALL      3     // GPRS Network call
#define NET_LED_READY        2     // READY state
#define NET_LED_READYGPRS    1     // READY GPRS state

The normal behavior is it will start at 10 green blinks and count down to 2 (GSM only) or 1 (GPRS). If GPRS lock is lost, but GSM is still up, the green will blink 1.

The followed error codes are defined:
// LED ERRORS
#define NET_LED_ERRLOSTSIG   1     // Lost signal
#define NET_LED_ERRMODEM     2     // Problem communicating with modem
#define NET_LED_ERRSIM1      3     // SIM is not inserted/detected
#define NET_LED_ERRSIM2      4     // PIN lock on the SIM
#define NET_LED_ERRCOPS      6     // COPS GSM lock could not be obtained
#define NET_LED_ERRGPRSRETRY 7     // Error (maybe temp) during GPRS init
#define NET_LED_ERRGPRSFAIL  8     // GPRS NET INIT failed

The error code is cleared (red led turned off) once everything is ok.

Another few hours testing, then I'll commit this code.

Regards, Mark.

On 8 May, 2012, at 7:37 PM, Mark Webb-Johnson wrote:

> Not too bad.
> 
> I've re-worked the low priority interrupt handler stuff used to drive the comms port to also drive these LEDs off timer#1. That makes the entire LED subsystem self-sustaining and I don't need to change other parts of the code to maintain the animation.
> 
> Tricky stuff to get right, and I haven't had so much fun with blinking lights since basic electronics classes all those years ago using 555 ICs.
> 
> 1 time period on, then 3 off, gives a nice clear countable display.
> 
> One experiment that didn't work was to leave the timings for the two LEDs independent. It is too hard to count flashes of green when a red led next to it is flashing a different code at a different start time. My current approach is to synchronize the two to start the codes at the same time, for a set fixed time period. If one is flashing less digits than the other, then it just waits, before they both start together again.
> 
> Next step is the code for solid on (easy), then startup animation, then I update the modem driver logic. In the modem code, it is much easier now, as we don't need to do any flashing animation at all. Just a function call to tell the led code what digit to show, and the led will start flashing that at the next cycle.
> 
> With luck, so long as I haven't messed anything up, I should be done with the leds this week.
> 
> I've also done the code changes for volt/ampera support stub, and some minor bug-fixes.
> 
> Then, timed-charges command support, and I'm moving on to the charge and drive logs.
> 
> Regards, Mark
> 
> On 8 May, 2012, at 11:23 AM, William Petefish wrote:
> 
>> Mark,
>> 
>> How goes the coding?
>> 
>> William
>> 
>> On Sun, May 6, 2012 at 2:41 PM, Udo Werges <Udo.Werges at t-online.de> wrote:
>> sounds good, the changes will give a lot more information via the flashing LEDs.
>>  
>> pro voting
>> 
>> Udo
>> Germany
>> 
>> mobil +49171 374 7978
>> e-mail udo.werges at t-online.de
>> eFax +49322 23 73 9801
>> 
>> 
>> -----Original Message-----
>> > Date: Sat, 05 May 2012 10:46:57 +0200
>> > Subject: Re: [Ovmsdev] Flashing Lights
>> > From: William Petefish <william.petefish at gmail.com>
>> > To: OVMS Developers <ovmsdev at lists.teslaclub.hk>
>> 
>> >
>> #6 has my vote. It may be more complex in code, but easier to impliment on existing hardware.
>> I guess it could act similar to the old OBD that cars had prior to OBD2.
>> William
>> On May 5, 2012 2:36 AM, "Mark Webb-Johnson" <mark at webb-johnson.net> wrote:
>> 
>> I've been getting frustrated lately trying to help users diagnose problems early-on in the GSM connection sequence. We've had problems with SIMs cards getting recognised (broken sim cards), with sim locks (PIN lock on), with general modem comms issues, and with lack of GSM signal - and all these show up as the same red flash, red solid, red flash, red-green-alternate indicators. Without getting out a USB-serial cable and laptop, it is real hard to diagnose.
>> 
>> Talking this through with Bennett, and others, I think we can do better, and I suggest the following changes:
>> 
>> Take the LED control out of the individual code files and have them controlled by a central module with its own timer. This module would be told at a high level what to do with the LED (eg; make the green led flash 7 times) and would make it so.
>> 
>> Both LEDs off would indicate NO POWER.
>> 
>> On startup, animate both LEDs for a short time to demonstrate that they both work.
>> 
>> Change init code to (a) use AT to verify modem is connected, (b) check for SIM connected and readable, (c) check for SIM PIN lock, (d) initialize modem to our required settings, and (e) AT+COPS for cellular signal search. By splitting this up, to separate check states, we can individually alert on a failure at a particular state.
>> 
>> In general, use the green LED to show status, and the red LED to show the last error (cleared whenever a state is successful).
>> 
>> On startup, you would see the green led count up through each stage, and if it got stuck at a particular stage the blinks would tell you where it is. If there was an error at any stage, the red LED would indicate the error code.
>> 
>> For blinking, I suggest just off for a second, then rapidly blink the code, then off for a second, then rapidly blink the code, etc.
>> 
>> Once we reach a final GOOD state (either GSM with GPRS disabled, or GPRS connected to server), we would just turn both LEDs to a steady blinking pattern (perhaps on for a second, off for a second).
>> 
>> As well as the obvious clarity to diagnostics that this brings, it would also be for general use to see at a glance if the module is working correctly and is connected to the server ok.
>> 
>> What do people think?
>> 
>> Regards, Mark.
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20120510/318bbf28/attachment.html>