Problem with a Byte String
AdamL
Posts: 30
Good morning!
I'm having a problem with a PBasic program, and am hoping that you can help.
I'm sending a byte stream to a connected device.· When the device gets a correctly formatted stream, it replies with an echo, followed by its own byte stream.· I only want to capture part of the incoming byte stream.· I know (via o-scope) that the other end is receiving the data, it's correct, and it is replying.· However, I am completely unable to extract the incoming data.
I'm sending (hex values) 64 B2 FF 22 B1 00 E8
The other unit is replying with an echo of the above, a 34msec pause, then (hex values) A4 FF B2 62 B1 00 FF FF FF FF 64
The only data that I want is the four FF pairs.· All the rest can go to the great resistors in the sky.· Here's the code that I wrote, with help from the forums earlier.
· IOL······ VAR·· Byte
· IL······· VAR·· Byte
· IR······· VAR·· Byte
· IOR······ VAR·· Byte
· KIn······ PIN·· 13
· KOut····· PIN·· 14
· SEROUT· KOut, 76, [noparse][[/noparse]$64, $B2, $FF, $22, $B1, $00, $E8]
· SERIN· KIn, 76, 5000, No_Data, [noparse][[/noparse]WAIT($62,$B1,$00), HEX2 IOL, HEX2 IL, HEX2 IR, HEX2 IOR]
·
If I add a debug command to display IOL, IL, IR, and IOR, it doesn't work.· In fact, it jumps down to the No_Data subroutine, indicating that it's getting nothing.· What am I doing wrong????
·
I'm having a problem with a PBasic program, and am hoping that you can help.
I'm sending a byte stream to a connected device.· When the device gets a correctly formatted stream, it replies with an echo, followed by its own byte stream.· I only want to capture part of the incoming byte stream.· I know (via o-scope) that the other end is receiving the data, it's correct, and it is replying.· However, I am completely unable to extract the incoming data.
I'm sending (hex values) 64 B2 FF 22 B1 00 E8
The other unit is replying with an echo of the above, a 34msec pause, then (hex values) A4 FF B2 62 B1 00 FF FF FF FF 64
The only data that I want is the four FF pairs.· All the rest can go to the great resistors in the sky.· Here's the code that I wrote, with help from the forums earlier.
· IOL······ VAR·· Byte
· IL······· VAR·· Byte
· IR······· VAR·· Byte
· IOR······ VAR·· Byte
· KIn······ PIN·· 13
· KOut····· PIN·· 14
· SEROUT· KOut, 76, [noparse][[/noparse]$64, $B2, $FF, $22, $B1, $00, $E8]
· SERIN· KIn, 76, 5000, No_Data, [noparse][[/noparse]WAIT($62,$B1,$00), HEX2 IOL, HEX2 IL, HEX2 IR, HEX2 IOR]
·
If I add a debug command to display IOL, IL, IR, and IOR, it doesn't work.· In fact, it jumps down to the No_Data subroutine, indicating that it's getting nothing.· What am I doing wrong????
·
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
·· See, in the full code the line you posted isn't even being used...It's commented out.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
I had modified the code, and hadn't re-saved it.· Here's the current code.
Sorry
·· Have you been able to confirm receipt of the data into the Stamp at all?· Are you adding the DEBUG after the SERIN?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
I haven't been able to confirm that it's receiving the data. I can confirm that the other end is replying, and it's coming in at the same baud rate, same inversion and all thru the o-scope. As you saw from the first attachment, I had a DEBUG in there, but it never had anything. In fact, right now the program is running the subroutine every time (every 5 seconds). If it was receiving something, anything, it shouldn't be hitting the timeout.....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
SERIN· KIn, 76,·[noparse][[/noparse]HEX2 IOL, HEX2 IL, HEX2 IR, HEX2 IOR]
DEBUG HEX2 IOL, HEX2 IL, HEX2 IR, HEX2 IOR
BTW, what are your baud parameters for this device?· 76 isn't a baud rate value I recognize as being standard.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
This device runs at 10400 baud, 8 bits, no parity.
The only time I can get any response from the debug screen is if I only bring in one variable (if I delete everything after IOL above). In that case, it replies with 0B repeating as it runs through the program.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
I can see that the incoming pulses are correct on the o-scope....
If I change the SERIN command to be Hex2 IOL, then I get 0B. If I make the command HEX 2 IOL, HEX2 IL, it just hangs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
Sorry, I hadn't noticed your other questions.....
I'm kinda jumping in the middle of the thread here, but are you sure of the communication protocol of your vehicle? I (with very limited experience) understand that all vehicles past 1997 use one of three protocols, none of which are standard serial. I made a reader for my vehicle ('97 Subaru Outback) using a very nifty chip called the ELM2322 as the interpeter and a Stamp. Works a treat. Anyway, just thought I'd bring that up in case it is relavent.
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.madlabs.info - Home of the Hydrogen Fuel Cell Robot
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
Unfortunately, I am sure about the protocol.· It isn't a standard serial interface, but there is an interface board that allows a computer (RS-232) to communicate onto the K-Line.· We've modified the board by removing the MAX232 chip, since we had 0-5V levels, instead of the +12 to -5 volts of RS-232.· The outgoing part of the system is working like a champ, with the other end replying back properly.
I've attached a scan of the waveforms, outgoing and incoming.· The Basic stamp is the outgoing waveform, and the reply is on the right.· The last of the waveform scans shows the 4 sensor outputs, each one of the $FF.· This is the part of the message that we need to extract.· But it seems like the Stamp module is hanging up when I try to pull more than one byte out of the stream!· Also, I've attached a scan of the schematic of the interface board.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
What year, make and model is the vehicle? I'm just curious, I'm sure you are correct about the protocol.
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.madlabs.info - Home of the Hydrogen Fuel Cell Robot
I think you might be on to something there. I don't have the schematic from my reader handy, but now that you mention it I did have an inverted data issue. The original schematic I used had transitors etc instead of a MAX232, and I decided I wanted to use a 232 chip. Drat, wish I could get at the schematic.
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.madlabs.info - Home of the Hydrogen Fuel Cell Robot
The entire answer to this problem lies in the OBDI ==> RS-232 converter chip you are using. Which one are you using, and where can we download the specifications for it? Once we have that information the whole problem should take only a short time to rectify.
The converter chip SHOULD be going from ISO 9141-2 (aka K-Line) ==> RS-232 if my vehicle information is correct.
Regards,
Bruce Bates
Chris, Jonathan, and Bruce,
The last page of the scanned batch is the schematic for the interface board. The reason we jumpered out the MAX232 is because there already are inverters (NAND gates) in the circuit, so it does a couple of inversions to take it from +12 (logic 0) to -5 (logic 1) for the RS-232 to what the K-Line can read. BUT since we are using a +5 as logic 0 and 0 as logic 1, it's inverted compared to RS-232 logic. Also, notice on the o-scope printouts that there is a constant +5 volts for logic 0 and and it spikes to 0 volts for logic 1.
Jonathan,
It is for a 2008 Ford Escape. Aren't university projects in the motor city fun? [noparse]:)[/noparse]
Bruce,
Originally the interface board (last page of the scan, custom board by Valeo) was as you say. But the Basic Stamp was not feeding a negative voltage (-5 for logic 1), and the interface board was looking for it. Yes, there are converter chips that do the conversion all by themselves, but we are limited in our project somewhat as to the parts that we can use.
Thanks to everyone for their help.......still dunno why she isn't working........I might have to make up a MicroCap simulation to show how the interface board works.....Please help me get this board to read the information coming in!!!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
But for now, I'm still trying to figure out why the Basic Stamp isn't understanding the pretty pulses that are coming into it!
Is there any particular reason that it wouldn't accept this signal?· If I connected two Stamps together and set their baudrates to 76, would the receiving Stamp be able to read the signal correctly?· I need help!!!
Thanks
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
The Basic Stamp is still giving me these problems.....it's not reading what is being sent! Why? Why? Why?
Can someone PLEASE help!
Post Edited (AdamL) : 12/11/2005 12:28:54 AM GMT
I reprogrammed the PBasic chip to send the same signal as what I know is coming in to the chip. I then ran the o-scope on the waveform, and set the scope to have the same volts/div and time/div. Then I compared where I was sending $A4 $FF $B2 $62 $B1 $00 to the incoming waveform (from the scanned images above). I was able to see that there was three spilkes for each byte, varying in length for the encoded info. I was able to find the exact same pulses on the incoming waveform, with only one difference--the PBasic stamp had a pause of approximately 340 usec between the bytes, and the incoming only has about 200 usec between the bytes (looks like no pause). I'll attach a scan of the printout later, once I'm at a scanner.
It seems that the stamp module is looking for the pause, and when it isn't finding it, it doesn't know what to do.
Is there any way to tell the stamp module to look for a shorter pause between bytes?
Is there something else that I'm not seeing here? I've even tried moving the incoming line and the resistor onto another pin (and yes, I changed the location in the program), with no change. I do not understand what is going on....
HELP!!!!
Also the Stamp can have trouble receiving a reply when the reply comes too soon after the outgoing message/command. It looks like this should not be the problem in your situation, as there seems to be a good 5 milliseconds between the outgoing command and the reply.
You might want to take a look at my web page here,
www.emesys.com/BS2rs232.htm
and click on the link for the setup and execution times for SERIN and SEROUT.
There are several things you can do to resolve this, if it is in fact a problem...
1) add an extra stop bit or slow down the baud rate of the reply. I guess that is not possible with what you are doing.
2) Use a different form of the SERIN command. For example, this form
is much better than any other form of the command for receiving bytes head to tail. It can receive bytes at 9600 baud. There is a setup time of around 600 microseconds before it is ready for the first byte, but you have 5 milliseconds, there, plenty of time. You can also allow input to terminate when a certain character is received, $00 for example.
3) Use a faster Stamp. The BS2p or BS2px can receive serial data faster. On the BS2p or 'px, you also can use the [noparse][[/noparse]SPSTR 6] modifier, to stream the data into a buffer in scratchpad RAM. That is often useful for things like GPS or calipers that reply with a long string of data that has to be parsed to get at the salient information.
4) Use a serial buffer on the input to the Stamp, such as the MAX3100, or the SX project in Al William's book or DIY with SX/B.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
On another note, due to variances in timing, you might want to experiment with adjusting the baud rate parameter up/down a little in steps of, say 1 at a time, just to see if that could be an issue.· I know of at least one time this worked for a customer with an odd baud rate issue.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com