programmable logic

[tarlo]

I would love in the future if you could step up virtual logic to be programmable perhaps in function block or text with Boolean (and and or if etc) to allow lots of flexability to the end user. the virtuals are great but can be limiting.  Thanks 

[Davidv]

I know its a bit of a bodge, but I've done this by using CAN inputs and outputs. 

You can output variables over can, do maths/programming/etc on your canbus device using the information, then send the variables back into the ECU. 

I do this to log a litres per 100km parameter into the ECU so I can view it in the logs with everything else (only cc per min is available otherwise) 

I've also used a canbus input as the load axis on an ignition table and had my device trim the ignition timing with more logic than is available on the ECU. 

Check out Teensy 3.6 and the IFCT library for it.
 

[redmist]

So David, do tell? Spill the code! 
After using a Raspberry pi and a small radio modem to transmit Link CAN Bus data over a serial link I've now started playing with an arduino to simply pull data off the bus and display it on a set of 4 x 7 Segments, an 8x8 matrix (gear display) and neopixel leds (RPM Limits). My coding is Uuuuuugly... but it works... mostly.

[Davidv]

19 hours ago, redmist said:

So David, do tell? 

Ages ago I was using cruise control to do some road tuning for best fuel economy. 
I'd drive a set piece of road at a set speed. Then had digital inputs on the dash that added different combinations of ignition timing.
So I'd go do a run at XYZ speed, which has lots of ups and downs in it to vary the load. Record a log file.
Then come do that same thing again, with different amounts of ignition advance added by the switches. 
This showed clear as day in the CC per min fuel usage logs, and TPS, which was best. 

So I took this a step further and made an arduino canbus unit that would wait for certain conditions to be met (cruise control on,steady driving no tps movement)
When cruise control is turned on, a virtual aux is triggered by the Teensy which sends a digital canbus input to turn on a 4D ignition table that has an analog canbus input as the load axis.
Then the Teensy has a full separate ignition table in it, and outputs the can value that represents ignition advance for the table.
It would collect 100 samples of fuel economy. Advance the ignition 3 degrees. wait for conditions to stabilize again. Then collect another 100 samples. 
Then it would compare the results of the test. If the results were better above a certain margin, it deinterpolates the current load/rpm ignition timing addition back over the 4 cells that its interpolating from.
Then it checks that if there is any lower load area or lower rpm that has less ignition timing than this, it will update those values too.
If the economy got worse, it would creep the ignition timing slightly back from where it started from, and do it again.
Basically it's auto road tuning for MBT. (But only works in a fairly narrow rpm and load range, because you dont have cruise control turned on at 8000rpm WOT)

So it iteratively builds up an ignition timing map on its own and keeps fine tuning it.
Starting with 10 degrees timing everywhere, it builds up a relatively sane ignition timing map in about an hour or two which is really cool. 
But whats nice is that when the car comes to a stop I can store the values to Eeprom so they're not lost when car shuts off.
So I'm also planning to shuffle the knock sensing logic over to this board too, so I can store long term knock trims instead of losing everything when car turns off.

However, this then also scope creeped into a context sensitive plug and play digidash / 3d printed housing.
With a whole bunch of other crap going on like auto dimming, changing screens based on what you're doing, xy plots, histograms, etc etc.
Also takes all of the standard dash inputs like lights, indicators, etc etc. Work in progress! (Its for an 80s car hence LCD type look) 
Working through some bits at the moment like estimated range off remaining fuel, and things like that. Has been a good learning experience and I'm pretty happy with the results so far.
Once the auto dimming became functional It's been really nice to drive with.

Trust me though, you dont want to see the code hahaaha.

[Davidv]

I started out building apon the excellent work of @paulr33 with his canbus example code that he put in a post here and also on his website:

http://www.paulr33.com/?page_id=16

I'm not using any of that initial code anymore as I moved from Arduino Mega to Teensy 3.6.
But it helped me understand the basics immeasurably.
 

[paulr33]

Good work. I ended up going for a plex usdm but making the arduino CAN display did help me learn it all and how it works which was good fun 

[TechDave]

On 5/31/2019 at 12:19 AM, Davidv said:

This isn't just a mock up? This is functional?

[Davidv]

On 6/6/2019 at 9:09 PM, TechDave said:

This isn't just a mock up? This is functional?

Yep it is a plug and play swap for factory dash, and everything works.

The cruise control ignition trim, I've had it automatically build some surprisingly sane ignition tables just from starting at 10deg everywhere. But still fine tuning it. 

I had my 3D printed housing get a bit melty left in the car on a super hot day and sagged on its mounts and warped a bit.
So I've reprinted it with a more temperature resilient material.

It's a bit of a mess behind the cover as its a hodge podge of lots of parts. but I'm just in the process of consolidating everything onto a single circuit board.

Still heaps of work left till I'm done, but, was an awesome milestone to get it working as a plug and play.

[redmist]

On 6/7/2019 at 8:20 PM, Davidv said:

Yep it is a plug and play swap for factory dash, and everything works.
 

Nice job David!
Thank you for the pointers to Pauls well presented site. Thankyou Paul for spending the time and effort to detail such. 

I gather the reason people have migrated from the arduino mega/nano to the teensy (or other platform) is because it's just too slow? I suspect by the time I generate interrupts from the flappy paddles and insert new frames on the canbus I'll simply ask too much from this stupidly cheap device. 

My dash is currently being benched (chose a mass of 7 segments as they are bright in sunlight for the open race car), have it testing libraries and some basic code to pull frames  and data from the canbus... it just needs some proto board... me to design and print a case (I'll keep away from PLA now thanks Dave!!!) and a tonne of tidying in code and wiring. 

Think I'll design and print the case around the ability to replace it with a Raspberry Pi Zero W. The nano seems fast enough, but does not seem reliable. I've also broken apart the canbus frames with my Pi based radio telemetry such that given the 7 segment and nanopixel libraries I shouldn't have too much issue migrating to the Pi. 

[Davidv]

Yeah I started out using a mega but it was starting to chug. If there are any instances where you need/want floats then youre gonna grind to a halt.

Teensy is just so much faster, instant boot time compared to a pi, floating point and 32 bit calcs no sweat.

Plus the dual onboard canbus of course.

In your case PLA might be fine, I actually drove around for a month or two with it - it was just a whole day of left out in the beating summer sun in a sealed car that did it. But have redone in petg which should be good.

If youre ever looking at getting a screen go for the nextion options over 4dsystems. 

Cheaper and much much much faster.

4d screens only have an 8 bit processor and have a crappy slow refresh rate.

[redmist]

On 6/10/2019 at 11:54 AM, Davidv said:

Plus the dual onboard canbus of course.

If youre ever looking at getting a screen go for the nextion options over 4dsystems. 

 

Thought the Teensy still required a can bus transceiver? If I could attach the teensy straight to my canbus then it would save me a tonne of grief!!!
I've a friend that's had issues with Nextion and refresh rates, switched to a cell phone. Seems all the integrated intelligence screens struggle.  

[Davidv]

Yeah the transciever is miniscule though, doesnt increase footprint:

https://www.tindie.com/products/Fusion/dual-can-bus-adapter-for-teensy-35-36/

The refresh rate is good especially when optimized to minimize pixel writes.

But if youre spamming it with lots of fast moving stuff or your code has a lot of unnecessary writes it can chug a bit.

Moving over to realdash on a tablet is a whole bunch less work to be fair. But this is a learning exercise for me as much as anything else.

The start up time, for me, is something that needs to be super snappy. Thats where a microcontroller is so good.

I want to migrate my project to a twin core stm32 and a custom board at some point. So i wont need nextion it can control an lcd panel directly.

But this is a huge amount of work and ive got lots to learn in the meantime.

[redmist]

On 6/11/2019 at 2:41 PM, Davidv said:

But if youre spamming it with lots of fast moving stuff or your code has a lot of unnecessary writes it can chug a bit.

But this is a huge amount of work and ive got lots to learn in the meantime.

I've currently got all 6 seven segments and the 8x8 Matrix to work with Link "generic dash" can bus output. There is some work to do with my neopixel library conflicting another of my libraries, and a weird issue with my can bus adapter only picking up frame 0 or 1 when you start to introduce a delay (like writing to the 7 Segs). However given a correction of my frame issue I'm not seeing any problems with refresh from the Nano. Weird thing is the Nano will do several hundred main loops prior to picking yet another frame 0 from the buffer. 
Although there is a deep imprint of my keyboard in my forehead I'm enjoying battling with the cheap ahrse and very flashy intelligent 7 Segs, 8x8 and neopixels... the cheap can bus adapter... not so much.

[Richard Hill]

3 hours ago, redmist said:

I've currently got all 6 seven segments and the 8x8 Matrix to work with Link "generic dash" can bus output. There is some work to do with my neopixel library conflicting another of my libraries, and a weird issue with my can bus adapter only picking up frame 0 or 1 when you start to introduce a delay (like writing to the 7 Segs). However given a correction of my frame issue I'm not seeing any problems with refresh from the Nano. Weird thing is the Nano will do several hundred main loops prior to picking yet another frame 0 from the buffer. 
Although there is a deep imprint of my keyboard in my forehead I'm enjoying battling with the cheap ahrse and very flashy intelligent 7 Segs, 8x8 and neopixels... the cheap can bus adapter... not so much.

I moved away from using generic dash as it employs a compound CAN message, which can be a bit of a mouthful for both the ECU sending and the device receiving.  I prefer to use messages which are split over several CAN IDs such as transmit generic dash 2.  The only problem with Generic Dash 2 is there's appears to be a  bug in the non driven wheel speed (1 byte assigned, but shows as 0-1000kph, guess the text was copied from generic dash).  Not a problem though if you aren't planning on going more than 158 MPH...

[redmist]

12 hours ago, Richard Hill said:

I moved away from using generic dash as it employs a compound CAN message, which can be a bit of a mouthful for both the ECU sending and the device receiving.  I prefer to use messages which are split over several CAN IDs such as transmit generic dash 2.  The only problem with Generic Dash 2 is there's appears to be a  bug in the non driven wheel speed (1 byte assigned, but shows as 0-1000kph, guess the text was copied from generic dash).  Not a problem though if you aren't planning on going more than 158 MPH...

I'd also like to move away from the Generic Dash to something more customized around my needs. Although I've "fudged" the generic dash such that I can display my gearbox temp, unfortunately the AIM Evo 4 that I'm currently using in the offroad race car requires that protocol. The rally car runs a G4 Storm, which by default does't appear to have a Generic Dash 2 LLC (although I'm sure I could create one). 
I am however having an issue with either the arduino libraries or the MCP2515 controller. Specifically it's dropping large amounts of frames from the buffer and given a small delay in the program (such as a write to the 7 Segs) it drops all but the frame 0. It's a weird timing issue as I can "count" main loop cycles in the hundreds before an can bus interrupt is generated. Might have a crack with one of my ESP8266 devices (which is sure to make everything worse). 

 

[paulr33]

I didn’t have any issues with speed and always had fast updates on my display. The problem with my setup was when I needed to change something on the display I had to put it all apart and plug it into the PC seperately to update the 4D systems screen and then the arduino code seperately and also the screen would drop out and flicker because the wiring was always loose from the plugs. 

The plex usdm is a commercial solution and I can change the scenes and layouts and customise to my hearts content while sitting in the car via USB on the side of the display. 

[CamB]

On 6/15/2019 at 9:30 AM, redmist said:

I am however having an issue with either the arduino libraries or the MCP2515 controller. Specifically it's dropping large amounts of frames from the buffer and given a small delay in the program (such as a write to the 7 Segs) it drops all but the frame 0.

I have a problem similar to this too. I sort of solved it by reducing the number of parameters being transmitted and the update speed, then doing a lot of reading before writing to the screen. Not very satisfactory.

I'm pretty sure I am just going to buy a plex usdm one day instead.

[cj.surr]

 

On 5/2/2019 at 4:17 AM, tarlo said:

I would love in the future if you could step up virtual logic to be programmable perhaps in function block or text with Boolean (and and or if etc) to allow lots of flexability to the end user. the virtuals are great but can be limiting.  Thanks 

+1 

If not in virtual logic, it would be nice to at least have functions available for log viewing and dash gauges. For example, I would like to be able to log/gauge AFR error (afr - afr_target) or water injection flow ({water pressure - map} * coef}).

[redmist]

I dropped the Nano and went ESP32 wrover. On board can so only required an external transceiver. Picks up almost all frames. At least it's more consistent than the Nano and more than enough for a good refresh rate on the dash. 
Because of the "pause" between data sends the ESP will always pick up the first frames, which means the RPM is always refreshed quickly. It's dropping the occasional frame mid to late in the dataset, again not enough to bother a dash refresh. 
I tried lowering the transmit rate, but all that does is increase the "pause" between "burst" sends. As such it still drops frames. 
Only real option is to lower the data rate... and considering I'm running a AIM Evo, which is set at  data rate, transmit rate and parameter set I can't alter my configuration without dropping the Evo. 

My Pi with PiCan2 will pick up all frames, however as soon as you burden it with an IDE the python scripts will drop frames similar to that of the ESP.