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 [email protected]:

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
#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 [email protected] 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 [email protected]:

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
#78.

www.boekel.nu

—
Reply to this email directly or view it on GitHub
#78 (comment).

[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 [email protected]
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 [email protected] 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 [email protected]:

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
#78.

www.boekel.nu

—
Reply to this email directly or view it on GitHub
#78 (comment).

—
Reply to this email directly or view it on GitHub
#78 (comment).

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 [email protected]
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 [email protected]
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 [email protected]
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 [email protected]:

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
#78.

www.boekel.nu

—
Reply to this email directly or view it on GitHub
#78 (comment).

—
Reply to this email directly or view it on GitHub
#78 (comment).

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
#78 (comment).

[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 [email protected]
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 [email protected]
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 [email protected]

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 [email protected]
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 [email protected]:

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
#78.

www.boekel.nu

—
Reply to this email directly or view it on GitHub
#78 (comment).

—
Reply to this email directly or view it on GitHub
#78 (comment).

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
#78 (comment).

—
Reply to this email directly or view it on GitHub
#78 (comment).

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 [email protected]
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 [email protected]
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 [email protected]

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 <
[email protected]>

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 [email protected]
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 [email protected]:

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
#78.

www.boekel.nu

—
Reply to this email directly or view it on GitHub
#78 (comment).

—
Reply to this email directly or view it on GitHub
#78 (comment).

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
#78 (comment).

—
Reply to this email directly or view it on GitHub
#78 (comment).

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
#78 (comment).

[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