Lets talk realtime embedded systems!
Where's my coffee?...
01-19-2004, 09:13 PM
#20
Registered User
Join Date: Oct 2003
Location: Grayslake, IL
Posts: 485
Likes: 0
Received 0 Likes
on
0 Posts
Indy car? 18k? Oh, IRL! 
I *did* used to work on CART EFI systems FWIW.
You're not getting a tooth per degree, the sensor wouldn't keep up. Maybe you've got a tooth every 10deg. So you've got some math to do to determine the engine speed. Include acceleration/deceleration, and some filtering perhaps?
My 8ms quote was based on 180deg of rotation (1/2 of the compression and 1/2 of the exhaust cycles) at 4k. It's likley that the pulses will be much closer together. And with any multi-cylinder engine you're going need to consider having concurrent events.
Yes, at 4k you're looking at 24000 degrees/second. And with a 3GHz CPU you've got 125000 clocks per degree. Sounds like a lot, eh? But you've got other things to do. You can't just spin in a loop and be at timer. IMHO the complexity requires some sort of tasking model. And context switching becomes an time waster.
That's where the hardware comes in. You program it with some time/angle you want the events to occur, and it generates the waveforms. Once a tooth you go off and service it, updating what needs to be updated. This leave plenty of time for other things. And has the timers all operating in parallel with good accuracy. It decouples you from the precise tasks. If nothing else it makes SW development sane.
A DAQ board from NI would sample this data. And it does. I can vouch for that. But can it do math on that and generate accurate output waveforms "real time". There are some "hardware in the loop" boxes that can. But, they are very expensive, and I'd suspect they've got some custom timer hardware too.
Plus keep in mind that the original post was talking about having the PC controlling the ECU via some sort of serial link. I maintain that the latency in that link would kill you. Plus using Linuxworks led me to think that the poster hadn't thought of the timing issues involved fully.
Maybe I'm just lazy and spoiled, but I'd think you would be crazy to try an do this unless you really knew what you were doing. NOT just the digital side, the software, but the engine-specific details as well.
I *did* used to work on CART EFI systems FWIW. You're not getting a tooth per degree, the sensor wouldn't keep up. Maybe you've got a tooth every 10deg. So you've got some math to do to determine the engine speed. Include acceleration/deceleration, and some filtering perhaps?
My 8ms quote was based on 180deg of rotation (1/2 of the compression and 1/2 of the exhaust cycles) at 4k. It's likley that the pulses will be much closer together. And with any multi-cylinder engine you're going need to consider having concurrent events.
Yes, at 4k you're looking at 24000 degrees/second. And with a 3GHz CPU you've got 125000 clocks per degree. Sounds like a lot, eh? But you've got other things to do. You can't just spin in a loop and be at timer. IMHO the complexity requires some sort of tasking model. And context switching becomes an time waster.
That's where the hardware comes in. You program it with some time/angle you want the events to occur, and it generates the waveforms. Once a tooth you go off and service it, updating what needs to be updated. This leave plenty of time for other things. And has the timers all operating in parallel with good accuracy. It decouples you from the precise tasks. If nothing else it makes SW development sane.
A DAQ board from NI would sample this data. And it does. I can vouch for that. But can it do math on that and generate accurate output waveforms "real time". There are some "hardware in the loop" boxes that can. But, they are very expensive, and I'd suspect they've got some custom timer hardware too.
Plus keep in mind that the original post was talking about having the PC controlling the ECU via some sort of serial link. I maintain that the latency in that link would kill you. Plus using Linuxworks led me to think that the poster hadn't thought of the timing issues involved fully.
Maybe I'm just lazy and spoiled, but I'd think you would be crazy to try an do this unless you really knew what you were doing. NOT just the digital side, the software, but the engine-specific details as well.
01-22-2004, 05:49 AM
#21
Registered User
Join Date: Jan 2004
Location: Dayton, OH
Posts: 61
Likes: 0
Received 0 Likes
on
0 Posts
Originally posted by stevenknapp
A DAQ board from NI would sample this data. And it does. I can vouch for that. But can it do math on that and generate accurate output waveforms "real time". There are some "hardware in the loop" boxes that can. But, they are very expensive, and I'd suspect they've got some custom timer hardware too.
Plus keep in mind that the original post was talking about having the PC controlling the ECU via some sort of serial link. I maintain that the latency in that link would kill you. Plus using Linuxworks led me to think that the poster hadn't thought of the timing issues involved fully.
Maybe I'm just lazy and spoiled, but I'd think you would be crazy to try an do this unless you really knew what you were doing. NOT just the digital side, the software, but the engine-specific details as well.
A DAQ board from NI would sample this data. And it does. I can vouch for that. But can it do math on that and generate accurate output waveforms "real time". There are some "hardware in the loop" boxes that can. But, they are very expensive, and I'd suspect they've got some custom timer hardware too.
Plus keep in mind that the original post was talking about having the PC controlling the ECU via some sort of serial link. I maintain that the latency in that link would kill you. Plus using Linuxworks led me to think that the poster hadn't thought of the timing issues involved fully.
Maybe I'm just lazy and spoiled, but I'd think you would be crazy to try an do this unless you really knew what you were doing. NOT just the digital side, the software, but the engine-specific details as well.
About the Indy or IRL example, I was just trying to make the problem really difficult by using 1 timing mark per degree. I knew it wasn't realistic.
01-22-2004, 09:11 AM
#22
Registered User
Join Date: Oct 2003
Location: Grayslake, IL
Posts: 485
Likes: 0
Received 0 Likes
on
0 Posts
About the Indy or IRL example, I was just trying to make the problem really difficult by using 1 timing mark per degree. I knew it wasn't realistic.
Actually....18k is low, at least for our CART controller. We did have a "factor of safety" in it. We told them how fast it could go, they said "Fast enough". The customer set the rev limit, that bit was a bit hush hush, so I don't know where exactly that was.
There becomes a limit of how many teeth you can have before the sensor just sees a solid wheel. But even so, you've got more than 1deg accuracy in a production car even.
Actually....18k is low, at least for our CART controller. We did have a "factor of safety" in it. We told them how fast it could go, they said "Fast enough". The customer set the rev limit, that bit was a bit hush hush, so I don't know where exactly that was.
There becomes a limit of how many teeth you can have before the sensor just sees a solid wheel. But even so, you've got more than 1deg accuracy in a production car even.
Thread
Thread Starter
Forum
Replies
Last Post
JWillms81
3rd Generation Ram - Non Drivetrain - All Years
28
05-28-2008 11:08 PM
Dan Marino
3rd Gen High Performance and Accessories (5.9L Only)
4
04-25-2008 11:01 AM