god_of_cpu

Well according to Rick327, the current idea is that the hardware will send out status at 10-100Hz

I will be writing the plug-in to use a seperate thread for actually reading data from the serial port so the program will never lock because it is waiting on or reading data from the serial port, it will also only try to read data once it is recieved, although at 100Hz it should recieve data more or less continuously.

Since we need to be reading the data for the analog input ports at a pretty high refresh rate to calculate things i.e. 0-60 from a speed sensor, this is probably the best way to do things and adding the status of the relays to the status of the analog input ports should be negligible.

I will have some sort of event driven mechanism that will be triggered when either an analog input changes or the relay status changes etc sent out to the host program of the plugin. This will be calculated by the plugin, i.e. if the last value was 120 and the new value as read from the STATUS message is now 125 an event will be triggered.

__________________
StreetDeck.com Developer (I am Chuck)
Get StreetDeck at http://www.streetdeck.com
The Official StreetDeck Forums have moved, please visit us at http://www.streetdeck.com/forum for official support for Streetdeck.

MP3Car.com

 

pauldy

I just got through reading this and I'm wondering to myself why so complicated? It seems like this is most likely going to be a get or set event right? So why not use the 8 bit nature of the pic to your advantage and make everything a bit masked event. I.E. the first 6 bits represent the io device. Bit 7 is a get or set and bit 8 would be the state. This gives you access to 64 io pins and does not require more than 1 byte per get or set. On a get for a device the reply could be the first 6 bits representing the device number and a second byte representing the state of the device. This would encompass both the digital status and analog as well.

Now you have a loop the polls each value and when a value has changed you send the device byte and the state byte out the serial port. Then a serial interupt would handle all incoming serial requests and process them accordingly. This would also increase the throughput of your application up to 7 times what I saw was possible.

Ricky327

The post you read is outdated

Post #46 already mentioned that and alot of things had already changed and not being posted in the thread...they go through PM


I guess god_of_cpu should have mentioned what this exactly means.

Example :
$STATUS 10011001,10111001,1F,10,11,FD


This is the format :
$STATUS [RELAYS],[DIGITAL INPUTS],[ADC0],[ADC1],[ADC2],[ADC3]

The first 8 bit binary on the left represent the current status of the 8 relays. The second set of binary represent the 8 digital inputs and the last 4 HEX represent the read analog values. This whole STATUS string is updated at 10Hz - 100Hz at always a fixed string lenght.

The status of the relays and the digital inputs is reprented in 8-bits binaries purely for human readability for easy diagnostics. The analog values is left presented in HEX, it can be made into decimal by Im not gonna bother.


Changing the state of the relays is done by sending the command as follow...it can be in this format :

Individual relay control :
$RELAY 0,1 = Turn RELAY 0 ON
$RELAY 1,0 = Turn RELAY 1 OFF

Simultanous relay control :
$RELAY A,10100111 = Turn all 8 relays ON/OFF as defined by the 8 bit binary

Again its done like this for easy operation in hyperterminal for diagnostics or experiments. Although pure binary format can be done for speed and simplicity but using the relay board with binary format can be difficult in some situations...take it as NMEA against SIRF protocol

Still nothing is 100% set at what format it should be at.

Ricky327

Its better to update all the status in one string. The analog values need to be updated in a constant rate anyway so why not update the status of the relay and digital inputs with it. The post above explain all that




Thats a nice piece of kit. Only if it was tailored made for car PC then I would have bough that instead. The size of the board is also a little too big for what it is.




Its all on paper together with abit of PIC code Ill publish the whole design, schematics, PCB, source code and the documentation when done. It can be built on strip-board if you like. The idea is so that most people in here can build it...parts are easy to souce. Programming the PIC maybe the only problem for some. Danceheaven and god_of_cpu will write the software for it

DjBac

Is it possible when you go over 20km/h to auto-lock the doors?? But it should then know that doors are locked so that when you stop ie. at a stoplight it shouldn't lock again!! Is this possible?

Ricky327

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.

But then than can be done without a controller or PC

Hmm practical or not thats up to you.

Danceheaven

Like ricky said proberly best to leave this to the software side of things
as for functionality or features this can all be discussed later once the hardware is built, im hopeing this card is so flexible that it will acomandate any functionality or feature needed

__________________

Ricky327

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.

Danceheaven

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 purpose

__________________

rando

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.

__________________
2004 4runner

DjBac

I think with the handbrake is more practical, right??
how can this be achieved? maybe with some relays?
Do you have something in mind?

Ricky327

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?

Ricky327

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

rando

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.

In any case, its just an idea. I understand that you're wanting to keep complexity down.

__________________
2004 4runner

Ricky327

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.

MP3Car.com