# Monitoring two serial lines at the same time

First this is the setup: (please note that one of the grounds is not connected, both FTDIs working properly)

Now, I have used PuTTY to look at these two serial streams, both exchanging data at 9600 bauds, but my problem is logging the activity time-wise.

I've also tried some serial monitors that I found on the tubes, but the time resolution is in seconds.

Is there a tool for monitoring these two streams at the same time? If there is not, I should program one myself in Processing (it will take less time in this language I suppose).

PS: the ultimate goal of this is to replace the remote device (an actual wired remote) with a little MCU like the ATtiny85 or ATtiny2313 with a simulated input.

PS2: I only have these two FTDIs, an analog oscilloscope and a multimeter.

• What you really want here is a logic analyzer. However, budget constraints seem to render that unavailable. – Connor Wolf Dec 31 '10 at 1:52
• You're absolutely right Fake Name, budget and lead-time is a bitch when you're in a company that's not in the electronics business and in the last country of the earth (Chile). – J.P.Wack Jan 4 '11 at 23:45
• Also, in the end the signals in the question's cables where not RS232@TTL :( – J.P.Wack Jan 4 '11 at 23:46
• Something like the USBee SX (usbee.com) or Saleae Logic (saleae.com/logic) USB logic analyzers would do this easily and for under $150. I personally own the USBee SX but should have got the Saleae (I don't run Windows). Both are otherwise pretty much identical. – akohlsmith May 1 '11 at 19:50 • I have both USBee AXPRO and Saleae Logic. USBee SUCKS!!!! Their software crashes all the time and it has cumbersome UI. Saleae, on the other hand, much more polished. – Eric M Dec 25 '11 at 3:02 ## 6 Answers If you're on a 32bit Windows OS, I would recommend using PortMon. It goes down to the millisecond at least. It might even be microsecond resolution. I've used it a lot in the past with great success. In your particular case, you will put each FTDI chip on its own serial port. Then in PortMon, simply select the ports you want to monitor from the pulldown menu. Both sets of data get logged at high resolution, and you can even add filters to reduce the amount of data. For serial protocol monitoring, I add the include filter IRP_MJ*. • Many thanks to you my friend! the program works flawlessly!, anyway I have to open each port independently (with PuTTY) for it to capture. Now I'll look the captured data now. – J.P.Wack Dec 30 '10 at 15:36 • great, I'm glad it's helping you. PortMon has been my friend for a very long time. :) – Dave Dec 30 '10 at 18:58 • Bear in mind that the USB conversion will affect timings, and teh relative ordering of bytes on each channel may even appear different. Reducing with latency timer and settings in the FTDI driver can make a big difference here (device manager->port settings->advanced). If timing is critical there is no substitute for real COM ports. – mikeselectricstuff Dec 31 '10 at 17:29 • absolutely! You will see about a 16ms latency in round trip communication. It's very noticeable when you compare reflashing a micro over a USB->serial adapter vs. a "real" COM port. – Dave Jan 1 '11 at 1:19 • Another option is to use FTDI's FT2232 or FT4323 dual/quad UART chips - these runs USB2 High Speed, so the latency from USB should be a lot lower. – mikeselectricstuff Jan 1 '11 at 12:38 Docklight is the tool you're looking for: http://www.docklight.de/ I've used it before and it's great. Give it a try as well as PortMon. • Docklight really shines when you want to work with mixed ascii/binary protocols. In addition, I have found the macros feature really useful, where you can pre-program a series of bytes to automatically send. The auto-respond feature is also very cool. However, it can't log two ports simultaneously (as far as I can remember). – Dave Jan 1 '11 at 1:24 Another option could be com0com or its sister project hub4com. • com0com is awesome, plus it works on 64bit Windows. I didn't know that it logged -- I've only used its super handy port simulator / internal null modem loopback / port mapping feature. – Dave Jan 1 '11 at 1:25 I wrote something like this explicitly to watch the conversation between my iPod and the iPod adapter in my car. The source is here on GitHub. It's pretty specific to the iPod protocol, but I need to be able to see the data being transmitted to and received from the iPod in real-time and match a response with its request as closely as possible. This works quite well for me. If you want accurate timing, you can't go to separate serial ports. You need a microcontroller that can capture the data from both sources and output it to the PC at a data rate which is more than twice as fast as the data rate for the devices that are communicating. Suppose the devices communicate at 115,200 baud and the PC connection is at 500,000 baud (a rate supported by the FTDI). One could then, 12,500 times/second (every 80us), have the microcontroller output a 1-3 byte record, consisting of a header, and the lower 7 bits of transmit and receive data bytes (the latter only being included if present) Header formats: 10rrRttT - Both bytes are present; RX byte received rr*20us after start of frame; MSB is R TX byte received xx*20us after start of frame; MSB is T 11000rrR - RX byte only is present; data as above 11001ttT - TX byte only is present; data as above 11111111 - Neither RX nor TX data is present; Next one or two bytes may provide a long timestamp  Including a timestamp in the case neither byte of data is present would avoid having to send 12,500 records/second at times when nothing was being sent. Using an approach like this would allow far more accurate evaluation of data timing than would be possible using two separate serial ports (where timing resolution would be 1ms at best). PC software would have to be prepared to parse out the data, of course. This may be a time when scrounging the resources to buy an inexpensive USB-based logic analyzer is the right answer. I recently acquired a USBee SX and have been very pleased. Out of the box, it can decode serial on multiple (TTL level only) lines, and keep it all synchronized to well better than single bit time. It has no internal RAM, so it pushes all the data it samples up the USB. That has a couple of advantages, and at least one disadvantage. A big advantage is price. There's hardly anything inside the USBee SX between your signals and the USB, so it doesn't have to cost many arms and legs. The biggest advantage is capture depth. You are limited only by the storage on the PC. If you need a one hour capture to catch an elusive timing window bug, it can do that. A disadvantage is that the top sample rate is limited so that all sample can be fed up the USB. This makes it less useful for high-end digital logic, but for serial communications protocols that really isn't a big deal. The SX lists for about US$170. At that price it doesn't have to save your company very many hours to pay off....

It certainly isn't the only example of the breed, but it is the only one I've personally used.

• USBee software sucks. I get a reproducible crash at 24Ms with 3 logic channels. I had their AX PRO and dumped it for a Saleae product. Saleae software is SOOO much nicer. – Eric M Dec 25 '11 at 3:26
• That certainly has not been my experience. I've continued to use my USBee SX on several PCs around the office since I wrote the original post, and the only quirks I've seen relate to letting Windows do power saving modes that seem to plague all USB devices and are nearly impossible to reproduce. No product is perfect, certainly, and your mileage can and will differ. – RBerteig Dec 27 '11 at 21:35
• you really owe it to yourself to try out Saleae's software. Compare the navigation and the zooming. Although Saleae is a couple guys in a garage, they have a better product their support sucks and is as bad as USBee's support. But at least with Saleae, the owners respond directly to emails. They have no concept of software roadmap... I could go on. I guess I'm picky and shouldn't expect much from $140 or$500 USB device right? – Eric M Jan 5 '12 at 2:47