Serial Data reading.

You need to decode the bytes probably. What data are you expecting to read?

>>is that really 10001101 ?

Possibly, although that would be quite wasteful of bandwidth

160baud
  DATA STREAM DEFINITION
  ----------------------
    WHERE "WORD" IS THE BYTE OF DATA STREAM AS IT IS READ FROM THE VEHICLE
    AND "BIT" IS THE BIT OF THE BYTE, WHERE 0 IS THE LEAST SIGNIFICANT BIT.

    WORD  BIT      DESCRIPTION
    ----  ---      ---------------
    1            PROMID BYTE 1
    2            PROMID BYTE 2
    3            BATTERY VOLTAGE
    4            COOLANT TEMPERATURE
    5            VEHICLE SPEED
    6            MANIFOLD ABSOLUTE PRESSURE
    7            OLDPA3
    8            THROTTLE POSITION SENSOR
    9            OXYGEN SENSOR
    10            MIXTURE CONTROL SOLENOID DUTY CYCLE
    11            MALFUNCTION FLAG WORD 1
          0      C24 VEHICLE SPEED SENSOR
          1      C23 OPEN N/C SOLENOID CIRCUIT
          2          NOT USED
          3      C21 THROTTLE POSITION SENSOR HIGH
          4      C15 OPEN COOLANT SENSOR
          5      C14 SHORTED COOLANT SENSOR
          6      C13 OXYGEN SENSOR CIRCUIT
          7      C12 NO DISTRIBUTOR REFERENCE PULSES TO ECM
    12               MALFUNCTION FLAG WORD 2

I would like to read them in a byte. as in 0000000 - 11111111 or if i get an decmial value it should be 0-255. then i can convert it back to a byte.
So i would expect to see like 200 20 158 243 0 0 0 128 0 .... up to 20. then see it repeat with the zeros staying the same and the other numbers changing a bit.

The data should not be looking as you have it currently. Don't try to make String - there are none involved

abstract  int read()
                    Reads the next byte of data from the input stream.
 int                read(byte[] b)
                    Reads some number of bytes from the input stream and stores them into the buffer                        array b.

yea thats why i tried inputstream.read() but i would only get zeros and 255s.
nothing else.

add some more points.

seems like all my bytes are highs or lows. 0 or 255

http://www.geocities.com/MotorCity/Shop/9938/

ok that is what im really working with.
where is my problem

You need to post your code

import java.io.*;
import java.util.*;
import javax.comm.*;

public class SimpleRead implements Runnable, SerialPortEventListener {
    static CommPortIdentifier portId;
    static Enumeration portList;

    InputStream inputStream;
    SerialPort serialPort;
    Thread readThread;

    public static void main(String[] args) {System.out.println("got to main");
        portList = CommPortIdentifier.getPortIdentifiers();
      //  System.out.println(portList.hasMoreElements());
System.out.println(((CommPortIdentifier) portList.nextElement()).getName());
        while (portList.hasMoreElements()) {System.out.println("inloop1");
            portId = (CommPortIdentifier) portList.nextElement();
            if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) {
                System.out.println(portId.getName());
                if (portId.getName().equals("COM1")) {
                //if (portId.getName().equals("/dev/term/a")) {
                    SimpleRead reader = new SimpleRead();
                }
            }
        }
    }

    public SimpleRead() {
        try {
            serialPort = (SerialPort) portId.open("SimpleReadApp", 2000);
        } catch (PortInUseException e) {}
        try {
            inputStream = serialPort.getInputStream();
        } catch (IOException e) {}
      try {
            serialPort.addEventListener(this);
      } catch (TooManyListenersException e) {}
        serialPort.notifyOnDataAvailable(true);
        try {
            serialPort.setSerialPortParams(9600,
                SerialPort.DATABITS_8,
                SerialPort.STOPBITS_1,
                SerialPort.PARITY_NONE);
        } catch (UnsupportedCommOperationException e) {}
        readThread = new Thread(this);
        readThread.start();
    }

    public void run() {
        try {
            Thread.sleep(20000);
        } catch (InterruptedException e) {}
    }

    public void serialEvent(SerialPortEvent event) {
        switch(event.getEventType()) {
        case SerialPortEvent.BI:
        case SerialPortEvent.OE:
        case SerialPortEvent.FE:
        case SerialPortEvent.PE:
        case SerialPortEvent.CD:
        case SerialPortEvent.CTS:
        case SerialPortEvent.DSR:
        case SerialPortEvent.RI:
        case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
            break;
        case SerialPortEvent.DATA_AVAILABLE:
            byte[] readBuffer = new byte[20];

            try {
                while (inputStream.available() > 0) {
                    int numBytes = inputStream.read(readBuffer);
                }
                System.out.print(new String(readBuffer));
            } catch (IOException e) {}
            break;
        }
    }
}


that is Sun's SimpleReader.

You shouldn't ignore exceptions:

>>catch (PortInUseException e) {}

as it makes debugging almost impossible. Sun shows examples like this quite a bit - a BAD thing! Fill in all emtpy blocks with e.printStackTrace.

>>System.out.print(new String(readBuffer));

As i mentioned above, there are no strings involved here so you can't create String with binary data and expect to get meaningful output. You should do something like

System.out.print(new sun.misc.HexDumpEncoder().encode(readBuffer));

Can you make those adjustments and post the comple output?

run
0000: FF FF FF 00 00 00 00 00   00 00 00 00 00 00 00 00  ................
0010: 00 00 00 00
0000: 00 00 00 00 FF FF FF FF   00 00 00 00 00 00 00 00  ................
0010: 00 00 00 00
0000: 00 00 FF 00 FF FF 00 00   00 00 00 00 00 00 00 00  ................
0010: 00 00 00 00
0000: FF 00 FF FF FF FF FF 00   00 00 00 00 00 00 00 00  ................
0010: 00 00 00 00
0000: FF FF FF FF FF FF FF FF   00 00 00 00 00 00 00 00  ................
0010: 00 00 00 00


run
0000: FF FF 00 00 FF FF FF FF  
0000: FF FF FF FF FF FF 00 FF  
0000: FF FF FF FF FF FF FF FF  
0000: FF FF FF FF FF FF FF FF  
0000: FF FF FF FF FF FF FF FF  
0000: FF FF FF FF FF FF FF FF
0000: FF FF FF FF FF FF FF FF  
0000: FF FF FF FF FF FF 00 00  


Last one i changed the array to 8 since was losing data.

Looks like the same data as before.

Aight max points now.

Think it must have soemthing to do with
"The GM C3 Synchronous format has no time gaps between the bytes. The receiver must synch up with the data stream at the beginning of the message and stay in sync until the start of next frame, (no gaps). Any interruption in the data will require a re-synch on the next data frame. A typical frame consists of a start byte made up of nine '1's' followed by 20 - 25 nine-bit bytes.

Total bit count would be 21 x 9 or 189 bits for a 20-byte message. Transmission time would be 189 x 6.25usec or 1.18 seconds. There is a time gap between the complete data frames, so the fastest up date is about 2 seconds. Each bit starts with a falling edge, (The data line rests in the high condition), that is 200 usec low, followed by a 1 or 0 (the data), that is 4400 usec long, and ends with a 1650 usec high condition. The signaling voltage is 0 and 5 volts, (TTL).
 

Synchronization is accomplished by waiting for a falling edge, followed by nine "1's" ones in a row."


thanks if you can help.
i know its a hard one.

>>The GM C3 Synchronous format

Can you post a link to this in some way? I think i might need to 'get into it' a bit

link i posted before http://www.geocities.com/MotorCity/Shop/9938/
on top left click on 160 baud under aldl.

best info i have found on it.

And i know the serial port is getting the data because i have a program that can read most of it.

thanks for ur time CEHJ.

kinda mad i cant figuare it out myself.

>>And i know the serial port is getting the data because i have a program that can read most of it.

Is it reading the *same* data as you're trying to read in Java?

We need also to check that you're reading the right port:

>>
        System.out.println(portId.getName());
                if (portId.getName().equals("COM1")) {
>>

What is the output as a result of the first line above?

COM1

only got 1 serial hooked up.
And im not tryin to run them at the same time because then it would throw a port in use ex
and i would not be able to claim ownership as sun would put it.

Have you filled in all those empty blocks as i mentioned? Otherwise it could be that a non-fatal exception is thrown that is nonetheless causing errors

>>serialPort.setSerialPortParams(9600,

You haven't changed that setting in their code. Shouldn't you be reading at 160 baud?

ill changed it to 160, 2400 (the other program uses 2400), and left it at 9600.

no good.

yea i had system.err out before, and added e.printtrackstack or whatever to all.

If you haven't already done so, you could post a 20 point pointer question in another TA to this one. Sometimes difficult to know which. I'd be tempted to try the Assembler TA (if there is one ;-))

hahha yea thanks.

the only real thing that putts me off is that i get alot more highs (255) then i think i should get.
Most should be 0.

but i think i just need one of the people who already have a working program to give up some source code so i can port it to java.

thanks for the attempt.

Well i'm not giving up, but beginning to run short of ideas ;-)

>>SerialPort.STOPBITS_1,

I don't know much about these things, but maybe there aren't any stop bits (according to spec). Try 0

Also, since the data seem to be arranged in 12-byte blocks, that should be the size of your buffer, not 20 bytes

yea played with the stopbits.

but after the buffer reads 8 bytes they just turn all 0.

>>
Think it must have soemthing to do with
"The GM C3 Synchronous format has no time gaps between the bytes. The receiver must synch up with the data stream at the beginning of the message and stay in sync until the start of next frame, (no gaps). Any interruption in the data will require a re-synch on the next data frame. A typical frame consists of a start byte made up of nine '1's' followed by 20 - 25 nine-bit bytes.
>>

I'm wondering how that tallies with the format you gave above. Must confess, don't quite get the above, and it's a pity about the vague '20-25'

Alright from what i get.
The frame is 1 output set.

So it should start 111111111 then 20 bytes of the data i want to read.

but how do you have nine-bit bytes???

The start byte shouldnt be part of the data. Just think it is there to "sync" up to the data.


"Each bit starts with a falling edge, (The data line rests in the high condition), that is 200 usec low, followed by a 1 or 0 (the data), that is 4400 usec long, and ends with a 1650 usec high condition. The signaling voltage is 0 and 5 volts, (TTL)."

That makes it sound like i should see high data high.so like 255 0 255 or 255 255 255.

oh and for that link http://www.geocities.com/MotorCity/Shop/9938/ you have to click on Diagnostics first then 160 baud.

the 20-25 is cause this format spans about 10 years, and they added more info down the line but kept the same format.

My data is 20 different values.
so 21 * 9 = 189 bits
but then it could be 21*9*3= 567. (if im reading the high points).
if its the latter then i should be able to look for 9 *3 =27 highs to know thats my start byte(maybe).

>>but how do you have nine-bit bytes???

Well i think that's probably what the stop bit is for. I'd guess that what happens is that setting SerialPort.STOPBITS_1 does that automatically, in which case, ignore my previous comment about having no stop bits ;-)

Given the blurb though, it may be that you should ignore the first byte

Yea ill have time to do some more data collecting tomorrow so i think ill record more like 1000 "Bytes" so maybe i can find a patten.

26      208      128      135      0      229      0      26      0      128      0      0      0      0      28      79      128      0      231      0

That is kinda what i should see.

Maybe i need to invert my data. Because i c that 9 group of 0s like on line 5-6
And that might be my start byte.
and it repeats like about 23 lines down again.
So i need to decode it into int values but that might be it right there.....

0-0-0-255-0-255-255-255-
255-255-255-255-255-255-255-255-
255-255-255-255-255-255-0-0-
0-255-255-0-0-0-255-255-
255-255-255-255-255-255-255-0-
0-0-0-0-0-0-0-0-
255-255-255-255-0-0-255-0-
255-255-0-0-255-0-255-255-
255-255-255-0-255-255-255-255-
255-255-255-255-0-255-255-255-
255-0-255-0-255-255-255-255-
255-255-255-255-255-255-0-0-
0-255-255-0-255-0-255-255-
255-255-255-255-255-255-255-255-
255-255-255-0-0-255-0-0-
255-255-255-255-255-255-255-255-
255-255-0-255-255-255-255-255-
255-255-255-255-255-255-255-255-
255-255-255-255-255-255-255-255-
255-255-255-255-255-255-255-255-
255-255-255-255-255-255-255-255-
255-255-255-255-255-255-255-255-
255-255-0-0-0-0-255-255-
0-0-255-255-0-0-0-0-
255-0-255-255-255-255-255-255-
255-255-255-255-255-255-255-255-
255-255-255-0-0-0-255-255-
0-0-0-255-255-255-255-255-
255-255-255-255-0-0-0-0-
0-0-0-0-0-255-255-255-
255-0-0-255-0-255-255-0-
0-255-0-255-255-255-255-255-
0-255-255-255-255-255-255-255-
255-0-255-255-255-255-0-255-
0-255-255-255-255-255-255-255-
255-255-255-0-0-0-255-255-
0-255-0-255-255-255-255-255-
255-255-255-255-255-255-255-255-
0-0-0-255-255-255-255-255-
255-255-255-255-255-255-255-0-
255-255-255-255-255-255-255-255-
255-255-255-255-255-255-255-255-
255-255-255-255-255-255-255-255-
255-255-255-255-255-255-255-255-
255-255-255-255-255-255-255-255-
0-255-255-255-255-255-255-255-
0-0-0-255-255-255-0-255-
255-0-0-0-0-255-0-255-
255-255-255-255-255-255-255-255-
255-255-255-255-255-255-255-255-
0-0-0-255-255-0-0-0-
255-255-255-255-255-255-255-255-
255-0-0-0-0-0-0-0-
0-0-255-255-255-255-0-0-
255-0-255-255-0-0-255-0-
255-255-255-255-255-0-255-255-
255-255-255-255-255-255-0-255-
255-255-255-0-255-0-255-255-
255-255-255-255-255-255-255-255-
0-0-0-255-255-0-255-0-
255-255-255-255-255-255-255-255-
255-255-255-255-255-0-0-255-
0-255-255-255-255-255-255-255-
255-255-255-255-0-255-255-255-
255-255-255-255-255-255-255-255-
255-255-255-255-255-255-255-255-
255-255-255-255-255-255-255-255-
255-255-255-255-255-255-255-255-
255-255-255-255-255-255-255-255-
255-255-255-255-255-0-0-0-
255-255-255-0-255-255-0-0-
0-0-255-0-255-255-255-255-
255-255-255-255-255-255-255-255-
255-255-255-255-255-0-0-0-
255-255-0-0-0-255-255-255-
255-255-255-255-255-255-0-0-
0-0-0-0-0-0-0-255-
255-255-255-0-0-255-0-255-
255-0-0-255-0-255-255-255-
255-255-0-255-255-255-255-255-
255-255-255-0-255-255-255-255-
0-255-0-255-255-255-255-255-
255-255-255-255-255-0-0-0-
255-255-0-255-0-255-255-255-
255-255-255-255-255-255-255-255-
255-255-0-0-255-0-255-255-
255-255-255-255-255-255-255-255-
255-0-255-255-255-255-255-255-
255-255-255-255-255-255-255-255-
255-255-255-255-255-255-255-255-
255-255-255-255-255-255-255-255-
255-255-255-255-255-255-255-255-
255-255-0-255-255-255-255-255-
255-0-0-0-255-255-255-0-
0-255-255-0-0-0-0-255-
0-255-255-255-255-255-255-255-
255-255-255-255-255-255-255-255-
255-255-0-0-0-255-255-0-
0-0-255-255-255-255-255-255-
255-255-255-0-0-0-0-0-
0-0-0-0-255-255-255-255-
0-0-255-0-255-255-0-0-
255-0-255-255-255-255-255-0-
255-255-255-255-255-255-255-255-
0-255-255-255-255-0-255-0-
255-255-255-255-255-255-255-255-
255-255-0-0-0-255-255-0-
255-0-255-255-255-255-255-255-
255-255-255-255-255-255-255-0-
0-255-0-255-255-255-255-255-
255-255-255-255-255-255-0-255-
255-255-255-255-255-255-255-255-
255-255-255-255-255-255-255-255-
255-255-255-255-255-255-255-255-
255-255-255-255-255-255-255-255-
255-255-255-255-255-255-255-0-
255-255-255-255-255-255-0-0-
0-255-255-255-255-0-255-255-
0-0-0-0-255-0-255-255-
255-255-255-255-255-255-255-255-
255-255-255-255-255-255-255-0-
0-0-255-255-0-0-0-255-
255-255-255-255-255-255-255-255-
0-0-0-0-0-0-0-0-
0-255-255-255-255-0-0-255-
0-255-255-0-0-255-0-255-
255-255-255-255-0-255-255-255-
255-255-255-255-255-0-255-255-
255-255-0-255-0-255-255-25

yea looking good

ignoring the start byte and i bit off the front


26     208     128     135     0     229     0     26     0     128     0     0     0     0     28     79     128     0     231     0

255-255-255-255-0-0-255-0- 255///// = 000011010= 00011010=26
255-0-0-255-0-255-255-255-255///= 011010000=11010000= 208
255-0-255-255-255-255-
255-255-255/////255-0-255-255-255-
255-0-255-0/////255-255-255-255-
255-255-255-255///////255-255-0-0-

think we just figuared it out.

That's good. Try using the hex dump as before as you get a better display then

OK - so the bytes *are* bits then ;-)

>>ignoring the start byte and i bit off the front

So, effectively, that means ignoring *9* bytes?

well the 9 start bits just tell me where to start.

255-255-255-255-255-255-255-0-
0-0-0-0-0-0-0-0-
255-255-255-255-0-0-255-0-
255-255-0-0-255-0-255-255-

that group of 0 is really 111111111
which is the "start" byte just telling you that the data is starting over again.
then i have to ignore the first 0 ( 255 ) then the next 8 bytes (bits) are my data.

For my first value. Then i do that 19 more times. Then i will c the start byte again.
Then 20 more , and so on so on.

Made a lil convertion program and now it looks alot better.
Having 9 bits for the byte is kinda helpful because it makes it super ez to c the start byte.
Since it will be the only byte with 1 begainning it.

111111111
000011010
011010000
010000000
010000011
000000000
011100110
000000000
000011100
000000000
010000000
000000000
000000000
000000000
000000000
000011100
011001111
010000000
000000000


Thanks for your help CEHJ.

final looking data

255 26 208 128 131 0 230 0 28 0 128 0 0 0 0 28 207 128 0 232 0
255 26 208 128 131 0 230 0 27 0

:-)

Great stuff. But they *do* seem to be wasting bandwidth eightfold ...

Yea i know really.
But the final version of this will be a subset of gauges for my car with a computer just for this with a  15 sec booting windows, about 20-30 total after java starts and gauges reading.

so i can waste it since its only has 1 task and it will be the only thing the comp is doing.

unless u got any ideas on how to fix it????
haha

thanks again.

Well no - i'm not blaming you ;-) You can't do anything about it AFAIK