@ Reinhard Ostermeier - I also like the hardware LCD driver of the G120(and G400) board over the Cerb’. Using that can be handy for debugging as you can do plot data for instance without all the performance hit of Debug statements. With the emc overclock the external RAM performance hit is not too bad.
That said the G400 is much much faster than both. If the budget stretches it means you might not have to spend so much time tweaking the code for performance gains.
@ HypersonicHonda, what is your budget like? Also, are you really two thousand and fourteen years old 
I think that’s only from our point of view as observers. He’s travelling so fast that he barely ages at all. 
Yes, as mentioned above a data logger would be an excellent idea, both for seeing current state and seeing the effect of the system.
Yes the response time does need to be fast. The one system I saw on line (I posted the video for that) measures acceleration of the wheel from pulse to pulse i.e. with 8 pulses per revolution of the “drive shaft” (of a car). It therefore learns from a couple pulses back what the acceleration “should” be and if it falls outside a certain parameter it starts to kick in some engine restriction.
Yes I am 2014 years old 
No actually I am 45… I will see if I can find where it shows that and change it.
Budget: Not really on a budget, I would say from a purchasing perspective I want to buy what is going to be the most reliable, durable and trouble free.
If speed is an issue, then I want the fastest unit. All these withing some sort of reason I guess. To put matters in perspective the unit that is commercially avialable start around $800 for a real dumbed down unit (which really would NOT work for drag racing very well) all the way up to about $4,000 or $5000 for a good “self learning” drag unit.
Obviously I would love to do it cheap, but it would not bother me for example to spend $100 on a controller versus a $20 to gain ease of use, speed or whatever. So I guess I am looking for the upper end of what can be attained??
Humm, determining speed based on time between pulses; that requires a counter for sure.
Can you tell us more about this self learning feature? Or is it just a math equation between shaft speed and engine speed.
Will the system need to interface with the ECU?
I’ll have a go at implimenting the pseudo code I posted earlier to see what can be achieved performance wise on the G120 and G400(possibly cerb if I can be bothered). I suspect better would be possible with RLP and some clever use of the hardware pin capture features, but I’ll stick with the GHI code for now. The hardware timers on these things are pretty flexible, but NETMF only exposes a small amount of what’s possible.
I think the easiest way to do this would be to hook an hardware PWM straight to a GPIO input. That should be easy to duplicate. I can hook up some pretty beffy signal generators if I need to, but better stick to what others can replicate.
basic algorithm (the constants need tweaking - number of times per sec, threshold, gain_factor):
c0 = -1;
100 times per sec do:
c = count of pulses from wheel
if (c0 == -1) { c0 = c; return; }
delta = c - c0;
if (delta > threshold)
{
//decrease power… proportional with delta;
//output is the resulting throttle applied to the engine
//desired is the desired throttle applied by the user(pilot?)
output = desired - (delta - threshold) * gain_factor;
}
else
{
output = desired;
}
c0 = c;
Some back of envelope calculations.
Say the max speed of interest is about 60mph
60mph = 26.8 meters per second
A 17" wheel has a circumference of about 2.7 meters
So 26.8 / 2.7 gives about 10 revolutions per second.
Assuming the sensors are built to give 10 pulses per revolution the pulse repetition rate we need to be able to measure is about 100Hz.
I have done some tests on the G120 using the SignalCapture() method and can measure anything up to and over 10KHz. At this speed it makes about 2500 measurements per second so it does miss a few pulses between measurement. Overall I think the NETMF hardware is easily fast enough to support this task.
Also, I think that if possible it would be best to have of the order of 100 pulses per revolution to be able to measure and react to any wheelspin rapidly the hardware should be able to handle this easily.
I will post my code on Codeshare shortly.
Hi guys, sorry for the late response.
I saw a couple questions:
They were not specific on how many pulses it would track backwards to compare to.
It might be something that has to be fiddled with to get a proper response.
Thanks so much for helping!
I look forward to see how the Pseudo code works!
I’m guessing after that testing you will know what controller(s) to use?
Thanks a ton!
Some follow up data. I calculated the pulse per revolution of the rear tire that the other system uses. Based on an assumed rear axle ratio of 4.11 to 1 and a rear tire overall diameter of 26" it works out to be about 33 pulsed per revolution of the rear tire on a drag car.
So if we were to use the 6 bolts that hold on a rear sprocket for a pulse pick up (many systems for motorcycles do in fact use these bolts) then we would be at 6 pulses per revolution of the tire. I am guessing this is still enough, however if needed I could install a set of ABS sensors on the bike and that unit has roughly 30 to 60 slots in it’s pickup disk.
I guess if other people can make elaborat traction control systems using the 6 bolts as pick up point, then we should be be safe to assume that it would work for our purposes as well. So maybe keep it simple and use the bolts and see if it works??
The numbers are below in a screen shot of an excel file.
with 6 pulses per revolution of the rear tire, that equates to about 1.1 feet traveled per pulse.
Those numbers look about right to me.
The method I suggested will miss alternate pulses as it has to sit and wait for a high start state before triggering the capture.
A slight tweak… I saw your numbers using 60MPH to calculate pulse rate etc. (using 10 pulses per wheel revolution)
Actual speed can be in excess of 150 to 160 MPH, possibly up to 200 MPH in super extreme cases…
So that might change things some.
Also after doing some research the methods that the manufactures use seem to boil down to two methods, one superior to the other.
a reactive system, which is what we have been discusing. i.e. monitor for sudden acceleration then react with a correction. The theory is this is somewhat inferior in that the slip has exceeded that maximum traction value and hence the vehicle (car or bike doesn’t matter) is no longer at peak acceleration during the correction phase. This is probably a wonderful situation for street use, and race track (not drag track but race course) use. However in DRAG RACING it may not be the best version.
a predictive actively monitored system. This system can actually measure wheel slip real time and predict when a loss of traction will occur and PREVENT it from happening.
This type of system would keep the power at the absolute edge of loosing traction providing the most acceleration possible.
As it turns out there is a percentage of wheel slip that is actually desireable. <— Ironic, I know, and counter inuitive. From what I have researched, the best traction / acceleration is obtained when the real wheel “slip” is somewhere between 6% and 15%. Go figure.
So realistically to make the best system possible you need to be able to determine (learn?) at what point the slip is too much (i.e. breaks totally free) and keep the bike just under that level of slip. To determine slip requires monitoring not just the wheel speed but the ground speed also.
On the more sophisticated systems they monitor the front wheel speed and compare that to the rear wheel speed. But that introduces another problem: Wheelies. Once you are in a Wheelie. your data from the front wheel is Garbage.
Soooooooooo, the big question is: is it possible through some kind of sensor to accurately and quickly measure true ground speed, maybe some kind of laser speed sensor, infra red sensor or maybe even GPS (I don’t like GPS because you could loose a signal in bad weather)??
weather is seldom a real issue for GPS. Things like multipath(reflections from buildings etc) are. From what I’ve been told GPS can be actually very accurate for velocity measurements and is derived from the received Doppler frequency rather than just measuring the distance between 2 fixes. With a good antenna that is well positioned it is possible to get 100hz updates.
This UK company specialises in this sort of thing. I seem to recall that they could actually measure the sideways slip of formula 1 cars going round corners.
I’d forget about your average commercial grade receivers like surf, ublox etc etc. They filter the results like he’ll to make the positions look good.
The other possibly cheaper alternative is MEMS based accelerometers. The integral of acceleration is velocity. Doing this can introduce drift, but a drag run is over pretty quick anyway.
Sorry to have walked away from this for so long! :-[
I’m back to where I think I might have some time to work on this.
I don’t know if there was ever any real consensus on what controller to get?
I would like to dive in and at least buy the controller and whatever I need for prototyping to start with.
Do they have a sales team at GHI or… are you guys thinking a different controller?
Thanks again!
They certainly have sales people who can help you.
Try contact them directly: