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

[skybolt]

On one of my arduinos, this is the JSON output:

[{"title":"fuel used 0.000 gal/0.000 gal/0.000 gal/hr",
"subtitle":"fumes remaining, 18.000 gal e-reserve",
"ranges":[18.000,4287116.976,7868.320],
"measures":[0.000,18.000],
"markers":[0.000]},

{"title":"distance 0.73 mi/1.26 mi",
"subtitle":"0.00 mi to E, ---------- mi e-reserve, 4294967.30 mi safe range, 4294967.30 mi dry range",
"ranges":[4294967.3,4294967.3,2147483.6],
"measures":[----------],
"markers":[----------]},

{"title":"fuel economy 4294967.295 MPG",
"subtitle":"drag stats: 0-30 MPH in 0.000 sec, 0-60 MPH in 0.000 sec, 0.000 sec to 0.000 mi @ 0.000 MPH, engine output 0.000 HP @ 0.000 MPH",
"ranges":[110930.553,166395.830,277326.383],
"measures":[----------,----------,4294967.295],
"markers":[4294967.295]}]

Note the "--------------"

Since this appears only on my new arduino, I suspect it's because I have not run the setup routine, and some some parameters are resulting in calculations returning invalid values, which then return "---------".

I recommend returning a valid number for calculation errors. Blank will also work, however a JSON field with comma-delimited blanks will not work, so "measures":[,,4294967.295] is invalid and will result in a blank display, but "measures":[] is perfectly legitimate.

[skybolt]

Originally Posted by skybolt

Note the "--------------"

CAUSE FOUND! When no fuel used (i.e. tank reset), calculates to --------. Cannot be read by pi.

Q: What's the precise sequence for tank reset? Once I'm on the tank reset screen, I keep getting "button pressed (hex value)". At that point it appears to be reset, do I just use R+L (normally setup trigger) to exit tank reset?

[t vago]

Originally Posted by skybolt

This appears to have been an intermittent (!) issue associated with my USB-C to mini-to-FTDI adapter. It is now functioning as expected.

Good to hear!

Originally Posted by skybolt

I assume you are not referring to sleep mode after not detecting speed/inj pushes for a set time? I can work around sleep with a periodic reset or extending the timeout period. If, on the other hand you leave it on all the time, and suppress output to save energy, then that would cause problems. How much energy is saved when suppressing output?

I can see the logic in not wanting to send output when there is nothing to send, and it is elegant, but it also seems to be a solution in search of a problem.

I can set it up so that MPGuino never falls asleep. I think it's there now, in fact, just got to test it. If not, I can ensure it gets added in when I implement the EOC timeout, idle timeout, and the like.

As for JSON output shutting off when there's no engine or VSS signals - that's easy enough to take care of. Just move the doOutputJSON() function call from the sampling section of the main loop to the display section. That'd be where the JSON setup function would want to be located, too.

Originally Posted by skybolt

I have a work item to be tackled later -- setup over JSON. That would require constant output, but of course that could be addressed by

(if SETUP) {send_output;}

I don't see it as much of a deal - there's a JSON frame being spat out every 0.5 seconds anyhow, and it'd be back-to-back every time a button was pressed. That's another benefit of moving doOutputJSON() from the sampling loop to the display loop. The display loop updates on every sample or on any button press or on any cursor flag change (that's how I can get those slowly blinking letters on the LCD screen).

Originally Posted by skybolt

In other news, SUCCESS!! I now have a working arduino pro mini (3.3v, 8MHz) working, attached to a raspi shield containing all car-to-arduino circuits and arduino-to-pi pins. It's a bit ugly, but it works, and so I can now do in-car testing with the new code base and pi output. I've noticed the most recent JSON output isn't formatted correctly, I'll start working on that.

Originally Posted by skybolt

CAUSE FOUND! When no fuel used (i.e. tank reset), calculates to --------. Cannot be read by pi.

I can have the code write a bunch of 9s instead of those dashes, for JSON output. Should have done that anyhow, for the traditional data logging option. Almost ready to kick out the next release version.

Originally Posted by skybolt

NOTE: I will post specifics later, but using VNC on the pi and my phone's hotspot allows me to project the 2nd pi (with the new code) to my phone, so I can view new and old back-to-back. I will post which pi-based VNC server I'm using -- which if you go this route you will want, as it a) projects the console, if desired; b) uses native authentication making it both slightly less insecure and easy to use, and c) works flawlessly with the official vnc clients.

Truly an awesome idea - MPGuino with a smartphone display! Quite a journey from the original HD44780 2x16 monochrome LCD.

Maybe we can get MPGuino to take input from a smartphone, too (via the pi)?

Originally Posted by skybolt

Q: What's the precise sequence for tank reset? Once I'm on the tank reset screen, I keep getting "button pressed (hex value)". At that point it appears to be reset, do I just use R+L (normally setup trigger) to exit tank reset?

Well, if Partial Fuel is selected as a compile-time option, you do a long-press of the Left+Center buttons to enter the Partial Refuel page, then press the Right button to scroll through the options until you see "Reset Tank Trip". Once you see that, you long-press the Center button until you see "Tank Reset".

If Partial Fuel has not been compiled in, just do a long-press of the Left+Center buttons.

Basically, the idea is to have any button press that actually resets a trip or writes a value to EEPROM, be a long button press.

[skybolt]

Maybe we can get MPGuino to take input from a smartphone, too (via the pi)?

Right now I'm working on how to deploy a sketch to the arduino from the pi -- FTDI is out (an extra board is undesirable, also don't want to collide with tx out); ICSP is out (don't want to have to add a capacitor and extra crystal), I think I can do it if I send a 0 (or low) to the rst pin. This would be first level of control from the pi/phone.

Should be easy to have the pi send signals to the arduino (such as A3, 4, 5 to ground). Long term (i.e. future plan with no idea of work involved) would be to scoop serial rx pin for string commands from pi.

Basically, the idea is to have any button press that actually resets a trip or writes a value to EEPROM, be a long button press.

Good plan, I'm sure you've had a number of accidental resets before putting long-press into place.

"subtitle":"drag stats: 0-30 MPH in 0.000 sec, 0-60 MPH in 0.000 sec, 0.000 sec to 0.000 mi @ 0.000 MPH, engine output 0.000 HP @ 0.000 MPH",
"

As you know this is scrolling off the screen to the right. I've given up trying to insert a BR or CRLF into the display text; I will toy around with moving some drag stats to the middle graph, leaving some at the bottom. Probably distance stats in the middle/mileage section, fuel usage drag stats in the 3rd section.

const unsigned int pAddressInjectorCount = pAddressRefFuelPressure + byteSize(pSizeRefFuelPressure);
const unsigned int pAddressInjectorSize = pAddressInjectorCount + byteSize(pSizeInjectorCount);

As near as I can tell, mS/Gallon is calculated/modified by numberOfInjectors. Why is this there? Is this for Chrysler compatibility? I've been going back to the old method of 1 injector and my old mS/Gallon. Fuel pressure and injector size appear to have no effect on my setup, is this for future hyper-precise calculations? Can I ignore this for now? If not, I have 650cc injectors, is the size (246cc default) the maximum or a different flow value?

scratchpad
BGLower
BGDSize
FE Filter
FE Time Period

What's the significance of these parameters?

[t vago]

Originally Posted by skybolt

Right now I'm working on how to deploy a sketch to the arduino from the pi -- FTDI is out (an extra board is undesirable, also don't want to collide with tx out); ICSP is out (don't want to have to add a capacitor and extra crystal), I think I can do it if I send a 0 (or low) to the rst pin. This would be first level of control from the pi/phone.

I am wondering if you could use I2C to talk with the MPGuino, since I have now coded in a fully functional I2C interface (it's also called TWI). That would be bidirectional, and you could code any sort of interface on the pi end.

Originally Posted by skybolt

Should be easy to have the pi send signals to the arduino (such as A3, 4, 5 to ground). Long term (i.e. future plan with no idea of work involved) would be to scoop serial rx pin for string commands from pi.

I did some experimentation some years ago with serial Rx and the Arduino platform. I was somewhat less than impressed, as I discovered that the Arduino would randomly drop characters for no apparent reason. I might revisit the code I wrote back then, and see if I made any mistakes (which is entirely possible).

Originally Posted by skybolt

"subtitle":"drag stats: 0-30 MPH in 0.000 sec, 0-60 MPH in 0.000 sec, 0.000 sec to 0.000 mi @ 0.000 MPH, engine output 0.000 HP @ 0.000 MPH",

As you know this is scrolling off the screen to the right. I've given up trying to insert a BR or CRLF into the display text; I will toy around with moving some drag stats to the middle graph, leaving some at the bottom. Probably distance stats in the middle/mileage section, fuel usage drag stats in the 3rd section.

Is the pi code failing to properly interpret any <BR> or CRLF combination within the quotes?

Originally Posted by skybolt

const unsigned int pAddressInjectorCount = pAddressRefFuelPressure + byteSize(pSizeRefFuelPressure);
const unsigned int pAddressInjectorSize = pAddressInjectorCount + byteSize(pSizeInjectorCount);

As near as I can tell, mS/Gallon is calculated/modified by numberOfInjectors. Why is this there?

MPGuino reads the signal from only one injector for an engine, but modern port fuel injection engines have one injector per cylinder. The numberOfInjectors parameter tells MPGuino to account for that in its calculation of usec/gallon.

Originally Posted by skybolt

I've been going back to the old method of 1 injector and my old mS/Gallon. Fuel pressure and injector size appear to have no effect on my setup, is this for future hyper-precise calculations?

This is partially for Chrysler products, but yes, it can be used for hyper-precise calculations. I remember that josemapiro reported last year that MPGuino calculation of usec/gallon wasn't working, and that I traced it to a couple of coding faults that I corrected and made available with the 20170116 release. What version of MPGuino are you using? I justed tested this feature and it works well for me.

Originally Posted by skybolt

Can I ignore this for now? If not, I have 650cc injectors, is the size (246cc default) the maximum or a different flow value?

It should accept up to 999.999 cc/min injectors. I've just now identified another bug that prevents it from accepting 1048.575 cc/min.

But you can also ignore it and enter in the usec/gallon figure directly.

Originally Posted by skybolt

scratchpad
BGLower
BGDSize
FE Filter
FE Time Period

What's the significance of these parameters?

BGLower - this is the lower speed parameter for the FE vs. speed graphs. Any vehicle speeds lower than this parameter will be ignored.

BGDSize - This is the width of each speed bar on the FE vs. speed graphs. If BGLower is set to 25 MPH, and BGDSize is set to 5 MPH, then Bar 0 corresponds to 25 MPH <= speed < 30 MPG, Bar 1 corresponds to 30 MPH <= speed < 35 MPG, and so on.

FE Filter - enables or disables the window filter function for the Instant Trip variable. It smooths out the jumpiness associated with taking 0.5 second samples and the inherent jumpiness of OBDII fuel injection systems that vary fuel delivered in order to make the pre-cat O2 sensor jump around stoich. This window filter is only applied after Instant Trip updates Current Trip, Tank Trip, FE vs Time (if compiled), FE vs Speed (if compiled). Accel test and coastdown do not use Instant Trip at all.

FE/Time Period s - This is for FE vs. time graphs, and is the width of each time period that is graphed.

[skybolt]

Is the pi code failing to properly interpret any <BR> or CRLF combination within the quotes?

The d3.js library strips any characters it doesn't like from the text field, as it applies all HTML tags itself. (This is probably to keep people from breaking it by inserting custom tags). The d3.v3.min.js is about 7800 lines of code, so I've been putting off trying to pull it apart and understand its whitelist/blacklist approach. The main issue is 'subtitle' is a single field, and it only assigns HTML tags outside of fields. Reasonable, but it doesn't help us.

I am wondering if you could use I2C ...

Not knowing what I2C is, I looked it up. Ah, now I see where you're headed. No, it's not a one-to-many (or one-to-two) issue. The Arduino already accepts uploads via the serial port which as far as I can tell is the same whether it's connected via FTDI or just a wire. I looked up programming the Arduino over the Rx port and it has to do with boot time - the first .n or N seconds after boot (configurable, I think and coded into the each bootloader), the Arduino bootloader will look for an incoming sketch. (This is only true if you have not deployed a sketch via ISP, which overwrites the bootloader). The trick is to programmatically send the RST pin a LOW as the first part of the upload process, OR hit the Arduino reset button like a monkey and hope you get the timing right). Now that I have a pi/duino combo in the car I have an incentive to explore this, as I could simply use dropbox to sync source code, then use the Arduino IDE to deploy directly from the car. No wires, not even a laptop required.

MPGuino reads the signal from only one injector for an engine, but modern port fuel injection engines have one injector per cylinder. The numberOfInjectors parameter tells MPGuino to account for that in its calculation of usec/gallon.

I see, that makes sense. I am glad that you alter the value in the displayed uSec, it made it easier to understand what was going on.

So, ... if I understand correctly, injector size and pressure must be for fuel use by pure calculation rather than tuning by observation, trial and error. I've noticed that changing # of cylinders alters the uSec saved value, but this doesn't extend to injector size, injector delay and fuel pressure. If I modify injector size and fuel pressure, shouldn't it change the saved value in uSec? Perhaps it has and I haven't noticed. If I have injectors set to 1, and change uSec to value N, and leave injector size at 246, should I expect to have it change fuel pressure to reflect the change in uSec? If so, your calculations must get a bit ... involved. Perhaps changing injector size/pressure overwrites uSec but manually setting uSec in essence overrides size/pressure?

What version are you using?

0116. I try and use your most recent code base unless I'm working on any changes (like I am know with the JSON output), and even then if my modified code just drops in place I'd move to the newer version. I assume I can send you a modified copy of your code and you can easily do a diff to see what's changed. Let me know if it's not the case. I'm trying to follow your conventions and comment styles to make it easier for you to deal with.


In other news, I've tested my old modified Meelis code (on a Meelis mpguino) back-to-back with your 0116 code on an 8MHz Pro Mini attached to a raspi prototype board. It's ugly, but it's one piece. uSec, pulses per mile and injector delay were set the same.

Results were identical!

I intend to move to the new code base in the car as soon as I can cobble together a second prototype shield. Parameter programming is easy, I made a pro-mini to LCD harness, with buttons. Reset is trivial since I view resets directly on the Pi screen, so I remove the LCD harness once it's been configured, leaving only the buttons.

[skybolt]

I'm goofing around with the code at approximately line 10915 (I say approximately because I may have added lines.

text::stringOut(devLogSerial, PSTR("\"ranges\":["));

(this is in the 3rd JSON section, 'fuel economy').

In a nutshell, we don't want the marker or measure extend past the range. Today, IMPG can be very large, especially when engine-off-coasting. One of the ranges has to be at least as large as the largest measure and marker.

A couple of ways to handle this.

1 (alt 1) : MAX(5/3 econ; IMPG, tank/trip MPG).

This is cleaner and allows for any value (like those long downhill coasts with hundreds of mpg), but forces me to ditch my current layout showing and obsession with EPA estimates on my ranges. Also, method 1 doesn't require much in the way of code changes, simply a max wrapper, which probably already exists as a macro in C.

1 (alt 2): Same as above but simply cap the IMPG white marker (and trip measure I suppose) at 5/3 tank. Instant MPG is reflected in text and can easily show hundreds or thousands of MPG. This is probably what most people would expect to see. Ford would do this in a dashboard readout, for example.

2: Set range values manually or set a not-to-exceed value for all markers, measures and ranges. (I do this today in my modified Meelis code).

This has disadvantages: Values would either need to be hard-coded (bad!) or yet more parameters must be saved to EEPROM (inefficient and not worth the effort).


I'm experimenting with code. Working on it now.

[skybolt]

One more issue to contend with that merits a standalone post. What to do about engine-off-coasting and instant MPG?

I changed the overflow return value -------- to 999999 (or so), which then calculates instant MPG as 4294967.295. This isn't bad ... people might like that. But, it's not exactly factory polish.

Option 1:

In the displayJSON code

reserveQuantity = doCalculate(instantIdx, tFuelEcon)

if (reserveQuantity >= 9999) text::stringOut(devLogSerial, PSTR("infinite
MPG, "));

The text string could also be blank, an arbitrarily high number (such as 999999), or even ∞MPG. Personally, I like ∞.

I cannot determine an effective way to do this outside of the JSON render code (i.e. mathematically inside the instantMPG calculation, based on 0 fuel and positive speed).

I'm going to add this "∞ mpg" to your 0116 code base right now and test it in the morning.

[skybolt]

  doOutputNumberJSON(2 * doCalculate(tankIdx, tFuelEcon) / 3, 3, PSTR(",")); // 2/3  tank fuel economy 
   doOutputNumberJSON(3 * doCalculate(tankIdx, tFuelEcon) / 3, 3, PSTR(",")); //  tank fuel economy, helps user differentiate current trip measure vs tank measure, with goal to keep current measure and instant marker above tank range
   doOutputNumberJSON(5 * doCalculate(tankIdx, tFuelEcon) / 3, 3, PSTR("],\n")); // 5/3 tank fuel economy

  text::stringOut(devLogSerial, PSTR("\"measures\":["));

//  min comparison keeps measure bars from extending past range, even if values in text are shown larger than range
  doOutputNumberJSON(min(doCalculate(currentIdx, tFuelEcon),5 * doCalculate(tankIdx, tFuelEcon) / 3), 3, PSTR(",")); //return lower of current trip mpg or range high bound
  doOutputNumberJSON(min(doCalculate(tankIdx, tFuelEcon),5 * doCalculate(tankIdx, tFuelEcon) / 3), 3, PSTR("],\n")); //return lower of tank mpg or range high bound
  
  text::stringOut(devLogSerial, PSTR("\"markers\":["));
//min compare keeps white marker from extending past range 
  doOutputNumberJSON(min(doCalculate(instantIdx, tFuelEcon),(5 * doCalculate(tankIdx, tFuelEcon)) / 3), 3, PSTR("]\xfd")); //

[skybolt]

The following is based on:

const char overFlowStr[] PROGMEM = "999999";

  reserveQuantity = doCalculate(instantIdx, tFuelEcon); //instant fuel economy
  if (doCalculate(instantIdx, tFuelEcon) > 999999) {
    text::stringOut(devLogSerial, PSTR("999999\",\n")); //infinte fuel economy, good for overflow and reasonable for anything above 999,999 (current overflow is 4,294,967.295 or (2^32)-1), check decimals is 999999 999.999 vs 999999.000? 
  } else {
  doOutputNumberJSON(reserveQuantity, 3, PSTR("\",\n")); // instantaneous fuel economy    
  }