RS422 / Sony P2 protocol and serial stuff!

When running P2 protocol over RS422 (i.e. Sony VTR remotes) there is no hardware handshaking so RTS and CTS (Request To Send and Clear To Send) aren’t used; a bit like the old 3-wire XModem/YModem/Kermit protocols used in RS232 (remember RS422 is just a balanced version of RS232).

We base our RS422 wiring on the Quartz remote standard (Quartz were one of the first firms to use RJ45s & cat5 for RS422 remotes):

However – I know for certain that Probel use a different standard and many places are wired to whatever the local standard is; remember – until ten years ago most places wired ‘422 on star-quad cable rather than cat5e/6. I don’t know if current model Evertz routers have maintained the Quartz standard – I bet they have given they bought Quartz for its router business.

Whatever wiring standard is used always make sure that pins 2 & 7 are a twisted pair and likewise 3 & 8 otherwise you lose all the advantage of common-mode noise rejection that balanced RS422 brings.

Finally you need to be certain if a place is wired for chassis earth (pin 1 on a 9-pin) or signal earth (pins 4 & 6 on 9-pin). Signal earth is best as there is always a chance of earth-hum between areas when you tie chassis earths together but hopefully properly designed kit with balanced lines have the signal earth floating WRT to power/chassis ground. BUT, you have to stick with the local standard; if the engineer has wired only chassis earths you need to continue using pin 1 or even shorting pins 1, 4 & 6 at the remote end.

Remote control options

If (like me) you find yourself as the default tech support provider for friends and family you've no doubt wondered about remote desktop software - VNC, RDP, Apple remote desktop, or any of the paid-for managed services (Go To Assist, LogMeIn etc).

I think there are several things to bear in mind;

1. NAT routers in the way? If you're merely using remote desktop to go between machines on the same LAN then this isn't an issue but if you have to take control of your Mum's laptop and you're both behind routers then you either have to have made a hole in her's or be using a protocol that supports NAT translation.
2. IP address - again, the person you're trying to reach may well be on a dynamically assigned IP address.
3. Bitmap vs remote GUI rendering; VNC sends a bitmap (admittedly compressed) and so maybe sluggish whereas Windows RDP or Apple remote desktop send GUI primatives which render at the remote end.
   
4. What combination of OSes are you using? Running Windows but supporting someone on a Mac? The remote desktop client built into OS-X since Tiger falls back to VNC if the remote machine isn't a Mac - nice touch.

So - in the case of my Father-in-law's Windows XP desktop machine I use VNC every time - This is because I don't know if he's going to call me during the working day (when I'm using an OS-X laptop) or in the evening when I'm likely on a Windows 7 or XP desktop. Since his machine is fixed I had the liberty of installing a DynDNS account on his router (so I hit a username.dyndns.org address rather than trying to discover his internet-facing IP address) and I opened a hole in his routers firewall (so traffic on TCP port 5900 gets mapped through to his PC). With all that in place I know I can grab control of his desktop using TightVNC (my favorite VNC client) under Windows or the built-in remote desktop of Snow Leopard;

On the other hand my Mum has a laptop which may or may not be at her house. Since she is running Windows 7 and I can always get to a Win7 machine she Instant Messages me with a Windows RDP support request and after a bit of typing in confirming codes it works well without having to worry about IP addresses or NAT traversal.

That leaves the paid-for server-based systems like Log Me In and Go To Assist which require no software installed (it's done via a quick Java download) and take care of NAT traversal etc.

So - you pays for money, you takes your choice. I prefer VNC because it's open and works across OSes. It does require a bit of work to send it across the public internet. After that Windows RDP is fine if you have contemporary Windows boxes. I suspect at some point I'll sign up to Go To Assist and pay as it is very convenient and works entirely well across networks and OSes.

VNC connected to my home Windows 7 media machine, running inside a Windows 7 virtual machine on my Macbook Pro under OS-X

TCP/IP Congestion Avoidance

TCP/IP is a jolly clever protocol that now forms the bulk of the traffic that runs across the Internet. Given that routers and gateways along a packets route are entirely at liberty to drop packets without informing either the sender or the recipient (it's up to the client/server to figure out packet sequence and if any packets were lost) there is a very clever way that the IP stack in your computer does packet collision avoidance.
So when TCP establishes a connection it goes through an IP-slow-start. In essence the stack has to "sneak-up" on a transmission speed where packets are being lost faster than they're being sent; when that occurs the stack backs off until packet failure is happening less than new packets are being sent. The initial condition is that the stack can send two packets without getting a confirmation. For every confirmed packet the stack can increase the maximum segment size by one so that two packets can become three and so on. After that there are several commonly used strategies, most commonly "TCP Reno" and "TCP Tahoe". Tahoe reduces the congestion window to one MTU ("Maximum transmission Unit" - typically a 1550 byte packet in Windows) and then go back to the IP-slow-start. Reno halves the size of the congestion window and so backs off slower than Tahoe but hopefully the link has recovered fast enough to make that a better strategy than Reno.

Anyway - as ever the Wikipedia article is very comprehensive;
http://en.wikipedia.org/wiki/TCP_congestion_avoidance_algorithm