question about ADC vs RCTIME
paysonbadboy
Posts: 81
On my project I'm trying to interface a Throttle Position Sensor to my PBASIC2 controller. This is for my EFI project on my ATV.
The Throttle Position Sensor (TPS) is just a pot. The simplest way to interface it to the controller seemed to be using the RCTIME command. But I'm thinking that operation may be too slow for what the controller has to do. It needs to be able to fire the injector 50 times per second and therefor take that sample really quickly.
When I'm doing this watching the screen with the debug feature it seems to be doing what I want. But that doesn't tell me if it's taking the TPS reading fast enough not to miss the next cycle thus actually only firing my injector every other cam pulse or so.
So, would it be better to use some sort of Analog to Digital interface? Would that be able to send the data·to the controller faster than the RCTIME sequence does?
I saw some cheap ADC in my digikey catalog. never used one of them chips before. Are they all serial or can·I find a low bit one (like 4 bits or 8 bits) that could just directly connect to 4 or 8 I/O pins and use programming to calculate the reading.
Anyone have any ideas on this?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.paysonarizona.net/
The Throttle Position Sensor (TPS) is just a pot. The simplest way to interface it to the controller seemed to be using the RCTIME command. But I'm thinking that operation may be too slow for what the controller has to do. It needs to be able to fire the injector 50 times per second and therefor take that sample really quickly.
When I'm doing this watching the screen with the debug feature it seems to be doing what I want. But that doesn't tell me if it's taking the TPS reading fast enough not to miss the next cycle thus actually only firing my injector every other cam pulse or so.
So, would it be better to use some sort of Analog to Digital interface? Would that be able to send the data·to the controller faster than the RCTIME sequence does?
I saw some cheap ADC in my digikey catalog. never used one of them chips before. Are they all serial or can·I find a low bit one (like 4 bits or 8 bits) that could just directly connect to 4 or 8 I/O pins and use programming to calculate the reading.
Anyone have any ideas on this?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.paysonarizona.net/
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Dallas, TX· USA
Another thought I had was to also use a second Controller. One to calculate all the inputs, TPS, O2, MAP, etc and then send out a value via the I/O pics to the 2nd controller that would just monitor the cam sensor and vary the pulse width by calculating some fixed data to the data it got from the 1st controller. Then I wouldn't need to worry about bogging down one controller by having to monitor all the inputs and try to control the injector in such short timing cycles.
I've got a pair of PBASIC2 controllers coming. Been like two weeks or more since·I won them on ebay. That last to sellers I've dealt with·on ebay have been slow as heck with sending the products.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.paysonarizona.net/
Also, using a smaller capacitor will reduce the time needed for the RCtime.
Dave
Sometimes having a few DEBUG commands will noticeable slow down the program. It is a great tool to see if everything is working as it should, but dont use it if you need to test the exact timing of your program.
I've never really tried using the RC time method, so I am biased, but I've had great results using both the LTC1298 & MAX1270 12-bit converters, and they are both relatively easy to use. Moreso the LTC1298, tho. You can get both from Parallax. 12 bit might be overkill for a TPS, but it would be good for something like an O2 sensor whose minimum to maximum readings are both relatively small (at least the GM ones are). Not sure what kind of vacuum those ATV's pull, or what kind of sensor you plan to use, but IMO the more resolution the better.
Post Edited (The Lazy Destroyer) : 2/9/2005 12:21:25 AM GMT
I also thought about the smaller cap. It has less resolution when I use the smaller cap but I think I did have too big of a cap in there.
the charge time on a .01MF could be a big difference compared to a .1MF cap now couldn't it?
As for a ADC I figured 4 bits would even be enough I bet and 8 would be great. So, how many I/O pins do i need to read from a ADC and if that is SERIAL wouldn't that take a certain count of cycles as well to complete?
I was thinking if I used the dual controllers idea and simply found a way to say use 8 I/O pins to send data form one to the other and having the second one just look at those 8 pins in a single command line (if possible) and adjust the pulse width using one fixed calculation that I would have plenty of speed even using the PBASIC2 controllers i plan on using rather than my one sx.
Now. Anyone know of a quick way to make one contoller change a calculated value into say an 8 bit binary output (256 steps) and then for the second one to read that as 8 bit value with any sort of commands? I fiugured that would take less cycles than serial data between the two. They don't even need to be in exact sync with each other. As long as the first controller places a output value per the input devices for the second controller to use on it's next cycle that should work.
I know many car controllers are'nt even really fast. Watch how some EFI cars breifly blow a black cloud of smoke (rich) when someone goes to wide open throttle quickly.
Anyway. What do you think? Does the ADC have to be serial form the chips you speak of? Or can I send from one controller to another like I am thinking?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.paysonarizona.net/
Just be aware that the stamps won't receiver your rs232 stream unless it stops to listen to it.· So, you'd need to play with some flow control I'd guess.
If you're slave stamp is doing all this measuring....how often will you send the data to the master stamp?· Every cycle?· The Master stamp is only doing a couple measurements then controlling the EFI?....but then has to stop to 'listen' for the slave stamp stream....if you miss the stream then you'll be waiting longer than wanted.....
The slave stamp would be cycling (going from top to bottom of it's program) slower than the master (just a guess...but based on all the measurements) so, some fancy playing with timing/delays would be in order.· You're master might cycle 2 or 3 times before the slave is done.·
Have you looked in to PID coding for your EFI?· There was a nice article on it in the previous Nutz&voltz.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
Steve
http://members.rogers.com/steve.brady
"Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
what's that?
As far as using two controllers. I wasn't going to worry too much about the timing. I figured the one taking measurements from the TPS and what not would just set values on it's outputs each time it takes the measurement. I think from what i know the outputs would stay in the given state until it changes them when it re calculates the measurement of the input device(s). The second controller would just look at whatever values where there just before it calculates the pulsed output when the cam sensor input clocks it. I'd figure at higher RPM's the second one could very well fire the injector multiple times before the first one even makes a change to some of the outputs but who cares. It would still be responding faster than my hand would change the throttle position or some other changes so it wouldn't matter.
It's just that I don't see a way for a single controller to be gathering data from several inputs using commands like RCTIME and what not AND being able to calculate and fire the injector in the short timing cycle.
So. I'm sure I'd find a way with some math or something eventually, but is there any easy way that for instance could the second controller say use eight inputs and store them as an 8 bit value form the first one thus using one short cycle of that controller?
I wouldn't plan on using a clock signal or anything from the first one. Like I said the second one would take samples form the first one faster than the first one will change it's output values. But who cares.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.paysonarizona.net/
It's used in house thermostats and motor position control.· The January 2005 Nuts and Volts mag has a good article for beginners.
Basically, if you want the heater to turn on at 60degF, then you make a setpoint.··Now, when the thermostat reads the 60F, it turns off the heater and within a few minutes its back on.· Actually, you'll probably end up with a lot of chatter around the setpoint.
So they add some math to it which takes in to account the difference from the present reading and the setpoint.· I won't explain what each part of the P, I, and D offer (cuz I always get them confused)....but basically, they'll give you some nice smooth control.· There's been a couple threads on this already (try the search function).
The reason i suggest it, is I'm not sure what type of control you want from your EFI.· or what's likely in regular cars.· If you crank the throttle then you get an immediate reaction to your command.· Since you are using stamps, if you were to miss a measurement that would result in a null (or some other garbage) send to your EFI controller, then you might find you misfire due to this missed data.· A PID would buffer this affect somewhat (think of an elastic band....pull it hard in one direction and it'll fly nearly the same length to the other side but each time it crosses the middle/setpoint it doesn't travel as far and eventually will settle.·I think this is a good explanation of Proportional and Integrative).·
Anyhow, someone spent the time figuring out what time each function takes to execute in a stamp ( http://www.emesystems.com/BS2speed.htm·).· See if anything there is helpful.
But I think you're right about 1 controller being overworked.· If you have more than one controller....try them and as you figure out what you really need to do, then see if you can fit it in to one.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
Steve
http://members.rogers.com/steve.brady
"Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
that's a short period of time all by itself. but several commands could add up!
I think I know what you are talking about with the t-stats. New ones use lots of logic but not sure if it's nesessary for me.
I just need to figure a way to send a 8 bit value form one controller to the other with as short of a cycle as possible. 4 bits would equal 16 steps and 8 bits would equal 256 steps of resolution, right?
I used to know this but at say 50Hz (50 pulses a sec) what is the actual time in between cycles in micro seconds? I think it's actually just milli seconds which is where I need to be. Would it be .020 milliseconds?
It's late and my brain is tired.
As far as reading sensors go the engine doesn't really change states in real time as fast as the first controller could take samples of the sensors so I don't think there's a problem with MISSING a event.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.paysonarizona.net/
Post Edited (paysonbadboy) : 2/12/2005 6:08:46 AM GMT