[ruckusman]

Hi there,

I'm doing preliminary research and hopefully asking sensible questions.

A wee bit of background, originally I purchased a 2011 GSXR600 Yoshimura EM-Pro ECU and loom for this project.
Unfortunately getting the EM Pro software has been a demoralising task, I made the required connection cable easily enough.
Yopshimura USA were very helpful, they kindly sent me a version of Em Pro, but it doesn't include years past 2008 unfortunately.
Anyway that wasn't a huge expense.

The bike I am considering is an FZR250 specifically, it redlines at ~18K RPM - the other little 250/4s rev as high and a little it higher in the case of the CBR250RR and ZXR250R -> 20K RPM.
There's also the GSXR-250R which is a rev demon
I see such an endeavour as being equally applicable across all of those bikes so: Honda CBR250RR and variant Honda Hornet 250;
Kawasakei ZXR250R and variant Balius 250;
Suzuki GSXR250R and variant Bandit 250;
Yamaha FZR250 and variant Zeal 250.

So it's worth asking two or three question.
Not quite safe to assume that Speeduino will have the processing power to handle that RPM range, I'd like to assume that it will, but it's safer to ask.

I'm fairly certain staged injection is going to be necessary at the top end - Speeduino - CHECK - at the really high RPM's?

Speeduino can control both stepper and other motors via PWM - the Yamaha has the EXUP valve in the exhaust as well as secondary throttle butterflies in the throttle bodies I am considering - CHECK.
There's additional stepper and other outputs via assignable pins from what I understand.

Speeduino has available small well priced wideband controllers - CHECK - this was previously a barrier to entry as wideband controllers and gauges are expensive.

Speeduino can run both the OEM wasted spark coils and (dumb) COP coils via external ignitors - CHECK

The feature set Tunerstudio and Shadow Dash is perfect, especially the data logging function, guessing at a tune is pointless and dyno time is expensive.
That software really does complete the ecosystem.

Regarding Speeduino
First I'll start with what I 'think' I know - there's some incredibly useful hardware and software associated with Speeduino.
The ardu-stim - and the engine simulator board from https://www.everythingfuelinjection.com ... p260389763

I love it, that takes so much of the guess work out of actually knowing what's doing what, triggers, sensors and working correctly for what is essentially a cleansheet and unknown install.

Can the engine simulator be used to imitate an OEM VR crank signal so that I can interrogate the TCI unit and make a spark advance map?

I've got a decent oscilloscope and can connect to the coil driver transistor in the TCI isself and avoid the voltage spikes and ringing on the coil driver lines themselves.

Imitating/ spoofing a running engine would also allow me to check nd map the EXUP valve motor movement with respect to engine RPM.

I anticipate being able to simulate the majority of a running engine and actually plugging in various components that I do already have to check their function, observe their behaviour.
Things like the TPS, secondary butterfly motor and it's sensor.

I intend to make an ECU connection board which plugs into whichever Speeduino board I chose so that I can use as much as possible of the GSXR wiring loom(s) I already have - I think that's a the path of least resistance as I have all but the VR crank trigger for a complete EFI setup.

I could go on almost endlessly, but I suppose at this stage it comes down to requirements/suitability.
At the basic end
4 channel ignition - that's most Speeduino board - correct?
The external ignitors solve coil choices - are they classified as high current or low current devices?

8 injector channels - there's a few available which satisfy that criteria natively, other look to have enough high current output available via development pins

Extra stepper/DC motor controls - all Speeduino boards basically via either available or through development pin assignment.
Hall/VR sensors - daughter/external - all boards from what I can discern.

So my immediate choice would be to go for either the 0.4.4 board, solder it myself and deal with extra injector channels and anything else on the separate connector -> ECU loom board.

Is there a significantly better choice as a starting point?

[purplelightning]

The RPM question has come up a few times. In short, yes 18-20K is possible. Technically the limitation is the velocity of pulses\interrupts which of course is a function of RPM multiplied by number of pulses per crank rotation. There used to be a calculator that you could work out what trigger pattern would be "safe" at a given RPM. 12-3 would be OK for sure.

The tables are 16x16 so I guess you could go to a second map so you have more granular control over that wider RPM the engines use.

Mapping the existing ignition timing might be challenging... Any chance you might be able to acquire the stock map details from documentation or maybe Yoshimura since you sent them some money and didn't get much value. I guess you could go old school too with a timing light, but if the ignition map is by RPM and load, that could be tricky.

Four cylinder can be run with just two channels in batch fire, although with those RPMs it might be a bit harsh on the coils. Same with fuel.

[ruckusman]

Thanks - I kept reading the forums a lot after I posted and did find 9KHz is the upper limit for signals, trigger or others.
I already have 24-1 trigger, not that I have to use it, but it would yield 7.2KHz signal by my calculations.
I don't yet have a VR or hall sensor for that trigger.

The Yoshimura ECU isn't going to be used at all, that was my original plan, now jettisoned - Now that means I can make/use crank and cam triggers that are most suitable - that's liberating.

Same goes for the various other components/sensors - I have freedom for MAP, IAT, CLT etc to ones that have been included and characterised by Speeduino already.

I need to interrogate the original Yamaha TCI, it's very basic, RPM based spark advance based upon VR sensor, the rotor is 3 short 1 long - it doesn't any other features, no TPS on the carbs or anything of that nature.
It provides spark, controls the EXUP (exhaust) valve motor and gives the dash a tacho signal.

I will delve more into Speeduino, Adrdustim and Tunerstudio to see what signals can be imitated - I do have an oscilloscope for the readings.

I like your suggestion of a second set of tables as after posting I read this post/thread
viewtopic.php?f=21&t=1351&p=21130&hilit ... ter#p21130

He sets the focus on low RPM in the tables to get smooth idle.
The FZR250 has a 1600RPM idle, the only change in the system is that the EXUP (exhaust control valve) is closed at low RPM and I think fully open by ~10K RPM.
That's a simple DC motor with a trimpot for positioning feedback which I can hopefully map to another function like VVT or perhaps Idle control.

Fairly certain that the secondary throttle butterfly control is a stepper with a trimpot for positioning also.

Anyway, on the topic of suitable boards, I have spent time on here and on github

This board stands out as suitable - 4 ignition channels and 8 injector channels
https://github.com/Tjeerdie/SPECTRE

I'm part way through this thread on the topic

Am I on the right track?
viewtopic.php?t=1914

[LAV1000]

Try to find one of these:
https://www.tinytronics.nl/en/tools-and ... hannel-usb

Most vendors sell them or something like it.
Can log 8 digital signals, 5Volt dc only.
Ideal for logging outputs vs cranksensor......

[ruckusman]

Thanks, that' a nice lightweight, versatile method of signal capture - a very sensible solution indeed - I'll search one out.

[ruckusman]

Just putting this here as it's another piece of the puzzle - secondary throttle plate control
viewtopic.php?p=47038

[ruckusman]

Working on adding some different wheel definitions for ardustim so that I can interrogate my OEM TCI for both the spark map and determine the EXUP (exhaust valve servo motor) settings -v- RPM.

I've got working ardustim board and loaded/tested the latest firmware and app, works well for signals up to 20K RPM just measuring the signal frequency output -v- loaded trigger wheel with the multimeter Hz measurement.
The gauge dial obviously doesn't go that high, however the simulated LCD readout does and it's very accurate

I like everything that I am seeing to this point.

I've created a fork here: https://github.com/ruckusman/Ardu-Stim/tree/master
I've added three placeholder entries in wheel_defs.h
https://github.com/ruckusman/Ardu-Stim/ ... eel_defs.h

Now I'm up to also appending those entries to the ardustim.ino project file.

But my questions can just as easily refer to the master repository.
https://github.com/speeduino/Ardu-Stim/ ... dustim.ino

/* Setting rpm to any value over 0 will enabled sweeping by default */

Looking at the description of the entries in
/* Pointer to friendly name string, pointer to edge array, RPM Scaler, Number of edges in the array, whether the number of edges covers 360 or 720 degrees */

The RPM scaler in the above description from looking at the entries seems to have something in common with, or is loosely related to the number of edges in the array in some instances, however in others there's no relationship between the RPM scaler and the number of edges in the array.

Am I correct in assuming that the RPM scaler is an arbitrary number (chosen to be above zero for automatic sweeping if desired) but can be a sensible number - there are entries between "0.06667" and "6.0" for that field and I don't detect and discernible difference in the speed of the sweep of the gauge when I choose the different entries in ardu-stim.

So for my intended entries and the RPM scaler field I can enter a number above zero for automatic sweep - correct?

thanks

Glenn