I need some help in displaying serial output from a device

Siri

I need some help in displaying serial output from a device ported via SERIN to BS2 and then displaying on LCDscreen(4X20).
The data is received via the serial port appear as : R067S099 and repeated every 1/2 sec.The letters "R" and "S" are repeated
in the same sequence but the numbers change.

When I use "SERIN· 16,Baud2400, [noparse][[/noparse]DEC sData]· - where· sData· VAR·· Byte - variable

and then sent to the LCD using - SEROUT 14,Baud2400, [noparse][[/noparse]sData]· - I am able to see only one digit on the LCD screen.

I would like to display only the Last 3 digits after "S" in the initial input data. I tried using SERIN formater "· WAIT ("S"),DEC sData· "

Still unable Display the last 3 digits on the LCD display.

Thanks

Siri




Post Edited By Moderator (Chris Savage (Parallax)) : 4/30/2007 5:38:39 AM GMT

Chris Savage

Siri,

Try SEROUT 14, Baud2400, [noparse][[/noparse]DEC3 sData]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support

Bruce Bates

Siri -

What Chris indicated may work, depending on how the data is actually presented in the input stream. Perhaps a more sure method would be to skip the unwanted characters in the SERIN command, and then pick up the ones you want. Take a look at the SKIP sub-parameter of the SERIN command in the PBASIC Reference Manual, or the PBASIC Help File.

The general format is simply: "SKIP nn" where nn characters are ignored in the input stream regardless of what they are. See the manual for greater details.

After that you just use the SEROUT as indicated by Chris above, presuming it's a serial LCD you are using. Unless so specified, LCD's are not generally serial devices.

Regards,

Bruce Bates

Post Edited (Bruce Bates) : 4/30/2007 11:20:40 AM GMT

Chris Savage

Bruce,

As he is using the DEC modifier in his SERIN the only data in the variable is numeric. He is also using SEROUT for the display and says he can see a single character. This is because he is sending the binary version of the value just put into that variable. The formatter I used should print back exactly what he received. Take care.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support

Siri

Thank you,
Both your code help me to display the serial out-put from the device but there seem to be a problem with the accuracy
of the displayed data.
The display on the LCD is accurate for about 3 min. then the LCD displays inaccurate Data - that is not in the input data.
There seem to be some dats corrution after about 3 min.

I would like some advise on this problem.

Siri

Phil Pilgrim (PhiPi)

Siri,

Since the BASIC Stamp is unable to listen to the incoming data stream continuously, you may be experiencing synchronization problems with your SERIN. Two questions:

1. Does the "S" occur anywhere else in the data stream than before your numerical data?

2. What comes before the "S"? Is it always the same character? If so, it's always better to synchronize on more than one character for the best reliability.

-Phil

Siri

Phil,

The Data stream is always in this format :"R067S099" - the "R" and "S" are always inthe same positon and "S" does not appear elsewhere.

Thanks,

Siri

Phil Pilgrim (PhiPi)

Siri,

Assuming you don't need what comes after the "R", try using:

DO
  SERIN  16, Baud2400, [noparse][[/noparse]WAIT("R"), SKIP 3, s, DEC3 sData]
LOOP UNTIL (s = "S")

where s is a BYTE variable. This might help with synchronization by requiring a longer "pattern" to be matched.

-Phil

Post Edited (Phil Pilgrim (PhiPi)) : 5/1/2007 11:04:27 PM GMT

Siri

Phil,

Thanks for the prompt reply.I will try your code snippet and let you know

how it went.

Once again thanks for the help.

Siri

Siri

Phil,and others

I tried the code snippet you suggested and I still get corrupted data after about 2mins.

I am attaching the code Iam using may be you will figure out what the problem is.

Thanks again for the help.

Siri

Phil Pilgrim (PhiPi)

The code you've attached doesn't include my suggested mods, so it's impossible for me to tell if it was implemented correctly. Scanning for a single "S" could lead to synchronization problems if SERIN happened to be invoked in the middle of a transmitted character. The Stamp, in that case, may mistake a data bit for a start bit and, just coincidentally, read what comes next as an "S".

1. What else is in the entire data stream besides "RnnnSnnn"? Carriage returns? Linefeeds? Punctuation?

2. What numbers exactly should you be reading, and what numbers are you reading?

3. Once it goes bad, does it stay bad, or is the bad data sporadic?

4. Could it be that whatever you're receiving data from is simply sending bad data?

-Phil

Siri

Phil,
I attached the exactly how I implemnted your code snippet.I hope this will help to solve my problem.
1.The entire data stream when viewed over the ' HyperTerminal is "RnnnSnnn" and a carriage return -[noparse][[/noparse]Thr same format appears on the line below - R056S098
···················································································································································································································· R040S094···
2.I like to display only the 3 digits following "S" --->·· 98
3.Once it goes bad continues to show more incorrect Data than correct data. Like 5-6 bad readings then on ncorect reading - including reading s like 008.
4.· The Hyperterminal does not show any bad data at all -

Phil Pilgrim (PhiPi)

Siri,

I've tried simulating your setup using both your programs on a BS2 with an LCD display, and with a second BASIC Stamp providing the data — both at TTL levels through P0 and at RS232 levels through P16. I have yet to see the problem you're reporting. Are you sure you have a good solid serial cable connection? If you have a scope handy, take a look at the signal on the Stamp's Sin pin. What do you see? What are the highest and lowest voltages present on the signal, not including over/undershoots?

-Phil

Phil Pilgrim (PhiPi)

Siri,

One other thing occurs to me: The BASIC Stamp echoes everything it sees on its serial input line. This means that it's sending the received information back to your sensor. Could it be that this is causing problems with the sensor itself? Perhaps it has a buffer that overflows after 2-3 minutes. Maybe it uses DTR for handshaking and is resetting the Stamp when the buffer gets full. Or perhaps it sees something echoed that it interprets incorrectly as a command. Hyperterminal doesn't automatically echo what comes in, which may explain why you always see clean data when you use it.

If this really is the problem, it's easy enough to remedy with an RS232 breakout box. Just cut the connection from the Stamp's DB9, Pin 2, back to the sensor.

-Phil

Siri

Phil,
One more point I did not mention earlier is that I have to use a "Null Modem" cable to receive the data
from the device.
The serial cable and the null modem converter are from Radio shack.
I had to use the null modem cable because I did not get any data using a direct serial cable attached to the device.
I have another serial cable I made and I will try disconnecting the Pin 2 and try using a PIN3 Nd PIN 5 connection only.
Thank you very much for all the help.

Siri

allanlane5

No, that's not going to work either.

The DB-9 on the BOE board uses the 'idle' voltage on the 'TX' line from the 'remote' device for its 'RX' signal back to the device. This is why everything sent on the DB-9 gets echoed back.

So if you disconnect the 'TX' line, the 'RX' line gets no voltage for its 'RX' signal back. Not going to work.

The simple solution to this is to go to www.kronosrobotics.com and get a MAX-232 with DB-9 mini-board. Then you can use two pins on the BS2 as 'RX' and 'TX' through the mini-board to your 'remote' device.

If you're "recieving to the BS2 only" from the remote device, you can do that by using a 22 Kohm resistor in series with the signal, and then using the "Inverted" baud mode on that pin. The 22 Kohm resistor drops the current enough that the built-in 'protection diodes' on the BS2 can handle the signal.

Post Edited (allanlane5) : 5/3/2007 6:49:05 PM GMT

Phil Pilgrim (PhiPi)

Allan,

The solution proposed here is not to disconnect the TX (pin 3) line, but the RX (pin 2) line, which will work fine to prevent the echo from the BASIC Stamp from going back to his sensor.

-Phil

allanlane5

Ah! Sorry about that, that should work. Though sending that signal through a 22 Kohm resistor to some other pin would also work.

Siri

Phil,
I did cut the RX - PIN 2 to the device and it worked.I had no bad data at all for over 10min.
Thanks a bunch - I am glad there are people like you who go out of their way to help others
who are less knowlegible.

PROBLEM SOLVED by PHIL.

Thank you again

Siri

Siri

My thanks to go to all of you - Chris Savage
Bruce Bates
Phil Pilgrim
Allan

who took time to help me to solve my problem

Regards,

Siri