NABU PC Cable Length Experiment

[@leo.binkowski]

Interesting. I thought the signal could go pretty far, but I didn't expect it would be reliable THAT far.

[@geekwithsocialskills]

I thought my 40' cable was impressive, but wow, 624 feet is just bananas.

[@geekwithsocialskills]

Great video and backed with science and specifications. Nicely done!

[@RudysRetroIntel]

Wow!! That's a long cable! Nice to see others making videos that shows this works and not just me. Thanks for sharing.

[@ChrisMasto]

Feel free to call me out on any errors. Things I know I said wrong: 1. RS-422 maximum cable length is 1200m (3900ft), which is a long distance but not "miles" 2. I was casual with my usage of the terms "balanced" and "differential", as well as describing the purpose of twisting the pairs. To be technically accurate, there is no need to use twisted-pair to reject common-mode interference (if it is sufficiently far away), and (quoting en.wikipedia.org/wiki/Differential_signalling): "Differential signalling does not make a line balanced, nor does noise rejection in balanced circuits require differential signalling." These are true facts, however, they're not very important here. RS-422 is balanced *and* differential, and there's no practical impact of using the wrong word (these are very commonly conflated). As for twisting the pairs, it is a good way to keep the wires the same distance apart and it does aid in rejecting nearby interference and especially crosstalk. So maybe your untwisted cable works fine. Lots of things work that are out of spec, that wasn't really my point here. 3. I said 0.2 volts. 0.4 is more accurate (+/- 0.2). I also said "more than 0.2 volts" and "less than 0.2 volts". That's not the right way to think about it: it's really about which one is higher. 4. I didn't discuss ground loops in any detail. That also wasn't the point of this video. I suggest watching the videos linked in the description for a more thorough treatment of RS-422 from someone who knows a thousand times more than I do. My short answer is: yes, I am creating a ground loop. You have to make a choice, and I am prioritizing keeping the common mode offset voltage low over any interference that may be picked up by the ground loop. Your priorities may differ.

[@mwolrich]

The RS-422 Shield should only be connected at one end, this is supposed to be the shield (foil) on shielded twisted pair wire, only connecting to one end prevents ground differential loops… it will probably work with and without it, but best practice on RS-422 is to connect shield only at one end

[@MrWaalkman]

These are just some the best practices/life lessons/hard knocks that I learned/took away from dealing with various networks over the decades. As I said elsewhere, at the lengths that we are using for the RS-422 cable on the NABU, we could just as effectively use straightened out clothes hangers. If you plan on keeping you cable length to less than 15 meters / 50 feet you can safely skip this entire reply. If you have a cable that is less than 50 feet, and your network doesn't work, then it's not your cable that is causing the problem. So what's the big deal about *not* attaching your shield to ground at both ends? Well, if that other end is a considerable distance away, which given the capabilities of the medium is highly likely, then it is also highly likely that your ground reference voltage is at a different voltage level. This will cause current to flow in your shield and potentially cause transmission errors and/or melt your cable down. Cable quality comes in to play at high speeds + distance. A cable that is purpose built for RS-422 will have (among other things) a characteristic impedance that will be designed to keep parasitic capacitance to a minimum. Basically limiting the amount of unwanted signal conditioning that your cable is going to impose upon your signal (like it or not). Look no further than @7:18 for what I am talking about. A "good" cable will usually have foam insulation that helps keep the conductors physically separated further apart. It will have a certain number of twists per foot, it will have a shield that covers x% of the conductors, along with other considerations. From a hardware standpoint "Slew Rate" can be a critical decision, the rule of thumb is "no faster than you need". DeviceNet designers (a protocol using what looks to be RS-485) shot themselves in the foot by using a slew rate locked into the theoretical highest speed of the network. This causes all sorts of distortion on the network for no purpose whatsoever. And it's the #1 reason why DeviceNet is "obsolete" (read: "Universally Hated"). The reason why it is brought up here is because RS-422 uses pretty much the same transmitters. So if you plan on designing the hardware for TX/DX RS-422/485, do yourself a favor and don't go overboard. Better yet use a device that allows for selectable slew rates. Cable termination is important as well, you want to match the impedance of the cable with a resistor. Looking at the schematic of the NABU, we can guess 180 ohms was the cable impedance that the NABU was designed for. (Transmission) speed kills. Looking at the RS-422 length chart from RS-422 Annex A.1 you can see that you can go 1000M+ at 10kb/s (more or less 9600 baud), or you can travel around 50M at 10Mb/s. What they don't tell you, is that if you want to, you could go to the next county over if you slow things down to 50 baud, or better yet, CW at 5 words per minute. And you could exceed that 10Mb/s limit by making your cable shorter. Don't put anything past an engineer who has to make some poorly designed system work. Especially if he was the designer. And again, the NABU using a RS-422 network is probably a design decision made to support multiple NABUs off of one adapter. And given the potential maximum network length, you could easily add your neighbor's units to your system as well. Other than for multi-drop purposes there is no reason to use RS-422 (likewise there is no reason not to use it either). So given the "normal" 3 meters / 10 feet length of cable between the NABU and its host, feel free to use bread wrapper twisty ties to get the job done if you like. :) The 111k baud rate is the silent killer here. Speaking of sketchy design decisions... :)

[@derekchristenson5711]

Thanks for the explanation! I'm more of a software guy than a hardware guy, but I was suspecting that the recommendation (from DJ Sures?) to use a short cable was based on the assumption that many / most of the people making their own NABU RS-422 cable would be using random, technically inappropriate cable / loose wires, and that this would likely be a good reason to not take chances with extra cable length (especially since most people wouldn't need more than two or three feet total, anyhow).

[@MrWaalkman]

@@derekchristenson5711 You're welcome! In the PLC world it helps to wear a couple of different hats. Or have partners that do. :) Short cables are almost always the best. I like the "localized" converter (as in inside the case of the NABU) solution best, because there is no cable. Jamie's Hack Shack! shows one way to do it: kzbin.info/www/bejne/a4fSh6x8freFe8U But the real problem is that the NABU uses a baud rate that is non-standard, and was derived from the 10.738635 megahertz crystal. This crystal not only sets the CPU speed, as well as the frequency needed for NTSC video generation, it then gets further divided until it becomes the 111.861k that the NABU uses. Don't get me wrong, it was fine for NABU to do this. It's their system. It's just inconvenient for the rest of us. And Brett (The Clueless Engineer) and I had a discussion on what was going on here (and what you can do about it): kzbin.info/www/bejne/Y6fKZGOOqNRsr80 1) Use a RS422 (or a RS232) to USB adapter that has an excellent driver for it. The Tripp Lite (USA-19HS) is an excellent adapter but I have not verified if it will support 111.9k baud www.amazon.com/gp/product/B0000VYJRY/ref=ppx_od_dt_b_asin_title_s01?ie=UTF8&psc=1 2) Use an el-cheapo Arduino board and replace the crystal. Options 1 & 2 require that you set up your TR1863P as a RS232 port (it's been done). See: kzbin.info5VoVyFIRREc 3) Build an adapter that the TR1863P UART chip plugs in to which has its own 1.84Mhz crystal driving it. Some random thoughts and brain drippings: I had hoped that it would be a rather simple crystal swap to boost the serial port to a standard baud rate. I tried tracing the clock back to where it comes from on the schematic, but it leads you nowhere. Cool looking schematic, but it needs a layout page (at the very least) to tie it all together. However, the very first page in the "NABU Computer Technical Manual" says this about the clocks: "Clocks The processor board is designed to operate in a television environment requiring specific clock frequencies. The processor board has a 10.738635 megahertz.!. 50 ppm fundamental frequency, parallel-mode crystal. This is directly connected to the video processor. The video processor divides the clock frequency by three resulting in a 3.579545 (referred to hereafter as 3.58) megahertz basic clock rate. This 3.58 megahertz clock is used to drive the Z80A microprocessor." So I guess that reading the fine manual pays off from time to time... Swapping the clock (at the source) will fix one thing, but will most likely break the NTSC video signal as well. Adding a local 1.84Mhz crystal at the TR1843P (UART) chip should take care of the issue. In any case, I think that we now know why it's 111,861 baud. And I'm hoping-and-a-guessing that the RS422 to USB adapter that you bought has a fully fleshed out driver for it, so that you can use a multiplier of 26 for 'n' and 7 for 'x' From the FTDI manual: "Baud Rate = 3000000 / (n + x) Where ‘n’ can be any integer between 2 and 16,384 ( = 214 ) and ‘x’ can be a sub-integer of the value 0, 0.125, 0.25, 0.375, 0.5, 0.625, 0.75, or 0.875." So 26.875 (n=26, x=7) into 3000000 = 111.628k baud. Pretty darn close.

[@derekchristenson5711]

@@MrWaalkman I was going through my emails, came across your reply, re-read it, and thought I'd reply to it since I didn't at the time: I bought the (cheap) RS-422 adapter that DJ Sures recommended, made an appropriate cable by cutting a MIDI cable in half and soldering the cut end to a 9-pin subminiature connector, and it's been working great ever since. 🙂 I only have one NABU, but it is interesting to think that, if I had two (running at once), I could potentially be running them off of the same adapter (at least, the same ORIGINAL adapter -- not sure if the USB-->RS-422 adapter supports multidrop). Unrelated to the NABU, though, I did run into an issue with an odd baudrate on another, hobbyist project recently. Adding the VGA Expansion Card to the Minimal UART Computer project required changing the (again, ONLY) crystal to an even 16MHz, making the baudrate of the serial terminal 125,000 baud (even). Doing that caused the TTL serial adapter I was using with it to lose its dang mind and make the whole terminal hang! I guess it wasn't made to do anything non-standard, hehe. Thankfully, another adapter I had didn't mind it at all, and Tera Term lets you type in any old number for baudrate. I don't think any of my (modern) standalone terminals allow that, though. I can see why the designer did it ("Minimal", after all), but, like the NABU, it does add an extra complication when choosing equipment to connect with!

[@MrWaalkman]

@@derekchristenson5711 Nice to hear from you again! The "Minimal UART Computer" looks interesting. But I'm not sure where the guy got his definition of "Minimal". Looks like a lot of extra glue logic to me. :) That sounds like a nice and tidy cable. I'll have to get a MIDI cable and make my own. And based on the cable length and baud rate, it should work perfectly, and look nice while it's at it. I didn't know that about Tera Term, but I'm not surprised. It's a great terminal program. The "missing" piece to a multi-drop NABU system would be the software. The NABUs in the network would all have to have a unique ID (which could also be done in hardware, but why? You have to do the software anyway), and the host would have to assign packets to the various systems on the network. Which would make for a neat, but a bit slow, networkable LAN party of sorts. Sounds like fun. :) A USB to RS422 adapter (by definition) would have to support multidrop, the four wire RS422 version of course. And it would have to be tolerant of legacy RS422 devices on the same network, with so many out there that they go by the name of "Legion". :) The usual rub will be that the designer of a sketchy device will have stopped their development at "Good enough for government work" and have headed off to the bar. Probably the best example of this phenomena is Modbus. The universal protocol that has been universally abused by most of its developers (myself included). :)

[@ChrisMasto]

Using this cable, I ran the slideshow for over 12 hours and streamed it live. Here's the recording if you want proof: kzbin.infoQI-o_uMkjR8

[@arcadeshopper]

that sir, is a long cable :)

[@geekwithsocialskills]

Yep! 624 feet long!

[@DavidLatham-productiondave]

190.195m in case anyone didn't do the math.

[@Technoid_Mutant]

I started at about 20 feet of naked ribbon cable, knowing rs485 was impervious to distance. I think it might start balking at 600 meters length.