[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.