t vago's MPGuino workspace thread, continued

[josemapiro]

Hi t vago

Originally Posted by t vago

I'll add it in, but it won't be a priority.

It's just a suggestion, I'm not in need of this, so is resets that are not practical either, perhaps when the menu is implemented, you can create a sub-menu for resets only.

Originally Posted by t vago

However, I do have some good news - My code now is able to use the TWI as an output interface. I have it using a SainSmart 2x16 LCD module for now for testing, but I hope to have that Adafruit RGB LCD shield fully functioning by the time the week is out. After that... a TFT interface? Why not?
I lifted the TWI code from the twi.c code that was part of the Arduino Wire library, and have cleaned up extensively and modified for use with the code. I hope to have it be able to support buffered output very soon. Yes, TWI is itself buffered, but it acts in practice as an extra digital input/output port, with all of the timing constraints and pin manipulation requirements, so I still have to do all of the port manipulations that I did with the original legacy 16x2 LCD module.
I also plan to try to implement LCD brightness over TWI that isn't either off or eyeball-scorching on.

This is not good news, it is excellent news.

Thanks
José Rodrigues

[t vago]

Coding goes slowly, but I am making progress.

I have convinced the code to use the display portion of the Adafruit LCD module, and that includes being able to display any of 7 separate colors for the backlighting. I've also further streamlined the TWI module. I figured out a really neat trick with regard to sending 4-bit values to LCD displays over TWI, and I'm actually surprised that it's not part of any of the TWI-compatible LiquidCrystal libraries I've seen so far.

Next, going to try to get the code to read the buttons every 15 ms, from within the timer0 overflow interrupt. This might cause some sort of performance degradation on the LCD display, so I might have to bump up the TWI base frequency from 100 kHz to 400 kHz. Unfortunately, the Adafruit LCD module contains no provision at all for having the button presses generate an interrupt, as the legacy 3-button interface does. The buttons on the RGB LCD unit must be polled.

[josemapiro]

Without a doubt, the work that you have been doing with MPGuino is fantastic.

Thanks
José Rodrigues

[t vago]

I just had a derp moment. I think it may easily possible to have MPGuino calculate the usec/gallon and the injector microsecond delay, given two separate fillups. The procedure to do so will be remarkably similar to how I will tackle coastdown.

[Ardent]

That's be cool.

[t vago]

Originally Posted by smonson

Here are the results of my observations

The following maths treat all cylinders as a single measurement. Figures will be 4 times higher than the real value for a single injector.

WARNING: PEDANTIC GUY AHEAD

Tank 1 (country):
- predicted 28405mL
- actually 28360mL (error: 0.15%)
- PWM fired 332468 times for 2195.598 seconds
- average pulse width: 6603uS
- average fuel quantity injected: 85.301uL

Tank 2 (city):
- predicted 30954mL
- actually 30950mL (error: close enough)
- PWM fired 385078 times for 2403.540 seconds
- average pulse width: 6241uS
- average fuel quantity injected: 80.373uL

The difference in pulse widths is 362uS and the difference in fuel injected is 4.928uL. From this we can infer that the fuel pumping rate is 0.01361325 uL per uS. Converting units, that's 204cc per minute which is in the expected ballpark for a small car.

The total time to transmit the average injected fuel amount into the cylinder is then 6266uS (tank 1) or 5904uS (tank 2). This predicts the injector time delay at 337uS for both, depending on how inaccurate those particular fuel pumps were.

Thanks dcb and everyone else for all the advice!

I just verified that my idea for determining these numbers will work. Now I have even more reason to get off my dead butt and implement matrix math inside the MPGuino code.



Basically, I'm just solving a system of linear equations using matrix math. To be sure, since I'm only solving for two variables instead of three, I could just use elimination to crunch the numbers.

In any case, it will be much simpler to calibrate the MPGuino with this in place. All the driver would have to do is fill up two separate times to full, and press a few buttons in both cases.

[josemapiro]

Spectacular

[t vago]

Finally got the bugs out of the interface to the Adafruit RGB LCD module. Now there is a 5-button/LCD solution for MPGuino that uses only two pins instead of 10.

https://www.youtube.com/watch?v=vO2dT2RaWeI

Short demonstration of new idle timeout, EOC timeout, and park timeout. I think the Meelis code does something similar.

Idle timeout is engaged when MPGuino senses an idle condition, and activates an Idle screen after the idle timeout period elapses. The default setting is 15 seconds, but may be changed via stored parameter "Idle Timeout (s)"

EOC timeout is engaged when MPGuino senses an EOC condition, and activates a separate EOC screen after the EOC timeout period elapses. The default setting is 2 seconds, but may be changed via stored parameter "EOC Timeout (s)".

Both Idle and EOC timeouts can be temporarily overridden by pressing a button - this temporarily restores whatever screen was being displayed normally for a button-press timeout period. The normal screen is also displayed when the engine is running and the vehicle is moving, or if both the vehicle and engine are stopped. The default setting is 5 seconds, but may be changed via stored parameter "BtnPress T/O (s)".

The park timeout engages when MPGuino senses both the engine and the vehicle are stopped, and when the park timeout period elapses, the Current and Tank Trips are both saved to EEPROM (if configured). After this, the driver may safely remove power from the MPGuino. The default setting is 5 seconds, but may be changed via stored parameter "Park Timeout (s)".

After the park timeout period elapses, the traditional inactivity timeout engages. When the inactivity timeout elapses, MPGuino either enters deep sleep mode, or it shows a clock display. Either may be configured at compile-time. The default setting is 120 seconds, but may be changed via stored parameter "OFF Timeout (s)".

https://www.youtube.com/watch?v=o3eL4hxIW4Q

[josemapiro]

More one brilliant work like so many others.
One more step to implement the menu.

Thanks
José Rodrigues

[t vago]

I found a rather serious bug related to one of the fuel injector validity monitors, which was in the 20170208 release. The bug has since been fixed, and is in the 20170210 release.

I also added a skybolt-related modification to the doOutputJSON routine, and corrected a very old bug related to displays on the LCD screen that I was finally able to track down.