Shop OBEX P1 Docs P2 Docs Learn Events
Problem with a Byte String — Parallax Forums

Problem with a Byte String

AdamLAdamL Posts: 30
edited 2005-12-13 02:54 in BASIC Stamp
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????
·
«1

Comments

  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2005-12-08 18:16
    You don't have the complete code posted, so there's no way to even see the routine you mentioned.· Please attach the code instead of pasting it into the message.· This will allow us to load it into the Stamp Editor easily and compile it.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
    csavage@parallax.com
  • AdamLAdamL Posts: 30
    edited 2005-12-08 18:17
    Okay.· Here's the complete code
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2005-12-08 18:19
    Adam,

    ·· 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
  • AdamLAdamL Posts: 30
    edited 2005-12-08 18:23
    Whoops.

    I had modified the code, and hadn't re-saved it.· Here's the current code.

    Sorry
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2005-12-08 18:35
    Adam,

    ·· 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
  • AdamLAdamL Posts: 30
    edited 2005-12-08 18:40
    Chris,

    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 SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2005-12-08 18:43
    It sounds like you may need to use a hack version of that code to SERIN the data into several byte variables and then DEBUG them to the screen.· This would be without a WAIT modifier or timeout.· If you SERIN 5 bytes, and it hangs, then you're not getting anything.· Have it DEBUG what it receives right after, and you should see the 5 bytes you expect first.· Does your output string need a CR or other terminating value?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
    csavage@parallax.com
  • AdamLAdamL Posts: 30
    edited 2005-12-08 18:46
    Okay, so how would I do that?
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2005-12-08 19:10
    SEROUT· KOut, 76, [noparse][[/noparse]$64, $B2, $FF, $22, $B1, $00, $E8]

    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
  • AdamLAdamL Posts: 30
    edited 2005-12-08 19:15
    Sits there with a blank debug screen.

    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 SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2005-12-08 19:17
    Are you sure about that baud rate?· Intersting, since the one byte you are getting isn't what you expect.· So something's wrong with the communication.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
    csavage@parallax.com
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2005-12-08 19:19
    Is the other device sending TRUE or INVERTED data?· Is it TTL level serial or RS-232 level?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
    csavage@parallax.com
  • AdamLAdamL Posts: 30
    edited 2005-12-08 19:26
    Yup. It's the required baud rate for K-Line communication in a Ford vehicle......

    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 SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2005-12-08 19:29
    You didn't answer my last questions thought about the polarity and level.· What is between the Stamp I/O pin and the device you're trying to talk to?· Some kind of driver?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
    csavage@parallax.com
  • AdamLAdamL Posts: 30
    edited 2005-12-08 19:36
    yes. There's a circuit board to translate it.....outgoing goes through a NAND gate, resistors, transistor, and another transistor to give it pull up. Incoming does pretty much the same thing. Coming into the stamp module it is TRUE data, and coming in at 5V(resistor added to Stamp board to bring it down to 5 V). It was coming in as RS-232, but we modified the board so that the reply looks like (baud rate, voltage level, etc) the outgoing request.

    Sorry, I hadn't noticed your other questions.....
  • JonathanJonathan Posts: 1,023
    edited 2005-12-08 20:01
    Adam, All,

    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 SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2005-12-08 20:14
    After the last messages I was beginning to wonder myself, since I know there are converters to go from the OBDC-II standard to serial and visa-versa.· These are special chips.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
    csavage@parallax.com
  • AdamLAdamL Posts: 30
    edited 2005-12-08 20:20
    Pretty close to being relevant!

    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 SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2005-12-08 20:49
    Adam, interestingly enough, the MAX232 would've inverted the data, and so jumpering that changes that aspect and makes me think possibly that this could affect the data coming into the Stamp Module, although I would have to simulate this.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
    csavage@parallax.com
  • JonathanJonathan Posts: 1,023
    edited 2005-12-08 20:50
    Adam, All,

    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
  • JonathanJonathan Posts: 1,023
    edited 2005-12-08 20:55
    Chris,

    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
  • Bruce BatesBruce Bates Posts: 3,045
    edited 2005-12-08 22:23
    AdamL -

    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
  • AdamLAdamL Posts: 30
    edited 2005-12-09 01:07
    Sorry all, I wandered off from my computer for a while. Now to answer my computer.....

    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 SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2005-12-09 06:48
    2008 models are already available?· Maybe that's the problem!· =)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
    csavage@parallax.com
  • AdamLAdamL Posts: 30
    edited 2005-12-09 21:29
    LOL....unfortunately, no.· Since I live and go to school in the Detroit area, we get to work on development cars.· But that's not the problem here.· We are doing the development on the module outside of the car, then we'll install it into a car and fix any new problems!

    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
    742 x 534 - 50K
    700 x 582 - 47K
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2005-12-10 01:14
    Yes, and you could test this theory if you have two BASIC Stamps.· In fact, a common practice in Tech Support when someone has a device we don't is to simulate it using a BASIC Stamp.· So if you have a module that transmits at 10400 bps and we don't have it, you tell us it sends out a string of whatever when it receives this other string, we actually program a BASIC Stamp to do that, then we run your program (Or ours) on another BASIC Stamp and test the code.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
    csavage@parallax.com
  • AdamLAdamL Posts: 30
    edited 2005-12-11 00:09
    Okay, cool. So any chance that you've simulated this problem?· In the Basic Stamp Manual, it says that the baud range for the BS2 is 243 to 50K.· So running at 10400 shouldn't be a problem.· Does the o-scope captures help out at all?· It looks to me like it's a correctly formatted message in there....am I really that wrong?

    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
  • AdamLAdamL Posts: 30
    edited 2005-12-11 02:58
    Okay, here's something that I've been able to see.

    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!!!!
  • Tracy AllenTracy Allen Posts: 6,658
    edited 2005-12-11 03:38
    I haven't been following this thread closely, so I'm not sure if anyone pointed this out before. The BASIC Stamp has trouble receiving data via SERIN at baud rate above 4800, when the bytes arrive head to tail, that is, with only one stop bit and no extra idle time. The clue for that is your statement "looks like no pause (between bytes)".

    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

    serbuffer VAR byte(6)   ' buffer to receive serial data
    SERIN 0,baudmode,[noparse][[/noparse]STR serbuffer\6]
    
    



    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
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2005-12-11 06:38
    I dunno...speed shouldn't be an issue with getting a small string of numbers into a few variables.· I still can't help but wonder if something in your modifications to the driver circuit is what's affecting things.· The signal would've been inverted before, but now it's not.· It puzzles me why you did this exactly.

    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
Sign In or Register to comment.