MuLPI - a Multiple LEGO Remote Protocol Interface

[Toastie]

Dear All,

the purpose of this thread is to assemble as much information as possible on old and current LEGO remote communication protocols, composed from scratch, i.e., data (= channel + action, e.g.: set channel 1 to motor power +3) encoded to the bit/byte data stream emitted by various LEGO remotes using simple algorithms. Such approaches have been repeatedly reported in individual threads here on EB as well as on many places out there in the depths of the WWW, sometimes even whole collections of protocol data exist. Maybe some old farts like me are interested in a more or less comprehensive collection, maybe not. I take the Nike route and – just do it. The hardest part (for me) when encoding LEGO remote control data is the calculation of the checksum, which is always used in TLG’s protocols. It looks like this, when I am trying to find the way the damned checksum is calculated:

I will try summarizing all the information and links to encode respective data for a particular LEGO IR protocol, including the commands available and their corresponding value. Again: This is all out there, but as far as I am aware not documented in one place – at least I did not find that particular place. I will simply append any missing information that becomes available to this thread and update the files on the UoWuppertal cloud server, as referenced below (PDF and PPT format): LEGO Protocols: Data format, bit/byte streams and data encoding (very far from beng complete): https://uni-wuppertal.sciebo.de/s/BbYzAnDGLwmWnv7
For the remainder of this post: You may just ignore it. It is very, very long. At the very end there is a link to my “C++” program running on an ESP32 Dev board, which is doing all the protocol translation and signal generation work for my DELL laptop (2019, i7 CPU@2.60GHz, 16Gbyte RAM) as well as for my ZX Spectrum (1985, Zilog Z80 CPU@8MHz, 48kByte RAM). Both are running a control program (of rather different nature) for operation of my trains: 2 RCX, 1 RC, 7 PF (12V, 9V, 4.5V), 4 Pup.

When you read on ... OK then, here is

MuLPI – a Multiple LEGO protocol Interface

 

It may appear as if this thread is a copy of this device in the Mindful Pub thread, but it is not; basically everything inside the LEGO box has changed:

 

Thus far MuPLI can directly control these LEGO devices/speaks these protocols:

(@1963maniac: Thank you for help in fixing the following list!!!)

White bullets = devices/protocols: (1) VLL (Code Pilot, MicroScout, Scout, RCX, Spybotics); (2) RC Car (NitroFlash, Bonicle Manas, Spybotics); (3) RC Train (RC Trains only), (4) + (5) RCX (RCX, Scout, Spybotics, NXT/EV3 w/ IR Link sensor); (6) PF; (7) BLE (PoweredUp)

Yellow bullets = computer input/output: (A) Serial input w/ HW RTS/CTS handshake (e.g., for ZX Spectrum + Interface 1); (B) Serial input via UBS to serial adapter, for “modern” computer control via e.g. USB port (XON/XOFF). RTS and CTS lines connected for operation with LEGO software (ScriptEd, Scout Tool, vpbcom.ocx etc., see below)

Green bullets = MuPLI output/input: (V) Built-in VLL (TX only), visible light best transported via optical fiber; (W) Built-in BLE (RX/TX); (X) Built-in IR (RX/TX); (Y) External IR via RS232 (RX/TX), e.g. for LEGO serial tower boosting the IR signal; (Z) Built-in RF (433 MHz RX/TX)

The individual bit/byte streams are encoded using only two input values: “channel” and “action”. Exception is VLL, as there is only one channel; all VLL devices will respond to the “action” data sent. VLL requires thus one dedicated output (LED) per “channel”. I am using optical fibers on my train layout to operate multiple MicroScouts from one “controller” as shown in this EB thread:

 

 

The following is mostly babbling and bragging. Also the thread title is utter hubris – MuLPI sounded funny to me, that’s all: There is no direct Bluetooth (NXT/EV3) protocol implemented yet, but that is rather current and merely a serial over BT connection, I may by wrong though. And no Cybermaster protocol yet, because I don’t have Cybermaster hardware … and many other things are surely missing as well.

MuLPI is built around an ESP32 Dev board (30 pin layout) with the help of a PANT. As I don’t know what a thing attached to an ESP32 Dev board is called, I freely chose PANT: Arduinos have SHIELDs. RaspberryPi’s have HATs. For both, the GPIO (etc.) board connections are facing upward, using sockets (as far as I know). The ESP Dev board has pins facing down. It thus appears as if an ESP32 Dev board needs to get its pants on, whereas a Pi needs a hat, and an Arduino a StarWars type SHIELD. The PANT looks like this (left ESP32 Dev board with a 2x2 tile and plate glued to the "processor and other stuff" cover, right PANT)

 

What may be of interest is the encoding of the bit/byte sequences of all the addressed protocols (VLL, RCCar, RCTrain, RCX, see below) from basic input data (channel + action). Some people have sniffed the various IR protocols and then used the bit streams recorded. This is not the approach here; I am trying to use super simple encoding routines. As said, there are many references out there. In the coming weeks/months/years (yes, years, time goes by, so slowly …) I will just append individual encoding routines here – or maybe other folks as well.

So far I have done this for the VLL, RC Car, RC Train, and RCX protocol. PF is available as part of the Arduino Legoino (https://www.eurobricks.com/forum/index.php?/forums/topic/180905-new-version-100-of-legoino-arduino-library/) library package, which runs on ESP32 boards. There are many other well documented PF encoding routines out there; even TLG has provided superb RCX, VLL, and PF documentation – the olden days were better. See draft(!) tables at the end of this way too long message.

Spoiler

MuLPI - what is it really? It’s a box made of LEGO bricks and plates (referred to in the outer space regions I come from as LEGOs) I made to (sort of) resemble the appearance of a ZX Spectrum. Why such a box? Because I am much into this vintage stuff, some old farts as me seem to appeal to when they can’t hold-up with current developments such as 5G smartphones or Windows 12 … They can brag about the good’ol days and that “we” essentially had it in priciple all already back then. And how hard it was. Modems and stuff. And that we still know all these things and can make such hardware raise from their graves and operate them .

This is from the PANT marketing department: "The PANT features a most powerful 74HC00 DIP-14 chip from the late 1980’s, three (equally powerful) very low wattage resistors, and a bunch of connectors. All this soldered to a 1985 state of the art bread board. Furthermore, most powerful RF technology from around the Y2k is used: LINX RXM/TXM 433 MHz OOK RF receivers and transmitters (note: The old “LC” version that is, as the newer “LR” versions from 2007 or so cause noise trouble, at least the receivers). And finally a gigantic almost 1” 128x64 high resolution monochrome super-bright OLED display showing the status of the MuLPI. And there are four (super) push buttons, one of which is a 1998 LEGO touch sensor – the ultimate push button solution."

MuLPI Hardware

 

Figuring out what to use and how to solder always begins with very professiona sketches and notes in my “LEGO ideas scratch pad” – the ones operated with a pen:

 

Here’s the PANTs size: XS – no, sorry, the circuit diagram (not used for any fancy PCB production, simply made for documentation - although I do trust my pen version much more!):

The entire electronics looks like this:

 

This is my ZX Spectrum operating 15 trains (2 RCX, 1 RC, 7 PF, 4 PUp):

Using the Speccy is absolutely >not< comfortable, as you can only see the data of two trains simultaneously on the screen; one has to “scroll” left and right to see/change other train data. Not the point: I just wanted to see my Speccy getting it done. For more comfortable operation I am using the MuPLI connected to my laptop running this VB6 program:

 

Spoiler

Uninteresting details: When I was about to finish an “interface” allowing my vintage ZX Spectrum talk to my RCX and PF trains with the help of an NXT with IR Link Sensor, The Internet told me that my currently favorite micro controller board, the ESP32 Dev board, has 3(!) programmable UARTs available, two of which are set-up/printed per default on the board (RX0/TX0 and RX2/TX2). RX0/TX0 are used for communication via USB with e.g. the Arduino IDE (serial I/O via the Serial Monitor window and program upload etc.). Why is this exciting at all? Well, for me, it is/was this:

As already discussed in the above referenced thread, the ZX Spectrum with ZX Interface 1 attached only knows the “8 data bit/no parity bit/1 stop bit” (8N1) protocol at various standard baud rates up-to 19200 (although 9600 is recommended in the ZX books; don’t forget, we are back in 1983). Furthermore, the Interface 1 requires CTS/RTS hardware protocol handshake to digest each data byte arriving at its port as there is only a one byte serial “buffer”. Output-wise, RTS needs to be pulled low before the Interface 1 sends out any data. When connected to any type of modern computer equipment, you can securely leave this line permanently low – after almost 40 years of further development, serial communication has become a little more efficient than back in 1983 with one Z80 CPU, two ULAs (one in the ZX Spectrum, one in the Interface 1) and breathtaking 16 (up-to 48) kByte memory.

In contrast, the LEGO IR protocol of the RCX (Mindstorms) and RC Car system is 2400/4800 baud, 8 bit, odd parity, 1 stop bit. And the odd parity was the challenge (for me only of course: C++ gurus will certainly add one, max. two lines of unreadable code to the Serial.h/.cpp files of the Arduino IDE and voila … I am basically a basic BASIC programmer, pretending to program C++ in the Arduino IDE). And that stopped all my efforts on using an Arduino Uno for my interface: The Uno has only one programmable UART – and for some reason I did not manage to get ANY of the software serial libraries to work with the weird “odd parity” LEGO setting on one serial port and the other port on “no parity” setting on the ZX Interface 1 side. However, an Arduino MEGA (for example) has 4 UARTs available and they work flawlessly regardless of the individual settings.

Now, why is the ESP32 so interesting? Because it features an on-board BLE hardware/software stack (among WiFi and BLE and so on and so forth) – and Cornelius Munz made some very nice code to operate PoweredUp devices with the ESP32 called Legoino: https://www.eurobricks.com/forum/index.php?/forums/topic/180905-new-version-100-of-legoino-arduino-library/. In addition, Legoino also incorporates a publicly available PowerFunctions library. And: The ESP32 features 3 UARTs, so two can be used to make the ZX Spectrum <-> LEGO IR connection – and even much more …

Getting the third UART of the ESP32 alive is as simple as declaring two suitable GPIOs as inputs/outputs. So that was it: I put the MEGA aside and began to make a “Mulitple LEGO Protocol Interface” or simply MuLPI.

The LEGO protocols “handled” by MuPLI are:

• VLL (Visible Light Link) protocol; applicable to Code Pilot, MicroScout, Scout, RCX, Spybotics.
• RC Car infrared protocol; applicable to NitroFlash, Bionicle Manas, Spybotics.
• RC Train infrared protocol; applicable to RC Train, NXT w/ IR Link sensor, EV3 w/ IR Link Sensor.
• Mindstorms infrared protocol; applicable to RCX, Scout, Spybotics, NXT w/ IR Link Sensor, EV3 w/ IR Link Sensor.
• PowerFunction infrared protocol; applicable to PF, NXT w/ IR Link Sensor, EV3 w/ IR Link Sensor, uses the Legoino library.
• PoweredUp BLE protocol; for all hubs covered by the Legoino library.

Once again: Many others have already done similar things, and there are many and diverse, sometimes dead, sometimes only reachable via the Wayback Machine links, with some information of the protocols out there. But there appears to be no comprehensive compilation featuring the encoding software routines for the bit/byte stream used to control the various LEGO devices.

How does MuPLI work? Well, as simple as this: It routes data from the serial port connected to a “computer”, which may even be a Sinclair ZX Spectrum with Interface 1 (or any other old/new computer with serial port or USB to serial adapter) – to the serial port of the “LEGO terminal”. Both terminals are plain vanilla RS232 ports. Depending on the MuPLI mode selected (out of four), it also translates the incoming data from a computer/user to communicate with the “LEGO terminal”. Mode selection is done by repeatedly pressing the Mindstorms touch sensor on the back of MuLPI located next to the VLL output diode.

The button is de-bounced with a bold 500ms delay, so no super quick rush through the modes. Patience. There (partly) is almost 40 years old hardware at work here!

 

Operational Modes of MuLPI

 

The four operational modes of MuLPI are:

(Manual Mode) Uses the Serial Monitor window of the Arduino IDE to submit data to the MuLPI; format is one ID byte (range 170 to 201) and one data byte = action (power setting and stop), see below. Depending on the device class “identified” by the ID submitted, corresponding output signals are generated using MuLPI hardware (VIS LED/IR LED/RS232). The second serial port is always sending out encoded LEGO IR protocol signals (RC Car, RC Train, RCX, PF) and thus the LEGO Serial Tower can be used to significantly amplify the rather weak signals strength of the built-in IR diode in MuLPI. This works for all IR protocols as the LEGO serial tower is “dumb” and just turns its IR LEDs on and off, according to whatever data are coming in on its RX line (modulated at 38kHz when “on”). Also, any IR signals modulated at 38kHz are detected by the tower and put onto the TX line. See below for further details on the tower.

(ZX Interface 1 Mode) Serial data (ID/data byte) from the computer terminal at 9600 baud/8 data/no parity/1 stop bit is inspected and then handled as in Manual Mode. However, both ID and data byte are wrapped into the Mindstorms IR Message Protocol (3-byte preamble, message command, 1 byte message content, checksum. The three latter bytes are each followed by their two’s complement, which results in a 9 byte data packet. Any replies to the control program are also full 9 byte Mindstorms IR Messages. HW handshake is turned on; the computer should send out data to MuLPI only when the RTS indicates MuLPI is ready to accept data; the MuLPI replies only when the CTS line indicates computer is ready to accept data. The former is always the case, as the UART/Serial port software of an ESP32 is mostly bored when data arrive; it could digest many more bytes in one go, as the (max.) 2x9 byte packets arriving from the computer. The latter though is critical, as the ZX Spectrum is thinking about every byte arriving for quite some time, before it accpets another.

(LEGO Message Mode) Similar to ZXIF1 Mode, but RTS/CTS HW handshake turned off; rather default XON/XOFF synchronizes the data transfer between computer and MuLPI. I am using this mode for my VisualBasic6 train layout control program. Again, data transport is via 9 byte Mindstorms IR Messages. All modern computers should work using this mode; USB to serial adapters work fine as well.

(Direct Serial Mode) For programs such as NotQuiteC (NQC/BRIXCC), ScripEd (Mindstorms SDK2.5) or SCOUT tool (SCOUT SDK), and the like. What comes in on one serial port is routed to the other and RTS and CTS on the computer side are “connected”, i.e., what comes in on the CTS input GPIO is echoed to the RTS output GPIO. Some of these programs, particularly the SDK versions and the vpbcom activeX control for VisualBasic6, verify the presence of a LEGO tower by pulling CTS low for about 30 ms, then putting it back to high and test all of the following three things: 1) Was RTS low, 2) did it get back to high, and 3) within a defined time, which appears to be around 50 ms. Both serial ports of MuLPI are set to 2400 baud, 8 bit, odd parity, 1 stop bit as this is what TLG chose as protocol.

 

Output generated by MuLPI

 

The output generated by MuLPI depends on the data coming in. In principle, these input data simply consist of two bytes:

One ID byte followed by one data byte. As simple as that. ID determines the protocol to be used = one of the above; and data byte = action, e.g. power. Current (power) data range is -7 … 0 … +7 as this is the power resolution for RCX outputs, VLL, PF, RC Car, and RC Train. For PoweredUp, the scale is +/-0 … 100% but not used here, as +/- 0 … 7 always works for my trains. The PoweredUp scale is thus simply converted to the +/- 7 scale. Since LEGO IR messages can't be negative (data type is uint8_t) and should not be zero, -7 is mapped to 1 and thus +7 = 15.

With regard to IDs: In my layout ID 170 - 174 = VLL; 175 - 179 = RC Car; 180 - 187 = LWP3.0 (PoweredUp – I believe Legoino handles max. PoweredUp devices), 192, 193 = RCX (my two RCX propelled trains), 194 = RC Train (my ICE), 195 – 201 = all PF trains, which are 4.5V/9V/12V trains.

 

 

Communication data transport

 

As mentioned above, both VLL terminal and RS232 port on the LEGO side are always active. The same holds true for PoweredUp devices, however only when they were discovered and are connected.

The 1) built-in IR, 2) built-in 433MHz RF board, and 3) the BLE device discovery function can be turned on and off using three push-buttons on MuLPI; the buttons feature LEDs to indicate the transport status. This is totally overdone, but I like blinking lights and things visually changing their status when tinkered with.

Built-in bidirectional IR: Mainly for testing and/or firmware upload to RCX bricks. The built in IR LED (front, covered by trans blue 1x4 tile) is powered by two parallel 74HC00 outputs at 3.3V and does thus not provide any considerable range. When the RCX (or any other IR devices) are located directly in front of MuLPI, all works fine.

Built-in bidirectional RF: There is a simple 433MHz RF transmitter and receiver present in MuLPI, which can be turned on and off. When on, all signals on the serial LEGO port are also sent via RF/listened to via RF. This latter is only relevant for my two RCX trains, as they reply to an incoming message with a receipt message. All my trains have either a set of 433 MHz transmitter/receiver on board (RCX) or 433MHz receivers only (PF, RC Train). This way I can reach all of them without line of sight on my layout. This layout is built into my under-the-roof office; there is way more no-line of sight than line-of-sight.

BLE discovery: As I don’t really know how this is done correctly using Legoino, the BLE device discovery can be turned on and off. I believe, the idea in Legoino is to discover BLE devices one after the other and in a certain order. When you initiate discovery for all known devices simultaneously, the ESP crashes (naturally) producing a very nice error message: One core of the two apparently “panicked” – I like that error message). I am initiating the discovery for each device every 2 seconds consecutively – that works and you can switch on the devices as you see fit. May be principally totally wrong what I am doing though … When done with the discovery, I turn that off and all discovered and connected PoweredUp trains are happily doing what told.

 

Miscellaneous

 

There is a JoyIt (Adafruit compatible) 1” monochrome OLED display showing the status of MuLPI. I really like lights and stuff, as this is also the way they do it on the USS Enterprise (NCC 1701) or on vintage computer main frames. I believe no one really knew what all the blinking lights meant other than: Power is connected and some program is running. However, on the ESP Dev board there are only so many GPIOs – and currently I have only 2 left over as outputs. Many lights = indicators would have meant to use a multiplexed LED matrix or the like.

And behold: Yes, I did cut into this slope brick (4515), and I used glue to affix the OLED display. It is now a “modified slope brick”. As TLG doesn’t make these, I took the freedom of motivating them to do so .

The display also updates the hub (PUp) connection status, the circles are filled when a (known) hub is connected and open when not.

 

 

Protocol bit/byte streams encoding

 

As of now I have compiled the encoding information simply into one PDF. Forgive me my stupid comments or inefficient programming – as said, I learned programming using (punched) tape cards (FORTRAN and BASIC) and then on my ZX Spectrum (BASIC). Moved on to MS QuickBasic (BASIC), MS VisualBasic6 (BASIC; my current programming environment) and also a bit into NQC and C++. Guess my “programming structure” when using the latter. Also, in the current C++ code for the MuPLI, THERE ARE EVEN GOTO instructions, which is the WORST THING EVER a C++ program should feature. As a BASIC programmer, I simply cannot care less … Rest assured though, that the ESP32 still runs fine. Also, the Arduino IDE did not crash without saving any data, when I typed “Goto”. Nor did the BIOS of my laptop melt down; it is still doing fine (I am c/p'ing text into this post right now from this vey laptop ). According to C/C++ gurus, all these things may happen at once and in parallel, when using Goto.

For now these are screenshots of a PowerPoint/PDF. This link https://uni-wuppertal.sciebo.de/s/BbYzAnDGLwmWnv7 gets you to my university's cloud server for the original documents (hopefully with working embedded reference links). Here are just screen dumps:

 

Here’s the “C++” code (Arduino IDE) running on the ESP32 – it is ugly but works. C/C++ professionals will certainly enjoy this section:

Link to ESP Program MuLPI__ESP_V19: https://uni-wuppertal.sciebo.de/s/BbYzAnDGLwmWnv7

The LDraw file for the box around the electronics is stored in this folder as well.

 

And as said, I’ll use this thread for changes/updates. And for numerous corrections – no way that I got everything documented correctly. Maybe I can hack the Cybermaster stuff hopefully soon …

All the best, and have a wonderful Christmas season!

Thorsten

 

Edited December 6, 2021 by Toastie
Crap; typos all over the place.

[Tcm0]

Nice collection. One note:
you can enter the extended PF mode and control up to 16 devices individually. It works with all the normal receivers after V1 and I think that the EV3 IR sensor ignores the extended bit.

[Toastie]

57 minutes ago, Tcm0 said:

Nice collection. One note:
you can enter the extended PF mode and control up to 16 devices individually.

Thank you!

Yes, back in the days I wanted to do that as well - the only problem is, that I don't know which of the PF receivers can make use of that feature and which can't. I do have one V2 receiver in my HE and could give it a try. 

Is there any way to know (other than the V2 imprint), which receiver type is in my hands?

Thanks and all the best,
Thorsten

[Lok24]

13 hours ago, Toastie said:

Is there any way to know (other than the V2 imprint), which receiver type is in my hands? 

Add two XL Motors with load to one port, that shoul stop on V1

[Tcm0]

18 hours ago, Toastie said:

Thank you!

Yes, back in the days I wanted to do that as well - the only problem is, that I don't know which of the PF receivers can make use of that feature and which can't. I do have one V2 receiver in my HE and could give it a try. 

Is there any way to know (other than the V2 imprint), which receiver type is in my hands?

Thanks and all the best,
Thorsten

The V1.1 blinks the green led on startup. The 1.0 just turns on.

[Toastie]

Thanks to both of you @Tcm0 and @Lok24 for your swift replies. Will try!

Best
Thorsten

 

P.S.: Oh yes, and it is always very beneficial to check with @Philo's page first ...

Edited December 14, 2021 by Toastie

[maehw]

Hi all!

I came here by researching programmable brick internals - interestingly exactly one year later after the original post.

My current journey started several weeks ago when I got the LEGO 51515 set at an airport. I remembered the times of LEGO Mindstorms RCX (first generation) - and that I never had one. I got in touch with the original LEGO apps and then stumbled across Legoino which gave me control over the Boost hub that's included in the set. (I saw that Cornelius is/was also here.) I then started to buy other programmable bricks from eBay and now I have an NXT, several RCX, a Cybermaster, two Code Pilots and an old Technic Control Center. I then started to remember that my actual journey started back in 1997, where I got a Code Pilot. But I never had an RCX when I was young.

Thanks for collecting and sharing the infos. Interesting to see that there are multiple infrared protocols. I've also done some research on the RCX infrared protcol and made my Flipper Zero first replay some signals (that I had previously recorded from an IR tower using BricxCC under Windows). I then wrote a little tool to synthesize the IR signals to be sent by the Flipper Zero which works quite well. I'd also like to write my custom UI plugin for Flipper Zero, first steps of my approach - but without help, I won't continue this effort.

I also came up with the idea about a universal programmer - so basically what you've already done with MuLPI. However, I'd do it with a custom PCB. I've wondered if you know anyone who has rebuilt this.

I actually came here when I searched for details about the Cybermaster. I got one (unfortunately without any antennas) - it seems to work with radio frequency ~27 MHz. I did not find many details about it - might be AM and seems to be an obsolete remote control band. You can still buy crystals/ crystal pairs, but they are quite expensive. And there don't really seem to be modules readily available that work with that frequency range. Maybe a minimalistic SDR approach might be good here... or a VCO.

A small correction to the accumulated information: at least in the RCX protocol not "two's complement" is used but "one's complement" (i.e. all bits are inverted). I'll probably try to program the Code Pilot using the VLL protocol next - do you know if the LED color is relevant?

And afterwards test the newer generations step by step and maybe grow my collection of other programmable bricks, too.

[Toastie]

Hi @maehw - and welcome to EB!

Wow, your Flipper Zero is an insanely nice piece of engineering!!! As well as your software, you published on GitHub. Congratulations!

Ahh - finally ... you know, everything I learned with regard to programming originates from Fortran77 and a couple of BASIC dialects :D, mostly Sinclair BASIC ... and I just copied the "two's complement" text bit from some websites. So I looked up what a two's complement actually is, tried like 100 times for the RCX IR code generation and failed miserably 100 times. Then I looked into the RCX generated code; it sure was not the two's complement, but just the all-bits inverted byte (I now learned is the one's complement, thank you!). As you see in the protocol above, I am using "FF - byte" for the byte's complement - which is what you are saying. One year ago, I simply thought: Some call it this, others that :D. Glad that this is crystal clear now.

With regard to the VLL LED: The color does not matter much. The only thing is, that the MicroScout's sensor needs to be able to discriminate between "light" and "no light" present. It also sort of "calibrates" the sensor depending on ambient light conditions. Not much to expect here: The darker the sensor is upon start-up and then during operation, the better it gets. I am using a blue LED for VLL light; white will of course work as well, so does green. I have not tried with other color LEDs, but they'll work as well, when you get close to the sensor. I like to use dead cheap optical fibers for light transport with a Technic pin 1/2 (#4274) or even better 3/4 (#32002) as terminal. They attach nicely to the MicroScouts light sensor. I don't have a CodePilot box, but the protocol is identical to that of the MicroScout - well it is LEGO's VLL protocol. 

With regard to Cybermaster: That is next on my agenda - maybe spring next year. 27MHz is true, I believe. Your Cybermaster units have no antennas, but can't you use a simple whip type? Just a wire cut to appropriate length? Or do you have the receiver unit only, without the RF tower?

Best regards,
Thorsten   

[maehw]

Hi Thorsten,

thanks for your reply.

The credits for Flipper Zero don't go to me - but I agree, it's a nice gadget to play & hack around with. I've not done very much with it but recording and replaying (or synthesizing and transmitting) RCX commands via the IR interface was a great fit. However, a custom UI instead of the generic remote UI would be really nice, so that you could use Flipper Zero as an RCX remote control.

Nice that I could help with "one's complement". The last few days, I was able to bring up my Cybermaster. The hardware still works - or at least started to work after disassembly and reassembly. I've documented my first steps in some toots on Mastodon/ in the Fediverse: https://chaos.social/@maehw/109514018789309270 + https://chaos.social/@maehw/109519738303048254

As mentioned there, a serial connection with the RF tower using 2400 baud, 8 data bits, odd parity, 1 stop bit worked. I am not sure about the command set. But the commands have a 4 byte header (FE 00 00 FF), one command byte (with it's one's complement) plus at least one data byte (with it's one's complement; maybe the number of data bytes depends on the command) and finally a checksum byte (and it's one's complement) - which is quite similar to the RCX IR protocol.

Unfortunately, Flipper Zero's RF TRX doesn't go as low as the 27 MHz - so an SDR might come handy here (I don't really have one; at most, I have an "SDR" RX dongle somewhere, not knowing about its frequency range though). The transmitter frequency seems to be at 26.995 MHz (OOK). So I am wondering if 27.000 MHz (OOK) would still work. This band seems pretty much outdated.

BTW, I haven't had time to play with VLL protocol in the meantime. Also another sidenote: I've used both Cybermaster's RF tower and mobile unit without antennas, which worked quite OK. Again, BricxCC was really helpful during bring-up.

I wrote John an email, if I could get the source code for BricxCC, as https://bricxcc.sourceforge.net mentions that it is licensed under Mozilla Public Licence. Unfortunately, I couldn't find the source code online so I made that email request. Are you aware of any source code?

 

 

 

[Toastie]

On 12/16/2022 at 10:07 PM, maehw said:

Unfortunately, I couldn't find the source code online so I made that email request. Are you aware of any source code?

No, unfortunately I cannot locate that code either. Hmmm. John as in John Hanson?

Best,
Thorsten

[elfprince13]

On 12/16/2022 at 4:07 PM, maehw said:

I wrote John an email, if I could get the source code for BricxCC, as https://bricxcc.sourceforge.net mentions that it is licensed under Mozilla Public Licence. Unfortunately, I couldn't find the source code online so I made that email request. Are you aware of any source code?

 

 

 

It looks like there is source code here - https://sourceforge.net/p/bricxcc/code/HEAD/tree/ - I think Pascal?

On 12/6/2022 at 1:14 PM, maehw said:

Thanks for collecting and sharing the infos. Interesting to see that there are multiple infrared protocols. I've also done some research on the RCX infrared protcol and made my Flipper Zero first replay some signals (that I had previously recorded from an IR tower using BricxCC under Windows). I then wrote a little tool to synthesize the IR signals to be sent by the Flipper Zero which works quite well. I'd also like to write my custom UI plugin for Flipper Zero, first steps of my approach - but without help, I won't continue this effort.

I've been cogitating on using my Flipper Zero to interface with my RCX for a while. Have you been working on this at all?