Enlisting Mufasa for Salt Duty

Not running the V-stacks at the moment, using K&N 4040s. I have to come up with a salt friendly intake, something I can safety wire to the bike and be positive will stay in place at max speed while gaining ~4"+ of length and pulling clean air.

It might be me being fussy, but in short, no. I was not satisfied with the tune on Mufasa or Alice. Both bikes had issues in the sub 25% throttle range after my visits there, above that was fine. Alice was easy to correct thanks to Woolich and the more advanced ECU.

It's fine though, the most difficult areas to calibrate on the street are accurate on both bikes.

The Rocket is a bit of a PITA to tune below 3% throttle, mainly because of bored out TBs and low vacuum (relative to stock R3) from big cams. I don't know that it's reasonable to expect perfect fueling in that area from dyno time alone due to the differences in the way the engine is loaded there.

I have this, now that I've mentioned the intake:



Basically I need to build a plenum, this facing forward, and have internal stacks to the TB. It won't be street practical.

I tested it on the Mini for ****s and giggles, flows so much it upsets the MAF reading throwing the fueling off lol.

I've identified another shortfall...
Datalogging.

I've looked at all the aftermarket stuff I can find. It's either insultingly overpriced, massive overkill, or just doesn't do what I want so...guess I'm building one.

For the first version I'll be using a Feather ESP32 board, featherwing with GPS/GLONAS, RTC, and SD-Card with blue tooth LE. It will capture everything in a CSV file compatible with Megalogviewer and be retrievable via Bluetooth.

Every time the bike starts it'll be logging CLT, IAT, TPS, WBO2, RPM, GPS Speed, Elevation, Rate of Acceleration, Ambient Temp, Humidity, Engine Vacuum, and Baro readings.

The challenge will be sample rate. Can it log all that as raw data fast enough? If so, can it log all that with some simple data processing fast enough? Finally, can it log all that and calculate a rolling 1 second average GPS speed to output to a guage concurrently? If so, great, a $50 solution the aftermarket is charging 20 to 40 times for the same capabilities to accomplish.

The best part: it will be tiny, low power, low cost easy code and provide all the data necessary to drive a generic gauge cluster.

love what you are doing
the information enter change sensor/actuators to ecu is super fast but are scanners (or gauges) are slow so if we need faster info we chose one or two like actual transmission pressure and ecu commanded transmission pressure.
i have found the more sensor/actuators you use the slower the info reads.
so it would be nice to be able to chose when you are trouble shooting.

Claviger said:

The challenge will be sample rate. Can it log all that as raw data fast enough?

Click to expand...

Depends on the OBD2 protocol used OBD2 protocols SAE J1850 PWM @ 41.6kB/sec but ISO 15765 CAN can go up to 1Mbps. OBD2 protocols

after the databus speed the only other limiting factor for the number of queries / second is the length of the PID message returned. OBD-II PIDs - Wikipedia

Seems that this esp can-bus breakout CAN Bus Mini Breakout Board can handle the 1Mbps

I'm not using OBD2 data, too slow on the Rocket ECUs, the reason I stopped using the Innovative LM-1 data logger. Direct sensor access, scaling, and conversion from voltage to information. The main question is, can the board do the voltage > value math while recording and still get a 100hz sampling rate or does it need to log raw voltage data and then have the data converted in excel/python externally to save clock cycles?

The fun part is I can scale boards up to quad-core 1.5ghz pretty easily once I build the prototype and find the relationship between CPU speed and logging interval. Will be writing all the code here over the next week while the parts ship and then testing soon before it finally gets too cold to ride comfortably here.

On the Z H2, it ECU allows logs at 100hz for the ECU OBD data and 20hz for the Wideband, fast enough for tuning work for sure, if I had to go down to 20hz for everything on the rocket it'll still be fast enough.

you are way ahead of me and i am always interested.
i hope you get it set up the way you want.

If it works as I intend, the plans, parts, and code will be posted on github for the world to adopt, as well as the STL for the cases/mounts.

Claviger said:

If it works as I intend, the plans, parts, and code will be posted on github for the world to adopt, as well as the STL for the cases/mounts.

Click to expand...

Sorry, this left me in the dirt, all I can do is follow and wish you well.

Unfortunately most of this information is going over my head. Is the purpose to get the bike to run smoother, faster, more reliable or simply measure what the bike is doing?

The unknown values affecting performance from my perspective is wind direction and speed, density of altitude, traction on the salt. These negatives can somewhat mitigated by running when the wind is usually minimal before 10:00 and the density of altitude is best between 0700 and 10:00. Traction drops off after 1:00 pm when moisture is wicked up through the salt and the density of altitude is 1700 to 2200 higher after 1:00 pm.

We can certainly use more fuel in the morning than the afternoon so that would be a good adjustment to me made. The course frequently gets ripped up and leaves on the margins of the left or right side of the course for motorcycles to use. The left side or right side can be used morning but frequently the left side cannot be used in the afternoon due to the wind blows you off the course.

I guess my long winded point is the course, wind and density of altitude isn't really predictable and changes every 30 minutes or so. If calculations are being made to run a broad range of conditions say from 5500 to 7200 feet then a quick tweak to tune, tire pressures while waiting in line then I think we will be fine.