It is a racing sidecar, I am using my foot to change gear. Gear change is on my right foot as opposed to traditional left foot changing on a solo. This means I need a linkage to change gears as the gear selector is still on the left side of the engine. (When looking from behind).

The rules do not state anything with regards to gear changes. There are pneumatic, finger button gear changes available. All cost a lot of money though.

I always take a laptop with me anyway, as I can alter fuel maps with it. The ease is not having to work out the delay time I get by adjusting a pot vs typing the delay time into some code. I might need to up the delay time by 10 ms. Easy enough in code. I would have some calculations to do with a pot and how would I accurately change it by 10ms?

I like the idea of a cam to push a microswitch, however, I am more interested in the hall sensor as there are no moving parts involved. I can envisage a microswitch getting destroyed quite easily.

Here are a few pictures of my sidecar. You can see the gear linkage has a quickshifter installed already (This has since been broken). This sidecar has the ignition cut built into the ECU so all I need is a hall sensor to get it working again. The circuit I am trying to build is for my brothers sidecar, his ECU can only cut the ignition with a HRC quickshifter so I need an ignition kill circuit and a sensor.



Here you can see the gear change on the left side of the pic.

 

I have rewritten the sketch, it will now only trigger a detection if the sensor has changed state for over 1ms. I can adjust this delay also.

With testing at home I can see that it needs to be in this state for at least 100 passes of the Arduino main loop. I am hoping this will make a difference and plan to test it later.

 

I would have some calculations to do with a pot and how would I accurately change it by 10ms?

I'm not buying it.

If the timer circuit is set up correctly you could have the pot setup with a range of however many mS you want. say 10 at one end of travel and 100 at the other so making an adjustment of a few mS is as easy as turning the pot a bit one way or another. Especially so if a multi turn pot is used.

It's like using a light dimmer device. Do you use a uC and reprogram it's mS firing delay time for each cycle of the AC power every time you change your light brightness or do you just turn the know up or down to vary it a bit?

 

I'm not buying it.

If the timer circuit is set up correctly you could have the pot setup with a range of however many mS you want. say 10 at one end of travel and 100 at the other so making an adjustment of a few mS is as easy as turning the pot a bit one way or another. Especially so if a multi turn pot is used.

It's like using a light dimmer device. Do you use a uC and reprogram it's mS firing delay time for each cycle of the AC power every time you change your light brightness or do you just turn the know up or down to vary it a bit?

I am not interested in the brightness of the light being precise. I am however interested in the delay time being exactly what I set it to. Any variance and it could destroy the gearbox.

 

I was thinking about this and wonder if maybe they cut the transmissions differently from what your friend's was. I am used to running a back cut. The gears can not be forced apart once they are under load. You have to kill the motor to get them to unlock. Attached you can see how the dogs are cut. I had a little too much power for this transmission, note all the teeth missing...

It's no different than shifting any other manual transmission with or without using the clutch. Put some preload on the shifting mechanisms so that they are loaded sufficiently to jump out of gear and into the next one then drop the input power allowing them to move.

I do it 1000+ times a day when driving truck with a engine and transmission that is way bigger than any motorcycle.

 

I am not interested in the brightness of the light being precise. I am however interested in the delay time being exactly what I set it to. Any variance and it could destroy the gearbox.

I'm guessing you have no knowledge or experience with simple analog timer circuits and how they work or how a potentiometers range of travel directly relates to the timing cycle durations in such a circuit.

 

For reference.

Monostable Nomograph

So by selecting suitable values of C and R in the ranges of 0.001uF to 100uF and 1kΩ to 10MΩ’s respectively, we can read the expected output frequency directly from the nomograph graph thereby eliminating any error in the calculations. In practice the value of the timing resistor for a monostable 555 timer should not be less than 1kΩ or greater than 20MΩ

From here. http://www.electronics-tutorials.ws/waveforms/555_timer.html

As shown making a adjustable 0 - xxx mS monoshot output is done with nothing more than 1 capacitor and a potentiometer of the correct values.

In your case getting a adjustment range of 0 to whatever you want is just a matter of picking the two values that work together which using the online calculator, http://www.ohmslawcalculator.com/555-monostable-calculator , a 100K pot with a .47 uF capcitor would give a range of 0 to ~.5 seconds and if a 10 turn presion potentiometer, http://www.digikey.com/product-detail/en/tt-electronics-bi/7286R100KL.25/987-1130-ND/2408708 (~$17) was used a that timing range could easliy be dialed in at 1 mS resolution.

Put a dial readout know on it and you have a accurate visual reference in 1 mS increments for your adjustments as well. http://www.digikey.com/product-deta...j4bx0rfZlxh3quaIf-F53FD99P6OJfQ6OlRoCYv_w_wcB

You follow?

I'm not saying that it cant be done with a uC device but given the physical and electrical conditions making such a sensitive circuit reliable is a fair design challenge whereas with a 555 IC yo don't need much more than a diode and a 50 ohm resistor in series on the 12 volt supply line and a 1000+ uf capacitor to give it a stable enough power source to work reliably.

 

For reference.


From here. http://www.electronics-tutorials.ws/waveforms/555_timer.html

As shown making a adjustable 0 - xxx mS monoshot output is done with nothing more than 1 capacitor and a potentiometer of the correct values.

In your case getting a adjustment range of 0 to whatever you want is just a matter of picking the two values that work together which using the online calculator, http://www.ohmslawcalculator.com/555-monostable-calculator , a 100K pot with a .47 uF capcitor would give a range of 0 to ~.5 seconds and if a 10 turn presion potentiometer, http://www.digikey.com/product-detail/en/tt-electronics-bi/7286R100KL.25/987-1130-ND/2408708 (~$17) was used a that timing range could easliy be dialed in at 1 mS resolution.

Put a dial readout know on it and you have a accurate visual reference in 1 mS increments for your adjustments as well. http://www.digikey.com/product-deta...j4bx0rfZlxh3quaIf-F53FD99P6OJfQ6OlRoCYv_w_wcB

You follow?

Ok, so I could have made a slightly simpler circuit by replacing the Arduino with a monostable 555 circuit. I would still have needed the power MOSFET though (But maybe not the driver).

I guess I would also need to look into hardware debouncing that I can do in software currently.

Let's just agree I could have done it simpler if I was more experienced, but I didn't, because I'm not.

In the mean time I will test the circuit, with de-bounces added later on tonight.

 

Yea I follow. I've done PLC programing for years and something an analog circuit does with ease gets way more complicated to do reliably in software.

Given a 555 IC has a 200 mA sink or source capacity directly driving the GAte of a P channel power Mosfet with it would not be a problem.

 

I was thinking about this and wonder if maybe they cut the transmissions differently from what your friend's was. I am used to running a back cut. The gears can not be forced apart once they are under load. You have to kill the motor to get them to unlock

The one I was involved with was a flat four VW powered dragster. The dogs in the tranny gears were undercut to keep it from jumping out of gear under full power. They had to be unloaded to allow the shifts, they could not be forced out of engagement without either the ignition shut down or clutch. The driver used a "line lock" type button in the shifter knob.

 

Nice looking chassis OP! Could you please show some pictures of the drive wheel and hub?

I have played with shifting a fair amount using pneumatics. Some push button, some auto. The software gets a little more complex but really, I see nothing wrong with what you are trying to do, using a micro to perform the kill. Your engine looks injected. Does the ECM have no way to do the kill? This may be an option as well.

The one I was involved with was a flat four VW powered dragster. The dogs in the tranny gears were undercut to keep it from jumping out of gear under full power. They had to be unloaded to allow the shifts, they could not be forced out of engagement without either the ignition shut down or clutch. The driver used a "line lock" type button in the shifter knob.

Makes sense. I assume the line lock was for starting. The transmissions do not all function the same like you may expect. This is the Robinson I currently use.

 

Makes sense. I assume the line lock was for starting. The transmissions do not all function the same like you may expect. This is the Robinson I currently use.

looks like the internals of a Harley trany. And similar to the VW bug trany.

 

I don't have any pictures of the rear hub. I will try to get some next time I go to the garage.

The sidecar shown, does have the ignition cut ability within the ECU. It is a Suzuki GSX R-600 K7 with a Yoshimura ECU. The sidecar I am doing the circuit for has a Honda CBR 600RR, with an HRC ECU, unfortunately this ECU does not have the functionality for killing the ignition (Unless you buy the HRC quickshifter).

Anyway, good news! I tested the circuit again tonight on the sidecar after making some modifications and it was working fine, it was cutting out the ignition when I brought the hall sensor close enough to the chassis and I was getting no false detections. I will have to do some more testing to make sure this is still the case at 16,000 rpm.

I have made one ceramic capacitor bigger and added another electrolytic capacitor on the sensor line. Circuit is shown below.

 

If it works good deal!

 

looks like the internals of a Harley trany. And similar to the VW bug trany.

Close.

The sidecar shown, does have the ignition cut ability within the ECU. It is a Suzuki GSX R-600 K7 with a Yoshimura ECU. The sidecar I am doing the circuit for has a Honda CBR 600RR, with an HRC ECU, unfortunately this ECU does not have the functionality for killing the ignition (Unless you buy the HRC quickshifter).
View attachment 113840

Good news indeed! Filtering in software is fairly common. You may need to play with it a bit but I'm sure you can get it to work.

Too bad about the ECM not having an input you can access. Now that we know there are two bikes, we need some pictures of the Honda as well!

Does the ECM use a wideband or knock. Just thinking with it not knowing about the kill, I wonder how it will react. Maybe just a little bang out the exhaust. Worse, I wonder if it will think something is wrong. Should be interesting. Maybe there is a way you could test it. Keep us posted.

 

Now I have got this circuit working, it got me thinking about the capacitor values I am using on the sensor pin. I didn't use any formula to work out what to use, I just used the biggest ones I had that fit onto the board.

My question is, can this cause any harm? Is there any benefit in reducing the capacitance?

I did revert my sketch to the previous version that had no debouncing present and it was still working fine, so it is pretty obvious that the capacitors I added are filtering out the noise.

 

All things considered being its an EFI engine you may be ahead on things to cut the power to the fuel injectors rather than the ignition.

Reason being even at a 60 mS ignition shutdown there will be ~ 8 injector firings happening per cylinder per thousand running RPM in that 60 mS time frame which means that if you are shifting at the upper RPM range of 6000 - 8000 RPM 50 - 60+ shots of fuel have been fired into each dead cylinder in that time frame.

 

I did revert my sketch to the previous version that had no debouncing present and it was still working fine, so it is pretty obvious that the capacitors I added are filtering out the noise.

I am not sure I follow. Did you revert the software to the previous version without the filter and that worked? By sketch it seems you changed the schematic that had no capacitors and it still worked.

 

All things considered being its an EFI engine you may be ahead on things to cut the power to the fuel injectors rather than the ignition.

Reason being even at a 60 mS ignition shutdown there will be ~ 8 injector firings happening per cylinder per thousand running RPM in that 60 mS time frame which means that if you are shifting at the upper RPM range of 6000 - 8000 RPM 50 - 60+ shots of fuel have been fired into each dead cylinder in that time frame.

I will have to do some more testing to make sure this is still the case at 16,000 rpm.

16,000 RPM = 267 RPS = 1 rotation in 3.75ms. 60ms kill covers 16 rotations or 8 injections for each cylinder (we know its a 4 stroke).

On a carbureted engine, the fuel will keep going into the engine as well. Should not be a problem if the ECM is fine with it.

 

As mentioned above, In 60ms, at 16,000 rpm. There are 8 missed ignitions per cylinder. The ECM does not throw any error codes when the sparks are stopped, I have tested it. There is a slight worry about unburnt fuel going into the cylinder, but my understanding is that it gets blown out of the exhaust valves and there may be some flames coming out the the exhaust when it ignites, which is always cool

I added an extra capacitor on the D2 line (470uF). And I also increased the capacitance of the ceramic capacitor right next to the pin from 22pF to 10uF. I think these hardware changes are what stopped the EMI causing issues. I say this because I reverted the code (sketch) on the Arduino to the previous version without debouncing, and with the new hardware added I was not getting any false detections.