Tibbo Technology I2C/SPI Tap for IO Ninja is Now Available

Courtesy of Tibbo Technology : I2C/SPI Tap for IO Ninja is Now Available

The new I2C/SPI Tap for IO Ninja is an affordable sniffer for monitoring I2C and SPI communications. Our sniffer allows you to tap into the lines of I2C and SPI links and immediately view the captured data bytes in IO Ninja software — in real time and using our innovative dual-hex view tailor-suited for the inherently full-duplex SPI data.

Key Features

  • Reliably captures I2C traffic at clock speeds of up to 700KHz and SPI traffic at clock speeds of up to 24MHz; all four SPI modes are supported.
  • Incorporates an I2C and SPI test sequence generator for self-testing the Tap.
  • Based on MAX10 FPGA.
  • Has 16 buffered IO lines D0~15 connected to a quick-release terminal block.
  • All buffers act as level shifters allowing the Tap to work with logical signals as high as 5V and as low as 1.8V.
  • Eight status LEDs.
  • High-speed (480Mbps) USB2.0 interface on a USB-C connector.
  • Supplied with a USB-C cable.
  • USB-powered, no additional external power necessary.
  • Compact, outside dimensions only 82 x 74 x 30 mm.
  • Product functionality may be expanded in the future.

For more details, please visit the official I2C/SPI Tap page.

Order I2C/SPI Tap Now

Introducing Tibbo’s Cable Probes

Courtesy of Tibbo Technology : Cable Probes (I2C Sensors)

Cable Probes are a family of miniature environment sensors. At the moment, Tibbo offers four Probe types: ambient temperature sensor (CP#01), ambient temperature and humidity sensor (CP#02), ambient light sensor (CP#03), and IR receiver/transmitter (BP#04). The Probes are functionally compatible with Tibbits #29#30#28, and #27 respectively.

Compared to their Tibbit counterparts, Cable Probes offer several advantages:

The accuracy of temperature (#29) and temperature/humidity (#30) Tibbits suffers from the internal heat generated by the Tibbo Project System (TPS). External Cable Probes #01 and #02 solve this by being outside of the TPS enclosure.

The ambient light sensing Tibbit #28 and IR receiver/transmitter Tibbit #27 are at a disadvantage because, being a part of the TPS system, they cannot be easily pointed in the required direction. In contrast, Cable Probes #03 and #04 can be easily mounted in the desired place and orientation.

Cable Probes are inconspicuous and can be mounted on walls and ceilings without attracting unwanted attention. The Probes come with a 100cm cable and are available with and without mounting ears.

Use the Probes in your system

Tibbo Cable Probes #01~03 communicate via a simple I2C interface and can be incorporated into virtually any control system.

Our Sensor Monitoring solution supports the use of Cable Probes. Replace Tibbits #27#28#29, and #30 with Cable Probes to improve the sensing accuracy and the convenience of system deployment.

By combining our Tibbo Project System (TPS) devices with Cable Probes you can also create your own environment monitoring systems.



  • CP#01 (ambient temperature sensor):
    • I2C interface;
    • Based on the same MCP9808 IC as Tibbit #29;
    • Mates with Tibbit connectors #20/#21, and Tibbit module #00-3;
    • Measurement range: -40 to +125°C;
    • Measurement resolution: 0.25°C;
    • Measurement accuracy: ±0.25°C.
  • CP#02 (ambient temperature and humidity sensor):
    • I2C interface;
    • Based on the same HIH6130 IC as Tibbit #30;
    • Mates with Tibbit connectors #20/#21, and Tibbit module #00-3;
    • Temperature measurement:
      • Measurement range: -25 to +50°C;
      • Measurement resolution: 0.5°C;
      • Measurement accuracy: not specified.
    • Humidity measurement:
      • Measurement range: 10 to 90%RH;
      • Measurement resolution: ±5%RH;
      • Measurement accuracy: ±4%RH;
      • Temp. range for valid humidity measurements: +5 to +50°C.
  • CP#03 (ambient light sensor):
    • I2C interface;
    • Based on the same BH1721FVC IC as Tibbit #28;
    • Mates with Tibbit connectors #20/#21, and Tibbit module #00-3;
    • Measurement range: 1 to 65528 lux;
    • Measurement resolution: 1 lux;
    • Measurement accuracy: 1 lux.
  • CP#04 (IR receiver/transmitter):
    • Contains the same IR receiver and transmitter as Tibbit #27;
    • Mates with Tibbit connectors #20/#21, and Tibbit module #26.
  • Two versions: without mounting ears and with mounting ears.
  • Supplied with a 100cm cable.
  • Power: 5VDC±10%.
  • Dimensions (LxWxH):
    • Without mounting ears: 22 x 29 x 12mm;
    • With mounting ears: 36 x 29 x 12mm.
  • Operating temperature range: -40 ~ +85C.

See Also:

More Info

Test App for Sensor Tibbits and Cable Probes: UI version

This Tibbo BASIC app is for testing sensor Tibbits and Cable Probes*. The app detects a sensor Tibbit or a Cable Probe type and displays the readings from this Tibbit (Probe) on the LCD. There is also a Sensor-Tester-Web app that implements a web interface.

More Info

Test App for Sensor Tibbits and Cable Probes: Web version

Again, this app uses DHCP, so you will need to find out the IP address of your TPS box before you can point your browser at it. The easiest way to do this is by using the Device Explorer utility. You can install just the Explorer, or our Tibbo IDE (TIDE) software — Device Explorer will be installed along with it.

More Info


Tibbo Technology WA2000

Tibbo Technology WA2000 Wi-Fi/BLE Add-on Module

Courtesy of Tibbo Technology WA2000

The WA2000 adds 802.11abgn Wi-Fi and BLE4.2 Bluetooth Low-Energy connectivity to compatible programmable Tibbo devices. The module is an upgrade of Tibbo’s GA1000 Wi-Fi add-on module.

The WA2000 is fully supported on Tibbo’s ARM-based programmable products: EM2000EM2001,TPP2(G2), and TPP3(G2).

The WA2000 is also partially supported on T1000-based programmable Tibbo products. These devices can only access the Wi-Fi interface of the WA2000, as the BLE interface is not supported by related platforms. The devices are: DS1101DS1102EM1000EM1001EM1206TPP2, and TPP3.

The WA2000’s internal firmware can be updated from a Tibbo BASIC/C app or over-the-air (OTA). OTA updates are performed from our iOS and Android Tibbo Updater apps. A single OTA update file may contain not only the new firmware for the WA2000’s internal CPU, but also TiOS and compiled Tibbo BASIC/C app for the host device (such as the EM2000)*. This means that your entire programmable Tibbo device can be updated over the air and using a single file.

In addition, we have developed an app for configuring compatible Tibbo devices via the BLE interface of the WA2000. Dubbed L.U.I.S., or Loadable User Interface System, the app relies on HTML5-formatted data to present the user with configuration pages sent by Tibbo devices. A simple-to-use library that adds L.U.I.S. support to your Tibbo BASIC?C app is also available.

The WA2000 utilizes the SPI interface and requires only 5 I/O lines to control. The module is supplied in two versions: the WA2000U with an U.FL connector for attaching an external antenna, and WA2000C device with a chip antenna onboard.

Please note that the WA2000 is a slave device and cannot be used on its own.

* TiOS and Tibbo BASIC/C app updates are only possible on Tibbo’s ARM-based programmable devices.



  • Supports the following wireless communications standards:
    • 2.4/5.0GHz Wi-Fi (802.11abgn);
    • Bluetooth Low-Energy (BLE4.2) (1).
  • Nearly 100% backward-compatible with the original GA1000 device.
  • Performs WPA key calculation completely internally.
  • Requires only five GPIO lines to control.
  • Internal firmware of the WA2000:
    • Stored in the WA2000’s onboard flash memory.
    • Upgradeable from a Tibbo BASIC/C app or over-the-air (OTA) (2);
    • OTA files may include TiOS+Tibbo BASIC/C app of the host (2);
    • Tibbo supplies iOS/Android apps for performing OTA updates.
  • L.U.I.S. app for iOS and Android facilitates convenient HTML5-based configuration of host devices through the BLE interface (3).
  • Two antenna configurations:
    • WA2000U — has a U.FL connector for an external antenna;
    • WA2000C — carries a chip antenna onboard.
  • Red status LED for connection indication (4).
  • Power: 200mA @ 3.3V (active state with data transmission).
  • Dimensions (LxWxH): 42.0 x 20.0 x 5.8mm.
  • Prototyping-friendly 2.54mm (100mil) pin pitch.
  • Operating temperature range: -40 ~ +85C.
  • FCC-certified, FCC ID: XOJ-WA2000.
  • CE certification pending.

(1) BLE is only supported on ARM-based Tibbo devices.

(2) Over-the-air (OTA) updates rely on the BLE interface and are only possible on ARM-based Tibbo devices.

(3) Requires a programmable Tibbo device running a Tibbo BASIC/C app supporting L.U.I.S. (through the use of the L.U.I.S. library).

(4) “Connection” means a BLE link or a Wi-Fi association with an access point.

See Also:

  • EM2000 programmable IoT module
  • EM2001 programmable IoT board
  • TPP2(G2) board, part of Tibbo Project System (TPS)
  • TPP3(G2) board, part of Tibbo Project System (TPS)


The WA2000 is controlled through two powerful objects — wln (Wi-Fi) object, and bt (Bluetooth Low-Energy, or BLE) object.

Files and Documentation

WA2000 binary file To be published
Documentation WA2000 Hardware Manual
CE Certificates To be published
FCC Certificates 2.4GHz band
5GHz band
Serial Controllers

Tibbo Serial Controllers

Courtesy of Tibbo Technology : Serial Controllers

DS110x Programmable Ethernet-Serial Series Family

Compact, stylish, powerful, and affordable, these tiny serial controllers are programmable in Tibbo BASIC and Tibbo C. Features include Wi-Fi, PoE, display, RS232, RS485, DIN rail and wall mounting options. Write your own app using our streamlined Tibbo IDE software or run one of our published open-source projects..

DS1102 Programmable 3-channel RS232/422/485 Controller:

Compact BASIC/C-programmable controller. Ethernet and optional Wi-Fi connectivity. Universal RS232/422/485 port. Three channels in the RS232 mode, two channels in the RS422 mode, one channel in the RS485 mode. Optional OLED display and PoE. View more here

DS1101 Programmable 3.5-channel RS232 Controller: 

Compact BASIC/C-programmable controller. Ethernet and optional Wi-Fi connectivity. 3.5-channel RS232 port with power input/output on pin 9 of the DB9 connector. Optional OLED display and PoE. View more here

DS1100 Programmable RS232 Controller:

Compact BASIC/C-programmable controller targeting cost-sensitive applications. Ethernet connectivity. Single-channel RS232 port with power input on pin 9 of the DB9 connector. Optional PoE.  View more here

Tibbo Technology Announces new TIDE Release 5.03.03 that features TiOS Simulator

New Tibbo IDE (TIDE) release 5.03.03 includes a Tibbo OS (TiOS) Simulator. The Simulator implements a virtual TiOS device incorporating virtual Ethernet interface, virtual EEPROM, virtual flash memory, virtual MD button, buzzer, and status LEDs, as well as virtual LCD and keypad.

The Simulator makes it possible to test-drive TIDE and TiOS, as well as run and debug Tibbo BASIC and C applications, without having to commit to a purchase of a physical Tibbo device.

The Simulator can be found here: WINDOWS START > Tibbo > Tibbo IDE > TiOS Simulator. You can also start TiOS Simulator from within TIDE: Debug > Start TiOS Simulator.

Once the Simulator is running, it appears in the Device Explorer as any other TiOS device would. To write an app for the Simulator, select the SIMULATOR platform and set the Simulator as the debug target.

TIDE 5.03.03 is distributed with a number of test projects written specifically for TiOS Simulator. You can find them here: (My) Documents\TIDE\Samples.

The real cost of robotics

Courtesy of


Dmitry Slepov is the managing director and a co-founder of Tibbo Technology.

Before we begin, I feel compelled to make an important disclosure: I love robots! Robots are cool. To me, robots are cooler than people, who are only cool occasionally. I especially love industrial robots: They help us “make” things.

Now please allow me to make an obvious observation: Like me, many folks think robots in general, and industrial robots in particular, are very cool. Some of these folks hold high offices in various business enterprises, where they broadcast their love for robots into their working environments.

The media’s current infatuation with industrial robots and automated manufacturing has these guys whipped into a frenzy. I know how they feel, because I feel the same way. How else can you feel after watching a video showing the production of motors for Dyson vacuums? The video is sexy as hell — shiny machines executing a complex dance in perfect unison. It’s a city full of wonders, completely devoid of boring humans.

The conclusion is inescapable: Sir James Dyson must be the overlord of robots. That is, until you see the video on how Tesla Model S is made. Another professionally put-together report from the land of (almost) no workers.

There are many videos like that, and the media is rebroadcasting them with enthusiasm. This leads me to this question: Why the renewed interest? Robots were perfectly capable of automatically manufacturing complex things decades ago. Just look at industries with products that can’t be directly handled by humans: The semiconductor industry, where the product is too small for human hands, has been building vast automated facilities since the IC revolution began and the American auto industry started to fill factories with robots back in the 1970s.

Why is the media taking such an interest now? Because today, the robotics industry has a set of fresh economic and political messages:

  • Robots are becoming affordable.
  • Anyone can benefit from purchasing a robot.
  • Robots will increase our production efficiency.
  • Robots will allow us to “reshore” (run away from China).
  • We will be able to make things in our country again.
  • We will get rid of workers — they are just too expensive and too lazy and kids these days don’t want factory jobs anyway.

Although all of the above are true to some degree, the simplicity of media coverage distorts the real situation. After watching numerous videos showing cool automation in action, it would be easy for you to get the wrong idea about how much effort it takes to automate anything.

A lot of folks imagine the process of bringing a robot onto their production floor as, literally, bringing a robot in.

I will argue, based on my own and my peers’ experience, that a lot of folks imagine the process of bringing a robot onto their production floor as, literally, bringing a robot in. You buy a robotic arm, you install that robotic arm, you’re done.

It’s hard to blame them. Robotic manipulators are what they see in videos. If you hear the words “industrial robot,” what pops up in your mind? The arm! Get one or a couple of these and you are on the way to your company’s automated future. If only it was that simple!

Let’s look at what it takes to create a typical manufacturing cell that assembles something. We start at the moment when you decide to acquire a robot…

Because you know that you definitely need a robotic manipulator, you start your purchasing or your mental journey from getting that arm. So you buy an ABB, KUKA, Toshiba, EPSON or some other brand you saw at the robotics trade show you visited recently. Depending on the brand, your outlay for the arm is perhaps $30,000-60,000. Despite the high cost, that arm is literally… an arm. No torso. No wrist. No fingers. No eyes. And no brains (I’ll get to this later).

Next, you find out that you can’t simply install your robot on any desk. No. It must be a heavy-duty, purpose-built pedestal. These things have enormous weights; they are expensive, too — expect to spend several thousand dollars.

But wait, there’s more. Your robot needs a cage… unless it’s one of those new collaborative robots like UR-10 from Universal Robots. Because they are allowed near people, they move like yoga instructors, putting you to sleep in the process. If you care about doing things fast, you’ll buy a speedy robot — and it will have to be caged. The cage will need to come with some safety equipment, like an emergency stop button, safety sensors and so on. Chalk up several more thousand dollars for the cage and all that safety stuff.

Next, you’ll need to take care of something called an “end effector.” That is the part that attaches to the business end of your robotic arm and allows it to do useful things. End effectors vary, from grippers with fingers for holding things to vacuum heads to electric screwdrivers to an endless array of specialized contraptions. Chances are you won’t find any suitable end effector for your application, so someone will have to build you one. Budget a lot of money for this part of your project.

Human hands are extremely versatile and can do thousands of different jobs. Not end effectors. Your robot will probably have to be equipped with several end effectors for handling different production steps. This will involve the use of a so-called tool changer. It’s just like in Japanese cartoons. One moment that giant robot holds a bazooka, the next it’s a ray gun.

With a tool-changing system, like the one made by ATI-IA, your robot will be able to quickly change between, say, an electric screwdriver and a suction gripper. The bad news is that tool changers are so expensive that adding such a system will easily cost you around 30 percent of what you paid for your robotic arm.

Next, you’ll need to think about giving that arm of yours some ability to sense. Most robots don’t come with “force feedback.” They boldly go where you tell them to go, no matter how many things get smashed along the way. A typical robotic arm with a gripper is about as sensitive as a crab claw (no offense to crabs). A force-sensing accessory will solve that, to a degree, but it will also set you back several more thousand dollars.

Wait, you aren’t there yet. Now you need to think of a way to hold your “parts in production,” i.e. parts that your robot will be working on. Humans come with two hands. We can hold a screwdriver in one hand and secure the part on which we are working in the other. Try doing any kind of assembly using just one hand. You won’t get very far. Well, that’s the situation your robot will be in, constantly, unless it’s one of those cute two-armed ABB Yumi robots (there is nothing cute about their price; you can buy two or three one-armed servants for the price of one Yumi).

So, in order to hold your “parts in production” in place, you’ll need to come up with fixtures and contraptions that are unique to whatever it is you are manufacturing. There are many ways to do this stuff. For example, my company supplies a construction system called UniQb. You can quickly build one-off fixtures and rigs using its “beams.” This part of your project may not be very expensive (in comparison to everything else), but it will consume quite a bit of time.

Alternatively, you can assign a worker who will service the robot while contemplating a philosophical question: “Who works for whom? Does the robot work for me or do I work for the robot?”

This step handled, you will need to think of how your robot will get the parts to work on and output the fruits of its labor. Robots can’t (yet) run to the warehouse and cart back a bunch of parts. You robot is like a master craftsman sitting in the middle of a studio. Everything must be brought to it. For small parts, such as screws, you will need to install “screw presenters” — machines that “offer” screws in the right orientation. Larger parts will need to come on conveyor belts or some other means of transportation. Alternatively, you can assign a worker who will service the robot while contemplating a philosophical question: “Who works for whom? Does the robot work for me or do I work for the robot?”

The next step is to equip your mechanical monster with eyes. With the exception of the aforementioned Yumi, which, in the appropriately mutant fashion features eyes on its hands, most robots arrive at your doorstep completely blind.

You will need to install a vision system consisting of one or more cameras and a processing unit. You will also need to arrange ideal lighting conditions: Cameras are not like human eyes. Too bright or too dark, and the system won’t work. Also, robots mostly see in 2D. There are some new 3D vision systems on the market, but these are still prohibitively expensive. A good vision system will cost you several thousand dollars and a lot of trial and error until you get it to work right.

Also, don’t forget about electric power and air supply. Many robots will require “industrial” power (not the power available “on tap” from your wall outlet). Your system will almost certainly use vacuum grippers or something else that requires “air.” Robots don’t come with compressors. You will need to buy and install one. More $$$ spent.

Are we there yet? Nope! All this extra stuff you now have around your robot will need to be hooked to a single control system that opens and closes valves, activates servos, senses the position of things and so on. Such jobs are typically accomplished with programmable logical controllers (PLCs) or embedded computers.

Last but not least: programming. This part is particularly fun. You will need to teach your robot how to do anything useful. Hello, disappointment. We all grew up watching Star Wars, so we automatically attribute some intelligence and magical powers to our mechanical helpers. Forget it. Robots are not smart. In fact, they are plain dumb. You will need to teach your robot literally every tiny little move. There is virtually no self-learning. Expect a lot of labor. You will be trying, adjusting and, when you thought you were done, you’ll find yourself coming back to adjust some more.

All these steps I’ve outlined require you to be a very skilled professional in a multitude of disciplines. Chances are that you aren’t — and even if you are, it’s unlikely you have time to deal with all this complexity. This is why you will probably hire an integration company to put the system together for you… for a price tag that is twice higher than the sum total of all the parts involved.

In the end, you will look at that robotic arm you started your journey with and realize that the arm is but a tiny part in the long list of equipment that had to be provisioned, installed and configured in the name of your automation project. You see now what it took Sir Dyson and Mr. Musk to fill their factories with hundreds of robots? They approved oceans of work, hundreds of thousands of hours of human planning and design and tens of millions of dollars in equipment costs.

And now for the worst part… Here it comes. Da-dah! These futuristic production lines you see on TV and YouTube are mostly built to handle just one product. Change the product, and you need to redesign your production line. You don’t just tell your robot to “stop doing this thing and start doing that thing right from tomorrow morning.” You start “retooling” — and retooling is expensive and time-consuming.

The U.S. auto industry with its futuristic robots learned this the hard way, while the Japanese (whom we firmly associate with robots) did not go overboard and simply stayed with lean production teams of human workers. Take heed! Before embarking on your automation journey, count how many years of human salaries you will be able to pay by NOT investing into your smart robotic manufacturing cell.

Have I just put you off robotics? I hope not! Like I said at the start of this conversation, I love robots! Robots are cool. There are many excellent reasons to use them. We humans are unpredictable and difficult, and as time goes by we become less and less inclined to take on factory jobs.

Automation is coming, and robots will eventually take over our production lines. I just want you to know that today’s real-life robots are nothing like what the media makes them out to be. Proceed with caution (and deep pockets).


Unusual features you would not expect from a terminal emulator

I don’t know about you, but I love Lego, I really do. Back when I was a kid I actually didn’t have the original Lego set – my father was a fan of more advanced construction toys like Meccano and Erector, where you had to screw parts together with nuts and bolts. However, being a programmer – and I am one – you get to appreciate the beauty of the Lego concept

Building complex devices or systems by connecting simple blocks together is the essence of engineering, and you will be hard-pressed to find a better example of “complex from simple” than that offered by Lego. All the blocks are compatible, all the blocks connect to other blocks easily, you don’t need any nuts, bolts or tools, and only your imagination is the limit for what you can build. And boy, have you ever tried to *break* a Lego brick? I dare you to accomplish this!

When we design software, this got to be our ultimate goal. We want it to be like Lego. We want it to be built with small building blocks, each one as simple and robust as a Lego brick, each one interchangeable and easily interconnectable with other blocks..

Unfortunately, it is not always possible to achieve this goal, and even when it is, we often find excuses for not going all the way in Lego-ising our projects – after all, our customers (and most employers) usually only care about the end product, not the bricks it is built of.

I will argue, however, that investing time, money, and creative thinking into Lego-ising your software product may reward you with unanticipated product strengths and features. In support of this statement, allow me to present Exhibit A.

Exhibit A

The case in point is our software called IO Ninja – here is a link to my introductory article covering the origins of Ninja. To make the long story short, once upon a time we were looking for binary-enabled IO terminals and sniffers for a specific set of transports and protocols. After not being satisfied with what we found (check the link above to find out why), we ended up creating our own all-in-one low-level IO debugger. Somewhere along the way we’ve got a crazy idea of making it programmable, so our users could write their own protocol analyzers and testing scripts. This is the preamble to what I want to tell you.

These two design goals – to build an all-in-one product and to make it programmable – have essentially forced a Lego-like architecture upon us. So, this wasn’t even a choice; we couldn’t get away with the usual “the end product is what matters” mantra. In our case, the end product had to look a lot like Lego!

Here is what we ended up with: IO Ninja software consists of two large parts – the binary part and the script part. The binary part provides a framework of Lego bricks: sockets, serial ports, sniffers, buttons, combo boxes and so on. Scripts glue our Lego bricks into specialized IO sessions.

Now comes the interesting part: After creating a Lego-like design, we discovered that IO Ninja naturally has a plethora or interesting, useful, and unexpected features that were not anticipated even by us – the builders of this product!

Ability to redirect anything-to-anything

Users of Unix-like systems are well-aware of the possibility of redirecting the output of one program to the input of another. Session linking in IO Ninja provides similar functionality. The difference is this: instead of unidirectional data cascade of Unix pipes, session linking shorts the TX stream of one session onto the RX stream of another – and vice versa. After this shorting, IO Ninja keeps passing the data back and forth between the two sessions. That turns IO Ninja into a universal redirector.

Let’s say you have a device attached to your PC via a serial port, and you want to be able to connect to this device over TCP. That’s right. Connect to a serial device over TCP.

Launch IO Ninja and start a new serial session. Open and configure your serial port. Next, open a TCP Listener session, choose a TCP port to listen on, and start listening.

Now all is ready for you to reap the fruits of IO Ninja’s Lego-like architecture! Go Menu->Session->Link sessions. Voila! You can now connect to your serial device via TCP (notice the chain links on session tabs):

You can use the same approach for redirecting TCP-to-UDP, UDP-to-SSH, Named Pipe-to-TCP, and so on. As an extra bonus, all passing data will also be logged in the process, turning your setup into a universal man-in-the-middle sniffer.

Searching for devices using UDP broadcasts

A common way of auto-discovering devices on a local network segment is by broadcasting a UDP request packet and collecting replies from participating devices. This is how Tibbo’s software discovers our devices.

With IO Ninja’s modular architecture, we were able to take a Lego brick of UDP socket and plug it into a dedicated session specifically designed to handle one-to-many communications.

To try it, open a UDP Socket session, set the remote address to (or to a subnet broadcast address like, then send an echo broadcast packet. As a result, you will see the list of devices connected to your local network segment. Now choose one of these devices, copy-paste its IP address and start communicating with this particular device!

Check out the compass button. When working with the UDP protocol, you often need to reuse the source address from which the most recent packet has arrived (after all, UDP is a connectionless protocol). Of course, nothing prevents you from copying an address from the log and pasting it into the remote address combo box, yet why do something manually when you can automate the task? Press the compass button, and the UDP Socket session will automatically readjust the remote address to the address from which the most recent packet was received.

Sniffing TCP data using a TCP proxy

IO Ninja includes a Network Sniffer session. This is a pcap-based plugin for monitoring network protocols. When running it, IO Ninja behaves much like the Wireshark software. Despite the prevalence of pcap-based software tools, the reality is that the pcap-based approach is not the only way to eavesdrop on network communications. In some situations, using a pcap-based sniffer is simply not possible, and in some situations, there are much better ways to tap into the data stream.

In addition to the traditional pcap-based sniffer, IO Ninja provides the second kind of a TCP sniffer: it is called a TCP Proxy, and it is a combination of two TCP sockets – a client one and a server one – passing data between each other.

Here is the benefit of this approach: instead of a packet-based log (with disjoint chunks of data you must mentally piece together), your TCP proxy session provides a clean log of data streams – just like you would see in a TCP connection session. Also, unlike with the pcap-based sniffing, which is only applicable to local networks, TCP proxy sessions allow you to monitor TCP links in all situations, as long as you can position yourself to be the man-in-the-middle.

Here is a screenshot of an FTP session being monitored with the TCP Proxy plugin:

Debugging named pipes in Windows

IO Ninja can be used to debug a very common IPC (inter-process communication) method in Windows called named pipes. For example, all Tibbo kernel-mode drivers use this method to communicate with user-mode services and configuration utilities.

Unfortunately, debugging named pipes can be pretty tough due to the lack of named pipe terminals and monitors. Before IO Ninja, you could not even send a packet over a named pipe without having to write a test application! Naturally, we were determined to fix that – IO Ninja can work as both the client- and the server-side terminal for Windows named pipe communications.

To use IO Ninja on the server side (the one that calls the ConnectNamedPipe function), launch the Named Pipe Listener session. This plugin allows you to accept named pipe connections originating from your application, driver, or service, much like the TCP listener plugin accepts incoming TCP connections. After accepting a connection, you can communicate with a client and analyze the log of received commands.

For emulating the other side of named pipe communications, use the Generic File session.

For monitoring named pipe communications you can employ the man-in-the-middle approach described earlier. To do so, start a Named Pipe Listener session, link it to a Generic File session and redirect your named pipe client to IO Ninja. In the future, we are planning to provide a dedicated standalone filesystem filter-based plugin for sniffing Windows named pipes. For the time being, the man-in-the-middle approach will suffice for most debugging scenarios.


Described above are just some of the many cool features stemming from the Lego-like architecture of IO Ninja. Allow me to repeat this: we haven’t even planned to implement some of those features – they simply appeared as a result of having a well-planned modular architecture. Make no mistake – applying this Lego principle to your project is a hard job. It requires a massive investment of time and effort, take my word on that. Still, going down this path is well worth considering. Who knows, maybe you will also discover a few unexpected and useful features magically appearing as a result of your Lego-like approach.

So, let’s Lego-ise!

Portfolio Items