-
If the probe cal signal works, you can transmit data across the RS-232 link but you're not seeing a signal, then a connection problem seems the most likely to me. Especially ground, since you don't need to connect a ground lead for the probe cal signal. Try switching between the signal ground and the shield of the RS-232 connector (you can sort of clip onto the screws / posts. Try a different probe or set the probe to 1x, if available.
-
If the probe cal signal works, you can transmit data across the RS-232 link but you're not seeing a signal, then a connection problem seems the most likely to me. Especially ground, since you don't need to connect a ground lead for the probe cal signal. Try switching between the signal ground and the shield of the RS-232 connector (you can sort of clip onto the screws / posts. Try a different probe or set the probe to 1x, if available.
Alm thanks. I have moved the ground connection from the scope probe to the PC chassis (to a screw on the RS232 port).
Let's go back a few steps. Do you think I should be on Pin 3 RxD where I get -12 volts, or on the Pin 2 TxD where I get +11.33 volts? I would think we want Pin 2 TxD as I assume that is the pin that is transmitting (from the PC to the scope).
Next, if the static (non transmitting) voltage is +11.33 volts, then what is the expected voltage when a key is depressed and at least some of the bits go low? (Where should the trigger be set? A few volts above zero, or between 0 and -12 volts?)
Thanks for the patience and persistence.
-
Like I said, if you set the computer to transmit continuously, you don't have to predict where to set the trigger, because you'll have a constant square wave. Just set it, probe, and play with the controls.
I don't know how I'm going to get the computer to transmit continuously. So far I can hit a key or several keys in a row manually (or for as long as I like keying), or I can transmit a relatively long file full of characters (but even that will send a page or so in about a second). I like the idea of transmitting continuously because then to your point I could just play with the trigger until it finds something. Just not sure how to make it transmit continuously. Thx -
Ok, as much fun as this is I'm starting to wonder.... Anyone out there with an analog oscilloscope and a PC with hyperterminal and an RS232 port want to see if this really works on an analog scope?
-
I think you're going to struggle to see anything much on an analogue scope.
Each RS232 character takes 10 bit times to transmit (assuming 8N1 data format). At 9600 baud, one character takes 1/960 sec, or about 1 millisecond to transmit. Even if you hold down a key in your terminal software and get 20 repeats/second, the line is busy for 20ms and idle for 980ms per second.
Set up the scope to trigger on rising edges, with a trigger level of 0V, and use normal (not auto) triggering. This will ensure you trigger on the beginning of the start bit, and only see the active period. Set the time base so each bit is about 1 division wide - say, 100us/div for 9600 baud.
Press a key and your scope should trigger. Most scopes have a trigger LED or similar indicator to let you know when they've triggered OK, so even if you don't see much on the screen, you should at least see the trigger light flash.
Once it's triggering OK, turn the CRT trace brightness way up, and see what you can pick out. If you can't see anything much when pressing keys in your terminal software, try sending a long file to keep the link actively transmitting more of the time.
This sort of sporadic, non-repetitive signal is just the sort of signal that digital storage scopes are much better at showing, because they can capture the trace once and then show it continuously until the next trigger comes along. The brightness and persistance problems you get with trying to examine the signal on an analogue scope just go away. If you do a lot of work with serial interfaces like this, an inexpensive DSO would be money well spent - and once you've tried one with serial UART decoding built in, you won't want to go back. -
Sometimes you can make a sporadic signal continuous, like the continuous stream. I was thinking wire rate, not keyboard repeat rate. Any programming language that can access the serial port can do this, but I guess you can also make a 1MB file with a million times the same character and send that.
-
I don't know how I'm going to get the computer to transmit continuously. So far I can hit a key or several keys in a row manually (or for as long as I like keying), or I can transmit a relatively long file full of characters (but even that will send a page or so in about a second). I like the idea of transmitting continuously because then to your point I could just play with the trigger until it finds something. Just not sure how to make it transmit continuously. Thx
Sometimes the obvious solution is the one overlooked...
Also turn the baud rate all the way down. 110 or so. -
I can use the DMM to probe Pin 5 GND (with DMM negative) and Pin 3 RxD (with DMM positive) and I get -12 volts (actually -11.98). When I connect the DMM probe to Pin 2 TxD (with DMM positive) I get +11.33 volts.
If no data is flowing the signal should be marking (i.e. negative). It should only be spacing (i.e. positive) to denote 0 bits in the transmission, or a break condition. This applies to both transmit and receive signals.
-
I think you're going to struggle to see anything much on an analogue scope.
Each RS232 character takes 10 bit times to transmit (assuming 8N1 data format). At 9600 baud, one character takes 1/960 sec, or about 1 millisecond to transmit. Even if you hold down a key in your terminal software and get 20 repeats/second, the line is busy for 20ms and idle for 980ms per second.
Set up the scope to trigger on rising edges, with a trigger level of 0V, and use normal (not auto) triggering. This will ensure you trigger on the beginning of the start bit, and only see the active period. Set the time base so each bit is about 1 division wide - say, 100us/div for 9600 baud.
Press a key and your scope should trigger. Most scopes have a trigger LED or similar indicator to let you know when they've triggered OK, so even if you don't see much on the screen, you should at least see the trigger light flash.
Once it's triggering OK, turn the CRT trace brightness way up, and see what you can pick out. If you can't see anything much when pressing keys in your terminal software, try sending a long file to keep the link actively transmitting more of the time.
This sort of sporadic, non-repetitive signal is just the sort of signal that digital storage scopes are much better at showing, because they can capture the trace once and then show it continuously until the next trigger comes along. The brightness and persistance problems you get with trying to examine the signal on an analogue scope just go away. If you do a lot of work with serial interfaces like this, an inexpensive DSO would be money well spent - and once you've tried one with serial UART decoding built in, you won't want to go back.
Andy, thanks. I will try 9600 and 100us/div.
I'm also going to try a much slower rate as suggested by amyk; 2400 to 110 or so. Any suggestions for the time div settings at these lower speeds or do you still like 100us/div? I've created a relatively large text file that just repeats a full line of text. So far it has carriage returns after each line. I'm not sure if the carriage returns are helping or hurting the process of trying to trigger the character strings - any thoughts on that? (My guess is that a carriage retrun is just another ASCII character and the scope doesn't know if I'm sending the Gettysburg Address or anything else - it's just a bunch of 1s and 0s and the longer I can keep 1s and 0s flowing at a steady rate the longer I have to twiddle dials while I try to figure out how to trigger on the overall serial string.)
This is a good learning process and I'm just wondering if it's something I'm missing or if even a more experienced scope operator would have find this to be difficult or impossible? Either way, I'm confident that on a DSO it is very doable - I'd just like to run this to ground and draw some some conclusion.
Getting serial data into a scope and having it help with decoding the data would definitely be a nice tool to have... I've got it narrowed down to about 5 DSO models
-
I can use the DMM to probe Pin 5 GND (with DMM negative) and Pin 3 RxD (with DMM positive) and I get -12 volts (actually -11.98). When I connect the DMM probe to Pin 2 TxD (with DMM positive) I get +11.33 volts.
If no data is flowing the signal should be marking (i.e. negative). It should only be spacing (i.e. positive) to denote 0 bits in the transmission, or a break condition. This applies to both transmit and receive signals.
dfmischler, thank you. So, are you saying (given what I described above) that when no data is flowing I should be at -12 volts? And are you saying that 0 bits (which are are part of some characters) will be represented by approximately +11 volts? If so, what about "1s"? What voltage would you expect for 1s? (Will those be treated as "markings" which are -12 volts, or something else?)
I think I need to get a grip on the expected voltage when the proper two wires are connected to the computer when it is powered up but nothing is being transmitted and what voltages are expected for each "0" and each "1" as they reach the scope. -
I think I need to get a grip on the expected voltage when the proper two wires are connected to the computer when it is powered up but nothing is being transmitted and what voltages are expected for each "0" and each "1" as they reach the scope.
The glib answer is, that's what you need to use your scope to determine.
There are two voltage levels used, called "mark" and "space". A mark is low voltage, and a space is high voltage. The precise levels of the voltages depends on the drivers, but they might be -12V for mark, +12V for space, or maybe something different. I would expect them to fall completely within the +15/-15 V range, and I'd expect them to be separated by at least a few volts. To find more details than that, measure them with your scope.
Put your scope on 5V per division and see what you see. That will surely display both the mark and space voltages, but maybe at poor resolution. After you see the voltages, adjust the position and scale of the vertical controls to make it so that they are displayed with better resolution, but still fall entirely on the display.
When the line is idle, it should have mark voltage. The start bit is a space voltage. After the start bit, you should see mark voltage for every 1, and space voltage for every 0, until the stop bit. Something like this:
http://en.wikipedia.org/wiki/File:Rs232_oscilloscope_trace.svg
One general strategy for probing an unknown signal is to start by using auto triggering with a very slow time base, say 1s/div, and a low enough gain on the vertical section so that you see the whole signal, in this case 5V/div should be plenty. Then watch the trace as you adjust the vertical section to capture the full range of the signal. After you've got the vertical section approximately set, speed up the sweep to see the transitions, and adjust the trigger to stabilize the waveform. Finally, you might want to adjust both vertical and horizontal controls to "zoom in" on something or fine tune the display to your liking. -
That is correct. A logic 1 is the negative voltage (mark), which is also the standby state.I can use the DMM to probe Pin 5 GND (with DMM negative) and Pin 3 RxD (with DMM positive) and I get -12 volts (actually -11.98). When I connect the DMM probe to Pin 2 TxD (with DMM positive) I get +11.33 volts.
If no data is flowing the signal should be marking (i.e. negative). It should only be spacing (i.e. positive) to denote 0 bits in the transmission, or a break condition. This applies to both transmit and receive signals.
dfmischler, thank you. So, are you saying (given what I described above) that when no data is flowing I should be at -12 volts? And are you saying that 0 bits (which are are part of some characters) will be represented by approximately +11 volts? If so, what about "1s"? What voltage would you expect for 1s? (Will those be treated as "markings" which are -12 volts, or something else?)
I think I need to get a grip on the expected voltage when the proper two wires are connected to the computer when it is powered up but nothing is being transmitted and what voltages are expected for each "0" and each "1" as they reach the scope.
I'm not sure how familiar you are with RS-232, but basically there are two types of devices: Data Terminal Equipment (DTE) and Data Communications Equipment (DCE)
If you are connecting a DTE to a DCE then you use a straight through cable. Otherwise, a DTE to a DTE (or DCE to DCE) requires a crossover, or null modem, cable.
A computer generally has a DTE port.
This means that according to the standard, it should be transmitting on pin 3 of its port. If you are using a crossover/null modem, then you would be looking at pin 2.
Are you checking on the oscilloscope with both devices connected, or only the one?
I actually built a tester I use at work, which is basically a diode from ground through two different LEDS; one to pin 2, and one to pin 3. Whichever pin has the negative voltage on it lights the relevant colour LED. This tells me which pin is the output pin of that device (the one that lights up).
It's very rare that it doesn't work. -
I'm also going to try a much slower rate as suggested by amyk; 2400 to 110 or so. Any suggestions for the time div settings at these lower speeds or do you still like 100us/div?
No, 100us is much too fast - at 110 baud each bit is ~9.1ms and a character is around 91ms. 100ms/div is more like it.
If you set keyboard autorepeat to the fastest and leave a weight on a key it's 30cps which is faster than 110 baud can handle so it'll start dropping characters but otherwise the UART is going to be transmitting continuously. That should give a good signal to scope. -
First up, here is that tester I made that I mentioned:
This is connected straight to the port. Being a computer, it is a DTE port and therefore transmitting on pin 3. The tester shows this with a red LED (and this is the pin I tested on my 'scope).
This is with a crossover in place. The port is now transmitting on pin 2, hence the green LED this time.
I then hooked up my 'scope, and used Realterm to transmit a constant string of capital U. I use this program because I know it outputs on the port as soon as you hit the key. I have found some terminal emulation software that only outputs once you hit 'Enter' or similar.
I have the baud rate on the port set to 1200. The scope is set to 2V/div vertical, and 1ms/div horizontal. I have it triggered off the negative edge roughly as it passes through ground. -
That is correct. A logic 1 is the negative voltage (mark), which is also the standby state.I can use the DMM to probe Pin 5 GND (with DMM negative) and Pin 3 RxD (with DMM positive) and I get -12 volts (actually -11.98). When I connect the DMM probe to Pin 2 TxD (with DMM positive) I get +11.33 volts.
If no data is flowing the signal should be marking (i.e. negative). It should only be spacing (i.e. positive) to denote 0 bits in the transmission, or a break condition. This applies to both transmit and receive signals.
dfmischler, thank you. So, are you saying (given what I described above) that when no data is flowing I should be at -12 volts? And are you saying that 0 bits (which are are part of some characters) will be represented by approximately +11 volts? If so, what about "1s"? What voltage would you expect for 1s? (Will those be treated as "markings" which are -12 volts, or something else?)
I think I need to get a grip on the expected voltage when the proper two wires are connected to the computer when it is powered up but nothing is being transmitted and what voltages are expected for each "0" and each "1" as they reach the scope.
I'm not sure how familiar you are with RS-232, but basically there are two types of devices: Data Terminal Equipment (DTE) and Data Communications Equipment (DCE)
If you are connecting a DTE to a DCE then you use a straight through cable. Otherwise, a DTE to a DTE (or DCE to DCE) requires a crossover, or null modem, cable.
A computer generally has a DTE port.
This means that according to the standard, it should be transmitting on pin 3 of its port. If you are using a crossover/null modem, then you would be looking at pin 2.
Are you checking on the oscilloscope with both devices connected, or only the one?
I actually built a tester I use at work, which is basically a diode from ground through two different LEDS; one to pin 2, and one to pin 3. Whichever pin has the negative voltage on it lights the relevant colour LED. This tells me which pin is the output pin of that device (the one that lights up).
It's very rare that it doesn't work.
Yes, I am assuming I have a DTE (the port on the computer) and therefore I am focusing on Pin 3.
I have the oscilloscope probe connected to Pin 3 with the ground from the probe attached to Pin 5.
I have reset Hyperterminal to 110 baud. The scope is set for .1 sec (100 milliseconds).
When no key is pressed the scope is seeing -12.1 volts.
When I press keys so far no triggering is occuring but I am still working at it. Seems like I should be getting closer.
Thanks for all the suggestions - please keep them coming!
-
First up, here is that tester I made that I mentioned:
This is connected straight to the port. Being a computer, it is a DTE port and therefore transmitting on pin 3. The tester shows this with a red LED (and this is the pin I tested on my 'scope).
This is with a crossover in place. The port is now transmitting on pin 2, hence the green LED this time.
I then hooked up my 'scope, and used Realterm to transmit a constant string of capital U. I use this program because I know it outputs on the port as soon as you hit the key. I have found some terminal emulation software that only outputs once you hit 'Enter' or similar.
I have the baud rate on the port set to 1200. The scope is set to 2V/div vertical, and 1ms/div horizontal. I have it triggered off the negative edge roughly as it passes through ground.
Ok, your post has given me full confidence that this is doable - hard to argue with a photo of the exact same model of scope showing the exact settings I need. Thanks. I am working to duplicate your results. Will keep you posted.
-
andtfoot,
I have duplicated your setup. 1200 baud, 2v/div, 1 ms div. Every light on my scope is the same as yours (including the alt under chop).
I am probing directly onto Pin 5 and Pin 3 on the computer port.
When no key is pressed my volt meter says -12 volts if I select DC on the screen menu (on the right side above +Peak, -Peak, PK-PK; I think you have your menu turned off); when I select PK-PK so the display shows CH1 PK-PK as your photo shows I get about 0.4V.
I have a second computer with a RS232 port I am also testing and it causes almost the same results except that instead of getting -12 volts I get -7 volts.
But no key pushing with your specific triggering settings or any trigger settings shows the square wave pattern you have or any pattern.
I am going to feel very silly when I find out what I have goofed on but so far it is mysterious.
-
Just to confirm... You don't have any kind of flow control turned on, right?
-
Just to confirm... You don't have any kind of flow control turned on, right?
uh oh... I had hardware flow control on; I have turned it off now (set flow control to none) and will repeat the testing.... -
Turning off flow control didn't seem to help (just curious.... what impact would flow control have on such a test?)
On a possibly related matter, I have found that even though I have echo turned on in both copies (on both computers) in Hyperterminal, the characters don't echo on either (local) screen - but they do successfully transmit over their respective RS232 ports and the RS232 cable in between. (It's possible that this is just a bug in Hyperterminal in an early version of the program.)
-
Turning off flow control didn't seem to help (just curious.... what impact would flow control have on such a test?)
In some circumstances it is necessary to assert the DTR (data terminal ready) signal at the receiver before the sender will transmit any data.
This is unlikely to be the case with a simple PC serial port, however.
To make absolutely sure of what you are trying to detect with the scope, you should make a complete link from one terminal to the another with an RS232 breakout device in the middle. Check that characters are sending and receiving from one end to the other and then probe the signals in the middle via the breakout box. Such breakout boxes often have LEDs to monitor the signals, and the TX (or RX) leds should flicker when you send characters. Once you see an LED flickering, probe this pin with the scope. -
HEY, HEY - MISSION CONTROL - WE HAVE LIFT OFF!
First the good (great) news. We have successfully transmitted ASCII characters via RS232 Pins 3 and 5 to a Tektronix 2247A (analog scope).
As can be seen in the attached image we have a steady stream of capital U characters triggered by the scope. Thank you to alm who pointed out that "A continuous stream of capital Us (eg. UUUUUUUUUUUUUUU...) is an excellent test signal. In 8N1 (8 bits, no parity, 1 stop bit) format this produces a square wave."
Also, thanks very much to andtfoot for getting the whole thing to work on his Tek 2247A which gave me confidence that there was light at the end of the tunnel (if I would just get my head of the sand and turn the light on).
Additionally, I'd like to thank each of you for your assistance, support, patience and persistence:
c4757p
AG6QR
alm
dfmischler
AndyC_722
amyk
andtfoot (brother 2247Aer)
IanB
I wish I could tell you what took me so long but here are a few things in case anyone else might want to go down a similar path.
The settings I homed in on were 1200 baud, 5v/div and 1ms/div. The winning transmission occurred after I kicked off a fairly long text file of random characters. Sending the long text file rather than keying characters one or a few at a time gave me extra time to sit at the scope and figure out how to find/trigger the signal. I sent a bunch of text files before finally getting it figured out. I'm sure it would have taken longer just hitting a few keys here or there. Keeping the baud rate low was a good idea too as it also gives more viewing time. After I got the first successful transmissions I realized they didn’t look quite so nice for the photo so I made a new file and photo using all capital U characters. (I've kept the photo of original first successful non capital U transmission in case the Smithsonian wants to put it along side the “Mr. Watson, come here, I need you” exhibit.)
It turns out that Auto Level, AUTO, and NORM triggering all work fine.
The key thing is that on an analog scope the triggered event will only remain in place while the string is being transmitted. A single key stroke results in triggered event about the duration of a key stroke; a long text file can last many seconds - but when the transmission is over the triggered signal is gone. I guess this is one reason DSOs are popular
Another part of the hold up was making sure I had the right pins on the RS232 port (I know, how hard could it be to find the right pins?). Another contribution to slow results was that the copies of Hyperterminal I have are near 1.0 and they don't support echo. So I could confirm that my two computers were sending and receiving while they were connected - but when I disconnected the cable between them so I could probe the pins on either port I couldn't be 100% sure any data was still going out the probed port since the local receiving computer was disconnected and the local sending computer (that I probed) didn't have the echo feature. If I had it to do over again, I'd have started by making sure I had software that would provide a local echo.
I suspect that my scope operating skills and especially my triggering abilities have now moved up from close to non-existent to 101 - I'm sure this was part of the holdup. I'd hate to admit that I might have been looking for signals that were off the screen because I lost track of the vertical position - hmmmm.
Anyway, my plan is take it all apart and prove I can put it back together and find/trigger the signal much faster on the next pass. Then I'm going to spend some time studying ASCII characters. I plan to see what happens when I go from no parity to even, odd, mark, or space parity and from 1 stop bit to 2 stop bits, etc. After that I’d like to see if I can generate specific ASCII characters without the computer just using a power supply and some type of programming. I know it's very fundamental and simple stuff for lots of folks here but I’m loving the ability to observe and manage in a hands-on manner at the intersection of A to D.
Thanks again to each of you. Go EEVbloggers!
Electro Fan (A Big Fan of Electronic Things, both Analog and Digital, both Hardware and Software, both Computing and Networking, both Wired and Wireless/RF)
-
Yay
If you want to study the effect of changing the data format, it's really important that you get a stable trace which always triggers in the same place, ideally at the beginning of the start bit. The proper trigger condition for this is a rising edge around zero volts.
One difficulty you'll encounter sooner or later is that rising edges occur at many times, every time the data transmitted changes from 1 to 0. If the scope triggers on data bits instead of just start bits, the bit patterns on successive sweeps won't necessarily line up, and you won't see a stable trace.
To work around this, you'll need to make use of the Hold Off control, which temporarily disables the trigger circuit for a period of time after each trigger event. Set the Hold Off period to be at least as long as it takes to send a complete character - 10 bit times at whatever baud rate you're using - and the trigger circuit won't re-arm until the character is complete and the line is idle again. This ensures that the first edge it sees will be the start bit.
This technique relies on there being an idle period in between characters on the line, which you'll get if you hold down a key. If you send a long file, triggering (not to mention identifying which bit is which) will be much more difficult. -
Yay
If you want to study the effect of changing the data format, it's really important that you get a stable trace which always triggers in the same place, ideally at the beginning of the start bit. The proper trigger condition for this is a rising edge around zero volts.
One difficulty you'll encounter sooner or later is that rising edges occur at many times, every time the data transmitted changes from 1 to 0. If the scope triggers on data bits instead of just start bits, the bit patterns on successive sweeps won't necessarily line up, and you won't see a stable trace.
To work around this, you'll need to make use of the Hold Off control, which temporarily disables the trigger circuit for a period of time after each trigger event. Set the Hold Off period to be at least as long as it takes to send a complete character - 10 bit times at whatever baud rate you're using - and the trigger circuit won't re-arm until the character is complete and the line is idle again. This ensures that the first edge it sees will be the start bit.
This technique relies on there being an idle period in between characters on the line, which you'll get if you hold down a key. If you send a long file, triggering (not to mention identifying which bit is which) will be much more difficult.
Ok, 1200 baud (roughly 1200 bits per second?) would mean 10 bits would take 1/120th of a second; not sure if I calculated that right but even if I did, how do I specify precisely that amount of hold off? On my scope I can use the hold off knob by simply eye-balling when the pattern stabilizes, but I'm sure if I can key in a specific time value - or maybe I'm confused, some more
-
Ok, 1200 baud (roughly 1200 bits per second?) would mean 10 bits would take 1/120th of a second; not sure if I calculated that right but even if I did, how do I specify precisely that amount of hold off? On my scope I can use the hold off knob by simply eye-balling when the pattern stabilizes, but I'm sure if I can key in a specific time value - or maybe I'm confused, some more
I don't know your scope well enough to say what options you have for specifying a precise holdoff value. But even if you have to adjust it only by turning an analog knob, you can achieve the right result by sending something that is NOT a "U" and adjusting holdoff to the lowest value that gives you a good stable pattern. For example, a "Z" is hex 5A, which means that the second four bits are reverse of the first four. It's got plenty of transitions, but you'll only get that sequence of two '1's to be stable in the right spot if your trigger holdoff is set properly.
Also, I'd recommend you make a simple RS-232 breakout box so that you can probe things while devices are talking to each other. It can be as simple as taking male and female DE-9 connectors, wiring everything straight through, but expose the insulation on pins 2 & 3, as well as pin 5, so that you can easily connect scope probes to 2&3 and ground clips to pin 5.
When you have a DSO, you can use that kind of breakout box to really dig in to serial device protocols. With a 2 channel scope, you put pins 2 & 3 each on a channel, and you can see the call and response as two devices talk to each other.