Yes thats possible. I have actually though about this. This need to be done on the windows software, of course the card need to know your speed. The easisest is to sense the handbrake on...once on the door will unlock and once off the door will lock.Originally Posted by DjBac
But then than can be done without a controller or PC
Hmm practical or not thats up to you.
im hopeing this card is so flexible that it will acomandate any functionality or feature needed
This is exactly what Im trying to achieve. I hope most of the functionality needed had been covered for most applications.
Maybe theres more features need including for flexibilty? I have seen some card with DAC...but whats the use of that in cars?
8 Relays, 8 digital inputs and 4 analog is it really enough? I do really hope so because I dont wanna go overkill as Im keeping the cost down to minimum.
DAC can be useful for some applications, such as a lot of my obdII info is in the form of 0-255 values but then a OBDII adapetr could be used for that purposeOriginally Posted by Ricky327
Nice project plan!
I'm wondering if one or more the digital inputs could be set up as a pulse counter? So instead of returning its value at each output interval you would instead return the number of pulses (rising edges) received since the last interval. As long as the interval timing is tightly controlled this would allow us to do things like sample our on-board speed sensors, rpm sensors or anything else that produces rapid pulses. In some cases, the 100Hz polling interval might be good enough. Pulse counting just extends the maximum frequency to whatever the PIC/firmware can support.
As an extension to the idea above, if you can invert the output to report period instead of frequency(i.e counts) then you'd really have something. Car speed sensors really measure distance. If you can provide an accurate time between pulses of speed sensor, you'll be able to produce very accurate measurements of average speed over the pulse interval.
I know OBDII already does this and much more but it's kind of overkill for some applications. For those of us that would like to implement dead-reckoning in our navigations systems, the solution above would be near ideal.
I think with the handbrake is more practical, right??
how can this be achieved? maybe with some relays?
Do you have something in mind?
Under the handbrake there should be a switch somewhere, use this to activate a relay/s which can then control the central lock. You may also want to include the state of the IGNITION.
So...the central lock will open when the IGNITION is off and the handbrake is on. Then lock when IGNITION is on and handbrake is off. The clifford alarm does this but it doensnt take the state of the handbrake.
I havent done it, just some thought in my head but I cant see it not working.
A cool factor?
In some cases, the 100Hz polling interval might be good enough. Pulse counting just extends the maximum frequency to whatever the PIC/firmware can support.
Im able to run the PIC at 115200 baudrate, with the amount of characters in the status string I stated earlier it is possible to update at about 311Hz. If we stick at 200Hz thats equivalent to 12,000 RPM, assuming 1 tick per rev. So it is possible to calculate the engine speed with no problem. I guess the application is almost endless, just a matter of being creative
I don't think that analysis is correct. At 12000RPM you'd get a constant stream of 1s or 0s (depending on phase) from that digital input line. That would be fairly useless. You'll need at least twice the sample rate as the highest frequency. Assuming your example (1 tick per rev), you can marginally reconstruct the input signal upto 6000RPM. But to get a feeling of the real problem, imagine what your stream sends at 5900 RPM? If you looked at only 3 consecutive status messages, you'd get the values 1..0..1 in both cases. To accurate determine what the RPM is, you'll need to look at MANY consecutive status messages (effectively counting sampled pulses). Hence the reason I was interested in the firmware pulse counter and/or period sampler.Originally Posted by Ricky327
In any case, its just an idea. I understand that you're wanting to keep complexity down.
Opps sorry my mistake, thanks for pointing that one out, I wasnt thinking straight
However it can still be done because the PIC (some) have a built in CCP module. This can be setup to time a pulse interval and return the measured value in 10bit resolutions.
From what you said we can still increase the sample rate alot higher than 200Hz but this involve changing the STATUS format from ASCII to binary.