I have built an in-dash head unit graphical mpguino display

[t vago]

Originally Posted by skybolt

Excellent work. I always thought the original code was very ham-fisted.

MPGuino was (and is) a very good idea, and the original author was really ambitious, with regard to his programming skills.

Originally Posted by skybolt

Are you grabbing both 0-30 and 0-60? I originally had it 0-speed, where speed was configurable as a parameter. Catching both removes the need for a parameter -- the only edge case I can think of is calculating 0-100, which I wouldn't even do. I assume for metric you're taking 0-50kph and 0-100kph, which are typically the values quoted by manufacturers.

I take the parameterized speed value, convert it into a cycle time value equivalent to the speed, then mulitiply that by two to get the cycle time equivalent to 1/2 of the speed. I do something similar to obtain the 1/4 mile equivalent VSS pulse count. These values are used by the accel test function as checkpoints.

Yah, I have both the speed and the distance figures parameterized, mainly because I'm lazy about having to code for separate metric and SAE calculations, and parameterization makes it really easy to convert between SAE and metric. However, removing those two parameters may be better in terms of freeing up EEPROM space. I still have yet to come up with a decent SWEET64 routine that calculates estimated engine power, so I may just re-write my existing accel test functions to remove the parameterization.

Originally Posted by skybolt

I still haven't created a working mpguignio shield (car-to-duino interface, basically two resistors and two zener diodes, with a voltage regulator for full compatibility). Once I've figured out how I messed up so simple a design I'll start in-car testing. My other choice is to simply overwrite my production MPiGuino, but it's a pain to deploy code to that one given the short wires involved, and there are benefits to having a dedicated dev mule that can be hooked up to the car.

I know what you mean. I have my production MPGuino installed in the Magnum, and while it does have a ISP header on it, I still have to take it out and hook it up to a power supply in the house, then use my computer to program it. Meanwhile, I have both an AtMega2560 and a TinkerKit LCD module that serve as development platforms.

Originally Posted by skybolt

Only catching instantaneous at the 1/4 mile causes a problem -- many ecomodders won't keep accelerating all the way to 1/4 mile, nor do I when the 1/4 mile time approaches 100mph and I'm testing on a freeway on-ramp. 0-60 is relatively safe and perfectly legal (in a 60mph zone). We don't want to capture end speed if it's less than maximum speed during the run. I'd originally solved this by taking updating trap_speed with MAX(speed, trap_speed), but as I recall you terminate the run when the speed begins to drop.

Actually, the accel test function cancels on speed only when speed drops down to zero and stays at zero for 1/2 a second. The accel test function also cancels when it senses the engine is no longer running, or if the user cancels the accel test.

The code is not sophisticated enough to detect momentary dips in vehicle speed.

Originally Posted by skybolt

Once I have in-car testing running I will report. Slow shifting in particular can cause a loss of at least 1 mph. I expect to be able to cobble together, today, a breadboard version of a working car-to-duino interface. I've already verified I can push JSON from the new code to my in-car display unit, so in-car testing will be very full-featured.

Cool! Looking forward to seeing more video of your display. I am thinking of adding something like that to my truck, using a rear view mirror with a built-in backup camera screen.

I just hunted down two very subtle bugs that I think got exposed when I did some of my major re-writing to support using JSON as a primary output (such as for editing parameters). One of them caused the primary LCD screen to quit updating upon meeting certain input conditions, and the other caused the big number display to not output correctly. Hopefully, will have the estimated power routine written. Will also have to provide a modified time function that outputs in 1/10 seconds, but that should be very easy to code.

[skybolt]

so I may just re-write my existing accel test functions to remove the parameterization.

Please don't! I thought you did something silly and hard-code it --- if the parameters are there, please leave them!

I know what you mean. I have my production MPGuino installed in the Magnum,

Do you have a double DIN unit in the Magnum? Head units with video in can be had cheaply these days ...

The accel test function also cancels when it senses the engine is no longer running, or if the user cancels the accel test.

That's good, but I consider that a side issue. Today I can do a 1/4 mile run, and stop accelerating at 60, then slow down, to say 30 or so. Then my 1/4 trap speed is shown as 30, which isn't the value one wants to capture for a 1/4 mile run. So, I used a max(current_speed, updated_speed) and the 1/4 mile trap speed would always be the highest speed obtained in the run. There are other options, but they'd be conditional and the function would quickly get more complex than is worth the effort.

Cool! Looking forward to seeing more video of your display. I am thinking of adding something like that to my truck, using a rear view mirror with a built-in backup camera screen.

Awesome! Do you have a raspberry pi to run the output? Really it can be anything that runs a web browser. This will force me to address the one remaining bug in the javascript code.

I just hunted down two very subtle bugs that I think got exposed

I can verify the first bug repros on my hardware. I simply unplugged to work around it.

[skybolt]

The Parallax serial LCD is emerging as the display with the smallest pin requirement, meaning it's the odds-on favorite for permanent deployment (inserting it temporarily for programming). There are two alternatives for having two tx pins:

1. Hardware. Obviously the mega can do this, but the mega isn't optimized for deployment. There may be another small board with 2 serial ports (such as the micro), but I haven't found it yet.

2. Software: There's a set of libraries called Software Serial, but since most of the community is complaining about the performance -- so I can only imagine how you feel about it. To me it sounds like a non-starter.

Third alternative would be a different LCD module, one that supports communications on a single pin via an interface other than serial. OsePP, Adafruit and others make them. They all use their own custom libraries which may or may not be optimized, so this also might be a non-starter.

What are your thoughts?

[t vago]

Originally Posted by skybolt

Please don't! I thought you did something silly and hard-code it --- if the parameters are there, please leave them!

Okay, they're left in there as parameters. Makes it easier for me, too.

Originally Posted by skybolt

Do you have a double DIN unit in the Magnum? Head units with video in can be had cheaply these days ...

No, but I do have a double din center console trimplate floating around. Might could go double din, but I think I'd also need some sort of plastic support thingy for the radio case. Ah, no biggie. If I could stuff a 6-speed into my Magnum, a double din radio should be child's play.

Both my Dakota and my Durango would probably receive a rearview mirror with one of them video screens built into it, as the cost associated with stuffing a double din radio into either of them would make it unpopular with my wife.

Originally Posted by skybolt

That's good, but I consider that a side issue. Today I can do a 1/4 mile run, and stop accelerating at 60, then slow down, to say 30 or so. Then my 1/4 trap speed is shown as 30, which isn't the value one wants to capture for a 1/4 mile run. So, I used a max(current_speed, updated_speed) and the 1/4 mile trap speed would always be the highest speed obtained in the run. There are other options, but they'd be conditional and the function would quickly get more complex than is worth the effort.

Hm... I could set up to obtain the maximum attained speed, rather than the speed when the accel test finishes. That would not take up very much more code.

Originally Posted by skybolt

Awesome! Do you have a raspberry pi to run the output? Really it can be anything that runs a web browser. This will force me to address the one remaining bug in the javascript code.

I'd have to buy a Raspberry Pi, as well as a TWI LCD module (see below). Not a big deal. I do currently have a Beaglebone Black, but it has HDMI output instead of composite video.

Originally Posted by skybolt

The Parallax serial LCD is emerging as the display with the smallest pin requirement, meaning it's the odds-on favorite for permanent deployment (inserting it temporarily for programming). There are two alternatives for having two tx pins:

1. Hardware. Obviously the mega can do this, but the mega isn't optimized for deployment. There may be another small board with 2 serial ports (such as the micro), but I haven't found it yet.

This would be a non-starter. The AtMega2560, while having gobs of EEPROM and RAM, is limited by its lack of built-in USB support, and any chip with built-in USB support will not have UART serial support. (that's kind of dumb, but that's just my opinion).

Originally Posted by skybolt

2. Software: There's a set of libraries called Software Serial, but since most of the community is complaining about the performance -- so I can only imagine how you feel about it. To me it sounds like a non-starter.

Well, I could incorporate SoftwareSerial into the MPGuino code I have now. Or, I could deliberately and repeatedly smack my thumb, as hard as I could, with a 5 lb sledgehammer. Let me think about it for a bit, and I'll get back to you on what I would decide to do...

Originally Posted by skybolt

Third alternative would be a different LCD module, one that supports communications on a single pin via an interface other than serial. OsePP, Adafruit and others make them. They all use their own custom libraries which may or may not be optimized, so this also might be a non-starter.

Actually, this is the most likely way forward. I've been meaning to code in I2C/TWI support, as it should be about as simple as the UART serial code already in place. That way, I can add in the battery-backed clock module support that I had promised over two years ago - that is also TWI-based.

This would be the way forward. TWI for the LCD display, and the existing UART serial port for the JSON output.

[skybolt]

I'd have to buy a Raspberry Pi, as well as a TWI LCD module (see below). Not a big deal. I do currently have a Beaglebone Black, but it has HDMI output instead of composite video.

''

I think I saw in your code somewhere you were pulling data from what looked like a Mac usb port (/dev/ttS-usb-1433...). Any laptop will work. The python script that writes the json file is laughably simple. Don't run it in Chrome, as Chrome correctly refuses to let web-page javascript to read a local text file. Firefox has no trouble with it.

This would be the way forward. TWI for the LCD display, and the existing UART serial port for the JSON output.

Excellent!

[josemapiro]

Hi skybolt and t vago
When we can see a video with this project working.
I see that it uses an LCD display that has touch, the touch will also work, or it will be turned off.
As you know there are many LCD displays with various sizes and resolutions, this design will be exclusively for one type of display, or allow adjustment for other displays.

Thank you congratulations for the project and a happy new year.
José Rodrigues

[skybolt]

I'll reply in more detail, but basically:

- I have a replicatable mpguino shield working with the Mega, in the car.
- josemapiro: the GUI works with any unix/linux computer that can read serial input. It even works on my mac! In theory there's no reason it couldn't use windows as long as python runs on it and I can figure out the syntax of reading from a serial port. The example is a raspberry pi and a small attached screen, but the goal is to use video output and show it over the head unit or other built in video screen in the car.
- I have a workaround for the scale bug, and have isolated the bug but haven't fixed it
- next step for me is to duplicate the shield in soldered form, get the code to run on a pro micro, properly (given the 8MHz clock speed).
- I'm seeing anomalous readings in the Mega, which is probably just because I don't understand all the parameters and how they affect calculations. (injector PSI for example). On the mega readings are about 5-10% too low (classic mpguinio reads about .42 gph at a idle, Mega reads about .39 gph.
- No matter what I do to reset the Mega's trip and current, my tank miles stays at 8.8. Will do further experiments in house (not in car) and it will be easier to start investigating.

[josemapiro]

Hi Skybolt
It seems interesting but complicated, you have to use two cards more the video system of the car, which I suppose is the car radio with android or windows.
It would not be easier to create an application for andrioid or windows and to make the bluetooth connection of arduino to the radio.

Thanks
José Rodrigues

[skybolt]

Originally Posted by josemapiro

Hi Skybolt
It seems interesting but complicated, you have to use two cards more the video system of the car, which I suppose is the car radio with android or windows.
It would not be easier to create an application for andrioid or windows and to make the bluetooth connection of arduino to the radio.

Thanks
José Rodrigues

I chose video out because it was the simplest, easiest way to display the output. The Raspberry Pi cannot replace the arduino, as a raspberry pi isn't a real-time processor and cannot be guaranteed to measure each speedometer tick or fuel injection pulse, not to mention that no measurements would take place during a boot process.

On the other hand, the arduino is very, very limited it its ability to display video. As hard as I tried, I was only able to get limited text, which rapidly exhausted the available memory necessary to run the aquino routines that measured fuel and speed pulses.

The combination of a raspberry pi and arduino can be made very, very small. I originally used a raspberry pi zero which is very small and can be attached to an mpguino with electrical tape. I chose a raspi 3 because I preferred the video performance. With a slightly larger raspberry pi I can mount a much tinier arduino pro mini, which is about the size of two quarters.

You aren't required to display this on a head-unit, but should you prefer to do so, you simply plug the raspberry pi video out to an open video port on your stereo. If you want to use an embedded screen like in my example, you can do that instead. It's very flexible and not limited to a single hardware architecture.

I can't continue work on miniaturizing the arduino and attaching it to the pi until I create the car interface board that are already on MPGuino boards -- the resistors, capacitors, diodes and voltage regulator. Once I've done that (and I have a working breadboard version, so I should be able to do this part shortly), I can start in on putting the new code base on a Pro Micro, and you should be able to use any display type you want.

Truth be told, hooking the mpguino up to your car is going to be a lot more difficult than attaching a video cable to your head unit, even when you factor in supplying power to the raspberry pi.

[skybolt]

Quick GIF of head unit