Searching \ for '[EE] Very odd problem with RS232...' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/serials.htm?key=rs232
Search entire site for: 'Very odd problem with RS232...'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Very odd problem with RS232...'
2007\01\12@162219 by Przemyslaw Lopaciuk

picon face
Hi,
I've encountered very odd thing with RS232 and I'm stuck... I don't have any idea what can be the problem..
I want to read information from RS232 ... I use 9600 baud rate, hardware and software handshaking.
The sequence looks like that...

1) DTR and RTS high. PC sends 0x80, Device sends 0x01 back
2) PC sends 0x81, Device sends 0x00 back.
3) PC sends 0x01 and then lowers DTR
4) PC sends 0x12, device sends 8 bytes back ( some information )

It works perfectly on PC but when I use my board it doesn't. When using the board I can get through step 1 and step 2. I can't get the 8 bytes from thep 4 though. When I test the board connecting it to PC the data goes through correctly.

I even thought that it might be voltage ( I've got 7,5 V on my board ), so I put resistor on the cable and lowered the voltage to 7,5 V from PC ( it is 12 normally ). The PC can still get data from the Device.

I don't know where did I make the mistake. Maybe I don't know something about RS232 standard?

Please help.

Thank you in advance.

Sam

2007\01\12@164052 by peter green

flavicon
face

> I even thought that it might be voltage ( I've got 7,5 V on my
> board ), so I put resistor on the cable and lowered the voltage
> to 7,5 V from PC ( it is 12 normally ). The PC can still get data
> from the Device.
you are driving the output from your board bipolar aren't you?


2007\01\12@164643 by Mauricio Jancic

flavicon
face
I would sugest to first test the comunications without the handshaking.
Transmmit a few secuence of bytes and see if everything is allright. You'll
spot the problem easily. If that test goes fine, you most propably have an
error in your handshaking code.

Regards,

Mauricio Jancic
Janso Desarrollos
http://www.janso.com.ar
spam_OUTinfoTakeThisOuTspamjanso.com.ar
(54) 11-4502-2983


> {Original Message removed}

2007\01\12@170229 by PAUL James

picon face

Sam,

What sort of clock are you running the PIC with?   And at what
frequency?
You may be getting out of sync with the PIC and the PC if the frequency
is
Off by more than a few percent.   Try lowering the baud rate on both the
PC
And your PIC board, and see if that makes any difference.  If it does,
you should
Look at your clocking scheme.   And as an FYI, on anything but maybe
2400 baud and
Lower, the internal RC clock is just not stable or accurate enough to
suffice for
Accurate baud rates.

Hope this helps.


       
Regards,

       
Jim

{Original Message removed}

2007\01\12@180027 by Jinx

face picon face

> You may be getting out of sync with the PIC and the PC if the
> frequency is off by more than a few percent.   Try lowering the
> baud rate on both the PC And your PIC board, and see if that
> makes any difference

Lowering the baud rate will just make errors take longer to happen.
If it is a timing problem, the PIC clock needs to be changed to match
the baud rate from the PC

Sam, are you going through an RS232 i/f (eg MAX232) ?

2007\01\12@191108 by Przemyslaw Lopaciuk

picon face
part 1 1167 bytes content-type:text/plain; (decoded quoted-printable)

Thank you for your replies.
I'm using Sipex SP232ACT.  I'm using crystal oscillator. It might be problem with oscillator. I wanted to have PIC running at 40MHz on my board, but I didn't read the datasheet carefully ( yes, I know :-/ ) and instead of putting 10Mhz oscillator and using PLL I put 40MHz oscillator on the board. It is actually running at 13,3 Mhz now.  Do you think that it might be the problem?
I'll try lowering the baud rate anyway.
Sam
 
________________________________

From: .....piclist-bouncesKILLspamspam@spam@mit.edu on behalf of Jinx
Sent: Fri 1/12/2007 11:00 PM
To: Microcontroller discussion list - Public.
Subject: Re: [EE] Very odd problem with RS232...




> You may be getting out of sync with the PIC and the PC if the
> frequency is off by more than a few percent.   Try lowering the
> baud rate on both the PC And your PIC board, and see if that
> makes any difference

Lowering the baud rate will just make errors take longer to happen.
If it is a timing problem, the PIC clock needs to be changed to match
the baud rate from the PC

Sam, are you going through an RS232 i/f (eg MAX232) ?

2007\01\12@202228 by John Ferrell

face picon face
I could be out of date with this but RS-232 specs I have used in the past go
from a + level to a -level. 0 volts is an invalid condition.
I would put a scope there to see.

John Ferrell    W8CCW
"My Competition is not my enemy"
http://DixieNC.US

{Original Message removed}

2007\01\12@222640 by Tony Smith

picon face
>
> I could be out of date with this but RS-232 specs I have used
> in the past go from a + level to a -level. 0 volts is an
> invalid condition.
> I would put a scope there to see.
>
> John Ferrell    W8CCW


+3 to -3 volts is invalid.  -15 to -3 is logic 1, +15 to +3 is logic 0.

Tony

2007\01\12@224552 by Jinx

face picon face
> It is actually running at 13,3 Mhz now

If you want your PIC running its fastest and comming with a PC,
use a 9.8304MHz and PLL -> 39.321600MHz

If you choose a frequency that's "decimal", eg 40.000000MHz,
then you will have an error at baud rates which are more suited
to hexadecimal timing

eg 40000000 / 9600 = 4166.66667 (h1046, d0.66667 is lost)

but 39321600 / 9600 = 4096  (or h258000 / h2580 = h1000),
which is 0% error (try those figures in the UART calcs)

In this case, 40MHz will be 1.7% high, ie sampling too fast. On
a few bytes, you could work out how many, this probably wouldn't
be a problem, but the PC and PIC will drift apart on longer strings
without a periodic re-synch

2007\01\12@225621 by James Newton, Host

face picon face
Most of the time, TTL levels will work just fine....

...which means that sometimes, TTL levels will NOT work.

http://www.piclist.com/techref/io/serial/RCL1.htm Converts TTL to RS232 when
needed

(shameless plug)

---
James.



> {Original Message removed}

2007\01\12@225751 by David VanHorn

picon face
>
>
> +3 to -3 volts is invalid.  -15 to -3 is logic 1, +15 to +3 is logic 0.


Most receivers (all?) take <3V to be equivalent to negative.

2007\01\12@225904 by David VanHorn

picon face
>
>
> In this case, 40MHz will be 1.7% high, ie sampling too fast. On
> a few bytes, you could work out how many, this probably wouldn't
> be a problem, but the PC and PIC will drift apart on longer strings
> without a periodic re-synch


The re-sync happens on the start bit of every byte.
1.7% isn't enough to cause a problem.

2007\01\12@233726 by Herbert Graf

flavicon
face
On Fri, 2007-01-12 at 20:25 -0500, John Ferrell wrote:
> I could be out of date with this but RS-232 specs I have used in the past go
> from a + level to a -level. 0 volts is an invalid condition.

Very true. Although much hardware will except 0 volts as a "high" (RS232
being inverted, a -ve voltage is considered "high", a +ve voltage is
considered low), I'd never let a device out of my hands that didn't
swing into the negative region properly. It's just begging for problems,
perhaps not today, but down the road.

TTYL

2007\01\12@233842 by Herbert Graf

flavicon
face
On Fri, 2007-01-12 at 22:57 -0500, David VanHorn wrote:
> >
> >
> > +3 to -3 volts is invalid.  -15 to -3 is logic 1, +15 to +3 is logic 0.
>
>
> Most receivers (all?) take <3V to be equivalent to negative.

Perhaps most, but most certainly not all. I've encountered cases where
0V would be flacky, sometimes registering as a logic 1, sometimes not.

I would never build something that relied on 0V working.

TTYL

2007\01\12@235118 by Jinx

face picon face
> The re-sync happens on the start bit of every byte.
> 1.7% isn't enough to cause a problem.

Are there not some protocols/methods that may not explicitly
re-synch or am I thinking of something else ?

2007\01\13@033852 by Mark Rages

face picon face
On 1/12/07, Przemyslaw Lopaciuk <picspamKILLspamamusementcity.com> wrote:
> Thank you for your replies.
>
> I'm using Sipex SP232ACT.
>
> I'm using crystal oscillator. It might be problem with oscillator. I wanted to have PIC running at 40MHz on my board, but I didn't read the datasheet carefully ( yes, I know :-/ ) and instead of putting 10Mhz oscillator and using PLL I put 40MHz oscillator on the board. It is actually running at 13,3 Mhz now.
>
> Do you think that it might be the problem?
>

Wait... you have an oscillator running at 40 MHz, but the PIC is only
seeing 13.3 MHz?  Maybe the crystal is designed for third overtone,
but you're running at fundamental frequency? In doesn't sound like
that going to a be a stable time base for the RS-232 communications.
Fix the oscillator first, before attempting async serial
communications.

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2007\01\13@035758 by Wouter van Ooijen

face picon face
> I'm using crystal oscillator. It might be problem with
> oscillator. I wanted to have PIC running at 40MHz on my
> board, but I didn't read the datasheet carefully ( yes, I
> know :-/ ) and instead of putting 10Mhz oscillator and using
> PLL I put 40MHz oscillator on the board. It is actually
> running at 13,3 Mhz now.

You are using a 40 MHz crystal with the PICs oscillator? Just one
answer: don't. IIRC even with an external oscillator the maximum is only
30 MHz. Switch to a 10 MHz + PLL if you want to get it working.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2007\01\13@061455 by Gerhard Fiedler

picon face
Jinx wrote:

>> The re-sync happens on the start bit of every byte.
>> 1.7% isn't enough to cause a problem.
>
> Are there not some protocols/methods that may not explicitly
> re-synch or am I thinking of something else ?

AFAIK, async protocols always (need to) have some kind of bit timing resync
built-in, see CAN for example.

Gerhard

2007\01\13@072458 by Bob Axtell

face picon face
James Newton, Host wrote:
> Most of the time, TTL levels will work just fine....
>
> ...which means that sometimes, TTL levels will NOT work.
>
> http://www.piclist.com/techref/io/serial/RCL1.htm Converts TTL to RS232 when
> needed
>
> (shameless plug)
>
>  
This shameless plug is totally legitimate. I have two of these and they
work VERY well.

--Bob

2007\01\13@072701 by Bob Axtell

face picon face
David VanHorn wrote:
>> In this case, 40MHz will be 1.7% high, ie sampling too fast. On
>> a few bytes, you could work out how many, this probably wouldn't
>> be a problem, but the PC and PIC will drift apart on longer strings
>> without a periodic re-synch
>>    
>
>
> The re-sync happens on the start bit of every byte.
> 1.7% isn't enough to cause a problem.
>  
Yes, it will resync on every start bit at 1.7% as long as little noise
is present..

--Bob

2007\01\13@073225 by Bob Axtell

face picon face
Herbert Graf wrote:
> On Fri, 2007-01-12 at 20:25 -0500, John Ferrell wrote:
>  
>> I could be out of date with this but RS-232 specs I have used in the past go
>> from a + level to a -level. 0 volts is an invalid condition.
>>    
>
> Very true. Although much hardware will except 0 volts as a "high" (RS232
> being inverted, a -ve voltage is considered "high", a +ve voltage is
> considered low), I'd never let a device out of my hands that didn't
> swing into the negative region properly. It's just begging for problems,
> perhaps not today, but down the road.
>
>  
The published RS232 standard has the minimum swing at -3V.

--Bob
> TTYL
>
>  

2007\01\13@073651 by Howard Winter

face
flavicon
picon face
Jinx,

On Sat, 13 Jan 2007 17:50:46 +1300, Jinx wrote:

> > The re-sync happens on the start bit of every byte.
> > 1.7% isn't enough to cause a problem.
>
> Are there not some protocols/methods that may not explicitly
> re-synch or am I thinking of something else ?

Far be it for me to predict what you are thinking (I don't even know what *I'm* thinking! :-) but I do think you are thinking of something else.  The
normal serial comms that we're used to is Asynchronous (the "A" in UART and USART) which means that there is no explicit synchronisation between
transmitter and receiver - there's no "Clock" line.  So the receiver has to detect the bit positions from the data itself, which is what the Start Bit is
for - knowing the bit length and when the byte starts, the receiver can recover the data, with the Stop Bit acting as a check that it got it right.  It's
not infallible of course...  But the upshot is that each byte is re-synchronised automatically, so as long as the timing doesn't drift more than half bit in
a byte (because most UARTs sample the middle of the bit) and there's enough time between bytes that an overrun on one doesn't cause the next
Start Bit to be missed, it works pretty well.  That last point needs to be emphasised:  if you're not sure of your timing, leaving a bit of a gap (or vice
versa!) in between the bytes is a Good Thing, even though it slows down the transmission a tad.

Cheers,


Howard Winter
St.Albans, England


2007\01\13@080404 by Bob Axtell

face picon face
Jinx wrote:
>> The re-sync happens on the start bit of every byte.
>> 1.7% isn't enough to cause a problem.
>>    
>
> Are there not some protocols/methods that may not explicitly
> re-synch or am I thinking of something else ?
>
>  
Some hardware UARTS make 16 samples per start bit, some 64 samples, a
few only
4 to 8 samples.  As long as the error  does not fall out of a  bit by
the end of a frame,
there are no errors. The higher the sampling rate, the more reliable the
UART.

The hardware UART locates the start bit after sampling several times,
and then resynchs
its sample point in a way that subsequent bits are sampled IN THE MIDDLE
of the remaining
8 data bits. Since the UART won't resync until the NEXT start bit, if
the error is not great, no
data is lost. At the very first data bit, the sample is made in the
CENTER of the bit, the next
data bit will sample at the center PLUS (or MINUS) the error percentage.
The next data bit
will sample at the center PLUS (or minus) the 2x(error %), the next one
3x(error %), etc. For
a typical 10-bit frame (start bit + 8 data bits + stop bit) an error of
1.7% makes the last bit
sampled at the center +/- 17%, which is acceptable assuming that the
UART properly locates
the CENTER in the first place.

The problem is that if the error rate is higher than 5-6%, unless extra
stop bits (or dead spaces)
are forced into the data transfer, the start bit will have trouble
resyncing reliably. This might be
what you are thinking about. Whenever I use a PIC with internal RC, I
manually add extra
dead space equal to two stop bits minimum after each byte.

Software UARTS are usually unable to precisely locate the center, thus
adding another source
of error to the protocol, usually another percent. There are so many
ways to write a software
UART that the error rate is not easily predictable. One advantage that
software uarts have is that
they can choose to ignore stop bit errors, or even resync slightly on
each bit, so a small gain can
be achieved and compensate for the imprecise action of the start bit
timing.

--Bob

2007\01\13@095123 by olin piclist

face picon face
James Newton, Host wrote:
> http://www.piclist.com/techref/io/serial/RCL1.htm Converts TTL to
> RS232 when needed
>
> (shameless plug)

And here's my shameless plug: http://www.embedinc.com/products/ser
These are in stock and ready to ship right now.

********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2007\01\13@095523 by olin piclist

face picon face
Jinx wrote:
>> The re-sync happens on the start bit of every byte.
>> 1.7% isn't enough to cause a problem.
>
> Are there not some protocols/methods that may not explicitly
> re-synch or am I thinking of something else ?

You must be thinking of something else.  The timing for each RS-232
character is relative to the leading edge of the start bit.  Since each
character has a start bit, the sender and receiver re-sync each character.
For a 8 bit character, errors only accumulate for 9 1/2 bit times (leading
edge of start bit to middle of stop bit).


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2007\01\13@115034 by John Ferrell

face picon face
Building equipment that has components operating outside of specs is not
engineering, it is hacking.
If you intentionally choose to ignore specs your product will become an easy
target for those who do follow specs.
BTW, I am not an Engineer.

John Ferrell    W8CCW
"My Competition is not my enemy"
http://DixieNC.US

{Original Message removed}

2007\01\13@121011 by Carl Denk

flavicon
face
As a registered Structural Engineer, I can say that the requirements are
you follow the recognized (legal) building codes, or else you are on
your own. There is the out of "Good Engineering Practice" but when
venturing into that area one treads very carefully.  85% of the
structural failures are due to  details, it's almost rare that a main
member like a column buckling or beam failing in bending happens. Many
times it's lack (or mis) communication between the designer and the
fabricator/contractor.  Most structural engineers require, as part of
the design package, the be paid for inspection to ensure their original
concept is followed through, and a final check on the design i.e. does
that beam or number of bolts look appropriate compared to the rest of
the pieces.

When visiting a medical doctor, I ask why his rates are so high, his
answer is usually "I save lives", my answer is "I prevent the loss of
life". :)


John Ferrell wrote:
> Building equipment that has components operating outside of specs is not
> engineering, it is hacking.
> If you intentionally choose to ignore specs your product will become an easy
> target for those who do follow specs.
> BTW, I am not an Engineer.
>  

2007\01\13@122749 by David VanHorn

picon face
On 1/13/07, John Ferrell <.....johnferrellKILLspamspam.....earthlink.net> wrote:
>
> Building equipment that has components operating outside of specs is not
> engineering, it is hacking.
> If you intentionally choose to ignore specs your product will become an
> easy
> target for those who do follow specs.


I totally agree.

Once you start going outside the specs, then there are no guarantees.
My professional projects are too important to do that way, and my hobby time
is too precious to me to waste that way, chasing wierd intermittent problems
from going outside the specs.

2007\01\13@140318 by Gerhard Fiedler

picon face
Howard Winter wrote:

> That last point needs to be emphasised:  if you're not sure of your
> timing, leaving a bit of a gap (or vice versa!) in between the bytes is
> a Good Thing, even though it slows down the transmission a tad.

Adding a second stop bit is an easy way to provide extra sync room without
additional overhead. Has helped me out more than once.

Gerhard

2007\01\13@143148 by David VanHorn

picon face
>
>
> Adding a second stop bit is an easy way to provide extra sync room without
> additional overhead. Has helped me out more than once.


I've run into PC applications that couldn't deal with 9600 full stream, I
had to add 1mS delays between the chars!

2007\01\13@164306 by William Chops Westfield

face picon face

On Jan 12, 2007, at 12:43 PM, Przemyslaw Lopaciuk wrote:

> It works perfectly on PC but when I use my board it doesn't.
> When using the board I can get through step 1 and step 2. I
> can't get the 8 bytes from thep 4 though. When I test the
> board connecting it to PC the data goes through correctly.
>
While everyone else is questioning the electrical setup, I thought
I'd throw out that an 8byte transmission will overrun the "FIFO"
of the typical microcontroller UART, but not the deeper FIFO of the
usual PC serial port.  The prior interactions were short enough
that handling received data bytes too slowly wouldn't matter.

BillW

2007\01\13@173041 by Bob Axtell

face picon face
Olin Lathrop wrote:
> James Newton, Host wrote:
>  
>> http://www.piclist.com/techref/io/serial/RCL1.htm Converts TTL to
>> RS232 when needed
>>
>> (shameless plug)
>>    
>
> And here's my shameless plug: http://www.embedinc.com/products/ser
> These are in stock and ready to ship right now.
>
> ********************************************************************
> Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
> (978) 742-9014.  Gold level PIC consultants since 2000.
>  
Looks good, Olin.

--Bob

2007\01\13@175117 by Bob Axtell

face picon face
Carl Denk wrote:
{Quote hidden}

Very good comments all.

Good engineering practice has never failed me. As a consequence:

-I have never had to testify in court as to why my product blew up in
the plaintiff's face.

-I never have to explain why it takes me a little bit longer while I VERIFY
things.

-I sleep well at night knowing that all those products actually WORK.


Just to mention a few good practices:

1. I never run a processor faster than its published rating, even though I
know the device will actually do so.

2. I actually test the product at 0C and at 80C to see if it actually works.

3. I stopped making my own PCBs many years ago, using one of several
proto shops.

4. I make sure that my product will pass UL tests even if my client doesn't
care (some of my  clients are specifically exempt).  Conversely, I will NOT
take on a project that I know could harm someone if the client will NOT
obtain UL testing; to do so puts me personally at risk.

5. I will not reverse-engineer or duplicate anybody else's design unless the
original manufacturer has been proven to be unreachable through an extensive
search. I HAVE reverse-engineered projects done by the company itself when
it lost its own documents through neglect or hard disk failure.

there are more, might be a good topic.

--Bob


2007\01\15@100246 by PAUL James

picon face
And that's exactly the point.  If this works and it takes longer to see
an error,
then it follows that the timing is the culprit, and means can be taken
to correct that problem.

Jim

{Original Message removed}

2007\01\15@112455 by Bob Axtell

face picon face
PAUL James wrote:
> And that's exactly the point.  If this works and it takes longer to see
> an error,
> then it follows that the timing is the culprit, and means can be taken
> to correct that problem.
>
> Jim
>
> {Original Message removed}

2007\01\15@152904 by Jinx

face picon face


> And that's exactly the point.  If this works and it takes longer to
> see an error, then it follows that the timing is the culprit, and means
> can be taken to correct that problem.

Jim - I appreciate the logic, and it's too nice a day to be quibbling,
but as the OP is using a crystal he should be able to work it out
mathematically **. "longer" is not that long on the scale of one byte
at 9600 baud. I should have said "the error will take longer to happen"
rather than see, and the difference, even if you dropped from 9600 to
300, would probably not be detectable by the eye as eg s/w drops
out. Unless you were actively looking for an error difference, changing
the baud rate may not appear to be changing the failure symptom

** assuming the output from the PC is an accurate and reliable 9600

2007\01\15@162704 by Paul James E.

picon face

Jinx,

Point taken.   I was just thinking of a way to perform a quick and dirty
test to see if timing were the problem.  And this is probably the way I
would have done it.  But as you say, the difference probably wouldn't be
obvious from an observers point of view, so it would most likely be a
waste of time.  

In that case, I would look at the signal with a scope.  Of course, I don't
know whether the original poster has a scope or not, so that may not be
the answer either.

In any event, it was just a suggestion off the top of my head that made
sense at the time.   In retrospect though, I see your reasoning and must
admit you make a good point.  

With the amount of knowledge, and willingness to help, that is available
on this list, I'm sure the OP will get to the bottom of his dilema, and
in short order.


                                                Regards,

                                                  Jim





{Quote hidden}

> --

2007\01\15@162827 by Paul James E.

picon face

Jinx,

Point taken.   I was just thinking of a way to perform a quick and dirty
test to see if timing were the problem.  And this is probably the way I
would have done it.  But as you say, the difference probably wouldn't be
obvious from an observers point of view, so it would most likely be a
waste of time.  

In that case, I would look at the signal with a scope.  Of course, I don't
know whether the original poster has a scope or not, so that may not be
the answer either.

In any event, it was just a suggestion off the top of my head that made
sense at the time.   In retrospect though, I see your reasoning and must
admit you make a good point.  

With the amount of knowledge, and willingness to help, that is available
on this list, I'm sure the OP will get to the bottom of his dilema, and
in short order.


                                                Regards,

                                                  Jim





{Quote hidden}

> --

More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...