Rawze's VGT turbo controller box

[BulkleyMotors]

I'd like to put together one of those arduino controller you use in your youtube video to test a turbo actuator.
Did you publish plans for it by any chance?
I checked github but no luck.

[Rawze]

The plans are not public, however, I do not mind discussing any information verbally on how things work towards someone who is wanting to make something for themselves.


Here are just some basic things that I keept in mind or had to endure ...

*========
* I started out with a simple idea of having a completely self-contained "control box" for these turbo actuators so they could be tested, calibrated, etc.. all on their own + have its own self-contained battery power and everything. Something that did not need a computer attached to it at all, completely stand alone, quick and convenient to use whenever and wherever needed.

I wanted to be able to ...

-- manually control the actuator with a simple knob.

-- have the ability to calibrate the actuator to the turbo fully, so that a laptop, etc. is not needed.

-- have an oscilliscope graph readout on screen showing the resistance on the motor thru its travel range so that I can test turbos to see if the control arm was hanging up or worn out, all without having to remove the actuator from the top of the turbo.

-- be battery powered with enough "umph" to run the actuator/turbo stand alone, so that it did not need a bunch of wires and cables, etc. - I wanted it simple and clean with only the one connection just like it is done on the engine.

Those were the goals to reach on how I wanted it to work.



Then came the nightmares ...
*========
* The turbo actuator needs a constant steady stream of information flowing between it and its host (the arduino in this case) on the J1939 data-link to and from it at all times, non-stop. Otherwise it will not run correctly, fault out, and/or constantly jump to a default position.

*========
* Because of the steady flow of data needed to control it, MOST arduino boards are not nearly fast enough in processor power to keep up with the actuator full time + at the same time, be able to deal with any user interaction, display screens, etc. ... even if someone cut the programming to the absolute assembly-language bone to try to keep up. I found all this out the hard way. I have an entire grave-yard worth of failed attempts, or attempts that just were not fast enough in the end.

The Uno, Micro-Pro, Mega, and most all the rest of the normal Arduino boards just cannot keep up properly. I even resorted at one point to using multiple boards networked together to share the processing load, this worked, but it was a messy way to do it that way and the oscilliscope-display was not responsive enough for my tastes.

*========
* Because most arduino boards cannot keep up with both the actuator and user interfacing, the bare minimum Arduino needed is a Teensy-3.6 controller set on 128MHz clock speeds. This is only after writing all 100% optimized custom libraries for the screen and for the J1939, it then does ok.

*========
* Any project involving the J1939 where a constant stream of information is needed non-stop ... like the turbo actuator needs ... and an Arduino board is involved, means that the Arduino is going to have to fully multi-task. Arduino processors are not capable of this on their own, not even the NXP processor in the Teensy3.6, which does have its own built in J1939 capabilities. This means that I had to write my own task manager for the processor to handle fully multi-tasked operations correctly.

*========
* I also had to write my own custom libraries for the display completely from scratch using the engineering data-sheets, including the text to pixel-placement translation tables, routines, etc., as all of the pre-made libraries that came with it were nothing but bloat-ware garbage that slowed down the processor too much to be useful.

*========
* Unlike cummins engines where the J1939 is at 250kbps, Detroit actuators use J1939 at much faster 1mbs buss speeds. Because of this, I also had to completely re-write all of the J1939 and can-buss front end driver libraries from scratch, again using the engineering data-sheets for the chip-sets, because the pre-made ones from NXP.. the chip-maker themselves... were absolute garbage and too slow to be useful when the J1939 buss speed was running +1MBs and Detroit actuators were connected to it.


*========
-== As someone can see.. There was a whole damn lot of sweat and tears and failed attempts + re-works and re-writes of low-end driver libraries, and digging thru chip-set data sheets to squeeze the program hard enough for it to all work smoothly .. but I finally got it.

At first i thought it would be a fun, easy project.. but as it progressed, I ended up taking the whole project on as a personal challenge in remembrance of those days not too many years ago when I had to regularly deal with logic control processors that were just not fast enough, or smart enough to do what you wanted them to... but somehow, you know it could do it if all the tricks were used to get it there.

It is like when someone knits a custom sweater from scratch .. every stitch by hand, months of work, intricate patterns, etc. .. and then others comming along and saying, that looks simple enough.. "I want to make one too". -- My response at this point so far is .. your more than welcome to make your own. I am not sharing the exact pattern specifically, but I am willing to tell you all about what I did, saving you most of the headaches I had to endure along the way.

[tree98]

Wow, truly amazing Rawze.

[BulkleyMotors]

Wow, I didn't know it took so much work!
I can do basic programing but I don't know enough to do the kind of optimization you did. Do you think I could save myself the optimizaion work by throwing more horsepower at it (raspberry pi instead of arduino)? Or is the CAN bus card a limiting factor as well?
What kind of CAN bus adapter did you use?

[jmartin]

Perhaps something like [/size]this would be a good choice for such applications. Infineon dev board with Aurix TC237 series tricore micro, onboard CAN, touchscreen etc. Meant for automotive controller development. With the three cores, one could be handling J1939 while others can be doing the real work. If you're an OEM or Tier 1 they hand these out, but I'm pretty sure you can buy these Dev boards on Mouser, etc. Not quite as cheap as Arduinos, but much more powerful.

[BulkleyMotors]

I'm thinking about something like this:
CAN hat

It seems to be compatible with CAN 2.0B and supported by the linux kernel.

See any red flag?
Does your adapter use the MCP2515 too?

[Rawze]

(06-10-2022 )BulkleyMotors Wrote:  ...
Does your adapter use the MCP2515 too?

I started out using a MCP2515 chip. It will do the job well enough but since I ended up using the the teensy3.6, it already has that ability built in, so the answer is no.

The NXP processor on the Teensy3.6 has 2 can buss chips already on board as part of the processor itself. There was no need for any external can bus controller.



BTW: The pics of that board you listed shows a 12.0 MHz crystal. That will not work on J1939. It needs to be a 16.000 MHz crystal for that MCP2515 to work on vehicles properly. I think there is some restriction on selling MCP2515 boards with 16.0 MHz crystals pre-installed or something in some countries, etc. - So it is not uncommon to have to replace the crystal to the proper one on the board after getting it.

[BulkleyMotors]

Great info, exactly the kind of gotcha I was looking for.
Thank you.