Serin

DAVID COOKE

the last thread disappeared from the PC screen
hopefully this is not a duplicate

i have a wind gauge which outputs the data in 17 bytes at 9600/7/E/1
the 'real data' is in the 6 bytes 11 to 16 (e.g. +01.30)

when downloading to a BS2 I seem to lose some of these bytes in a variable manner

is this to do with the baud rate?

the code I used was

SerData var Byte(18)
SerData(18)=0

SERIN 16,24660,[STR SerData\18]

thanks
david cooke

Franklin

I think SERIN defaults to 8/n/1 and you would have to check if that can be changed.

Mike Green

You really need to provide more information about your wind gauge and what's going wrong.

For example, your SERIN uses a Baud code of 24660 which is for 9600 Baud, even parity, inverted. The even parity matches the 7/E and the inverted matches the use of pin 16 which is the programming port that inverts the signal provided. The question is whether the wind gauge provides RS232 voltages or a TTL-like (5V) logic level. The latter may not work with your setup.

You're not showing the rest of your program. If your wind gauge sends data continuously and your program does much of anything else, it'll miss some of the data from the wind gauge. A Stamp only receives information when it's actually at the SERIN statement, not when it's doing other things.

DAVID COOKE

not sure about the RS232 voltage from the device but the output port looks a standard 9 pin female RS232 socket

the gauge only sends data when it is started manually or when a race is in progress

in other words, the data is only sent occasionally and not as a constant stream

i'm hoping ultimately to then automatically send the data to an LED display but obviously I need to capture the data first

at the moment I have no other code except a code to show the data on a single 7 segment display one byte at a time

would other basic stamps be better at capturing?

dc

Mike Green

1) How can you tell that your Stamp is missing characters?

2) Other Stamp models are faster and have more memory, but really wouldn't behave much differently for receiving data.

3) You really need to provide more information (like the source code of your program ... as a message attachment ... use the "paperclip" icon). From the limited information you've provided, it seems like it ought to work properly.

stamptrol

The way its set now, the SERIN will grab 18 bytes when the command is executed. If the wind gauge data is half way done, the Stamp has no way of knowing whether the grabbed data is the first, middle or last of the data transmission.

Assuming the data has some form of formatting, perhaps begins with $ or ends with CR, you can make SERIN much smarter with the WAIT modifier. (see the Helpfile under SERIN)

By using the WAIT modifier, SERIN will wait for a specific character before loading the array. That way, the Stamp will know its received a full and proper data transmission.

If the Stamp has other things to do if no data comes for a long period of time, you can also use the timeout parameter to ensure the STamp doesn't spend forever waiting for characters.

DAVID COOKE

the output for a reading of +00.00 is shown below

(i've changed the format below to make it readable
- the actual stream would show
(x x x x x x 0 0 1 3 + 0 0 . 0 0 x) where x is a character

1 19 71 87 2 16 48 48 49 51 43 48 48 46 48 48 4

i'll send my code later for picking the bytes up with a single LED display

one other point
when the stamp receives another 17 bytes does the original packet get over written?

dc

stamptrol

So you could set SERIN to WAIT for ascii 1, then SKIP 9 characters and then grab 6 characters which would include the sign and the decimal point of +00.00.

As for overwriting, you only have one array which gets reloaded with each read. However, with the Wait and SKIP concept. the array only has to be 6 bytes.

Cheers

DAVID COOKE

SerData VAR Byte(18)
x VAR Byte
SerData(18)=0

'SERIN 16,24660,[WAIT(1), SKIP 9, STR SerData\17] 'no good
'SERIN 16,24660,[WAIT("1"), SKIP 9, STR SerData\17] 'no good

SERIN 16,24660,[STR SerData\17]

'THIS tries to identify the correct bytes
OUTH=%00000000
DIRH=%11111111
PAUSE 1000
OUTH=%11111111
PAUSE 1000
OUTH=%00000000
PAUSE 1000

FOR x = 10 TO 16

SELECT SerData(x)
CASE 43 ' a positive
OUTH=%00010000 ' show a negative as unable to show a + on 7 seg display
CASE 46 ' a decimal point
OUTH=%00001000
CASE 48 ' a zero
OUTH=%11100111
CASE ELSE
OUTH=%11111111 ' all segments
ENDSELECT

PAUSE 2000

NEXT
DIRH=%00000000

GOTO main

Zoot

stamprol meant something like:

x VAR Byte
SerData VAR Byte(7)
DEBUG CLS
again:
' all code presumes ASCII characters, not BINARY/NUMERIC values
SERIN 16,24660,[WAIT("1"), SKIP 10, STR SerData\7]
' above -- wait for "1", then skip the 10 chars to what you want, then get seven bytes:
' the sign char, two digit chars, decimal char, three digit chars
FOR x = 0 TO 6 
   DEBUG SerData(x)
NEXT
DEBUG CR
GOTO again
' BUT HERE'S THE PROBLEM
' the above might not work, because you could have a "1" as some other char
' in the stream, and that would throw the wait.

Again, the above may not (probably won't) work if there is the possibility of an ASCII "1" anywhere else in the stream -- at least judging by your example of what the stream may look like.

It would be much more helpful if you could post documentation or something regarding the serial stream from the sensor. Header byte(s) or a trailing (end) byte on the packet would help. If not, you could set a "forever" loop in your code to check for any byte on the line, then presume that's the start of the packet, then check that an ASCII "-" or ASCII "+" is in the correct position -- if it's not throw out the packet and try again after updating your display.

Zoot

Actually, looking over your sample again, if indeed the xxxxx0013 is always sent, you could do this:

' sample packet: x x x x x x 0 0 1 3 + 0 0 . 0 0 x
x VAR Byte
SerData VAR Byte(7)
DEBUG CLS
again:
' all code presumes ASCII characters, not BINARY/NUMERIC values
SERIN 16,24660,[WAIT("0013"), SKIP 10, STR SerData\7]
' above -- wait for "0013", then skip the 10 to the sign, then get seven bytes:
' the sign char, two digit chars, decimal char, three digit chars
FOR x = 0 TO 6
   DEBUG SerData(x)
NEXT
DEBUG CR
GOTO again

Zoot

With a timeout as suggested. This will timeout the serin wait after two seconds of no bytes:

' sample packet: x x x x x x 0 0 1 3 + 0 0 . 0 0 x
x VAR Byte
SerData VAR Byte(7)
DEBUG CLS
again:
' all code presumes ASCII characters, not BINARY/NUMERIC values
SERIN 16,24660, 2000, No_Data, [WAIT("0013"), SKIP 10, STR SerData\7]
' above -- wait for "0013", then skip the 10 to the sign, then get seven bytes:
' the sign char, two digit chars, decimal char, three digit chars
FOR x = 0 TO 6
   DEBUG SerData(x)
NEXT
DEBUG CR
GOTO again

No_data:
DEBUG "No data!", CR
GOTO again ' just try again, or do something else

DAVID COOKE

thanks
i'll try these

I've connected the gauge directly to a PC and, using some serial port analysis software, looked at the data stream several times
it always begins with a character that is 1 in ASCII
the only thing that changes are the bytes showing the windspeed (and this is always
+00.00 indoors)

dc

stamptrol

Zoot has you on the right path.

All I'd add is that the WAIT should be WAIT(001) without quotes, assuming its the ASCII 1 (start of transmission) not the character "1".

To ensure that you're not coming up a character short during testing, I'd also set STR SerDat\4 until you know that the data is being received.