[help needed] Hi from Narrabeen FZR250 plan

[ruckusman]

Hi There,

I've long been considering doing EFI on the 1989 FZR250 which needs an alternative to the problematic CV carbs!
There also no satisfactory, economical alternative to the carbs - there are Keihin FCR carbs at over $2000 a set, which is twice the value of the bike.

This thread gave me inspiration
https://www.2fiftycc.com/index.php?threads/cbr250rr-mc22-efi-project.11151/
Using the original carbs as throttle bodies was a very clever move and less expense and less hassle.

Anyway given that all of the service manuals are in Japanese, specs are scarce, we don't even have an ignition map, and it has an exhaust valve EXUP which I will keep.

The other basic hurdle to EFI on the bike has been the cost of the various ECU's - more than the value of the bike, great for a project if you happen to have an ECU laying around unused, but very unlikely to gather any momentum amongst other owners.

My stepwise approach is going to hopefully enthuse other 250 owners on the www.2fiftycc.com forums, as there are plenty of other that would love to do EFI, at the right price...


Then I spotted this project
https://grassrootsmotorsports.com/forum/build-projects-and-project-cars/diy-ecu-build-thread/79518/page1/

That's not the first page that I read about this project, but that's amazing work right there, and here we are.

I've done more reading than I probably should have before writing this message - hopefully I have absorbed enough to make sense and not too much so as to have confused myself, and as I am writing this message, it is getting longer than I had intended or anticipated...

Big shout out to @Old grey for the instructional videos
https://rusefi.com/forum/viewtopic.php?f=2&t=1566

I've got a hot air station for SMD work/rework, various mutlimeters and an oscilloscope - very old Hameg 205-3 - works!
I've done more soldering than I care to remember, up to and including SMD reflow to recover graphics cards and motherboards on occasion.
So I should be good to go - famous last words...

I have Tuner Studio downloaded, not yet installed, about to do the same for RusEFI - then start with a basic project to see what's what - sorry if some of these questions would have been answered by doing that first...

Plan
I intend to start with the stm32f4discovery brain board, not be difficult or obstinate, but to see if I should consider designing a custom board - the reasons for that will become clearer below.
I may go straight to to the MicroRusEFI and just add the extra injector daughter board.

EDIT
I've just seen the Proteus board specs - it's got everything required - will be getting the brain to experiment whilst I get in line for one of those - not going to reinvent the wheel when it already rolls just fine

As I don't have any of the bits and pieces required for EFI, so I'm going to start at the start - get a tachometer signal, replicate it and and obtain an ignition advance map.

I don't know if the crank sensor is a hall effect sensor or a VR sensor - things to learn...

Then I'll see if can put the brain in between the crank sensor signal and the OEM ignition box and have it running on the OEM ignition.

I've already read about the OP amp necessary to do that -
https://rusefi.com/forum/viewtopic.php?f=2&t=242
I think the above will be handy as I sort the replacement of the OEM ignition

Then sort out the exhaust valve controller.
Then I can get OEM ignition control replaced.

That part right there may be of particular interest to other older bike owners with failed ignition boxes, or just if they would like adjustable ignition curves

Currently the bike runs TCI ignition, wasted spark, I'd like to convert it to sequential spark with pencil coils.
The pencil coil conversion has already been done with the wasted spark configuration. I'm aiming for sequential from the outset.
From there going to CDI with pencil coils.

I also need to read up on whether or not the coil dwell time is configurable to avoid going to pencil coils which can work with TCI and then having to purchase another set which works with CDI. - Work for me to do.

The DC CDI will hopefully just be a dumb, 4 channel igniter unit which takes the signal from the brain board as I don't want that sort of voltage travelling across the bike from the ECU to the coils.
Open to suggestions on dumb CDI igniters, needs to be 4 channel obviously or I might just get 4 GY6 units and rehouse them.

The reason for the CDI ignition is that they rev to 18K RPM and actually make max power at 16K RPM - that is where they get really fun - think Formula 1 Sound at almost legal speeds. Power drops off sharply, there may be many reasons, valve float, airbox &/or carb &/or exhaust restrictions or spark strength, or all of those things.

So I'll need to sort out a cam position sensor - I already have an idea on the potential location.
More research to do, for instance would the cam position sensor for #1 firing need to indicate that cylinder is about to fire @ maximum advance, which for this bike is 44 degrees BTDC.

I literally do not have an EFI bike available to be able to check that - it's just something which makes sense to me, no point telling an ignition control box that a cylinder is about to fire after it should have fired when the advance is at maximum.

I have question on placement of the MAP or MAF sensor as the bike obviously has 4 carbs, so is there a preferred location for the sensor and what length tubing would likely adversely affect the vacuum signal received.
I think the most sensible placement of the tubes themselves is the rubber carb manifolds which go to the cylinder head as they already have facility for tube connections to a manometer used when balancing the carbs.

I assume a 4 -> 2 -> 1 tube of the correct stiffness to the MAP or MAF sensor will give a clear signal for the ECU.
Question, will the ECU with cam position sensor be able to differentiate which cylinder is on the intake stroke to be able to balance the throttle bodies?

MAP or MAF - I know this is an open debate, so I have more to read.

Obviously a TPS is absolutely necessary as is a wideband O2 sensor and a 300 KPA fuel pump, intake air sensor and calibrate the NTC coolant temperature sensor.

Now the reason for staged injection - these little bikes although they're only 250's are very driveable at lower revs by virtue of the exhaust valve, it creates enough back pressure in the exhaust at low RPM so that the valve overlap doesn't see a significant amount of short circuiting of fresh charge straight out of the exhaust, yet maintains excellent high RPM performance - no this isn't a sales brochure - I actually commuted 75Kms/day for 2.5 years on this bike - they're loads of fun to ride at all speeds.

So I want to have a small injector for low RPM very close to the cylinder head to give good idle and low RPM response and a larger shower injector for higher RPM - spraying into the venturi.

I'll stop now, so as not to inundate everyone with this first message

Glenn

[mck1117]

I also need to read up on whether or not the coil dwell time is configurable to avoid going to pencil coils which can work with TCI and then having to purchase another set which works with CDI. - Work for me to do.

Everything is configurable - any reasonable dwell is possible. The biggest benefit of running sequential instead of wasted in your scenario is that at high RPM you might not have enough time to charge the coil twice per engine cycle.

So I'll need to sort out a cam position sensor - I already have an idea on the potential location.
More research to do, for instance would the cam position sensor for #1 firing need to indicate that cylinder is about to fire @ maximum advance, which for this bike is 44 degrees BTDC.

rusEfi doesn't care where your sensor(s) are located - the firmware synchronizes on the trigger wheel(s) and figures out the appropriate time to fire spark/fuel/etc. However, you'll get the best resolution (and ease of starting) with a wheel on the crankshaft with many teeth (lots of cars have 60, but that's not a good idea at 20k rpm - I'd recommend a 12-1 wheel or something. 12 teeth, one missing so you can find the "zero" point).

I assume a 4 -> 2 -> 1 tube of the correct stiffness to the MAP or MAF sensor will give a clear signal for the ECU.
Question, will the ECU with cam position sensor be able to differentiate which cylinder is on the intake stroke to be able to balance the throttle bodies?

MAP or MAF - I know this is an open debate, so I have more to read.

Obviously a TPS is absolutely necessary as is a wideband O2 sensor and a 300 KPA fuel pump, intake air sensor and calibrate the NTC coolant temperature sensor.

We don't currently support detecting per-cylinder MAP (based on timing), but do phase the sampling of the MAP signal such that it's at a predictable point in the engine cycle. Probably best to balance the throttles using the normal methods, not using the ECU.

MAP vs. MAF: in your case, MAF would be pretty hard as you'd need a plenum before the throttles that feeds thru a single hole, BMW E46 M3 style. MAP (or even alpha-N aka TPS-only works just fine, especially for a bike that you want to be really snappy).

A TPS actually isn't strictly necessary, but in your case it probably is. I'd recommend running alpha-n at least to start, since MAP can be finicky on small engines with ITBs like yours.

So I want to have a small injector for low RPM very close to the cylinder head to give good idle and low RPM response and a larger shower injector for higher RPM - spraying into the venturi.

How large/small are you thinking of for the large/small injectors? It's very possible that you could install only the large injector in the lower position, and get good results. rusEfi has precise injection duration accurate to within <3-6us, so good quality modern injectors shouldn't have a problem even with relatively short pulses like at idle.

[ruckusman]

I am using this blog as my guide - https://www.cbr250rri.com/p/home.html

The net has plenty of EFI project starts on bikes, but many taper off into nothingness - Thomas has done a fantastic job of both finishing his project and documenting his process.

I also need to read up on whether or not the coil dwell time is configurable to avoid going to pencil coils which can work with TCI and then having to purchase another set which works with CDI. - Work for me to do.

Everything is configurable - any reasonable dwell is possible. The biggest benefit of running sequential instead of wasted in your scenario is that at high RPM you might not have enough time to charge the coil twice per engine cycle.

I'm using this blog page as my guide https://www.cbr250rri.com/2016/08/back-to-basics.html
He discovers the exact same phenomenon at higher RPM

So I'll need to sort out a cam position sensor - I already have an idea on the potential location.
More research to do, for instance would the cam position sensor for #1 firing need to indicate that cylinder is about to fire @ maximum advance, which for this bike is 44 degrees BTDC.

rusEfi doesn't care where your sensor(s) are located - the firmware synchronizes on the trigger wheel(s) and figures out the appropriate time to fire spark/fuel/etc. However, you'll get the best resolution (and ease of starting) with a wheel on the crankshaft with many teeth (lots of cars have 60, but that's not a good idea at 20k rpm - I'd recommend a 12-1 wheel or something. 12 teeth, one missing so you can find the "zero" point).

Thank you, that's exactly the sort information which I need - I do know for a fact that currently the bike has 3 short 1 long on the stator flywheel which I suspect is a VR pickup - to be confirmed

I will investigate design and placement of a 12-1 crank trigger wheel - would doubling that resolution 24-1 for a cam pickup yield any benefits, or are we in the same realm where there is such a thing as excess resolution there also?

Is a VR trigger worse, more difficult, less reliable than a hall sensor? I know from may forum posts and blogs I have read, signal condition and inversion, EMI noise and filtering have caught a lot of people out with VR sensors.

If I can spend time early on getting a good crank trigger it's very much apparent that it pays of in the long run, so I'll sort a hall sensor if it's advisable.

I assume a 4 -> 2 -> 1 tube of the correct stiffness to the MAP or MAF sensor will give a clear signal for the ECU.
Question, will the ECU with cam position sensor be able to differentiate which cylinder is on the intake stroke to be able to balance the throttle bodies?

MAP or MAF - I know this is an open debate, so I have more to read.

Obviously a TPS is absolutely necessary as is a wideband O2 sensor and a 300 KPA fuel pump, intake air sensor and calibrate the NTC coolant temperature sensor.

We don't currently support detecting per-cylinder MAP (based on timing), but do phase the sampling of the MAP signal such that it's at a predictable point in the engine cycle. Probably best to balance the throttles using the normal methods, not using the ECU.

Vacuum gauges it is, that's a proven method, I was just wondering if it was possible as I have seen that accomplished on a Triumph 675 with software and and the ECU interfaced to a laptop.

I could probably achieve it with a 2 channel scope looking at a crank/cam trigger and MAP output

MAP vs. MAF: in your case, MAF would be pretty hard as you'd need a plenum before the throttles that feeds thru a single hole, BMW E46 M3 style. MAP (or even alpha-N aka TPS-only works just fine, especially for a bike that you want to be really snappy).

Thank you - I have just yesterday seen a BMW MAF sensor picture which seems to live after the air cleaner and before the throttle body.
It seems to look across the airstream for want of a better description, so I assume that it simply would not work in a plenum connected across the 4 throttle bodies.

A TPS actually isn't strictly necessary, but in your case it probably is. I'd recommend running alpha-n at least to start, since MAP can be finicky on small engines with ITBs like yours.

Thank you, that confirms some other research which I have done which was related to 3d spark mapping based upon TPS and RPM - I will make that one of the early priorities

So I want to have a small injector for low RPM very close to the cylinder head to give good idle and low RPM response and a larger shower injector for higher RPM - spraying into the venturi.

How large/small are you thinking of for the large/small injectors? It's very possible that you could install only the large injector in the lower position, and get good results. rusEfi has precise injection duration accurate to within <3-6us, so good quality modern injectors shouldn't have a problem even with relatively short pulses like at idle.

I will probably end up doing just as you suggest, at least to begin with because I realise that staged injection isn't yet an option.
I have been researching very small injectors < 100cc/min amongst the Asian scooter market for the dual injector plan.
If I can find some just over 100cc/min for single injector setup which can be replaced by smaller ones in the future if possible if staged injection becomes available.

One a side note, I have been researching scopes and meters, two have my attention as they are budget conscious
Hantek 6022BE/BL and Hantek 1008C - both of which need a laptop which is fine

Any experience/recommendation with either of those or anything else for that matter

Rigol DS1054Z is a great option, but doesn't actually do a whole lot more than my 30 year old Hameg, except for having 4 channels and higher sample rates which are well beyond necessary for this.

The availability of a signal generator/ arbitrary waveform generator seems to be useful, if not essential for bench testing and measurement purposes.
I have installed TS and loaded the Proteus firmware to have a poke around...so I am less of a NOOB - need to compile the simulator which I will get to as a next step

Once that's done, and I at least get the brain hardware, I can use the stimulator function to generate ignition and injector pulse signals, is this correct?

Sorry for the NOOB questions, I'm just trying to get my head around a few workflow steps so that I can keep on track and not get discouraged.

[AndreyB]

Why compile the simulator? Does your bundle not have precompiled simulator?

Not to confuse simulator and stimulator.

We have buttons to triple pulse bench test outputs. Stimulator is usually not used with real injectors.

[mck1117]

Thank you, that's exactly the sort information which I need - I do know for a fact that currently the bike has 3 short 1 long on the stator flywheel which I suspect is a VR pickup - to be confirmed

I will investigate design and placement of a 12-1 crank trigger wheel - would doubling that resolution 24-1 for a cam pickup yield any benefits, or are we in the same realm where there is such a thing as excess resolution there also?

Is a VR trigger worse, more difficult, less reliable than a hall sensor? I know from may forum posts and blogs I have read, signal condition and inversion, EMI noise and filtering have caught a lot of people out with VR sensors.

If I can spend time early on getting a good crank trigger it's very much apparent that it pays of in the long run, so I'll sort a hall sensor if it's advisable.

There is such thing as excess resolution, when the teeth are so close together that it makes us spend a bunch of CPU time on decoding that doesn't actually give more accuracy for ignition. Of course it depends on the engine, but I think most of us would be hard pressed to tell the difference between anything over 6-8 teeth. If you're making a wheel for a 20k engine, 12-1 will be great. A 12-1 at 20k is the same tooth speed as a 60-2 (very common on car engines) at only 4000 rpm, so it's no problem for rusEfi to keep up.

if you're building a setup from scratch, it's probably best to run hall effect, as it's more tolerant of weird setups (VR sensors work best when the wheel geometry, speed, and sensor geometry are all designed together). The ZF 1005/1007 sensors are widely used as hall effect swap sensors, are simple to interface with, and are available from normal electronics distributors. Here's the datasheet:

Datasheet_GS1005-GS1007_Letter_EN.pdf

(352.03 KiB) Downloaded 208 times

The availability of a signal generator/ arbitrary waveform generator seems to be useful, if not essential for bench testing and measurement purposes.
I have installed TS and loaded the Proteus firmware to have a poke around...so I am less of a NOOB - need to compile the simulator which I will get to as a next step

Once that's done, and I at least get the brain hardware, I can use the stimulator function to generate ignition and injector pulse signals, is this correct?

If you get ahold of the stm32f4 discovery board, you can run the proteus firmware on it. The "self stimulation" feature injects a fake trigger signal in to the software (and optionally outputs it on a hardware pin too) so that you can play with "running the engine" without a real engine. That includes injector/ign outputs, analog sensor inputs, etc. As far as the ECU is concerned, the engine is actually running.

[ruckusman]

Why compile the simulator? Does your bundle not have precompiled simulator?

Not to confuse simulator and stimulator.

We have buttons to triple pulse bench test outputs. Stimulator is usually not used with real injectors.

Hi Andrey,

I've been trying to compile the simulator all afternoon keep running into an error when I just try to run make in the simulator directory

Compiling chcore.c
clang: error: unsupported argument '-alms=build/lst/chcore.lst' to option 'Wa,'
make: *** [build/obj/chcore.o] Error 1

Searching for a solution to the error has been vexing

I used to run linux and this Macbook doesn't yet have all of the development tools installed - working on it

I may have solved it as I'm installing binutils now - famous last words...

EDIT - nope I just checked, that wasn't it

I've also tried compiling against three different versions of ChibiOS with the same result

Should I post this on github

Let me know which details are important

Let me know

[AndreyB]

I've also tried compiling against three different versions of ChibiOS with the same result

You are not doing it right. There is only one version of ChibiOS - the one linked to rusefi git repository as git submodule, and our Makefile is even trying to download it. Manually getting ChibiOS is a major red flag.

One way you might have got a corrupted set of files would be if you went with "download .zip" githib option instead of proper git cloning.

Please do not waste time trying to compile anything from master.zip

[ruckusman]

I've just cloned the git repository again - it gets as far as cloning eveything back into the rusefi folder - then starts the compilation again and falls over on the same related error on a number of files

Here's the output from make

Code: Select all

No CCACHE_DIR
OS is []
Compiler Options
gcc -c -Wall -O2 -Wno-error=implicit-fallthrough -Wno-error=write-strings -Wno-error=strict-aliasing -m32 -ffunction-sections -fdata-sections -fno-common -std=gnu99 -Wall -Wextra -Wundef -Wstrict-prototypes -Wa,-alms=build/lst/ -DSIMULATOR -MD -MP -MF .dep/build.d -I. -I. -I../firmware/ChibiOS/os/license -I../firmware/ChibiOS/os/common/ports/SIMIA32/compilers/GCC -I../firmware/ChibiOS/os/common/ports/SIMIA32 -I../firmware/ChibiOS/os/rt/include -I../firmware/ChibiOS/os/common/oslib/include -I../firmware/ChibiOS/os/hal/osal/rt -I../firmware/ChibiOS/os/hal/include -I../firmware/ChibiOS/os/hal/ports/simulator/posix -I../firmware/ChibiOS/os/hal/ports/simulator -I../firmware/ChibiOS/os/hal/boards/simulator -I../firmware/util -I../firmware/util/containers -I../firmware/util/math -I../firmware/init -I../firmware/console/binary -I../firmware/console -I../firmware/console/binary_log -I../firmware/config/engines -I../firmware/ext_algo -I../firmware/hw_layer -I../firmware/hw_layer/adc -I../firmware/hw_layer/digital_input -I../firmware/hw_layer/digital_input/trigger -I../firmware/hw_layer/sensors -I../firmware/hw_layer/algo -I../firmware/hw_layer/drivers/can -I../firmware/hw_layer/sensors -I../firmware/development -I../firmware/controllers -I../firmware/controllers/system -I../firmware/controllers/system/timer -I../firmware/controllers/algo -I../firmware/controllers/algo/airmass -I../firmware/controllers/algo/fuel -I../firmware/controllers/engine_cycle -I../firmware/controllers/trigger/decoders -I../firmware/controllers/trigger -I../firmware/controllers/sensors -I../firmware/controllers/sensors/converters -I../firmware/controllers/can -I../firmware/controllers/core -I../firmware/controllers/gauges -I../firmware/controllers/math -I../firmware/controllers/generated -I../firmware/controllers/actuators -I../firmware/controllers/actuators/gppwm -I../firmware/controllers/serial -I../firmware/ChibiOS/os/various -I../firmware/ChibiOS/os/hal/lib/streams -Isimulator main.c -o main.o

Compiling chcore.c
Compiling chsys.c
Compiling chdebug.c
clang: error: unsupported argument '-alms=build/lst/chcore.lst' to option 'Wa,'
clang: error: unsupported argument '-alms=build/lst/chsys.lst' to option 'Wa,'
Compiling chtrace.c
make: *** [build/obj/chsys.o] Error 1
make: *** Waiting for unfinished jobs....
make: *** [build/obj/chcore.o] Error 1
clang: error: unsupported argument '-alms=build/lst/chdebug.lst' to option 'Wa,'
clang: error: unsupported argument '-alms=build/lst/chtrace.lst' to option 'Wa,'
make: *** [build/obj/chdebug.o] Error 1
make: *** [build/obj/chtrace.o] Error 1
Simulator compilation failed

I cannot find this anywhere in the code files -Wa,-alms=build/lst/ and I don't know where that option is coming from

Going to give grep a whirl...

[ruckusman]

Just a quick outline of what's installed

Xcode
XCode command line tools

gcc
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin14.5.0
Thread model: posix

g++
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin14.5.0
Thread model: posix

libtool

this is clearly an issue at my end, not with your work - it has me truly stumped

[AndreyB]

Do i see "clang"? Well, great news we are not trying to use Visual Basic to compile rusEFI but why is clang mentioned in any relation to rusEFI?

I could also be very wrong about any part of anything.

[AndreyB]

https://github.com/rusefi/rusefi/issues/1848 created please consider helping with this change request.

[ruckusman]

Changed the build environment variables so that it's calling GCC not CLANG - got it working up to the last step

Details posted on the github page