• Hello Guest, welcome to the initial stages of our new platform!
    You can find some additional information about where we are in the process of migrating the board and setting up our new software here

    Thank you for being a part of our community!

Arduino LH Jetronic interface: live data + MicroSD logging + ELM327

I can completely identify with that.... I wish I had the spare time to learn the skills to be more help, or certain younger family members who were old enough for me to bribe into helping.... but that's still some years away.
 
TLDR: come back in a few days to a week. I'm hoping to have my first real LH2.4 log very soon.

Wow, just over 3 months since getting prototype boards back from China and I still haven't generated an actual in-car log, but I'm getting close. Work's been unexpectedly busy and, after long days in front of a computer, I really haven't felt like doing the programming for the logger in the evenings. Although slow, there has been some good progress.

The hardware seems fine except for what I think is a damaged MAP sensor. I've been holding off ordering a replacement until I accumulate a bigger order's worth of parts.

I've written the core interrupt driven measurement routines and they're working OK on the benchtop. I have some additional tuning and tweaking to do to clean up the interrupt jitter as best as possible. I haven't written anything yet for the the tuner studio serial protocol (also used by MSdroid), nor for bluetooth wireless.

Here's what the ECU / EZK / Logger wiring harness looks like with the logger black box. I'm using DB-9 connectors to make it easy to install/un-install. (click pics for full size)


Soldering the wires onto the EZK/ECU internal connectors seems like the easiest way to tap off the signals. Most of the wires are easy enough to solder, but the two inner/lower row ECU pins are a PITA to get to with my eyesight&nerves.


Currently, I'm dumping the measurements over the serial/usb port to a log file. I then massage the log file to a suitable .csv format so that it can be opened with MegaLogViewer. Here's a short benchtop example. For now, there is no software filtering on any of the sensors. Some of the fuzz/noise is due to the Arduino interrupt latency variation, but some of it looks like low speed resolution issues.
LH-Monitor-benchtop-MLV.png


Next up is to try it in the wagon and see if the logged values and graphs seem reasonable. After that is software changes to reduce the measurement noise/jitter, and figuring out the tuner studio/MSdroid serial protocol for realtime dashboard display and easier logging.

-Bob
 
Sorry, I'm experiencing technical difficulties. MS TrustedInstaller royally trashed my old laptop. R.I.P. Samsung NB30. I have a new laptop on order. Once it arrives, I figure ~4 hours to get it setup and get rid of all the pre-packaged crap, and maybe then I can actually dump a real log while driving.
 
Bob's Drive to Work and Back

It lives! :cool:




https://www.dropbox.com/sh/bjr74pnngq45t82/AAA6prATLvTM4l3rL6mkEgPma?dl=0

So many questions and so many things to investigate.... I don't know where to start.

For a quick walk through of the logs, bring up MLV and clear all the panes. Then setup a couple basic reference items in one pane, such as MPH and IDLE. In a second pane, click the drop-down button to select an item, and then use the keyboard up and down arrows to walk through the logged items one at a time.

Fine print: The logs are full speed with almost no filtering/averaging. They were created via a serial port dump (PuTTY) and then massaged in a spreadsheet. The noise is most likely interrupt latency jitter (which I'm hoping to improve). The MAP sensor is suspect, and ambient in Boulder is ~84kPa. The CLT values are the raw ADC conversions. I'll see if I can rescale them to degF and replace the logs. I trimmed off the initial startup entries because spark advance was going negative (ATDC) and screwing up the graphs, plus weird things were going on with IAC, Load, and Dwell. Oh, yeah, it's a factory '937 ECU and '148 EZK.

Feel free to post MLV screenshots and comments or questions. (And yes, I was granny driving because I wanted to check the VSS to MPH conversion accuracy, plus I wanted fairly stable conditions for the initial logs.)

-Bob
 
Last edited:
I'm still here paying attention, even bought myself a Leonardo few months ago. But it seems like something weird has happened to this thread. When I get to the "aftermarket engine management" section I can't find a link to this thread anymore.... maybe it's just me. I only find my way back because I have it bookmarked......
 
Yeah, it's slowly making progress. I've been running over bluetooth for a while now, both to a laptop PC and, more recently, to my Moto Droid phone. Happily, it's still running at full speed when just dumping to a log file.

There's a long list of little things I need to fix in the firmware, and I haven't tried to add support for MSdroid or Tuner Studio yet. Looks like this has become a good Winter time project.

-Bob

P.S. does the dropbox link work for you, and can you bring up the examples in MegaLogViewer?
 
yes the dropbox links seem to be working, I don't have MegaLogViewer, though I did go look at their website when you first posted, I need to go back and look at their offerings again.

Interestingly the link to this thread is showing up in "aftermarket engine management" again.

OK I installed the Lite version which is data limited, and I can load part of the sample files, which seems to work fine, so that's a start....
 
Last edited:
Oh, I forgot that the Lite version of MLV was file size limited (I'm running the basic paid version). The .msl log files are just plain text format spreadsheet CSV data. You can edit them with notepad or wordpad and cut out big sections to get them down to size. Just leave the first few header rows alone. The first column is time in seconds since starting the car. [And I see that I screwed up the calculated boost in the last column - another thing to fix in the next round.]

I'll try to put up some more recent bluetooth logs later this weekend. I'll also include a lower resolution log that you should be able to view completely with the Lite version (not everyone needs to see every spark over a 25minute commute).
 
Well it's been a long time, but I just wanted to say I'm still interested in this project, regrettably I still don't have the programing/signal conditioning skills to contribute.
 
How time flies! I thought I'd updated this thread late last year, but it looks like it was late 2021, or maybe the update got lost with the migration to XenForo?

I'm continuing to make slow progress on this project. I'm now running with TunerStudio to a laptop PC, using either USB or Bluetooth serial, and am running on my Android phone with ShadowDash over Bluetooth:
ShadowDashExampleScreenshot.png
(I was also running on my phone with MSdroid, but MSdroid is no longer supported and can no longer be installed successfully on new devices.)

Neither TunerStudio nor ShadowDash can keep up with full frame rate, currently, one frame per engine stroke. Directly dumping text to a log file over Bluetooth Serial works fine at full rate with no dropped frames. I'm going to rewrite my code to generate a single frame containing all 4 strokes, which will reduce the rate by a factor of 4. Even with this, I may need to add some speed dependent multi-frame averaging so that TS/SD can keep up. Or I'll just live with a high drop rate at higher rpms, which seems to be what everyone else does.

To get ShadowDash to work, I needed to impersonate a different device and needed to side-load a custom .ini file. There are also some intermittent ShadowDash connectivity problems that I need to chase down. Once I figure out the source of these problems, my code or the SD code, I'll contact the SD developer to see if there's a way to add a non-supported logging device more cleanly.

On the hardware side, I need to do a 2nd version of the main logger PCB to fit into a smaller box, and to use a soldered down Arduino Micro instead of the pin & header connected Leonardo. I may also change to dual RJ-45 (ethernet) connectors, instead of the DB-15, so that the external logger box to ECU and EZK wiring is a little easier. With this, you'd chop a standard ethernet cable in half, and then solder each set of 8 wires to the main connectors inside the ECU/EZK boxes. With the current DB-15, you need to do DB-15 to dual DB-9's, and then the DB-9's to the ECU/EZK pins (or ~4x the connections).

I also need to do an initial prototype PCB for the LCD dashboard display. This will fit behind a standard Volvo 240 2.75"x3" dashboard single-gauge blanking plate. I'll include provisions for a CANbus adapter so that it can also be used with a MegaSquirt/MicroSquirt running dashboard broadcasting over CAN.

On the plus side, I gave notice late last year that I'm retiring in 2023 - I just finished my last 3 months of full time, and am now 3days a week through ~September. This should give me a little more free time for this, and all the other languishing projects, but I need to finish my taxes first (ugh!).

-Bob
 
Before I do my next batch of PCBs, I wanted to figure out a reasonable way of providing some circuit protection for automotive stress conditions. I thought this would be straight forward, but ended up being a can of worms and taking many hours of surfing and reading to understand the options and tradeoffs. For anyone else looking at power supply protection circuits, the following links will be helpful:

App Notes:
https://www.analog.com/en/technical...nal-approaches-in-automotive-electronics.html
Really great overview! Maxim App Note, now Analog Devices (from 2008)

https://www.analog.com/en/analog-di...ctronics-systems-with-no-switching-noise.html
Newer ADI app note with different topologies for higher efficiency (from 2020)

Example ECU Designs:
rusefi frankenso v0.5.6 topology: fuse - active clamp - switcher
power supply design thread: https://rusefi.com/forum/viewtopic.php?f=4&t=394&start=90
repository: https://github.com/rusefi/rusefi-hardware/tree/main/classic-designs/frankenso
schematics: https://raw.githubusercontent.com/r...sic-designs/frankenso/frankenso_schematic.pdf (pg. 9)
bom: https://raw.githubusercontent.com/r...lassic-designs/frankenso/frankenso_by-ref.csv
pcb design guidelines: https://wiki.rusefi.com/PCB-Design-Rules/
hardware guidelines: https://wiki.rusefi.com/Dev-Hardware-Guidelines/

rusefi helen-one topology: TVS - fuse - schottky - switcher
repository: https://github.com/rusefi/hellen-one
schematics: https://raw.githubusercontent.com/rusefi/hellen-one/master/modules/power12/0.2/power12-schematic.pdf
https://raw.githubusercontent.com/rusefi/hellen-one/master/modules/power5/0.2/power5-schematic.pdf

rusefi proteus topology: TVS - schottky - switcher
repository: https://github.com/rusefi/proteus
schematics: https://raw.githubusercontent.com/rusefi/proteus/master/export/v0.7/proteus_0_7_schematic.pdf (pg. 9)

megasquirt v3.57 topology: VAR - negative zener clamp - diode - positive zener clamp - LDO
schematics: http://www.msextra.com/doc/pdf/MS2V357_Hardware-3.4.pdf (appendix A pg. 171)

microsquirt v3 topology: MOV - diode - positive zener clamp - LDO
schematics: http://www.msextra.com/doc/pdf/Microsquirt_Hardware-3.4.pdf (appendix A pg. 145)

speeduino v0.4.3 (thru hole) topology: schottky - TVS - LDO [note: current BOM uses different LDO]
repository: https://github.com/speeduino/Hardware
schematics: https://raw.githubusercontent.com/speeduino/Hardware/main/v0.4/THT/Latest/v0.4.3d.pdf (pg. 4)
bom: https://github.com/speeduino/Hardware/raw/main/v0.4/THT/Latest/v0.4.3d BOM.xlsx
older power supply design thread: https://speeduino.com/forum/viewtopic.php?f=14&t=2&p=268

eevblog thread:
https://www.eevblog.com/forum/eda/tvs-diode-layout-considerations-for-automotive-application/
Good commentary on diode - fuse - TVS - regulator design considerations (from 2018)

Bob's best guess Guidelines: (subject to change!)
- Load dump is rare and hard to handle. There was a comment somewhere that OEM ECUs may only survive a lifetime total of 2 or 3 max load dump events. I'm not sure if the LH 2.4 ECU or EZK boxes even have any load dump protection.
- If the TVS is before the inline diode, it must be bi-directional or else something will smoke during reverse voltage (VAR/MOV are all bi-directional).
- If the inline diode is before the TVS/VAR/MOV, it needs a big reverse breakdown voltage to handle -150V noise spikes (mostly a problem for schottky diodes)
- The regulators and capacitors downstream of the TVS/VAR/MOV need to be rated for the max Vclamp voltage of the TVS/VAR/MOV.
- The minimum TVS/VAR/MOV conducting voltage needs to be higher than the double-battery jumpstart voltage.
- I'm ignoring cold cranking voltage drop issues since my logger and auxiliary gauge can drop out briefly without safety concerns.
- Use 50mil traces up to the TVS/VAR/MOV (load dump is ~100V pulse decaying over ~400ms, but the alternator, wiring, and trace resistances filter this down).
- If I understand this stuff correctly, there are problems in the speeduino and rusefi helen-one/proteus designs. Megasquirt/microsquirt look OK.
 
Everything I said in my previous post still applies. Regrettably that still means I have no useful skills in programing or circuit design to contribute. My quick read of Load Dump would suggest that any electronic FI system ever in production must have some sort of protection. Bosch LH should, or might be more tolerant than modern ECUs due to the older technology involved.

Regardless I'm happy to see you still have been able to devote some time to this project. Maybe ChatGPT can help write some code.
 
Hello everybody, I'm still alive but last two years I spent most of my free time searching for a good old RWD Volvo (240, 740 or 940 estate) for my dad and working on the 940 turbo that he bought on February 2022. His Volvo seems today a brand new one also if some minor task must be completed yet. Furthermore this year I have a long list of maintanance jobs to do on my 940 (clutch, pneumatic climate actuator, timing belt, cooling radiator + pump + fluid replacement, valve clearance check and adjustment, trottle cleaning, check fuel level sensor that sometimes doesn't work as exprected, brake fluid replacement, engine oil plus filter....) and I believe that my project will have to wait for many many other months... but before suspending it I had rewired all the circuit replacing the optocouplers with spike snubbers accepting the suggestions you made me as you can see in this picture.

For the power supply I had bought a LM2596S and I don't think to add any particular protection for load dump problems, I'm only in doubt for the need to add a circuit for polarity inversion protection but I think that it will be useless in my case since the boad will be connected to the car using only the DB-25 connector of my breakout box (I don't plan to make any flying wiring connection)

I hope to get more free time in the future since I would like to finish my project and see it in action on the car and not only on my desk simulating signals.
Especially the ability to caputer analog signals and save them on a file could transform this fun project into a useful diagnostic device (in other words, an analog datalogger).



20230415_163450.jpg
 
Last week, I left $80 for the PCBoard fairy and today this showed up :cool:
jlcpcb proto0.1 072123.jpg

It's 20 prototype LCD MultiGauge boards, designed to fit behind a 240 dashboard blanking plate, with CAN bus or I2C support. It will take me a bit to bring them up and get the initial code running. I'll probably do CAN bus for MicroSquirt first. I'll post some more pics once the first one is put together and running some basic graphics.

 
Great work bob, my arduino project has been suspended and it is still paused but i've invested my free time in two other interesting projects that I think to be more useful at the moment (a maf diagnostic and a recalibration device plus an injector cleaning and testing bench)
I took a brief look to your circuit and I whoul ask you why you didn' t added a couple of bigger capacitors on the input and the output side of the voltage regulator.
I had to make a similar circuit to get a lower voltage from Vbat and drive an op-amp and I put a 470uF electrolitic 25V at the input and another 47uF electrolitic 16V at the output, each one in parallel to the respective polypropilene 0.33uF and 0.1uF that you can find on the datasheet of the LM78L0x
I think they could filter better the noise and the spikes and help to keep the voltage stable (may be I'm wrong, that's why I ask you this)
 
^^^ Looks similar enough to the MegaSquirt stuff, except there's more of it, and some of it is running at 50Hz (versus the default 20Hz MS update rate). Wanna pick 15 or 20 of those values of interest?

I've got the basic MicroSquirt CAN dash broadcasting working now. I need to setup more screens, get the pushbuttons working for screen selection / display dimming, and figure out what to do with the painfully bright blue LED. I also need to see if I can make a jig to drill/cutout the 240 bezel so that it all looks nice.

Pretty soon, I'll hopefully be looking for someone with a MegaSquirted 240 and some Arduino experience to be a guinea pig and try it out.
MultiGauge CANbus 072623.JPG
 
I meant to update this tread weeks ago, but my dash pictures were awful. I tried to get some better pictures yesterday, but they're still not great.

So, the MultiGauge and Logger are finally working together in my '85 GLT. I'm pretty happy with the results, but ran into a couple issues that I'll need to figure out. This is why we do prototypes.

Here's a picture of the parts for the MultiGauge, and the assembled gauge. In my car, it's running an I2C cable to the logger. I have the similar CANbus version working on my benchtop with a MicroSquirt and a JimStim.
MultiGauge Parts Assy.jpg

And here's the driver's view of the gauge, with a few of the different screens on the right:
MultiGauge Screens.jpg

I ran into two big issues with the prototype. First off, I'm almost out of Arduino Micro code space on the MultiGauge, so no room for SD card logging, or GPS, or better fonts (the current font is the default 5x7 font, which becomes ugly when upscaled). I'm looking at this Adafruit RP2040 with CANbus as an alternative processor (way faster, lots of memory, with CANbus, and easier to update code without needing the Arduino environment).

I never expected, or even considered, the other big issue. With my polarized sunglasses on, the gauge becomes very hard to see and has red/green shift. If I rotate the gauge, or my sunglasses, it's much better in some positions. I think the LCD I'm using was designed for Portrait mode orientation, and I'm using it in Landscape mode (this isn't spec'd anywhere I could find).

As a sanity check, I tried rotating my sunglasses when looking at the center display in my newish Subaru DD, and it goes completely blank when my sunglasses are at 90degrees. Guess I'm reading up on LCD polarization, and standard setup for glasses, gauges, window glass. I'm looking for alternative LCDs, or at changing it to Portrait mode.
 
Can I just say this is so freaking cool. I love this community! I would be in line for a plug and play version if it ever comes to life as this is way above my current time investment level.
 
Back
Top