Monitor RS232 comms with millisecond resolution
in [Embedded]
|
Prev: MAKE UPTO $5000 PER MONTH! $2000 IN FIRST 20 DAYS!
Next: Dexcel Electronics Designs is Hiring in Chennai
From: gnuarm on 22 Jun 2010 07:16 >> Anyone know the quickest or easiest way of recording a serial data stream >> and timestamping each byte with a resolution of at least 1ms (preferably >> finer)? I can only find cheap or free programs with less resolution, or >> very expensive solutions, often involving special hardware. >> >> I only need to monitor one port, and I don't need to send any characters >> (actually I'm snooping on an RS485 bus). >> >> I'm prepared to use an old PC with a "real" serial port, run MSDOS, Linux >> or whatever other OS will do the job, use some sort of microprocessor to >> capture the data (preferably one I'm familiar with, such as 8051 family or >> PIC) or anything else so long as it's quick and cheap. I just need to get >> the job done, preferably tomorrow! >> > >If you only want to analyse a serial data stream and if you are sure, >that the bits are correct, you can simply read the data with a PC. > >I don?t think, that you need a microcontroller. > >The simplest way is, you take the B wire (or D-) of the RS485 signal and >connect it via a 1K resistor with the RXD* line of the PC and the GND >line of your RS485 Device with the GND-Line of the PC-Com-Port. This is >electrically not ideal, but should normaly work. But You should not >connect the TXD* line (the one, where you see about -8V) of the PC to >the RS485 bus. > >A better solution of course would be the use of a RS485 tranceiver which >is used only in read-mode, e.g. max485. > >Now take a simple program, e.g. in Turbo-Pascal under DOS or Delphi >under Windows and record the data. > >For a one-cannel solution, i would prefer delphi. For a two-channel >solution, where i need the timing between the two signals, it might be >better in DOS. > >With some experience in serial communication, this should be done in >about half an hour. > >With MSDOS or Windows, you can use every baudrate that is a >factor/divider of 115200. > >best regards > >Stefan DF9BI The "A" side of the differential signal should be the inverted signal just so it will work with single ended signals. Rick --------------------------------------- Posted through http://www.EmbeddedRelated.com
From: Rich Webb on 22 Jun 2010 08:11 On Tue, 22 Jun 2010 10:33:29 +0100, "Rowan Sylvester-Bradley" <rowan(a)sylvester-bradley.org> wrote: >One other thing I learned - the Saleae logic analyser looks a really >interesting device for a very good price - I think I may get one of those... There are a wide variety of capabilities in the domain of USB logic analyzers. Be sure to read the specs on the Saleae and ensure that it can support the tasks you want to use it for. For example, its input voltage range is -0.5 to 5.25 V. It may become unhappy if it's connected directly to a +/- 7 (or +/- 12!) RS-232 line. -- Rich Webb Norfolk, VA
From: Hans-Bernhard Bröker on 22 Jun 2010 08:19 Am 22.06.2010 12:35, schrieb Peter Greuter: > I am surprised that nobody reacted to this statement : as always it > depends a lot on the programs involved ! It does, but not quite as much as you think it does. > But for instance under > MS-DOS it is possible to reprogram the baudrate divider of a > typical 16X50 UART Of course it is. But that doesn't lift restrictions given by the quartz the UART runs off. Ever wondered where those strange numbers like 115200, 57600, etc., come from? They're integer dividers of the PC's original quartz frequency of 1.8432 MHz, divided by 16 for oversampling. 62500 Baud is not, and no achievable baud rate is anywhere near enough to get working communication.
From: Stef on 22 Jun 2010 08:29 In comp.arch.embedded, gnuarm <spamgoeshere4(a)n_o_s_p_a_m.yahoo.com> wrote: >> >>The simplest way is, you take the B wire (or D-) of the RS485 signal and >>connect it via a 1K resistor with the RXD* line of the PC and the GND >>line of your RS485 Device with the GND-Line of the PC-Com-Port. This is >>electrically not ideal, but should normaly work. But You should not >>connect the TXD* line (the one, where you see about -8V) of the PC to >>the RS485 bus. >> > > The "A" side of the differential signal should be the inverted signal just > so it will work with single ended signals. Ah, the confusion of the A and B line that anyone who has ever done anything with RS485 has run in to and into which will run all who are going to use RS485 to eternity. Probably all due to a mistake in the original 75176, see for example: http://www.embeddedrelated.com/usenet/embedded/show/2056-1.php -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) Repel them. Repel them. Induce them to relinquish the spheroid. -- Indiana University football cheer
From: Rich Webb on 22 Jun 2010 08:49
On Tue, 22 Jun 2010 14:29:30 +0200, Stef <stef33d(a)yahooI-N-V-A-L-I-D.com.invalid> wrote: >In comp.arch.embedded, >gnuarm <spamgoeshere4(a)n_o_s_p_a_m.yahoo.com> wrote: >>> >>>The simplest way is, you take the B wire (or D-) of the RS485 signal and >>>connect it via a 1K resistor with the RXD* line of the PC and the GND >>>line of your RS485 Device with the GND-Line of the PC-Com-Port. This is >>>electrically not ideal, but should normaly work. But You should not >>>connect the TXD* line (the one, where you see about -8V) of the PC to >>>the RS485 bus. >>> >> >> The "A" side of the differential signal should be the inverted signal just >> so it will work with single ended signals. > >Ah, the confusion of the A and B line that anyone who has ever done >anything with RS485 has run in to and into which will run all who are >going to use RS485 to eternity. > >Probably all due to a mistake in the original 75176, see for example: >http://www.embeddedrelated.com/usenet/embedded/show/2056-1.php Some of the blame for the confusion certainly rests with the standards body. I've got a copy of a 1978 version of the RS-422A spec where the drivers ("generators") are clearly drawn and labeled as |\ | \------A | \ ---| / | /o-----B |/ just like the usual datasheet symbols from Maxim et al. Following normal conventions this would imply that "A" is non-inverting and "B" is inverting. But since UARTs universally (?) idle with a mark-high, and since the *text* of the standard states that "the A terminal ... shall be negative with respect to the B terminal for a binary 1 (MARK or OFF) state," the *inverting* output really should have been "A." So, basically, we're screwed. -- Rich Webb Norfolk, VA |