DEC with SERIN

docwisdom

I am capturing a serial string from a POS system. They are custom coupon codes that we programmed into the POS.
basically the string is: sR15e

s=start bit
R=type
15=qty
e=end bit

In order to capture the relevant material "R" & "15" I used the following SERIN command, then debugged the variables. From what I have read, DEC QTY should capture only numeric characters and stop once it reaches a non-numeric character (in my case "e")

Unfortunately the debug is not showing the variables or their values. Can anyone spot what I may be doing improperly?

' {$STAMP BS2}
' {$PBASIC 2.5}
' {$PORT COM4}
STX VAR Byte
TYP VAR Byte
QTY VAR Word
SERIN 1,16468,[noparse][[/noparse]STX, TYP, DEC QTY]
DEBUG ? STX
DEBUG ? TYP
DEBUG ? QTY

allanlane5

It's possible you didn't put a "\n" or <CR> or whatever after the "15" -- the DEC modifier needs to see that to know the number is 'finished'.

Mike Green

If you're not seeing any of the debug information, then the SERIN is not finishing. A BS2's serial I/O is always dicey at 9600 Baud, particularly when using the "formatters" like DEC. If you can change the configuration of the POS system, perhaps you could change its Baud setting to 2400 or 4800 Baud for testing purposes. Another alternative (if possible) is to change the POS system to use 2 stop bits at 9600 Baud. Sometimes the extra 100us is enough for the SERIN to work.

Make sure the signal from the POS terminal is correct for the Baud constant you're using. You're using 16468 which specifies 9600 Baud and an inverted signal (idle low). What's the output from the POS terminal and how do you have it connected?

docwisdom

Thanks for the input.

The baud rate seems to be correct because if I do the following code, it debugs just fine. Each variable is filled out properly. The problem is that the QTY is going to be variable length and I cant pad it with 0's in the POS output. Therefore it could be sR5e or sR22e or sR158e, etc


' {$STAMP BS2}
' {$PBASIC 2.5}
' {$PORT COM4}
STX VAR Byte
TYP VAR Byte
QTY VAR Word
SERIN 1,16468,[noparse][[/noparse]STX, TYP, QTY, ETX]
DEBUG ? STX
DEBUG ? TYP
DEBUG ? QTY
DEBUG ? ETX


allan:
The non-numerical character "e" should tell the DEC that it has finished. At least according to the datasheet on SERIN

docwisdom

A coworker had a pretty major thought. All of the data coming from the POS is ASCII. His opinion is that all the data is numerical so thats where the problem lies.
If this is in fact the problem. How can I interpret the incoming data as decimal not ASCII?

Mike Green

The formatters like DEC require additional time to set up (in the PBasic interpreter) and, at 9600 Baud, there may not be enough time to do the additional processing before the next serial character comes along. The Stamp then misses the start bit and loses sync with the incoming serial stream. One other option would be to use a faster Stamp model like the BS2sx or BS2px. You'd need to change the Baud mode constants and some other timing constants (like for PULSIN or PULSOUT), but those should really be declared named constants anyway (rather than putting the numbers into the program).

Mike Green

The DEC formatter is already dealing with ASCII. Its job is to ignore any ASCII characters that are not digits ("0" to "9"), then convert digits to a numeric value, and stop when the first non-digit ASCII character is received. The Basic Stamp Manual has some examples of this in the chapter on SERIN and in one of the appendices.

allanlane5

You COULD recieve it as a "STR" (array of byte) , then separate it in your own subroutine.

I wonder if "15e1" is a valid DEC string?

Chris Savage

I’m inclined to agree with Allan, with a specific approach…buffer the bytes from one string into an array and then print the contents of the array out as ASCII values. That way you can see what you’re getting. If you can post a few result strings from that I may be able to help you make this work. But I need a picture of exactly what’s being sent. Take care.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage

Parallax Engineering
50 72 6F 6A 65 63 74 20 53 69 74 65
·

docwisdom

Thanks for the replies!
I will look up arrays in the manual and see what I can do about getting you some sample data. This was my original approach. I was going to use a value separater, but PBASIC doesnt have a split function. ie s|R|15|e

Unsoundcode

I like the idea of the STR formatter to put QTY into an array. It has the advantage of including a terminating character of your choice which in this case could be "e"

The format would be similar to the following

SERIN 1,16468,[noparse][[/noparse]STX, TYP, STR QTY\3 \"e"]

Jeff T.

docwisdom

The STR modifier gave me a similar problem with the debug not outputting properly.

DEC worked great at 4800 baud. I may use that for now, but I have heard that POS software upgrades default the printers to 9600

Chris Savage

9600bps should work if we can narrow down exactly how the data is sent. Otherwise trying to use all the input formatters is going to be sketchy at best.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage

Parallax Engineering
50 72 6F 6A 65 63 74 20 53 69 74 65
·

Mike Green

You may just have to go with a faster Stamp model to handle the 9600 Baud. The BS2sx is a little cheaper, but the BS2p and BS2px should work better than the BS2.

Chris Savage

Mike,

Depending on how the string is formed realistically, he may be able to use the BS2 at 9600bps just fine. For example, using STR you can easily receive at 9600. The question is, is that the ideal way to handle this data? Without seeing it I can't say for sure.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage

Parallax Engineering
50 72 6F 6A 65 63 74 20 53 69 74 65
·

docwisdom

The string is literally
sR15e
where 15 is the variable quantity (up to 3 digits)
it is all coming through ASCII

Chris Savage

You now have three threads on this subject. I removed one earlier but you reposted it and got replies. You need to keep your related messages in the same thread. It is too confusing following this across three separate threads.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage

Parallax Engineering
50 72 6F 6A 65 63 74 20 53 69 74 65
·

PJAllen

Is your "startbit" = "s" irrelevant, is it always "s"?

parse      VAR  Nib
cpncodlet  VAR  Byte
cpncodnum  VAR  Byte (4)
 
SERIN 1, 16468, [noparse][[/noparse]WAIT("s"), cpncodlet, STR cpncodnum\4\"e"]
 
DEBUG cpncodlet, CR
DEBUG cpncodnum(0), CR
DEBUG cpncodnum(1), CR
DEBUG cpncodnum(2), CR
DEBUG cpncoDNum(3), CR, "***", CR
 
DEBUG cpncodlet
FOR parse = 0 TO 3
  IF cpncodnum(parse) = "e" THEN term
    DEBUG cpncodnum(parse)
    NEXT
term:
  DEBUG "e", CR, "***", CR

docwisdom

Yes, the start byte is always s

Apologies for the multiple threads. I didnt want to confuse the different issues I was having by mixing them up in one thread. Ill keep that in mind for the future. Different boards, different rules.