I think you may have hit it on the head there.· The bytes are arriving head to tail with no extra idle time, as you suggested.· I've attached scans of both the outgoing and incoming messages, both with the same contents.·
The baud rate that I'm using is 10400, and I can't change anything in the reply.
I had tried using the STR command, but it didn't appear to work any better.· If what you said is true (and I do believe it is!), then it doesn't work at speeds above 9600.· But then why do the specs for the BS2 say that it can receive at speeds up to 50k???
So it seems like you're pretty much saying that I need to used a serial buffer in order to get this to work?· As I mentioned before, the serial stream that is incoming is going to be A4 FF B2 62 B1 00 xx xx xx xx CK where·CK is the checksum and the 4 xx values are all that I actually care about, but the first 6 bytes are necessary to ensure that the message is indeed intended for my Basic stamp.
Thanks for your help in making sense of all this......
The modifications to the driver circuit were necessary. If you look at the interface circuit, you can see that the MAX232 chip has the input voltage doubled (output from the LM2931 chip, +5V, connects to Vdd and V+, giving high voltage output). It also reduced the incoming voltage, resulting in a non-existant voltage by the time it got out of the circuit. We were having a huge amount of trouble getting any sort of response to the Stamp's byte stream, and finally one of the Valeo engineers suggested removing the MAX232 chip due to the reason listed above.
I will try out the baud rate parameter adjustment.....hopefully that will help out.....
Let me know if anything still seems odd or wrong about the circuit modifications. As you can see from the o-scope captures above, I have a 4.8V signal, and it "looks" right.
·· If you don't get this solved before Monday I will run a simulation at work based on the baud rates and number of bytes you expect to receive, which appears to be 11 bytes.· Could you please clarify what you send to get the response?· I would do this tomorrow, but I only have access to one BASIC Stamp at a time on my mobile computer, and my home machine is running an experiment using the two boards here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Chris Savage Parallax Tech Support csavage@parallax.com
The input format in the progrram you posted earlier is
SERIN KIn, 76, 5000, No_Data, [noparse][[/noparse]WAIT($62,$B1,$00), HEX2 IOL, HEX2 IL, HEX2 IR, HEX2 IOR]
The WAIT modifier will be out of the question with head to tail above 4800 baud. I know you said you tried the STR modifier before, but I want to be sure we are on the same page. Try the following stripped down code and let us know how far it gets re: receiving the expected string {A4 FF B2 62 B1 00 xx xx xx xx CK}. It has to receive something! Note that the whole enchilada is wrapped up in a STR modifier.
{PBASIC 2.5}
preface VAR Byte(11) ' to hold A4 FF B2 62 B1 00
idx VAR nib
KIn PIN 13
KOut PIN 14
DO
DEBUG CR
SEROUT KOut, 76, [noparse][[/noparse]$64, $B2, $FF, $22, $B1, $00, $E8]
SERIN KIn, 76, 100, No_Data, [noparse][[/noparse]STR preface\11]
DEBUG BELL ' got all 11!
no_data:
FOR idx=0 TO 10
DEBUG IHEX2 header(idx),32
header(idx)=0 ' zero to make it easy to see correct captures
NEXT
LOOP
The BS2p is much faster, so it could be an option if the above almost works. You 'scope shots are very helpful. It looks like it should work!
I'm not going to have a chance to test out the ideas until Monday....I left the power supply at the lab.
Chris--I send the hex byte string A4 FF B2 62 B1 00, and the unit should reply with A4 FF B2 62 B1 00 xx xx xx xx CK (ck is checksum, xx are the variables that I care about and the only ones that change.
Tracy--I'll give it a try tomorrow morning and let you know how it goes. The last time I tried using the STR variable, the interface board hadn't been modified and it didn't work.
That code snippet worked like a charm! Weird thing is it's still going into the No_Data subroutine, even though all of the data is in there and it is correct. Would that be because there is no stop bit? But no matter, I can rip the info that we need from the No_Data subroutine for now.
That's always good news, when something works after not !%&$@ working. The snippet as written does execute the no_data code regardless of whether data is received or not. The question is, does the BELL ring or not? If it does ring, that means the SERIN command has received all 11 bytes without ever timing out.
·· I am currently testing this code on two BASIC Stamp Modules.· I will have some more information for you shortly, it was a little slow because the data you said you're sending didn't match what you had in the code you posted.
You said you needed to send, "A4 FF B2 62 B1 00", but your output code sends, "$64, $B2, $FF, $22, $B1, $00, $E8" which is totally different.· Also, one thing that will slow you down is having the HEX2 modifiers on the SERIN command.· I am not sure you need them.· The question is how exactly is the device sending data?· If it's just sending the values as bytes then you don't need the modifiers.· OTOH, if it's sending the "A" and the "4" as separate ASCII bytes then that is different, but I doubt that is what's happening.· Please stand by...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Chris Savage Parallax Tech Support csavage@parallax.com
I didn't hear the BELL ring...but I had it print "Got it" if it did and reinserted the original No_Data command.· It is getting all 11 bytes.· But now I can't get it to do the comparisons....if IOL = $FF then SOL = 0, if IOL < 40 then SOL = 2 and all that rot.· Currently, it always replies that SOL = 2 (and all the others = 2 also) regardless of what is in preface(7).
Yeah, code is attached.
Chris,
You're right, I copied the wrong line for the outgoing code.· As I posted above, the returning data is coming in as a data stream with no breaks between the bytes.· That makes it a tad bit more difficult......
edit: I see you found the assignment bug (congratulations!). But the other comments below still apply, about making it happen automatically by changing the order in which ythe variables are defined. (For program speed and elegance). The important thing is that it works, huh?!
AdamL said...
But now I can't get it to do the comparisons....if IOL = $FF then SOL = 0, if IOL < 40 then SOL = 2 and all that rot. Currently, it always replies that SOL = 2 (and all the others = 2 also) regardless of what is in preface(7).
I don't understand your code within the FOR-NEXT loop:
IF idx = 7 THEN preface(idx) = IOL
IF idx = 9 THEN preface(idx) = IL
IF idx = 10 THEN preface(idx) = IR
IF idx = 8 THEN preface(idx) = IOR
It seems to me that is backwards:
IOL=preface(6)
IL=preface(8)
and so on. Furthermore, it could go after the FOR-NEXT loop, not in the loop.
The same thing can be accomplished easier, automatically, by defining the variables in precisely the following order:
preface VAR Byte(6) ' to hold A4 FF B2 62 B1 00
IOL VAR Byte
IOR VAR Byte
IL VAR Byte
IR VAR Byte
CK VAR Byte ' checksum
Emphasis again: _precisely_ that order with no intervening variables, and if you do that, preface(6) will automatically be the same as IOL, and so on up to preface(10) the same as CK. Even though preface is "officially" only a 6 byte array, the array implicitly continues on up in the Stamp memory. The SERIN command then will automatically put those bytes exactly where you want them.
The assignment bug, eh? So you meant to put that one in there, eh? Uh huh.....
The reason I put that code in like that was because I was trying to minimize the amount of change that I made to your code snippet. I used your code initially, then I added a bit of my old code, then a bit more of my old code. I understand what you are suggesting, and I'm going to incorporate it into the program so it's cleaner and faster. I'm also going to clean up a few other areas that are bothering me in there.....
Comments
I think you may have hit it on the head there.· The bytes are arriving head to tail with no extra idle time, as you suggested.· I've attached scans of both the outgoing and incoming messages, both with the same contents.·
The baud rate that I'm using is 10400, and I can't change anything in the reply.
I had tried using the STR command, but it didn't appear to work any better.· If what you said is true (and I do believe it is!), then it doesn't work at speeds above 9600.· But then why do the specs for the BS2 say that it can receive at speeds up to 50k???
So it seems like you're pretty much saying that I need to used a serial buffer in order to get this to work?· As I mentioned before, the serial stream that is incoming is going to be A4 FF B2 62 B1 00 xx xx xx xx CK where·CK is the checksum and the 4 xx values are all that I actually care about, but the first 6 bytes are necessary to ensure that the message is indeed intended for my Basic stamp.
Thanks for your help in making sense of all this......
The modifications to the driver circuit were necessary. If you look at the interface circuit, you can see that the MAX232 chip has the input voltage doubled (output from the LM2931 chip, +5V, connects to Vdd and V+, giving high voltage output). It also reduced the incoming voltage, resulting in a non-existant voltage by the time it got out of the circuit. We were having a huge amount of trouble getting any sort of response to the Stamp's byte stream, and finally one of the Valeo engineers suggested removing the MAX232 chip due to the reason listed above.
I will try out the baud rate parameter adjustment.....hopefully that will help out.....
Let me know if anything still seems odd or wrong about the circuit modifications. As you can see from the o-scope captures above, I have a 4.8V signal, and it "looks" right.
Post Edited (AdamL) : 12/11/2005 7:23:46 AM GMT
·· If you don't get this solved before Monday I will run a simulation at work based on the baud rates and number of bytes you expect to receive, which appears to be 11 bytes.· Could you please clarify what you send to get the response?· I would do this tomorrow, but I only have access to one BASIC Stamp at a time on my mobile computer, and my home machine is running an experiment using the two boards here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
The input format in the progrram you posted earlier is
The WAIT modifier will be out of the question with head to tail above 4800 baud. I know you said you tried the STR modifier before, but I want to be sure we are on the same page. Try the following stripped down code and let us know how far it gets re: receiving the expected string {A4 FF B2 62 B1 00 xx xx xx xx CK}. It has to receive something! Note that the whole enchilada is wrapped up in a STR modifier.
{PBASIC 2.5} preface VAR Byte(11) ' to hold A4 FF B2 62 B1 00 idx VAR nib KIn PIN 13 KOut PIN 14 DO DEBUG CR SEROUT KOut, 76, [noparse][[/noparse]$64, $B2, $FF, $22, $B1, $00, $E8] SERIN KIn, 76, 100, No_Data, [noparse][[/noparse]STR preface\11] DEBUG BELL ' got all 11! no_data: FOR idx=0 TO 10 DEBUG IHEX2 header(idx),32 header(idx)=0 ' zero to make it easy to see correct captures NEXT LOOPThe BS2p is much faster, so it could be an option if the above almost works. You 'scope shots are very helpful. It looks like it should work!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I'm not going to have a chance to test out the ideas until Monday....I left the power supply at the lab.
Chris--I send the hex byte string A4 FF B2 62 B1 00, and the unit should reply with A4 FF B2 62 B1 00 xx xx xx xx CK (ck is checksum, xx are the variables that I care about and the only ones that change.
Tracy--I'll give it a try tomorrow morning and let you know how it goes. The last time I tried using the STR variable, the interface board hadn't been modified and it didn't work.
Thanks again to both of you for your help.....
That code snippet worked like a charm! Weird thing is it's still going into the No_Data subroutine, even though all of the data is in there and it is correct. Would that be because there is no stop bit? But no matter, I can rip the info that we need from the No_Data subroutine for now.
Now all I have to do is pull that info out......
Thanks again for all of your help!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
·· I am currently testing this code on two BASIC Stamp Modules.· I will have some more information for you shortly, it was a little slow because the data you said you're sending didn't match what you had in the code you posted.
You said you needed to send, "A4 FF B2 62 B1 00", but your output code sends, "$64, $B2, $FF, $22, $B1, $00, $E8" which is totally different.· Also, one thing that will slow you down is having the HEX2 modifiers on the SERIN command.· I am not sure you need them.· The question is how exactly is the device sending data?· If it's just sending the values as bytes then you don't need the modifiers.· OTOH, if it's sending the "A" and the "4" as separate ASCII bytes then that is different, but I doubt that is what's happening.· Please stand by...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
I didn't hear the BELL ring...but I had it print "Got it" if it did and reinserted the original No_Data command.· It is getting all 11 bytes.· But now I can't get it to do the comparisons....if IOL = $FF then SOL = 0, if IOL < 40 then SOL = 2 and all that rot.· Currently, it always replies that SOL = 2 (and all the others = 2 also) regardless of what is in preface(7).
Yeah, code is attached.
Chris,
You're right, I copied the wrong line for the outgoing code.· As I posted above, the returning data is coming in as a data stream with no breaks between the bytes.· That makes it a tad bit more difficult......
Happy days are here again.....
Figured out what was going wrong!· It was an "I - D - 10 - T" error!
Tracy, Chris, thank you SO very much for all of your help!
The corrected code is attached.....now it moves the camera to look at the area where the ultrasonic sensor is going off.
Thank you again, Tracy and Chris!
I don't understand your code within the FOR-NEXT loop:
IF idx = 7 THEN preface(idx) = IOL
IF idx = 9 THEN preface(idx) = IL
IF idx = 10 THEN preface(idx) = IR
IF idx = 8 THEN preface(idx) = IOR
It seems to me that is backwards:
IOL=preface(6)
IL=preface(8)
and so on. Furthermore, it could go after the FOR-NEXT loop, not in the loop.
The same thing can be accomplished easier, automatically, by defining the variables in precisely the following order:
Emphasis again: _precisely_ that order with no intervening variables, and if you do that, preface(6) will automatically be the same as IOL, and so on up to preface(10) the same as CK. Even though preface is "officially" only a 6 byte array, the array implicitly continues on up in the Stamp memory. The SERIN command then will automatically put those bytes exactly where you want them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 12/12/2005 8:45:56 PM GMT
The assignment bug, eh? So you meant to put that one in there, eh? Uh huh.....
The reason I put that code in like that was because I was trying to minimize the amount of change that I made to your code snippet. I used your code initially, then I added a bit of my old code, then a bit more of my old code. I understand what you are suggesting, and I'm going to incorporate it into the program so it's cleaner and faster. I'm also going to clean up a few other areas that are bothering me in there.....
Once again, thank you so much for your help.