Expose the LEGO USB IR Tower as a Virtual Serial Port?

[mesheets]

Might there be a way to expose the LEGO USB IR tower as a virtual serial port, similar to how the com0com project was able to create virtual serial ports? (While the Windows 64-bit installers posted to the com0com project now seem to be having installation troubles due to driver signing issues, I have posted some information along with some possibly better-signed installers on the BrickBot Archive site here.)

By exposing the LEGO USB IR tower as a virtual serial port, this would potentially save the need to have to re-implement existing tools and utilities and instead leverage the already-existing serial port support that nearly all such tools already have. (Plus, for some tools that never had USB IR tower support added, they could now be used with USB IR towers.) As you likely know, the prevailing suggestion for working with the RCX from modern 64-bit Windows systems has been to find a serial IR tower that shipped with the earlier LEGO MindStorms Robotics Invention System sets and then connect that tower using a good (e.g. FTDI) USB-to-serial adapter. Hopefully this might reduce the level of effort?

I have both serial and USB IR towers, and I've ended up doing a little more on the Linux side with USB IR towers since the 64-bit Linux kernel already includes support for the LEGO USB IR tower, but I know Linux isn't an option for everyone, and some popular apps of particular interest to the community are not available on Linux. So, this project should certainly fill what has been a long-standing gap!

[hangrydave]

Hey, thanks for reaching out! This is a really good idea, I like it a lot

Just kind of thinking out loud here: I haven't looked at it, but I'm curious how similar the serial tower interfaces are to the USB tower interfaces. I might need to write some code to go between and translate things, probably wouldn't be a big deal. Certain things might not play well with things like fast mode and certain features that only exist on the USB tower.

I'll do some research into this. Thanks again for reaching out and sharing this idea!

[mesheets]

Hello, I appreciate the follow up, and good questions!

I must first note that I am always open to someone who might be able to shed better light on such topics—especially lower-level details such as these. Based on when I was working with some of this code several years ago, I would perhaps highlight the following for starters:

• Scope: From what I have been able to gather, almost all non-LEGO projects and tools designed to interact with the RCX seem to build in some form or another off Kekoa Proudfoot’s librcx.
  • BrickOS ultimately seemed to extend those capabilities the most.
  • LeJOS, in turn, built off the BrickOS tools but lacked the full feature set compared to the BrickOS tools (c.f. the Java Tools ReadMe).
  • NQC had its own implementation, but for the most part the low-level details appears to be similar (more on that “for the most part” in a bit)

Like LEGO, the tools for these three projects all supported both serial and USB IR towers. LEGO’s “standard” communication seems to be followed by all third-party projects; the slight implementation difference I've noticed is in the "fast IR" for the RCX.

Communication Mediums

BrickOS

Beyond serial and USB, the ability to communicate over a a few additional communication mediums found their way into BrickOS, each with their own particular idiosyncrasies. Generally, the core communication was the same, but there were a few differences in how each communication medium was handled.

• Serial IR:
  • Due to the nature of the serial IR tower, data sent to the IR tower would be echoed back.
  • Under certain circumstances, a "keepalive" byte (0xFF) is sent to the serial IR tower
• TCP: To offer wider support for the BrickEmu emulator beyond just the Bibo firmware, the emulator had a TCP port setup as "virtual" IR. Incoming and outgoing data was the same, but just going through a TCP port instead of an IR transceiver. To mimic IR behavior, data would be echoed back to the sender.
• COM: Someone hardwired a serial Bluetooth device directly into the RCX. With this setup, there was no IR echo and no need for keepalive, distinguishing this connection type from the serial IR connection type.
• NCD: As COM is to serial IR, NCD is to the TCP connection type. NCD seemed to be intended to support a physical serial port with an IR tower connected (perhaps like com2tcp or hub4com in the com0com project support), so there would be an echo, but it would be coming from the physical serial IR tower connected on the other end.

With this background, the tty_type_t enum in rcx_comm.h perhaps might make more sense. (I would note that that enum is something I added after the original BrickOS project had died off and submitted patches were not longer seeing any activity.)

In short, the serial IR and NCD types would "naturally" echo and would both also require a keepalive byte. With these idiosyncrasies in mind, the following methods in rcx_comm.c will likely be of particular interest (e.g. note the calls to rx_flush() to handle echoed data):

• Read ( rcx_nbread() ):
• Write (rcx_nbwrite() ):
• Keepalive ( rcx_wakeup_tower() ):

As a side note, several PC-side tools were written that used varying versions of the code from or similar to the code in the BrickOS host utilities. To standardize and eliminate code duplication, I combined these into BrickOS (likewise after the original BrickOS project had died off). Thus, there should be consistent communication behavior across the BrickOS and LNP tools.

NQC

For NQC, there is a ReadMe covering RCX communication aspects. The primary communication mediums supported by NQC were serial IR and USB, but USB support was not available across all platforms. Interestingly, one of the suggestions in the NQC rcxlib ReadMe (line 88) for adding USB support to other platforms is to expose the USB tower as a serial port.

I added a TCP pipe for Linux because I wanted to be able to use NQC tooling with the aforementioned BrickEmu, but this never made it into any of the builds released by the original NQC project. (It is included in the code found under this BrickBot organization.)

Fast IR and Parity

BrickOS and NQC slightly diverge here. Fast IR seemed to be a community convention (as opposed to a LEGO standard), so that perhaps might explain the divergence at least in part.

Fast IR was supported over serial IR by increasing the baud rate from 2400 to 4800. From what I've been able to gather, while "standard speed" from LEGO was setup with odd parity, Fast IR was implemented in NQC with no parity (c.f. SetMode() in RCX_SerialPipe.cpp in the NQC project). However, as CyberMaster (2400 baud) and Spybotics (4800 baud) came along, those were also specified with odd parity.

At some point, then, a change was made on the BrickOS side to just be consistent and make everything odd parity across the board (c.f. rcx_comm.c implementations for Windows and Linux/Mac lines 881-882). So, Fast IR in BrickOS has been using odd parity, too.

According to the official LEGO USB Tower Interface Reference (available here), there is no way to set the parity on the USB tower. Based on what I have been able to find online, it seems the USB tower broadcasts and receives IR signals using odd parity. So, should the parity distinction in NQC between RCX Fast IR and Spybotics be removed and always be odd parity (like in the BrickOS tools)?

That USB Tower Interface Reference also documents that the IR transmit/receive speed can additionally set to 1200, 9600, or 19200 baud, and in the BrickOS tools code, there is code on the serial port side to (at least theoretically) support 9600, 19200, and 38400 baud.

(As an additional reference, LEGO also made USB tower header files (e.g. TowerApi.h, LEGOUSBTowerioctl.h) available in the LEGO MindStorms SDK v2.5 (also can be downloaded here along with the reference PDF). That SDK doesn't even need to be installed—if opening that file with 7-Zip, the header files are available in that archive file under the path "_\program files\LEGO\LEGO Mindstorms SDK\Include".)

TL;DR: Exposing a USB IR Tower via a Virtual Serial Port?

Given the above, would the following make sense for exposing a USB IR tower as a serial IT tower? (I have not delved into virtual serial port code like is in the com0com project; can the virtual serial port detect or access connection properties like baud rate and parity?)

• Speed/Baud: Set the IR transmit/receive speed of the USB IR tower (SPEED_COMM_BAUD_*) to match the baud rate setting on the serial side.
• Parity: It most cases, it appears odd parity can be assumed, but perhaps this doesn't matter as much if the parity setting on the virtual serial port side can be detected?
• Transmit Power/Range: The battery-powered serial IR towers have a manual toggle switch to control the transmit power/range, so having a configuration dialog with a transmit power/range setting for the USB IR tower probably wouldn't be a much of a loss of functionality.
• Duty Cycle / Carrier Frequency: Shouldn't need to explicitly worry about this on the USB IR tower side, as LEGO had a table defining the default duty cycle / carrier frequency based on the specified baud rate (pp. 16, 19, 21). Those defaults could be overridden, but in most cases it does not seem that there would be a need to do so.
• USB Tower LED: Likely isn't needed; the USB Tower Interface reference notes, "This feature is used in the hardware production test to check that the LEDs are working" (p. 14).
• Keepalive Byte: It seems the USB IR tower should not need the keep alive, so when a keepalive byte is received, it would appear it can be discarded.
• USB IR Tower Flush() Command: Perhaps an initial flush and then…?

Any corrections or clarifications to any of the above are welcome. If you might be interested in joining the BrickBot organization on GitHub, just let me know.

[hangrydave]

don't have time to read this rn but thanks for the info, I'll take a detailed look once I get some time later this week

for now though: I've got a virtual serial port running on Windows rn. I ordered a serial IR tower from Bricklink + a USB to serial cable so I can play with that and get more familiar w/ the differences. Probably don't need it and could just look at the NQC source or something to see how it handles them differently, but I wanna look at it myself as well

Thanks again for all the resources and info! I'll respond again with more thoughts later this week once I get a chance to read it

[maehw]

Might there be a way to expose the LEGO USB IR tower as a virtual serial port, similar to how the com0com project was able to create virtual serial ports? (While the Windows 64-bit installers posted to the com0com project now seem to be having installation troubles due to driver signing issues, I have posted some information along with some possibly better-signed installers on the BrickBot Archive site here.)

By exposing the LEGO USB IR tower as a virtual serial port, this would potentially save the need to have to re-implement existing tools and utilities and instead leverage the already-existing serial port support that nearly all such tools already have. (Plus, for some tools that never had USB IR tower support added, they could now be used with USB IR towers.) As you likely know, the prevailing suggestion for working with the RCX from modern 64-bit Windows systems has been to find a serial IR tower that shipped with the earlier LEGO MindStorms Robotics Invention System sets and then connect that tower using a good (e.g. FTDI) USB-to-serial adapter. Hopefully this might reduce the level of effort?

I have both serial and USB IR towers, and I've ended up doing a little more on the Linux side with USB IR towers since the 64-bit Linux kernel already includes support for the LEGO USB IR tower, but I know Linux isn't an option for everyone, and some popular apps of particular interest to the community are not available on Linux. So, this project should certainly fill what has been a long-standing gap!

I've just started reading this thread, but I like the idea.

This would help WebPBrick to easily add support for the USB IR tower via WebSerial API -- as I haven't managed to support it via Web USB API (yet?). The Serial IR tower works with WebSerial API. With the USB IR tower I only was successful with the vendor-specific commands - but no transmission of IR commands.

By the way, there's also the option of building your own DIY IR tower with only a few components. I have made one as shown in the slides of my talk. It works together with a USB/serial converter but could also be used to interface with embedded platforms directly (Raspberry Pi, Arduinos, ESP32, ESP8266 and so forth). Unfortunately, I only got 2400 baud working - and not 4800 baud (for double speed).

But for sure, just supporting the USB IR tower out-of-the-box would be best!