In-vehicle Datalogger part 8

Go To Last Post
70 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does somebody know if the project files are still available somewhere?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wow, it lives again :)

I built a partial prototype of the design you saw in all the PDF posts, and learned a few things ...

* Vehicle power is nasty. Needs lots of filtering to keep things smooth, and the A/D stuff even remotely clean.

* Optos weren't the best choice for interfacing - sometimes slow, not always clean. A better way is simple opamp buffers. Put them into schmidt trigger comparators if necessary to clean up the signal.

* The ADXL G sensor really needs a high-freq dampening mounting system in the car. You can do a lot of filtering in software, but I found that embedding the pcb in silicon foam (like data-center 19" rack door seals) and mounting the enclosure with shock-absorbing rubber tubes to work well.

* Keeping the analog portion clean is really tough on a single board. Vehicle electrical noise, digital noise etc, all contribute to jitter in the readings.

* Component tolerances can vary a lot. A lot. Either use 1% stuff, or correct in software (ugh).

* pcb layout is important, especially with regards to analog layout. Keep the GND planes clean, don't cross them, etc.

That all said, it does work. Not as well as I would have liked, but it do fly. I'm working (slowly) on a revised design. I have a couple of other projects to finish up first, but here's the gist of it :

Analog input moves to daughter board, and uses discrete A/D rather than AVR A/D. PCBs are cheap enough these days. The board will handle 16 inputs in 2 groups of 8 feeding into 2 A/D chips. The opamp buffer (programmable) will have 2 programmable DACs to set the low and high points of the range to be measured, rather than the jumper-selectable method I used before. Can have 2 boards in the system. Now can measure O2 sensors directly for example (50mV etc).

Still deciding as to whether to use a dedicated AVR for each board. I'm leaning towards that, as it allows the main micro to do more. Like ...

Video overlay output. Take in a video feed and overlay stats/data on the stream, then send it on out. Can also put synch marks on the video instead, to synch up a dataset with a video.

Lap-timer input. Put a high-intensity modulated IR beacon trackside, and an IR receiver in the datalogger. Trigger as you go by to get lap times.

Few more things here and there. Fear not, the MegaLogger thread will pick up again in the spring ! Part 9 here we come.

Dean.

Dean 94TT
"Life is just one damn thing after another" Elbert Hubbard (1856 - 1915)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Chancy99 wrote:
Wow, it lives again :)

I built a partial prototype of the design you saw in all the PDF posts, and learned a few things ...

Dean.

Apparently the pdfs where lost somewhere, because I couldn't find them.

Well, I suppose this thread was dead, as it last post was on 2002, but I tried and aparently it's back again!
In fact, I'm interested in interfacing my ECU, but I think I can get many ideas from your project.
For what I could read on all these posts, that's not the way you choose. Are you going to put sensors to measure all the parameters?
These could be an alternative to my project, if I can't get some ODBII info.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I also interested in this project.
But can not find any documentation.
Dean, could you point me to your documentation please.
regards,
irawan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll have to pull the PDFs together and post them again. It looks when the forum was switched over, the old links broke. I'm sure the files are still there, just not in the same places as the original links point to.

The only problem is that they will be one iteration behind - I took a disk crash before backing the latest design up to the server :( Thankfully the changes weren't major, the the newer layout was a royal pain. I'll describe them in more detail when I post.

The idea behind this project was/is to be generic. That is, not to depend on any specific sensors, or specific ECU, just to collect data. Analysis and understanding would come after the fact, on a PC with Excel or a custom app, playing with the raw data. For example, the ADXL data wasn't converted to G units - that's done on the PC.

I went this route after some digging into OBD - found out that most system could only log certain data, and even then only at slow rates. Most of the sensors one would want to watch all come into the ECU anyway, so why not tap in there ?

Some things require dedicated sensors though. For example, intercooler intake temp, intercooler exhaust/throttle body intake temp, individual EGT temps for each cylinder, spring compression rates. Things like this don't go to the ECU, but are valuable to track.

Hrm, if this is waking up again, it would be good to collect ideas, features, requirements and so on.

Dean.

Dean 94TT
"Life is just one damn thing after another" Elbert Hubbard (1856 - 1915)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Chancy99 wrote:
I'll have to pull the PDFs together and post them again. It looks when the forum was switched over, the old links broke. I'm sure the files are still there, just not in the same places as the original links point to.

Yes, I guess it was what happened.

Chancy99 wrote:

The idea behind this project was/is to be generic. That is, not to depend on any specific sensors, or specific ECU, just to collect data. Analysis and understanding would come after the fact, on a PC with Excel or a custom app, playing with the raw data. For example, the ADXL data wasn't converted to G units - that's done on the PC.

Well, it can´t be so difficult to dump some data on a little lcd, instead of or besides logging it.
I'm interested in showing some common info like RPM, speed, fuel consumption, temp, etc. Turbo info is not important now, as I don't have one in my car, but may be it's possible to add one later.
And I would like to log some info, specially when I go to the 1/4 mile track.
I'm not a runner, but I'm planning to take the car some day just to see how it goes...

Chancy99 wrote:

I went this route after some digging into OBD - found out that most system could only log certain data, and even then only at slow rates. Most of the sensors one would want to watch all come into the ECU anyway, so why not tap in there ?

You mean taking the signal *before* it enters the ECU?
Ups, I will have to get some info on the sensors my car has... Or perhaps I can get some info from the ECU manufacturer

Chancy99 wrote:

Some things require dedicated sensors though. For example, intercooler intake temp, intercooler exhaust/throttle body intake temp, individual EGT temps for each cylinder, spring compression rates. Things like this don't go to the ECU, but are valuable to track.

Hrm, if this is waking up again, it would be good to collect ideas, features, requirements and so on.

Dean.

Wow, I hadn't imagine you could measure spring compression rates...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lalo wrote:
Chancy99 wrote:

The idea behind this project was/is to be generic. That is, not to depend on any specific sensors, or specific ECU, just to collect data. Analysis and understanding would come after the fact, on a PC with Excel or a custom app, playing with the raw data. For example, the ADXL data wasn't converted to G units - that's done on the PC.

Well, it can´t be so difficult to dump some data on a little lcd, instead of or besides logging it.
I'm interested in showing some common info like RPM, speed, fuel consumption, temp, etc. Turbo info is not important now, as I don't have one in my car, but may be it's possible to add one later.
And I would like to log some info, specially when I go to the 1/4 mile track.
I'm not a runner, but I'm planning to take the car some day just to see how it goes...


Yup, LCD is no problem. I originally had a 4x40 LCD for status and monitoring. Though I would really like to use one of those nice 256x128 graphics displays :) Logging is to MMC card.

lalo wrote:
Chancy99 wrote:

I went this route after some digging into OBD - found out that most system could only log certain data, and even then only at slow rates. Most of the sensors one would want to watch all come into the ECU anyway, so why not tap in there ?

You mean taking the signal *before* it enters the ECU?
Ups, I will have to get some info on the sensors my car has... Or perhaps I can get some info from the ECU manufacturer

That's it exactly. I tap into the ECU harness, and just monitor all the interesting signals going in. When you see the specs, you'll see that the inputs are jumperable for 3 ranges. 0-12V, 0-5V and 5-12V. Those were the ranges we could find in the Supra.

lalo wrote:
Chancy99 wrote:

Some things require dedicated sensors though. For example, intercooler intake temp, intercooler exhaust/throttle body intake temp, individual EGT temps for each cylinder, spring compression rates. Things like this don't go to the ECU, but are valuable to track.

Wow, I hadn't imagine you could measure spring compression rates...


Yeah, there's a couple of ways to do it. Easiest, but mechanically kludgy, is to use a pot with a wheel on the axle and a lever on the lower spring perch. Kind of a like an RC servo, in reverse. As the wheel moves up and down, it turns the wheel, which changes the pot. A cooler way, which I haven't done, is to use the new Motorola field chip, to "sense" the change in the springs.

Dean.

Dean 94TT
"Life is just one damn thing after another" Elbert Hubbard (1856 - 1915)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We use string pots for shock displacement, little rotary potentiometers that have a string as the displacement measuring element. The string is spring loaded and rotates the pot as it is pulled or tension is released. On Toyota Atlantics they use rotary pots on the bellcranks. Most pro's use linear pots, the expensive kind look kind of like LVDTs, and attach them at both ends of the shock. Shock displacement is one of the biggies in data aq and worth getting sensors for.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Chancy99 wrote:

Yup, LCD is no problem. I originally had a 4x40 LCD for status and monitoring. Though I would really like to use one of those nice 256x128 graphics displays :) Logging is to MMC card.

Well, that's the final idea I have. I'll start with a character LCD, and in the mean time turn into a graphical one.

Chancy99 wrote:

That's it exactly. I tap into the ECU harness, and just monitor all the interesting signals going in. When you see the specs, you'll see that the inputs are jumperable for 3 ranges. 0-12V, 0-5V and 5-12V. Those were the ranges we could find in the Supra.

You mean your ECU specs?
I think that's the most difficult part, to match the values of your sensors to something human readable. I mean the sensors aren't probably linear, or may be affected by heat or something. I don't know.
I will try to find some info on mi ECU inputs.

Chancy99 wrote:

Yeah, there's a couple of ways to do it. Easiest, but mechanically kludgy, is to use a pot with a wheel on the axle and a lever on the lower spring perch. Kind of a like an RC servo, in reverse. As the wheel moves up and down, it turns the wheel, which changes the pot. A cooler way, which I haven't done, is to use the new Motorola field chip, to "sense" the change in the springs.

Interesting, I won't need it, but I'll try to get some info about.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Dean,

interesting project - I am developing nearly the same but for out-vehicle-use on the basis of the microPDA from promedox.

I am using the ADXL 213 - see AD support recommendation below:

"I would not recommend the (old) ADXL202 any more.
If you still want a PWM output, the ADXL213 is a good choice.

It is pin compatible with the ADXL202E.
The scale factor is higher (30%/g versus 12.5%/g for the ADXL202), but this is easily resolvable in software.
The zero g bias tempco is generally about 10 times lower than the ADXL202 and the price is similar."

On the other hand the ADXL 203 seems to be the best (depending on your application surely, but in any case if you want to measure tilt also).

Regarding the graphics the the 128*64 transflective display seems to be enough for most purposes - transflective is very important I guess also with in-vehicle use.

ESD / EMC - you should consider that in-car applications are tested at field-strenghts of up to 280 V/m (at least in Germany...) so you should carefully design PCB, case and I/Os unless you do not have to rely on your logger.

Regarding the MMC interface I am using the direct write to the card but I heard that Promedox is developing a fat lib for theire microPDA. Do you have any experiences with commercial or non-commercial fat libs?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Bike -

I didn't have any real problems with ESD at all. Very occasionally it would do a reset, but in general it was fine. This was the prototype original PCB I made back when ...

That microPDA looks very nice :) Lots easier than soldering my own M128 ... I used the Procyon MMC fat driver code - works well.

Be sure to keep us posted on how your project comes along !

Dean 94TT
"Life is just one damn thing after another" Elbert Hubbard (1856 - 1915)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Chancy99,

the Procyon code looks interesting - I´ll try to use it. Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Chancy99 wrote:
When you see the specs, you'll see that the inputs are jumperable for 3 ranges. 0-12V, 0-5V and 5-12V.

What method do you use to scale the input signal down.. for the ADC's, if you're sampling 0-12v?

Cheers.

Phil.

"If they did that in Manchester, they'd be chinned"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey ho,
i am building a similar construction like this logger but som simplified when i found this thread(s).
And i would like to see how you solved schematics and board layout, but i can't find any somewhere, is it still awailable somewhere?

Best regards Jag

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've been playing around with the Sparkfun (www.sparkfun.com) logomatic board. Whilst it doesn't use an avr (having more than 4k in a mega128), it is a fairly cheap board. I've tacked on a three axis accelerometer board (also from Sparkfun) and are playing around with the datalogging to mmc card. Using a x60 SD card, I'm getting around 150kbytes/s write speed. However, using a filesystem, the data rate drops dramatically. So, I'm looking at doing a fudge where the datalogging writes directly to the sectors on the MMC/SD card and fixes up the directory information when it is finished so you can read the file on a PC. I'm also pondering the various data rates of logging on each channel. 200hz on 8 channels is easily achieved, but logging slowly moving inputs like temperature seems a little wasteful, but a 1Gig card stores a LOT of data even at 8x200hz and in a comma delimited format. Makes for some large spreadsheets!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
I'm getting around 150kbytes/s write speed. However, using a filesystem, the data rate drops dramatically. So, I'm looking at doing a fudge where the datalogging writes directly to the sectors on the MMC/SD card and fixes up the directory information when it is finished so you can read the file on a PC.

You could always strap a "start" header before you start logging and then and EOF (End of File) Marker at the end.. no filesystem needed.. As long as you remember where you stopped you can then write a new header and start again etc... Then, like you mentioned, when reading back you'll have to read the whole lot back and get the PC to process the "headers" and split the file stream up... It'll be very much like writing to magnetic tape from a unix box.. your header only needs to be some "magic" byte combo with a preset field.. such as File Number or something so when you split it up later on you can keep the order.. even then you could probably get away without that since you'll be reading it back from the beginning to the end...

"If they did that in Manchester, they'd be chinned"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

pquinton - being able to pull the card out and having the PC read it directly makes things easier all round. What kills you in performance with a filesystem is the need to find the next cluster every 32 or so sectors (depends on cluster size). Assuming you have a freshly formatted card, the clusters should be sequential, so therefore you only need to open the file, create the directory entry and get the starting cluster. Then you can write sequential sectors from that point. You have to keep track of how many sectors you're writtten then to closethe file, you need to allocate all the used clusters in the FAT table and close off the directory. Just a little more work before and after the data log. You could also have the PC write one file the size of the card and fill it with 0xff's. Your logger code could then find the first cluster and start writing and do the SOF/EOF as you describe.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Your logger code could then find the first cluster and start writing and do the SOF/EOF as you describe.

My knowledge of SD/MMC is sketchy.. Can't you write in memory mode like a CF Card?... I suppose the hardest part is getting the PC to access the card without expecting a Filesystem on there (if you are going to write memory location by memory location). The other way is to, as you say, get the logger to do the re-packaging and send it over the serial link (slow)...

Phil.

"If they did that in Manchester, they'd be chinned"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

psquinton, you can do random sector writes to a mmc/sd card just like a CF card. Yes, getting the PC to access the card on a sector level is not that hard, but something I'd like to avoid. With the amount of data involved, sending via a serial link (other than USB) is not an option!

Pages