MoTeC Global Forum

I'm currently interfacing an intelligent paddleshift system to an M800 and need to get the ECU to blip the throttle for as long as the blip input remains active. I've worked out a way of doing this by setting up a timer that's started and stopped by the blip input, then using this as an axis in the DBW comp. However, this only allows a maximum of 20% blip, just like in the position translation table (for safety reasons). This 20% is often enough on a bespoke race engine, but this particular production based engine needs more like 30-40% to be able to get a fast & smooth downshift. I can easily use the downshift blip function to give the required magnitude of blip, but it doesn't then allow the shift controller to determine the duration of the blip, which is the all-important aspect of the downshift strategy.

Any help would be gratefully received.

Hi Neil,

Is there any way you can tell the ecu what the blip duration is before you trigger the shift?? if you have a blip duration either as a voltage or comming in on CAN you can set this to the down blip duration table, then the down blip will occur for this duration.
Or are you monitoring RPM and cutting off the blip when the target RPM is reached, closed loop??

The problem with using the gear shift blip position and duration is they sample the table on the blip request so do not react to changes in their tables during the blip so cannot respond in closed loop.

You should be able to setup these two tables to do the correct blip open loop, or even if this was setup roughly as to reach a higher than needed rpm and use the RPM limit to cap the RPM closed loop??

There are ways around the 20% limit but all of these remove some of the DBW system saftey so are not recomended. The TP request limit is actually calculated on TPD x 2+ 20. So with 10% TPD the TP request limit is 40%. TPD of 40% is effectivly no limit.

Where is the 20% limit to the DBW Translation Comp?


Does this mean that if TPD = 10% that TP will only go 40% and thereafter into error?


What controller is this if I may ask?

Hi Darren,

The shift controller operates everything in closed-loop mode, including the blip. The target for the blip is the barrel position rather than RPM. However the blip target for downshifts is often different to the cut target on upshifts, so we can't use the internal MoTeC gear detection to end the blip. Besides which, our gearshift strategies are based on using ECU's that aren't as smart as MoTeC We also do some other clever stuff on downshifts, not just the blip

The reason we use barrel position for the blip target is twofold - firstly, it's the correct barrel position that we're trying to achieve, namely getting it into gear! Secondly, there just isn't the time to look at RPM's and do anything about it, because as soon as we're out of the current gear it typically takes about 1 engine revolution or less to make the next gear, and there simply aren't enough tacho pulses to make any sense of in such a short period of time.

Regarding the safety issue with the DBW control - that was partly the idea behind using a timer to get the variable blip. Even if the blip input remained "stuck on", the timer would expire and put the throttle back to zero. Initially I thought that there was no limit on the comp table (unlike the translation table where the F1 help warns that the maximum is 20%) but despite the table allowing higher values, the data logging shows that the blip never exceeded 20%.

I don't see how I can overcome the 20% because when we want to do the blip the driver is off the gas and TPD will be zero. So the maximum will be (2 x 0)+20. If the throttle was already open 40% then we could take it to 100, but then we wouldn't be doing the blip in any case! Hopefully in a couple of months time when I get the new GCU into production I will be able to do this using CAN, but the current GCU doesn't support CAN

Martin - for your information, the shift controller is "Geartronics" designed & made by us in the UK.

Cheers guys.

Just quickly Martin,
If the TP request goes above TPD x 2 + 20 then the TP request is simply limited to this value, doesn't cause an error. The request is based on the DBW translation table and comp table. DBW idle control is also limited by this with the only exception being the down shift throttle blip which has a maximum time limit of 1000mS so still has a safety margin. Having this functions means that we can allow other channels to control the throttle, but still give the driver control of the throttle at all times (down to 20%). Since other channels do not have an error checking dual inputs and usually not directly controlled by the driver, this is another fail safe.

Neil,
I can see how your strategy would work very nicely if you can get the throttle to behave the way you need.
Are you doing clutchless down shifts??

Yes it can be a little difficult to do closed loop by engine RPM in a very short time window, unless you have direct access to the internal engine RPM calculation which happens around 6000 times a second with a 60-2 trigger at 6000rpm, which we don't...
A timed method based on barrel position would be the next best i would expect!
Generally table values, ie DBW position translation are only calculated at 100Hz meaning if you could request the correct throttle position you would have a 10mS resolution anyway and generally 15 - 20mS delay in the throttle movement itself, depending on travel.
The best way to improve this would be to request a higher than needed throttle and therefore RPM and use an ignition cut, which is effictivly the same as closing the throttle instantly? A slight variation on setting a rev new limit like i suggest. I'm sure you could work it this way, basically on the falling edge of your 'Throttle Blip' pulse, cut the ignition for enough time for the throttle to close again.

What do you think??

Hi Darren,

Yes, downshifts are all clutchless, so the blip is critical to a successful (and non-damaging) shift. We already do a cut after blip, but not necessarily for the reason you suggest. However, there are a couple of reasons why this isn't a way around this particular problem. Firstly, when I tried this on an M800 a couple of weeks ago (can't remember which software version) the ECU would not act on a cut request signal while it was already servicing a DBW blip (feature or bug?) Secondly, the typical range of blip times that we see on big production engines (or indeed low inertia race engines that drop off the cam) can be anything from as little as 20ms to as much as 500ms! So, if we give it a 500ms blip and then cut the excess, the cut would need to be 480ms long to be sure of killing it dead, or we would need to do some maths to work out how long the cut needs to be - which would get very messy. Doing it this way would also interfere with the next shift. On 'proper' low inertia race engines in open-wheel cars (F3000 for example) the drivers will often call for 4 downshifts in less than a second! Having said that, the F3000 cars use proper throttles with a cable Remember those?

The next generation GCU (which should be out in January) will have CAN, so how do we do it then? Aren't the same safety features built into a CAN request?