Searching \ for '[PIC]: Next big project' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Next big project'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Next big project'
2003\09\08@130241 by Jai Dhar

flavicon
face
Hello all,

While planning out what I should do for my next project, I decided on
implementing a little 16f-driven monitoring unit for my car. I am hoping to
have such functions as trip timers, mileage calculators, temperature
sensors, fuel level etc...  ideally, of course. Anyway, if I am not
mistaken, I will have to look into interfacing to the ECU, correct? Is this
data something that is readily available? ('96 Nissan Maxima), or is it
something that I'm going to have to try and figure out on my own. Any
direction is appreciated,

Thank you,

Jai Dhar
Sterner Automation Limited
43 Hanna Avenue
Toronto, Ontario
M6K 1X6
416-538-1826 x231
spam_OUTjai.dharTakeThisOuTspamsternerautomation.com
http://www.sternerautomation.com

#76 on this year's PROFIT 100
http://www.profitguide.com/profit100

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu

2003\09\08@132324 by Herbert Graf

flavicon
face
>  While planning out what I should do for my next project, I decided on
> implementing a little 16f-driven monitoring unit for my car. I am
> hoping to
> have such functions as trip timers, mileage calculators, temperature
> sensors, fuel level etc...  ideally, of course. Anyway, if I am not
> mistaken, I will have to look into interfacing to the ECU,
> correct? Is this
> data something that is readily available? ('96 Nissan Maxima), or is it
> something that I'm going to have to try and figure out on my own. Any
> direction is appreciated,

       That is something I actually started doing on my car, but got bogged down
with other things and never finished it. The biggest issues for me was data
storage (since I was making more of a black box then just a monitor). I
STRONGLY recommend you get a shop manual for your car, I couldn't imagine
trying to interface to today's cars without one. Even installing an alarm
system is many magnitudes easier if you have the shop manual. With that
said, you car does have OBDII, so you SHOULD be able to get many parameters
from that bus. TTYL

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu

2003\09\08@132950 by Jai Dhar

flavicon
face
Thanks for the info Herbert.. immediately after I sent my first message, I
ordered the factory service manual from ebay, so that should hopefully be
worth something (considering that the shipping will cost as much as the
book!). Will it explain the protocol though? It doesn't seem likely that
they would make it that readily available. Anyway, I have also seen that
word you mentioned, OBDII, floating around a lot, so I will do some more
research on that. If anyone knows any good resources off hand, please let me
know!

Jai

> {Original Message removed}

2003\09\08@134921 by Herbert Graf

flavicon
face
> Thanks for the info Herbert.. immediately after I sent my first message, I
> ordered the factory service manual from ebay, so that should hopefully be
> worth something (considering that the shipping will cost as much as the
> book!). Will it explain the protocol though? It doesn't seem likely that
> they would make it that readily available. Anyway, I have also seen that
> word you mentioned, OBDII, floating around a lot, so I will do some more
> research on that. If anyone knows any good resources off hand,
> please let me
> know!

       I doubt very much they'd explain anything about the OBDII connection,
that's something a scan tool is supposed to use. With that said there is a
lot of information on the net about it. However, unless you have to, I'd
stay away from the OBDII interface if possible, it's much easier to tie into
the sensors directly IMHO, and the shop manual will show you exactly where
you can tie into them. In my car (which is much older) all the sensors are
pretty much either analog or very simple digital (i.e. 4000 pulses per
mile), my plan didn't include any tying into the OBD port. TTYL

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam.....mitvma.mit.edu

2003\09\08@135542 by Jai Dhar

flavicon
face
So you are suggesting bypassing the computer (I was mistaken by calling that
the ECU, wasn't I?) altogether and talking directly to the sensors? Assuming
100 sensors then, wouldn't I need to basically know 100 different sets of
commands and whatnot instead of gathering data all from one place? And would
I be able to modify parameters such as air/fuel ratio with this method?

> {Original Message removed}

2003\09\08@135751 by Denny Esterline

picon face
I spent a couple years as a mechanic in a Chrysler dealer, NONE of our books
ever explained a data protocol.

-Denny


----- Original Message -----
From: "Jai Dhar" <EraseMEjai.dharspam_OUTspamTakeThisOuTSTERNERAUTOMATION.COM>
To: <PICLISTspamspam_OUTMITVMA.MIT.EDU>
Sent: Monday, September 08, 2003 1:27 PM
Subject: Re: [PIC]: Next big project


> Thanks for the info Herbert.. immediately after I sent my first message, I
> ordered the factory service manual from ebay, so that should hopefully be
> worth something (considering that the shipping will cost as much as the
> book!). Will it explain the protocol though? It doesn't seem likely that
> they would make it that readily available. Anyway, I have also seen that
> word you mentioned, OBDII, floating around a lot, so I will do some more
> research on that. If anyone knows any good resources off hand, please let
me
> know!
>
> Jai
>
> > {Original Message removed}

2003\09\08@140206 by Bob Blick

face
flavicon
face
Jai Dhar said:
> I will have to look into interfacing to the ECU, correct? Is
> this data something that is readily available? ('96 Nissan Maxima), or
> is it something that I'm going to have to try and figure out on my own.

Hi Jai,

I did a whole lot of work on OBDII a couple of years ago and it's getting
time to resurrect the project. It was an OBDII to RS232 adapter and worked
with all three flavors of OBDII. I did a PC board design and got the
firmware written and working for the protocol that Ford uses, since that
was the car I had. I also had a few PC boards made up and tried to get
other people involved but nothing ever came of that. I have another car
now so it's time to debug it for that protocol. I don't know which it uses
but it's not Ford.

The OBDII low level spec is likely not in your shop manual (it wasn't in
either of mine) but you can buy them from ISO at great cost. I have them
and really should write my own description of OBDII since that is probably
legal. Making copies of the ISO documents is likely not so legal, eh?

Anyway, don't get your hopes up for anything quick but maybe I'll dig the
info up, since I know there's interest.

BTW, it used a 16C63 so anything new like a 16F873 or 876 would work fine.

Cheers,

Bob

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestKILLspamspammitvma.mit.edu

2003\09\08@140827 by Jai Dhar

flavicon
face
Hey Bob,

If you need a test subject for a Nissan Maxima, I think I know someone who
might be able to help :-) Lol, any extra info would be muchly appreciated by
me. I was taking to some of the other Engineers in my company here (I'm a
student, so my experience is obviously limited), and they basically told me
that the problem isn't figuring out the protocol(s) used, however, finding
out the correct commands/params to issue/read from the on-board computer is
where the challenge lies since this information isn't readily available. Is
this more accurate of a problem description? One of them also went on to
explain to me what type of changes one simple parameter could make for
example, and that perked my interest even more in this project!!!

Anyway, like I said, whenever you find anything that might be able to help,
send it over and I will be very thankful!!

Jai

> {Original Message removed}

2003\09\08@141831 by David Devendorf

picon face
This might help.

http://www.davisnet.com/drive/products/carchip_products.asp

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestKILLspamspammitvma.mit.edu

2003\09\08@143038 by Denny Esterline

picon face
OBDII (on board diagnostics 2) was federaly mandated (IIRC 96 was the first
year). It was done so that cars didn't become "black-boxes" that had to go
to the dealer for service. Different years and makes/models may have more or
less information available but they all comunicate with the same connector
on the same protocol so one scan tool can work on all of them.

As far as changing parameters goes, I hate to be the spoil sport, but that
would violate about a hundred different emmisions regulations. (read: don't
tell anybody about it ;o)  )

-Denny

----- Original Message -----
From: "Jai Dhar" <RemoveMEjai.dharTakeThisOuTspamSTERNERAUTOMATION.COM>
To: <spamBeGonePICLISTspamBeGonespamMITVMA.MIT.EDU>
Sent: Monday, September 08, 2003 2:06 PM
Subject: Re: [PIC]: Next big project


> Hey Bob,
>
>  If you need a test subject for a Nissan Maxima, I think I know someone
who
> might be able to help :-) Lol, any extra info would be muchly appreciated
by
> me. I was taking to some of the other Engineers in my company here (I'm a
> student, so my experience is obviously limited), and they basically told
me
> that the problem isn't figuring out the protocol(s) used, however, finding
> out the correct commands/params to issue/read from the on-board computer
is
> where the challenge lies since this information isn't readily available.
Is
> this more accurate of a problem description? One of them also went on to
> explain to me what type of changes one simple parameter could make for
> example, and that perked my interest even more in this project!!!
>
>  Anyway, like I said, whenever you find anything that might be able to
help,
> send it over and I will be very thankful!!
>
> Jai
>
> > {Original Message removed}

2003\09\08@143505 by Jai Dhar

flavicon
face
Ahh, so with OBDII, I could basically get a lot (but not all) of the
information that I need since the spec defines both the physical protocol
and what msg's to send/receive etc..? And about modifying parameters, that
was said out loud by accident :-) To be honest though, just reading the
computer would be enough for me since this seems like a valuable project for
the future.

> {Original Message removed}

2003\09\08@144747 by Herbert Graf

flavicon
face
> So you are suggesting bypassing the computer (I was mistaken by
> calling that
> the ECU, wasn't I?)

       Nope, ECU is a common name for the main computer, ECM is also another older
common name.

> altogether and talking directly to the
> sensors?

       It depends on your car, on mine most of the sensors give a voltage or
frequency output, so it is FAR easier to work with those then try and
decipher the stream through the OBD port.

> Assuming
> 100 sensors then, wouldn't I need to basically know 100 different sets of
> commands and whatnot instead of gathering data all from one
> place?

       Again, I don't know about your car, however I think you are overestimating
the complexity of the sensors. I might be WAY off here but I doubt very much
that your sensors require commands or that sort of thing, most will just
give a voltage output, or in some cases frequency (maybe even current, i.e.
most fuel level sensors are current type). You MIGHT hit a sensor or two
that is "smart", however I doubt it, perhaps something like a MAF, but even
that on my car is just an analog signal.

       I must again say that I have NO idea what's in your car, the shop manual
will tell you quickly whether I am wrong or not.

> And would
> I be able to modify parameters such as air/fuel ratio with this method?

       Well if you want to do that then you'll have to pretty much tap into the
OBDII system, while you COULD modify that ratio doing it other ways, OBDII
would probably be the most straightforward. I guess I've made a mistake in
assuming you just wanted to monitor your car. I personally would NEVER fool
with that sort of thing, the car is a closed loop system and is optimized
for best running, by messing with air/fuel you risk shortening the life of
the engine and support components, that is something I'd personally NEVER do
so such a complicated engine. (give me a big block Chevy and then we'll
talk!) :)

       Good luck, TTYL

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu

2003\09\08@145338 by Jai Dhar

flavicon
face
Ok, it's all making some sense now... your proposed method definitely seems
easier. Regarding the tweaking part, you are correct, it is definitely
dangerous, and was not the intent of this project. However, I came up with
this idea maybe 3 hours ago, and it has taken a few turns since then :-)
Screwing up my car isn't the goal though, monitoring performance is, and I
don't plan on risking any damage to it. I just thought that if I'm forced to
talk through OBDII, then why not see what else I can do with it.

Thanks for straightening the rest out tho!

Jai

{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestEraseMEspam.....mitvma.mit.edu

2003\09\08@145956 by John N. Power

flavicon
face
>  While planning out what I should do for my next project, I decided on
> implementing a little 16f-driven monitoring unit for my car. I am hoping to
> have such functions as trip timers, mileage calculators, temperature
> sensors, fuel level etc...  ideally, of course. Anyway, if I am not
> mistaken, I will have to look into interfacing to the ECU, correct? Is this
> data something that is readily available? ('96 Nissan Maxima), or is it
> something that I'm going to have to try and figure out on my own. Any
> direction is appreciated,

> Thank you,

> Jai Dhar

There is an article in Circuit Cellar #123, October 2000, which discusses
ODB-II ISO-9141and describes how to build an "Automotive Diagnostic
Scan" tool. From the article: "It consists of an ISO-9141-2 to RS-232
protocol converter and a Windows 95/98 application (installed in the
user's computer)." See pages 56-64. There is an extensive discussion
of the protocols involved.

Also, Circuit Cellar #135, October 2001, there is an article describing
construction of a circuit to correct speedometer error in electronic
speedometers. There is extensive discussion of "intercepting the
signal" (their words) from the speed sensor.

John Power

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspammitvma.mit.edu

2003\09\08@152454 by Bob Blick

face
flavicon
face
John N. Power said:

> There is an article in Circuit Cellar #123, October 2000, which
> discusses ODB-II ISO-9141and describes how to build an "Automotive
> Diagnostic Scan" tool.

No, it describes how to BUY one.

-Bob

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestEraseMEspamEraseMEmitvma.mit.edu

2003\09\08@155151 by John N. Power

flavicon
face
     >> John N. Power said:

>> There is an article in Circuit Cellar #123, October 2000, which
>> discusses ODB-II ISO-9141and describes how to build an "Automotive
>> Diagnostic Scan" tool.

> No, it describes how to BUY one.

> -Bob

       We are both right, I think. There is a schematic on page 60,
     and the text states "The executable code is available to download from
     the ... web site for free." Also, "Verify that your parts match the parts list."
     On the other hand, the author states that a simple circuit " .. keeps the
     cost of the kit to a minimum." Apparently the author sells a kit of parts,
     but the article gives enough information to build the device without buying
     the kit. The software is available free, and the circuit is so simple (from
     looking at the schematic) that there should be no problem building it
     from the article. The photos accompanying the article show interior views
     of the mounted parts.

     John Power

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspam_OUTspamKILLspammitvma.mit.edu

2003\09\08@155604 by Jai Dhar

flavicon
face
Herbert,

Another thought came to me while thinking of your proposed solution of just
reading the sensors directly. Take the fuel level sensor for example... from
what I have seen before, it's simply a varying voltage level that is
controlled by a bubble-like sensor in the tank (that acts as a potentiometer
I guess). Anyway, now if I were to attempt to sense that voltage level by
splicing that line, wouldn't I be introducing a voltage drop? This would
then make the reading on my dashboard innacurate, unless I compensate? Would
this not be a problem in general for all of the sensors? With the fuel-level
sensor, it might not be such as problem, but for other critical ones, this
could be quite dangerous, correct?

Also, I have been doing a lot of reading on OBD-II since it seems really
easy to interface with (my particular car has an RS-232-like interface, all
it needs is some voltage level shifting). But from all the sites that I have
investigated thus far, not one really talks about "what information" I can
obtain. Most just say "fault codes", which leads me to believe that OBDII is
simply a way of troubleshooting a problem, not actually monitoring various
parameters. Is this correct? IF so, it is pretty much useless to me, and I
will have to go with the direct sensor method, or anything else ???

Thanks again,

Jai

> {Original Message removed}

2003\09\08@161335 by Denny Esterline

picon face
I don't know much about the protocol, but from my experience the "official"
scan tool can definitely view the readings on most any sensor. (I don't
remember seeing the accelerometer for the air bags, so I can't say 'every'
sensor ;o)   )

We also had a tool called a "co-pilot". when we couldn't duplicate a problem
we would program the co-pilot to watch whatever sensors we thought might be
related, plug it in (into the OBDII connector) and let the customer drive
with it for a few days. Whenever they though it was acting up, they push a
button and it would store the sensor readings for a couple minutes.
(actually it used a moving window where it actually had stored the readings
BEFORE the button was pressed, but that's not relevant to this discussion)

-Denny

----- Original Message -----
From: "Jai Dhar" <RemoveMEjai.dharTakeThisOuTspamspamSTERNERAUTOMATION.COM>
To: <EraseMEPICLISTspamspamspamBeGoneMITVMA.MIT.EDU>
Sent: Monday, September 08, 2003 3:56 PM
Subject: Re: [PIC]: Next big project


> Herbert,
>
>  Another thought came to me while thinking of your proposed solution of
just
> reading the sensors directly. Take the fuel level sensor for example...
from
> what I have seen before, it's simply a varying voltage level that is
> controlled by a bubble-like sensor in the tank (that acts as a
potentiometer
> I guess). Anyway, now if I were to attempt to sense that voltage level by
> splicing that line, wouldn't I be introducing a voltage drop? This would
> then make the reading on my dashboard innacurate, unless I compensate?
Would
> this not be a problem in general for all of the sensors? With the
fuel-level
> sensor, it might not be such as problem, but for other critical ones, this
> could be quite dangerous, correct?
>
>  Also, I have been doing a lot of reading on OBD-II since it seems really
> easy to interface with (my particular car has an RS-232-like interface,
all
> it needs is some voltage level shifting). But from all the sites that I
have
> investigated thus far, not one really talks about "what information" I can
> obtain. Most just say "fault codes", which leads me to believe that OBDII
is
> simply a way of troubleshooting a problem, not actually monitoring various
> parameters. Is this correct? IF so, it is pretty much useless to me, and I
> will have to go with the direct sensor method, or anything else ???
>
> Thanks again,
>
> Jai
>
> > {Original Message removed}

2003\09\08@161747 by Bob Blick

face
flavicon
face
Jai Dhar said:

> that I have investigated thus far, not one really talks about "what
> information" I can obtain. Most just say "fault codes", which leads me
> to believe that OBDII is simply a way of troubleshooting a problem, not
> actually monitoring various parameters. Is this correct?

You get all sorts of stuff, rpm, throttle position, coolant temperature,
air temperature, air flow and/or manifold pressure, injector pulse width,
ground speed, etc

Cheers,

Bob

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestKILLspamspammitvma.mit.edu

2003\09\08@161918 by Jai Dhar

flavicon
face
I think that answers my question Denny! If scan-tools can gather that info,
then so can I!! :-) Well, after all, if it plugged into the OBDII interface,
then theoretically it's possible. Now if I could just find a cheaper copy of
the OBDII scan code book (as if Uni textbooks don't cost enough).

Thank you once again!

> {Original Message removed}

2003\09\08@162116 by Bob Blick

face
flavicon
face
John N. Power said:

>> No, it describes how to BUY one.

>         We are both right, I think. There is a schematic on page 60,
>       and the text states "The executable code is available to download
> from the ... web site for free." Also, "Verify that your parts
> match the parts list." On the other hand, the author states that a
> simple circuit " .. keeps the cost of the kit to a minimum."
> Apparently the author sells a kit of parts, but the article gives

Oops, sorry, I was thinking about a different OBDII article in Circuit
Cellar that was basically an introduction to OBDII products and an
interface by B&B Electronics in particular.

Cheerful regards,

Bob

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestSTOPspamspamspam_OUTmitvma.mit.edu

2003\09\08@162532 by Herbert Graf

flavicon
face
> Herbert,
>
>  Another thought came to me while thinking of your proposed
> solution of just
> reading the sensors directly. Take the fuel level sensor for
> example... from
> what I have seen before, it's simply a varying voltage level that is
> controlled by a bubble-like sensor in the tank (that acts as a
> potentiometer
> I guess). Anyway, now if I were to attempt to sense that voltage level by
> splicing that line, wouldn't I be introducing a voltage drop?

       Not really, you simply sense the line with a high input impedance device, a
PIC's ADC input stage fits this bill pretty well (except during acquisition
but that would be so short I doubt it would be "felt" by the rest). If
really in doubt us a CMOS opamp, their input impedance is so high that you
need a special meter to measure the input current!

> This would
> then make the reading on my dashboard innacurate, unless I
> compensate? Would
> this not be a problem in general for all of the sensors? With the
> fuel-level
> sensor, it might not be such as problem, but for other critical ones, this
> could be quite dangerous, correct?

       Not at all, in most cases the sensors are voltage output, as long as you
don't load the line to much there will be practically no error. A modern ADC
or op amp would fit the bill nicely. As for frequency output sensors
(tachometer signal, road speed sensor, O2 sensor, etc.) there is NO error
involved (unless you load it so much it stops registering).

{Quote hidden}

       Interfacing to OBDII is easy, it's interpreting the data that's hard, and
that's why I avoid it. Every company tends to do things a little
differently, so a piece of hardware that works on one car might not work on
another. The biggest problem is the details aren't freely available, so you
have to dig and hope somebody made their efforts public domain or figure it
out yourself. Sending commands are even more tricky. This is the reason I've
stayed away from my car's OBD connector (which isn't OBDII BTW). TTYL

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestSTOPspamspamEraseMEmitvma.mit.edu

2003\09\08@163222 by M. Adam Davis

flavicon
face
Chances are very good that your university has a ISO subscription for
their students.  If you have an engineering library go ask them if
students have access to ISO standards.

-Adam

Jai Dhar wrote:

>I think that answers my question Denny! If scan-tools can gather that info,
>then so can I!! :-) Well, after all, if it plugged into the OBDII interface,
>then theoretically it's possible. Now if I could just find a cheaper copy of
>the OBDII scan code book (as if Uni textbooks don't cost enough).
>
>Thank you once again!
>
>
>
>>{Original Message removed}

2003\09\08@164226 by Michael Bishop

flavicon
face
You can modify several parameters before you are going to be worried about
emissions.  There are numerous products on the market that are sold for this
very reason, many CARB certified.  I've got a late model Firebird and own
two different programs for modifying the tables (complete reprogram as
opposed to simply changing parameters real-time).  There is several
horsepower and couple mpg to be gained with this.  You will have to be
careful though.  Depending on where you live and what laws you are trying to
meet.  California is a lot more strict on this for instance.

If you change parameters incorrectly SERIOUS damage can be done to the car.
Make sure you understand what you are doing before you start making changes.

Also, on some vehicles hooking into the OBD port will disable some
functionality of the on board computer.  This port is for debugging and some
computers can not handle the extra workload.  I don't know what kind of
affect it would have as a daily driven car to have a scanner hooked up.
This would probably be Make specific and I don't know much about Nissan.  My
scanner is never on for more than 1320 feet at a time.

Given all the warnings, there is a lot of information to be had from the
OBDII port.  It monitors nearly everything in the car from speed, gas
mileage, temperature (of more things than you realize), RPM, throttle
position, voltage levels,
It's a great single source of information if you want to know what's going
on in the car.

michael





{Original Message removed}

2003\09\08@171751 by

picon face
A little of-topic, but interesting anyway...

In Sweden there is currently an debate where the car
makers would like to save a "sliding window" (say 10 sec)
of history in the ECU. This values will be "frozen" whenever
the airbag is "blown".

Then you can read the history after a crash and answer
questions such as :
- Did the driver brake at all ?
- Was the throttle flat out ?
- Did the driver use the direction indicator before the crash ?

The "car owner organisations" is of course against this, they
are afraid that if it can be proven that the driver did *not*
breake (or whatever), that fact could be used in a trial.

Modern times...

Jan-Erik.

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu

2003\09\08@174218 by Michael Bishop

flavicon
face
Several manufacturers (Ford and GM) already have this and (at least) GM has
even been sued already.

I remember one store about a guy who was driving ~100 mph (160 kph) through
a residential area at night and plowed into a car that was backing out of a
driveway.  The guy said he was only doing <60 mph (100kph) and the
prosecutor wanted to pull the black box from the car for the case.

www-nrd.nhtsa.dot.gov/edr-site/uploads/USAToday--GM_sued_over_automob
ile_-black_boxes-.pdf



{Original Message removed}

2003\09\08@184155 by Herbert Graf

flavicon
face
> A little of-topic, but interesting anyway...
>
> In Sweden there is currently an debate where the car
> makers would like to save a "sliding window" (say 10 sec)
> of history in the ECU. This values will be "frozen" whenever
> the airbag is "blown".
>
> Then you can read the history after a crash and answer
> questions such as :
> - Did the driver brake at all ?
> - Was the throttle flat out ?
> - Did the driver use the direction indicator before the crash ?
>
> The "car owner organisations" is of course against this, they
> are afraid that if it can be proven that the driver did *not*
> breake (or whatever), that fact could be used in a trial.

       That's interesting, GM in NA (and a couple other manufacturers) have been
doing that for a while, I think the first GM car to have this sort of
monitoring was introduced in 1984. TTYL

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspamEraseMEmitvma.mit.edu

2003\09\09@082225 by Jai Dhar

flavicon
face
Great! I didn't know what kind of tolerance these sensors had (I knew the
PIC had a nice high impedance ADC, but with everything being so precise
these days, I was being safe :D), but that makes things all the easier. I
have obtained a Haynes manual on my car though, and it does talk about the
trouble codes associated with the OBD-II interface. These might help me
somewhat, and hopefully looking at the OBD-II book will shed some more
light. I will definitely get as much as I can directly from the sensors
though as it seems much easier at this point (providing I don't mess up the
existing circuitry!).

Thanks again, Jai.

> {Original Message removed}

2003\09\09@170130 by Igor Pokorny

flavicon
face
Hello Jai,

maybe looking at the site http://www.hondata.com helps you a bit.  I thought about
to get some information (consumption etc.) from ODB II port to my own board
computer but I am worried about not to lose a guaranty... Almost everything
is written to the ECU... :-(

Regards

Igor





{Original Message removed}

More... (looser matching)
- Last day of these posts
- In 2003 , 2004 only
- Today
- New search...