Ready to "Wring Out the Old"...

 2017 was wrapped up with a weeks-long 12+ hour days effort to move a data center "live" (that is, keep as much online as possible, while shifting it all to another building!), in an effort that ended 2 days before Christmas, because the building we had been in was going to be demolished! We got it done, but that was just the start of maintaining that operation while the campus around us was demolished, and significant renovations were being made to the building that we were now in. Going to the data center included suiting up in boots, jeans, hardhat, safety vest and safety glasses. Construction continues even today, on 5 of the 6 sides of the current data center. COVID-19  certainly played a part in extending the length of the construction project, and the end is now foreseeable.

  In January of 2021, I expect to see President Joe Biden sworn in as the 46th President of the US. We may even see the first inoculations for COVID-19 start in the US. In the Spring of 2021, I expect to be relocating to SW Oregon, and selling my California home. We've all been adapting to "working from home", as companies have had to change and adapt to remote working. With that move comes the decisions of what to pack, and where will it live in the new house. Older console servers from the test lab? Manuals and CDs from past vendors (example: Cyclades), with docs and firmware for older hardware. Even bins of serial adapters and specialty cables. Some of that stuff isn't going to "make the cut". This will be much of the "Wringing Out" in the next few months...

  In the past 3 years, I've been making LED Art with Arduino boards for fun (see https://www.instructables.com/IKEA-Star-With-ATtiny-and-NeoPixels/ for an example) and environmental monitors. I also got a Prusa MK2S 3D printer, and I'm learning how to make things. I was a supporter of https://www.hackerdojo.com, but COVID-19 has closed most of our maker spaces. I helped teach embedded computing to Jr High students for a year (1-day every couple weeks, in an Introduction to Technology class). I was at every (SF) Bay Area Maker Faire until there was no more Maker Faire. 

  I was wrestling with whether to start a new Maker-oriented blog as a fork, and try to keep that up after the move. But all the good names I could think of has been taken on blogspot, many years ago. Sadly, most of them had far fewer entries... some seemed to only try a few test posts, and then they want idle. Some started back in 2001, but none updated after 2014. :-( As a result, I think I'll stick with this blog, and post what I like going forward (versus only posting console-related things). 

  I still get the occasional email, asking for something that's not on my pages at https://www.conserver.com/consoles/, but I haven't needed to set up any hardware to recreate a problem for a long while. It may be Murphy's Law that after I toss out old hardware, that's when folks will have a problem that I'd want to look at myself. But since Murphy isn't going to help me load and unload the trucks, I'll learn to live with not having the hardware.

  I'm also exploring Raspberry Pi as I explore new Digital modes in Ham Radio (DMR, New Packet, and some HF modes next year), as I decide which monitors will be useful for Pi projects. There may be some interesting serial-related posts about these in the future.

  I hope for good luck, and good health for all of us in the new year.

Use the correct serial adapters, and trust them.

Today was a service window, and I was working in an old part of the network. I stumbled onto a broken DE9-toRJ45 adapter, dangling by it's wires. I swapped it out for a new one, from the proper vendor for the terminal servers in use, but there was no response via conserver.

"It was working fine last week." I'm told.

Looking further, I found a poor RJ45 termination, but the signals on on my signal tracer looked odd as well. This led me to the other end of the cable, where I found that I was looking at a USOC-Rolled cable (old CDDI-type wiring). This would have been a 'null-modem' if they had been using Cisco console servers, but they were not. Instead, they had only a couple leads correctly connected, and signal ground was not one of them. After a bit of frustration reaching more consoles, and reterminating those cables to be straight-through again, the network was back under our control. But why had they failed?

"But they've always worked like that." I'm told.

The wiring of the Cisco adapters, the null-modem (USOC-Rolled) cables, and the non-Cisco console servers wiring scheme had meant that signal reference was really be derived from the equipment chassis, across the power systems ground, between the console servers and the controlled devices. Today was they day that newer, fatter power circuits were installed, and moving the gear to different Power Distribution Units were too much.

The signal reference ground pin is extremely important, to prevent data errors, possible equipment damage, and possible injury to staffl handling the connections! (I'll share my 'bad ground, smoking gun' story another day, when I have more time.)

Using the correct adapters, and correct wiring, will lead to predictable results. Mixing and matching parts you have laying around with specialty cables will eventually cause you more headaches, and possibly more money than you will save. And the chances are good that you'll need to 'do it the right way' sooner or later. If your shop is as busy as the places I've been, you may as well do it right in the first place, because you may not have time to do it right later without sacrificing weekends or vacation time.

Mining for (serial) gold on Google

When I'm using my gmail account, I find that I know keep an eye on the 'content-relavant' ads they post on the right side of my screen. If a link looks interesting, I'll 'open link in new tab', and look at them later. This way, I don't really interrupt the flow that I'm following now. Most of the links don't pan out, but sometimes I find gold, that really valuable site that I might not have found using keyword searches before. (I don't know why I don't find them at other times. I'll take lucky chances any day! :-)

Today's nugget was the Intro to Serial Communications page at TalTech.com. There is a lot in common with my Minor Scroll of Console Knowledge, but there are a few other tidbits there that I haven't put on my page. (I've already emailed the webmaster, asking if permission to link to their page. Netiquette first, of course.)

If you haven't tried gmail, you might want to, now that you don't need a referral. My acount was a test, to chat with a friend. It expanded to become an archive for console-related emails that I received on my other accounts, and the ads became more relavant. Now it's one of my main accounts. Thanks, Google!

-Z-

Making the adapter or cable you need

I've got shelves, covered with tupperware tubs and drawers of adapters, sorted by wiring type and DCE/DTE, and labeled (both the adapters, and the tubs and drawers). I also have a variety of test gear handy to help me test serial ports and devices. But I know that I'm a bit unusual in this regard.

Most shops I've visited have one box or drawer where they collect 'stuff' that isn't 'Ethernet'. The problem is, many vendors do little to label their parts, other than to add a part number. (Sometimes, though, the part number is on a baggie around an unlabeled part. Once the baggie is lost, the part becomes useless as soon as you seperate it from its associated equipment.)

You can spend a lot of time trying various combinations of the parts at your disposal, testing at each step whether it shows signs of working, or you can set out to build the cable or adapter that you need.

To build the cable or adapter, you need to know:
1) are both devices using the same Electrical Signalling (i.e. RS232, TTL, RS488, etc.)
2) which pin/contact numbers are which on the connectors you need to use
3) which signals are on which pins, and which are inputs vs outputs

Your search for information should start with the equipment you need to connect. Some equipment will include pinouts and signal info on a label on the chassis itself. Next comes reading the manual, which should be on a bookshelf in your office if the equipment is still in use. Sometimes you can find the documentation on a CD-ROM that came with the equipment (you keep those, too, right?), or the vendors website, in their support section. Start with these if you can, since configuration information for the port may be needed later, and these documents will be specific to the software revision loaded on your equipment.

If you can't find the information resources from your vendor, your favorite search engine may be useful. I prefer Google, but they have their good and bad weeks when it comes to finding useful results. (There are occassional bouts with bogus search portals saturating the Google results. It's like a tide, really...when it gets really bad, they manage to clean it up, and results get really good again. No, I'm not trying to bite the hand that holds my new blog. ;-) I've had poor results with MSN, and Yahoo is hit-and-miss but they have too many ads for my tastes. The lesson here is to pick your favorite, but to try others if you are not successful in your searches.

You want to be sure that you only connect two devices if they have the same electrical signalling specifications. TTL signals are from 0v to +5v, while RS-232 signals are -12v to +12v. If you connect a TTL device to an RS232 device, you may not damage the RS232 port, but you will most likely 'let the smoke out' of the TTL interface chip (e.g. permanently damage it).

Now, it IS possible to connect a TTL device to an RS232 device, using an interface (electrical) level converter between them, but you cannot do it with a simple cable or adapter.

Once you know that your two interfaces are electrically compatible, just make a wiring diagram for your cable or adapter. List one connector on the left side of the page, and the other on the right side. Include which devices are being connected, as well as the connector type and gender, so you can identify this wiring diagram easily if you need it again in the future.

DCE and DTE were defined 'in the old days', but it was a 'draft specification'. It was an attempt to make things interchangeable. But it wasn't something which culd be enforced, so there are manufacturers that picked the 'less intuitive' option when designing their devices. As a result, they stack the odds against us if we are just guessing. So, when you find the pinout descriptions for the signals, you could 'bet' that TXD (Transmit Data) is an output, and RXD is an input. But, if you're using a less-popular/smaller manufacturers device, you may be disappointed. That's why I test the pinouts after I know where the Signal ('Reference') Ground pin is located. You should try to test your ports as well, whether you use a voltmeter, or a signal tester.

I usually list the pin numbers sequentially (with 1 at the top), and I also add the signal name, and the 'direction' of the signal. If the signal is an output, I use an arrow that points away from the number. An input will point at the number. The reference ground signal will not have an arrow. (You can see an example of this on my Signals page.) You can even use this format in simple text files or email, like so...

Cisco AUX         Cyclades ACS
RJ45-M              RJ45-M
1 RTS -->      <-- RTS 1  2 DTR -->      <-- DTR 2  3 TD  -->      <--  TD 3  4 GND ---      --- GND 4
5 gnd* <-      --> CTS 5
6 RD  <--      -->  RD 6
7 DSR <--      --> DCD 7
8 CTS <--      --> DSR 8 

You can now start drawing the lines that connect 'complimentary' signals, but I find that all of the crossing lines are difficult to read. Instead, I draw a second version, where I draw the signal straight across from the left side to the right side, and I put the appropriate number in the 'right-hand column'. It makes it easier for my eyes to follow. It would look like this...

Cisco AUX         Cyclades ACS
RJ45-M              RJ45-M
1 RTS -->      --> CTS 5
2 DTR -->      --> DSR 8
3 TD  -->      -->  RD 6
4 GND ---+--   --- GND 4
5 gnd* <-'   nc -> DCD 7
6 RD  <--      <--  TD 3  7 DSR <--      <-- DTR 2
8 CTS <--      <-- RTS 1 

This gives you a chance to count all of the pins on the right side. Is there one of each number? It also lets you see the 'odd' connections. In this case, the Cisco side needs to loop pin 4 to pin 5 (it's a switch in legacy products that tells the interface to be RS232. Without that input, the hardware doesn't use RS232 signalling.) Since the Cisco doesn't have a DCD output, the input on the Cyclades would not be connected. You can program the Cyclades to ignore the state of the DCD input. By diagraming the cable or adapter like this, it's a visual reminder that you need to check whether the device cares about an input which will NOT be connected.

I also find it's helpful to have a reference illustration for the pinouts of my connectors handy, when it's finally time to make the adapter or cable. You can find illustrations on the web, but you can find the cmmon connectors used for RS232 connections on my Signals page. Scroll to the buttom of the page for the DB and DE connectors. You can find a more verbose collection of basic RS232 clues and signal information on my Minor Scroll of Console Knowledge.

-Z-