If you write Python and you need to move small messages between devices or services, MQTT is usually the right fit. It is a publish/subscribe protocol: a client sends a message to a topic, a broker holds the connections, and every client subscribed to that topic gets a copy. Publishers and subscribers never talk to each other directly.… Read More: Python MQTT: Complete Guide to paho-mqtt 2.x »
XON and XOFF are two control characters that let a serial receiver tell a sender to pause and resume. That’s the whole idea behind software flow control. No handshake wires, no dedicated signals — just two bytes sent back up the same link the data travels on. When a device can’t keep up, it sends XOFF and the… Read More: XON and XOFF: Software Flow Control Explained »
A null modem cable connects two DTE devices directly — two PCs, a PC and a controller console port, two pieces of test gear — with no modem in between. The whole job lives in the wiring. Transmit on one end has to reach receive on the other, and depending on the device, a few control lines have… Read More: Null Modem Cable Pinout: DB9 & DB25 Wiring Reference »
On a Modbus serial line, every byte you send is wrapped in a few extra bits before it hits the wire. Those extra bits — the start bit, an optional parity bit, and one or two stop bits — make up the character format. Get them wrong on one device and it won’t talk to the rest of… Read More: Modbus Parity and Character Format »
Device control is where ICCP stops being a data feed and becomes an operational tool — and a liability if misunderstood. Conformance block 5 lets one control center trip breakers, raise taps, and write setpoints in another organization’s network. The protocol wraps that power in the select-before-operate pattern every operations engineer knows from local SCADA, adapted for the… Read More: ICCP Device Control: SBO Select and Operate Explained »
An ICCP link is a standing, months-long connection between two organizations, carrying real-time grid data and — where block 5 is enabled — live control of primary equipment. It crosses an organizational boundary by definition: the other end is somebody else’s network, somebody else’s patching discipline, somebody else’s incident. That makes it one of the most security-relevant connections… Read More: ICCP Security: Hardening TASE.2 Links With IEC 62351 »
A transfer set is the engine of an ICCP link. Data values are what you exchange; data sets group them; but the transfer set decides everything about the actual flow — when reports are sent, what they contain, how bursts are handled, and whether the client must acknowledge. Once transfer sets are enabled, the link runs itself: the… Read More: ICCP Transfer Sets: How TASE.2 Reporting Really Works »
Open Wireshark and search the protocol list for ICCP or TASE.2. You won’t find either. There has never been a dedicated ICCP dissector, which confuses many engineers the first time they capture an inter-control-center link — the traffic is right there on port 102, and Wireshark calls it something else. Here’s the thing that makes it simple: ICCP… Read More: Wireshark for ICCP: How to Decode TASE.2 Traffic »
The first time you capture ICCP traffic in Wireshark, the protocol column reads like an archaeology dig: TCP, then TPKT, then COTP, then Session, Presentation, ACSE, MMS. Seven layers deep before a single power system value appears. This article explains what each layer does, why the stack looks like this, and — since this is where commissioning time… Read More: The ICCP Protocol Stack: OSI Over TCP/IP Explained »
Every ICCP datasheet says the same thing: “supports blocks 1, 2, and 5” or some variation. Conformance blocks are how TASE.2 capability is packaged, sold, tested, and written into bilateral agreements. They’re also where datasheets, the wire protocol, and the standard itself quietly disagree. This article decodes each block, explains why nearly half of them were deleted from… Read More: ICCP Conformance Blocks: What Servers Actually Support »