Better debugging facilities

[collin80]

Currently it can be tough to figure out why something is not working. For instance, why is the motor controller stuck in neutral? What is causing it not to be in drive or reverse? The end user has no idea. Presumably something in code is doing it on purpose but the end user has no way of knowing what they can do to correct the situation. As such, it would be good to augment the code with facilities to provide better debugging information. This could be done via OBDII style fault codes. For instance, if there is a throttle problem in an ICE car you might get P0220 which means that there is a problem with the throttle position sensor. In fact, we should output that exact code when there is a problem with the throttle position sensing.

Doing this probably requires that we have a buffer for errors that can be read by a connected OBDII device (or listed on the web page or dumped out on the console).

This could end up being a huge amount of work to do it right. But, without extensive support for diagnostics we'll never be where we should be and users will be stuck guessing why things don't work.

[dboekel]

Would it be easier to implement this in the onboard webserver or via bluetooth? Also easier to readout for most users.

2014-09-03 15:38 GMT+02:00 Collin Kidder notifications@github.com:

Currently it can be tough to figure out why something is not working. For instance, why is the motor controller stuck in neutral? What is causing it not to be in drive or reverse? The end user has no idea. Presumably something in code is doing it on purpose but the end user has no way of knowing what they can do to correct the situation. As such, it would be good to augment the code with facilities to provide better debugging information. This could be done via OBDII style fault codes. For instance, if there is a throttle problem in an ICE car you might get P0220 which means that there is a problem with the throttle position sensor. In fact, we should output that exact code when there is a problem with the throttle position sensing.

Doing this probably requires that we have a buffer for errors that can be read by a connected OBDII device (or listed on the web page or dumped out on the console).

This could end up being a huge amount of work to do it right. But, without extensive support for diagnostics we'll never be where we should be and users will be stuck guessing why things don't work.

— Reply to this email directly or view it on GitHub https://github.com/collin80/GEVCU/issues/78.

www.boekel.nu

[collin80]

Probably. Which is why I did list wifi as one of the options. I absolutely do think that the fault read out should be on the website. That'd be so helpful to people it's not even funny. Imagine if your ICE car had a built-in website that lists all the problems with it. Well, that sort of already exists. If you subscribe to a service like OnStar it really will give you the faults in an email or online.

I don't know that we'll store the fault text in the firmware. It is probably sufficient to know that P0220 means throttle position sensor error without storing those words. The web page could have the definitions and use them. Maybe have a JSON file with the correspondence between code and the description. That'd even make it easy to allow for language translation if people want to know the faults in Swedish or German or some other language. A simple switch of the JSON file is all it takes.

On Wed, Sep 3, 2014 at 9:46 AM, dboekel notifications@github.com wrote:

Would it be easier to implement this in the onboard webserver or via bluetooth? Also easier to readout for most users.

2014-09-03 15:38 GMT+02:00 Collin Kidder notifications@github.com:

Currently it can be tough to figure out why something is not working. For instance, why is the motor controller stuck in neutral? What is causing it not to be in drive or reverse? The end user has no idea. Presumably something in code is doing it on purpose but the end user has no way of knowing what they can do to correct the situation. As such, it would be good to augment the code with facilities to provide better debugging information. This could be done via OBDII style fault codes. For instance, if there is a throttle problem in an ICE car you might get P0220 which means that there is a problem with the throttle position sensor. In fact, we should output that exact code when there is a problem with the throttle position sensing.

Doing this probably requires that we have a buffer for errors that can be read by a connected OBDII device (or listed on the web page or dumped out on the console).

This could end up being a huge amount of work to do it right. But, without extensive support for diagnostics we'll never be where we should be and users will be stuck guessing why things don't work.

— Reply to this email directly or view it on GitHub https://github.com/collin80/GEVCU/issues/78.

www.boekel.nu

— Reply to this email directly or view it on GitHub https://github.com/collin80/GEVCU/issues/78#issuecomment-54299146.

[jrickard]

I'm onboard. But it is actually very ambitious. I'm not clear on a roadmap from here to there, and it looks like a shitpot of work. Basically I guess pick out the standard error PIDS you would want to inform, and work backwards to find where in the code we would test for it. Then some EEPROM space to hold a static set of PID status's.

At that point, OBDII could retrieve them on receipt of a request.

The wireless or bluetooth is confusing. I would just use them as "alternate OBDII channels".

So the OBDII minder could operate over

CANBUS0 CANBUS1 ELM

The ELM module could then have option for Wireless via WiReach or Bluetooth via an add-on bluetooth card on the new GPIO connector Ed almost provided.

Jack Rickard

Wireless via the WiReach using ELM module. Bluetooth via some yet to be done bluetooth module.

I guess ELM could use either wireless or bluetooth.

On Wed, Sep 3, 2014 at 9:18 AM, Collin Kidder notifications@github.com wrote:

Probably. Which is why I did list wifi as one of the options. I absolutely do think that the fault read out should be on the website. That'd be so helpful to people it's not even funny. Imagine if your ICE car had a built-in website that lists all the problems with it. Well, that sort of already exists. If you subscribe to a service like OnStar it really will give you the faults in an email or online.

I don't know that we'll store the fault text in the firmware. It is probably sufficient to know that P0220 means throttle position sensor error without storing those words. The web page could have the definitions and use them. Maybe have a JSON file with the correspondence between code and the description. That'd even make it easy to allow for language translation if people want to know the faults in Swedish or German or some other language. A simple switch of the JSON file is all it takes.

On Wed, Sep 3, 2014 at 9:46 AM, dboekel notifications@github.com wrote:

Would it be easier to implement this in the onboard webserver or via bluetooth? Also easier to readout for most users.

2014-09-03 15:38 GMT+02:00 Collin Kidder notifications@github.com:

Currently it can be tough to figure out why something is not working. For instance, why is the motor controller stuck in neutral? What is causing it not to be in drive or reverse? The end user has no idea. Presumably something in code is doing it on purpose but the end user has no way of knowing what they can do to correct the situation. As such, it would be good to augment the code with facilities to provide better debugging information. This could be done via OBDII style fault codes. For instance, if there is a throttle problem in an ICE car you might get P0220 which means that there is a problem with the throttle position sensor. In fact, we should output that exact code when there is a problem with the throttle position sensing.

Doing this probably requires that we have a buffer for errors that can be read by a connected OBDII device (or listed on the web page or dumped out on the console).

This could end up being a huge amount of work to do it right. But, without extensive support for diagnostics we'll never be where we should be and users will be stuck guessing why things don't work.

— Reply to this email directly or view it on GitHub https://github.com/collin80/GEVCU/issues/78.

www.boekel.nu

— Reply to this email directly or view it on GitHub https://github.com/collin80/GEVCU/issues/78#issuecomment-54299146.

— Reply to this email directly or view it on GitHub https://github.com/collin80/GEVCU/issues/78#issuecomment-54303862.

http://www.EVTV.me http://EVTV.me

Electric Vehicle Television - KickinGas - One Car at a Time.

[collin80]

I originally wanted to use the existing PID specification but I looked at all of them and 98% of them are totally irrelevant. There are hundreds of codes for O2 sensors and other ICE related and emissions sensors. All of that is totally worthless to us. As such maybe it'd be better to do what OEMs do anyway and make up codes. The made up codes could still more or less conform to the OBDII diagnostics standard such that any OBDII scanner could retrieve the numeric codes. So, we'll have to make up a lot of codes.

I just pushed a git commit with a bunch of codes to start with. At this point I'm finishing up the fault handler code I had started a long time ago. It will be very fast to quickly finish it since it is so simple. At that point there will be a base to work with.

But, this is a huge task and a detailed specification for what it actually is and what it does will need to be constructed. The biggest part of the task isn't even really the fault handling system. That's relatively easy. The hard part is that calling into the fault handler touches every other part of the code. A lot of work has to be done in (motor controller / BMS / charger / throttle / etc) modules to make sure that everything that could be faulty is detected and reported. That's the difficult, boring, and time consuming part. Unfortunately open source projects tend to lack proper error checking because it's tedious and not exciting like building support for a new motor controller.

As far as getting to the faults. The normal route should be via OBDII pid be that over canbus or bluetooth or wifi. But, I think it'd be neat if the website hosted on the GEVCU could also list the current faults on a separate page. That'd be pretty handy.

On Thu, Sep 4, 2014 at 10:43 AM, Jack Rickard notifications@github.com wrote:

I'm onboard. But it is actually very ambitious. I'm not clear on a roadmap from here to there, and it looks like a shitpot of work. Basically I guess pick out the standard error PIDS you would want to inform, and work backwards to find where in the code we would test for it. Then some EEPROM space to hold a static set of PID status's.

At that point, OBDII could retrieve them on receipt of a request.

The wireless or bluetooth is confusing. I would just use them as "alternate OBDII channels".

So the OBDII minder could operate over

CANBUS0 CANBUS1 ELM

The ELM module could then have option for Wireless via WiReach or Bluetooth via an add-on bluetooth card on the new GPIO connector Ed almost provided.

Jack Rickard

Wireless via the WiReach using ELM module. Bluetooth via some yet to be done bluetooth module.

I guess ELM could use either wireless or bluetooth.

On Wed, Sep 3, 2014 at 9:18 AM, Collin Kidder notifications@github.com wrote:

Probably. Which is why I did list wifi as one of the options. I absolutely do think that the fault read out should be on the website. That'd be so helpful to people it's not even funny. Imagine if your ICE car had a built-in website that lists all the problems with it. Well, that sort of already exists. If you subscribe to a service like OnStar it really will give you the faults in an email or online.

I don't know that we'll store the fault text in the firmware. It is probably sufficient to know that P0220 means throttle position sensor error without storing those words. The web page could have the definitions and use them. Maybe have a JSON file with the correspondence between code and the description. That'd even make it easy to allow for language translation if people want to know the faults in Swedish or German or some other language. A simple switch of the JSON file is all it takes.

On Wed, Sep 3, 2014 at 9:46 AM, dboekel notifications@github.com wrote:

Would it be easier to implement this in the onboard webserver or via bluetooth? Also easier to readout for most users.

2014-09-03 15:38 GMT+02:00 Collin Kidder notifications@github.com:

Currently it can be tough to figure out why something is not working. For instance, why is the motor controller stuck in neutral? What is causing it not to be in drive or reverse? The end user has no idea. Presumably something in code is doing it on purpose but the end user has no way of knowing what they can do to correct the situation. As such, it would be good to augment the code with facilities to provide better debugging information. This could be done via OBDII style fault codes. For instance, if there is a throttle problem in an ICE car you might get P0220 which means that there is a problem with the throttle position sensor. In fact, we should output that exact code when there is a problem with the throttle position sensing.

Doing this probably requires that we have a buffer for errors that can be read by a connected OBDII device (or listed on the web page or dumped out on the console).

This could end up being a huge amount of work to do it right. But, without extensive support for diagnostics we'll never be where we should be and users will be stuck guessing why things don't work.

— Reply to this email directly or view it on GitHub https://github.com/collin80/GEVCU/issues/78.

www.boekel.nu

— Reply to this email directly or view it on GitHub https://github.com/collin80/GEVCU/issues/78#issuecomment-54299146.

— Reply to this email directly or view it on GitHub https://github.com/collin80/GEVCU/issues/78#issuecomment-54303862.

http://www.EVTV.me http://EVTV.me

Electric Vehicle Television - KickinGas - One Car at a Time.

— Reply to this email directly or view it on GitHub https://github.com/collin80/GEVCU/issues/78#issuecomment-54487231.

[jrickard]

I guess I am back to my conversation with Michael over the bitfield annunciators Collin. I just think we should guard that Website with our lives that anything on it be used pretty much to configure the device. We should strive for simplicity here, and keep it clean and simple. We have a status page now with inputs and outputs on the annunciators and a dashboard that is pretty simple to understand. But I think it's imperative to keep this clean, uncluttered, and understandable. And documented.

Things out the serial port, on the other hand, we can add to them forever. It is not really a problem to have undocumented commands there or stuff coming up at different loglevels. And for maintenance, plugging into a USB port is trivial.

But I would really like to be able to do the basic configuration of the device without a terminal program, as we actually have users who cannot get a terminal program up and running on Windoze NOW. They should be able to configure the device and see their inverter temperature. I do kind of plan to change the throttle and brake percentage on the STATUS page to the actual ADC values, so they can associate that with the numbers on the throttle configuration page. Right now, I have to run L on the serial port to get that value range to calibrate the throttle.

I am haunted by the interface to configure the Rinehardt controller and indeed the Curtis controller used with HPEVS. It has so many options that you just go into brain freeze facing all of them. Ultimately, what we are about is how throttle and brake and regen interplay. Then some basic "features" that are pretty common. How do we turn on the brake lights? How do we put it in reverse? How do we turn on the cooling fan? How do we do precharge.

For example, I think it's much more useful to be able to configure a PWM output for a tachometer, than to do PID codes for things that are broken. So basically mapping functions like brakelights to outputs (0-7).

I would like to keep OUT anything on that website that doesn't have to do with

1. Four digitial Inputs
2. Four analog inputs
3. Eight digital outputs
4. Operation of hte motor controller

I guess I don't see maintenance as any part of it. For that matter, I don't see charging, battery management, DC-DC converter management, or any of that as part of it either. That can all be handled as advanced tasks on the serial port.

And yes, we can put anything on the CAN bus, OBDII, and ELM and indeed the end user can setup Torque or EngineLink to display telephone poles per fortnight if it is at all important to them.

This is just general feel. I am not committed to any of it in a religious sense. But I am in a presentation sense.

For example, I could be bent over on the charger issue if it was a separate tab and REALLy simple, what the desired charge voltage and current is, what the actual charge voltage and current is. How many AH have gone in. Like a really SIMPLE tab called CHARGING with like five values in it - and two you could actually change.

But if you want to get off into which charger, Lear, Brusa, Tcch, what the CAN commands are for each, etc. we're back on the serial port. And really back on ENABLE and DISABLE device modules.

For example, we have annunciators for ERROR, FAULT, and WARNING that are little used. I'm ok with lighting one to show you HAVE a problem. But what the problem is, should be done better otherwise and elsewhere. We could MODESTLY expand that to a LITTLE more specific (THROTTLE FAIL/INVERTER FAIL/MOTOR FAIL/CHARGER FAIL/BATT FAIL) if pressed.

One of the great things about GEVCU at this point is it is relatively easy to understand and configure. I'm loathe to give that up.

One area that haunts me a bit is the enable function. Right now we can't really do that from the website. And the ENABLE function is tedious from the serial port. Worse, you can't configure it for your car without using the serial port.

I guess an equipment list on the web site with checkboxes beside what your car has might be very easy to use. It would be a nightmare to update each time we add a module. But to enable devices by checking a box next to the name would be cool.

Jack Rickard

Jack

On Thu, Sep 4, 2014 at 10:08 AM, Collin Kidder notifications@github.com wrote:

I originally wanted to use the existing PID specification but I looked at all of them and 98% of them are totally irrelevant. There are hundreds of codes for O2 sensors and other ICE related and emissions sensors. All of that is totally worthless to us. As such maybe it'd be better to do what OEMs do anyway and make up codes. The made up codes could still more or less conform to the OBDII diagnostics standard such that any OBDII scanner could retrieve the numeric codes. So, we'll have to make up a lot of codes.

I just pushed a git commit with a bunch of codes to start with. At this point I'm finishing up the fault handler code I had started a long time ago. It will be very fast to quickly finish it since it is so simple. At that point there will be a base to work with.

But, this is a huge task and a detailed specification for what it actually is and what it does will need to be constructed. The biggest part of the task isn't even really the fault handling system. That's relatively easy. The hard part is that calling into the fault handler touches every other part of the code. A lot of work has to be done in (motor controller / BMS / charger / throttle / etc) modules to make sure that everything that could be faulty is detected and reported. That's the difficult, boring, and time consuming part. Unfortunately open source projects tend to lack proper error checking because it's tedious and not exciting like building support for a new motor controller.

As far as getting to the faults. The normal route should be via OBDII pid be that over canbus or bluetooth or wifi. But, I think it'd be neat if the website hosted on the GEVCU could also list the current faults on a separate page. That'd be pretty handy.

On Thu, Sep 4, 2014 at 10:43 AM, Jack Rickard notifications@github.com wrote:

I'm onboard. But it is actually very ambitious. I'm not clear on a roadmap from here to there, and it looks like a shitpot of work. Basically I guess pick out the standard error PIDS you would want to inform, and work backwards to find where in the code we would test for it. Then some EEPROM space to hold a static set of PID status's.

At that point, OBDII could retrieve them on receipt of a request.

The wireless or bluetooth is confusing. I would just use them as "alternate OBDII channels".

So the OBDII minder could operate over

CANBUS0 CANBUS1 ELM

The ELM module could then have option for Wireless via WiReach or Bluetooth via an add-on bluetooth card on the new GPIO connector Ed almost provided.

Jack Rickard

Wireless via the WiReach using ELM module. Bluetooth via some yet to be done bluetooth module.

I guess ELM could use either wireless or bluetooth.

On Wed, Sep 3, 2014 at 9:18 AM, Collin Kidder notifications@github.com

wrote:

Probably. Which is why I did list wifi as one of the options. I absolutely do think that the fault read out should be on the website. That'd be so helpful to people it's not even funny. Imagine if your ICE car had a built-in website that lists all the problems with it. Well, that sort of already exists. If you subscribe to a service like OnStar it really will give you the faults in an email or online.

I don't know that we'll store the fault text in the firmware. It is probably sufficient to know that P0220 means throttle position sensor error without storing those words. The web page could have the definitions and use them. Maybe have a JSON file with the correspondence between code and the description. That'd even make it easy to allow for language translation if people want to know the faults in Swedish or German or some other language. A simple switch of the JSON file is all it takes.

On Wed, Sep 3, 2014 at 9:46 AM, dboekel notifications@github.com wrote:

Would it be easier to implement this in the onboard webserver or via bluetooth? Also easier to readout for most users.

2014-09-03 15:38 GMT+02:00 Collin Kidder notifications@github.com:

Currently it can be tough to figure out why something is not working. For instance, why is the motor controller stuck in neutral? What is causing it not to be in drive or reverse? The end user has no idea. Presumably something in code is doing it on purpose but the end user has no way of knowing what they can do to correct the situation. As such, it would be good to augment the code with facilities to provide better debugging information. This could be done via OBDII style fault codes. For instance, if there is a throttle problem in an ICE car you might get P0220 which means that there is a problem with the throttle position sensor. In fact, we should output that exact code when there is a problem with the throttle position sensing.

Doing this probably requires that we have a buffer for errors that can be read by a connected OBDII device (or listed on the web page or dumped out on the console).

This could end up being a huge amount of work to do it right. But, without extensive support for diagnostics we'll never be where we should be and users will be stuck guessing why things don't work.

— Reply to this email directly or view it on GitHub https://github.com/collin80/GEVCU/issues/78.

www.boekel.nu

— Reply to this email directly or view it on GitHub https://github.com/collin80/GEVCU/issues/78#issuecomment-54299146.

— Reply to this email directly or view it on GitHub https://github.com/collin80/GEVCU/issues/78#issuecomment-54303862.

http://www.EVTV.me http://EVTV.me

Electric Vehicle Television - KickinGas - One Car at a Time.

— Reply to this email directly or view it on GitHub https://github.com/collin80/GEVCU/issues/78#issuecomment-54487231.

— Reply to this email directly or view it on GitHub https://github.com/collin80/GEVCU/issues/78#issuecomment-54491492.

http://www.EVTV.me http://EVTV.me

Electric Vehicle Television - KickinGas - One Car at a Time.

[collin80]

I suppose I can see what you're saying - you want to keep the web interface simple so that mortal man can easily configure a few things and drive away. That's a reasonable goal. I actually thought that giving people the faults on the website would serve this purpose but there's no reason they can't just use an OBDII scanner or Torque to do the same thing.

I do think that it would be appropriate to expose generic configuration for every type of device. It should be possible to set voltage and current for a charger - generic things that should apply to a range of hardware without specifically knowing what hardware it is. You mentioned maybe having a checkbox or something to specify which devices are installed in a car. You're right that it'd be a nightmare keeping the list synchronized. That's why I don't bother trying to do that in the GEVCU code. You register your device in one place in the GEVCU code and it is automatically added to the list and supported. The same basic thing should be possible on the website. How? I'm not entirely sure. I've looked into it and really the only way to affect the website seems to be by sending parameters. So, we'd probably have to determine the upper limit for # of devices and register that number of parameters. Then we can send the device details to the iChip module just once upon start up and let it use them. This will probably be rather tricky to do. But, we've got to do something because it isn't good that there is no web-enabled way to turn device support on or off.

I think I'll add the above two things to their own issues in github so we can track them separately.

On Thu, Sep 4, 2014 at 11:51 AM, Jack Rickard notifications@github.com wrote:

I guess I am back to my conversation with Michael over the bitfield annunciators Collin. I just think we should guard that Website with our lives that anything on it be used pretty much to configure the device. We should strive for simplicity here, and keep it clean and simple. We have a status page now with inputs and outputs on the annunciators and a dashboard that is pretty simple to understand. But I think it's imperative to keep this clean, uncluttered, and understandable. And documented.

Things out the serial port, on the other hand, we can add to them forever. It is not really a problem to have undocumented commands there or stuff coming up at different loglevels. And for maintenance, plugging into a USB port is trivial.

But I would really like to be able to do the basic configuration of the device without a terminal program, as we actually have users who cannot get a terminal program up and running on Windoze NOW. They should be able to configure the device and see their inverter temperature. I do kind of plan to change the throttle and brake percentage on the STATUS page to the actual ADC values, so they can associate that with the numbers on the throttle configuration page. Right now, I have to run L on the serial port to get that value range to calibrate the throttle.

I am haunted by the interface to configure the Rinehardt controller and indeed the Curtis controller used with HPEVS. It has so many options that you just go into brain freeze facing all of them. Ultimately, what we are about is how throttle and brake and regen interplay. Then some basic "features" that are pretty common. How do we turn on the brake lights? How do we put it in reverse? How do we turn on the cooling fan? How do we do precharge.

For example, I think it's much more useful to be able to configure a PWM output for a tachometer, than to do PID codes for things that are broken. So basically mapping functions like brakelights to outputs (0-7).

I would like to keep OUT anything on that website that doesn't have to do with

1. Four digitial Inputs
2. Four analog inputs
3. Eight digital outputs
4. Operation of hte motor controller

I guess I don't see maintenance as any part of it. For that matter, I don't see charging, battery management, DC-DC converter management, or any of that as part of it either. That can all be handled as advanced tasks on the serial port.

And yes, we can put anything on the CAN bus, OBDII, and ELM and indeed the end user can setup Torque or EngineLink to display telephone poles per fortnight if it is at all important to them.

This is just general feel. I am not committed to any of it in a religious sense. But I am in a presentation sense.

For example, I could be bent over on the charger issue if it was a separate tab and REALLy simple, what the desired charge voltage and current is, what the actual charge voltage and current is. How many AH have gone in. Like a really SIMPLE tab called CHARGING with like five values in it - and two you could actually change.

But if you want to get off into which charger, Lear, Brusa, Tcch, what the CAN commands are for each, etc. we're back on the serial port. And really back on ENABLE and DISABLE device modules.

For example, we have annunciators for ERROR, FAULT, and WARNING that are little used. I'm ok with lighting one to show you HAVE a problem. But what the problem is, should be done better otherwise and elsewhere. We could MODESTLY expand that to a LITTLE more specific (THROTTLE FAIL/INVERTER FAIL/MOTOR FAIL/CHARGER FAIL/BATT FAIL) if pressed.

One of the great things about GEVCU at this point is it is relatively easy to understand and configure. I'm loathe to give that up.

One area that haunts me a bit is the enable function. Right now we can't really do that from the website. And the ENABLE function is tedious from the serial port. Worse, you can't configure it for your car without using the serial port.

I guess an equipment list on the web site with checkboxes beside what your car has might be very easy to use. It would be a nightmare to update each time we add a module. But to enable devices by checking a box next to the name would be cool.

Jack Rickard

Jack

On Thu, Sep 4, 2014 at 10:08 AM, Collin Kidder notifications@github.com wrote:

I originally wanted to use the existing PID specification but I looked at all of them and 98% of them are totally irrelevant. There are hundreds of codes for O2 sensors and other ICE related and emissions sensors. All of that is totally worthless to us. As such maybe it'd be better to do what OEMs do anyway and make up codes. The made up codes could still more or less conform to the OBDII diagnostics standard such that any OBDII scanner could retrieve the numeric codes. So, we'll have to make up a lot of codes.

I just pushed a git commit with a bunch of codes to start with. At this point I'm finishing up the fault handler code I had started a long time ago. It will be very fast to quickly finish it since it is so simple. At that point there will be a base to work with.

But, this is a huge task and a detailed specification for what it actually is and what it does will need to be constructed. The biggest part of the task isn't even really the fault handling system. That's relatively easy. The hard part is that calling into the fault handler touches every other part of the code. A lot of work has to be done in (motor controller / BMS / charger / throttle / etc) modules to make sure that everything that could be faulty is detected and reported. That's the difficult, boring, and time consuming part. Unfortunately open source projects tend to lack proper error checking because it's tedious and not exciting like building support for a new motor controller.

As far as getting to the faults. The normal route should be via OBDII pid be that over canbus or bluetooth or wifi. But, I think it'd be neat if the website hosted on the GEVCU could also list the current faults on a separate page. That'd be pretty handy.

On Thu, Sep 4, 2014 at 10:43 AM, Jack Rickard notifications@github.com

wrote:

I'm onboard. But it is actually very ambitious. I'm not clear on a roadmap from here to there, and it looks like a shitpot of work. Basically I guess pick out the standard error PIDS you would want to inform, and work backwards to find where in the code we would test for it. Then some EEPROM space to hold a static set of PID status's.

At that point, OBDII could retrieve them on receipt of a request.

The wireless or bluetooth is confusing. I would just use them as "alternate OBDII channels".

So the OBDII minder could operate over

CANBUS0 CANBUS1 ELM

The ELM module could then have option for Wireless via WiReach or Bluetooth via an add-on bluetooth card on the new GPIO connector Ed almost provided.

Jack Rickard

Wireless via the WiReach using ELM module. Bluetooth via some yet to be done bluetooth module.

I guess ELM could use either wireless or bluetooth.

On Wed, Sep 3, 2014 at 9:18 AM, Collin Kidder < notifications@github.com>

wrote:

Probably. Which is why I did list wifi as one of the options. I absolutely do think that the fault read out should be on the website. That'd be so helpful to people it's not even funny. Imagine if your ICE car had a built-in website that lists all the problems with it. Well, that sort of already exists. If you subscribe to a service like OnStar it really will give you the faults in an email or online.

I don't know that we'll store the fault text in the firmware. It is probably sufficient to know that P0220 means throttle position sensor error without storing those words. The web page could have the definitions and use them. Maybe have a JSON file with the correspondence between code and the description. That'd even make it easy to allow for language translation if people want to know the faults in Swedish or German or some other language. A simple switch of the JSON file is all it takes.

On Wed, Sep 3, 2014 at 9:46 AM, dboekel notifications@github.com wrote:

Would it be easier to implement this in the onboard webserver or via bluetooth? Also easier to readout for most users.

2014-09-03 15:38 GMT+02:00 Collin Kidder notifications@github.com:

Currently it can be tough to figure out why something is not working. For instance, why is the motor controller stuck in neutral? What is causing it not to be in drive or reverse? The end user has no idea. Presumably something in code is doing it on purpose but the end user has no way of knowing what they can do to correct the situation. As such, it would be good to augment the code with facilities to provide better debugging information. This could be done via OBDII style fault codes. For instance, if there is a throttle problem in an ICE car you might get P0220 which means that there is a problem with the throttle position sensor. In fact, we should output that exact code when there is a problem with the throttle position sensing.

Doing this probably requires that we have a buffer for errors that can be read by a connected OBDII device (or listed on the web page or dumped out on the console).

This could end up being a huge amount of work to do it right. But, without extensive support for diagnostics we'll never be where we should be and users will be stuck guessing why things don't work.

— Reply to this email directly or view it on GitHub https://github.com/collin80/GEVCU/issues/78.

www.boekel.nu

— Reply to this email directly or view it on GitHub https://github.com/collin80/GEVCU/issues/78#issuecomment-54299146.

— Reply to this email directly or view it on GitHub https://github.com/collin80/GEVCU/issues/78#issuecomment-54303862.

http://www.EVTV.me http://EVTV.me

Electric Vehicle Television - KickinGas - One Car at a Time.

— Reply to this email directly or view it on GitHub https://github.com/collin80/GEVCU/issues/78#issuecomment-54487231.

— Reply to this email directly or view it on GitHub https://github.com/collin80/GEVCU/issues/78#issuecomment-54491492.

http://www.EVTV.me http://EVTV.me

Electric Vehicle Television - KickinGas - One Car at a Time.

— Reply to this email directly or view it on GitHub https://github.com/collin80/GEVCU/issues/78#issuecomment-54498522.

[neuweiler]

FYI: In the latest pullRequest where the communication from ichip to client is done via web-sockets, I push logging information to the web client where it's displayed in a pop-up message. Helps a lot to discover errors / warnings