Mr Hobbles

Yeah, in fact I've seen many Arduino takes on it (ie. Jorge Periera did a similar approach a few years ago), but I wanted a single self contained "product" (for lack of a better term) that didn't involve fiddling with wires, soldering, etc. It should just be similar to the original adapter boards - plug and play out of the box. Sure - if Blockly spoke the protocol that BrickInterface does, it would work seamlessly. I integrated it into BrickLogo a similar way, here's a video: That's actually a really good idea, indicator LED's on the board. I like it! I'll add that to the next revision. Unfortunately it takes a while, as I need to design the PCB, then get it manufactured + assembled, so there's a few weeks lead time. And of course there's a minimum order quantity lol (and like I said, annoyingly, this batch had that bootloader defect) Absolutely, I just wanted a self-contained out-of-the-box ready-to-run "product" with no fiddling. I'm doing nothing new here other than building it all into a productionised designed + manufactured PCB with a nice firmware. (Though, I think combining IR + Interface A is perhaps new!)

So it's long bugged me that out of all the LEGO electronics they've ever released, the only one that truly cannot be used on modern computers is the Interface A. All the others (ie. Control Lab, RCX, etc) have hardware compatibility through USB<>serial adapters, just requiring bespoke software to use, but the Interface A has no such option. I've had to mess with Arduinos or hack a cable. So, I thought I'd design a modern "interface board". I designed a compact board that uses an extremely cheap CH552T micro controller that exposes a USB-C port, a 20-pin IDC connector for the Interface A (so original ribbon cables can be used, or even a replacement ribbon cable), and for the fun of it, two high-powered Infra Red LED's for Power Functions (since that also has no interface, despite a published protocol!) It exposes a serial interface over USB-C and has a simple protocol to drive the outputs and read inputs, as well as hardware input counting. It also has two holes spaced and sized for attaching to Technic beams and bricks with pins, so it can be affixed to a MOC. I plan to release the schematics and firmware when it's finished, though annoyingly this first batch of assembled PCB's I ordered have a hardware bug with I need to resolve first. I had to desolver one of the resistors as it was stuck in bootloader mode. >.< Here's a video of it running with a Python script on my mac that drives the motors on the Interface A and Power Functions IR receiver.

Well, code is source of truth of course, so I recommend reading the library first and foremost. But LEGO Dimensions uses tag pages 0x24-0x27. Block 0x26 stores a flag to detect if the tag is a vehicle or a character. If it's a character, then the id stored in a uint32 (first four bytes) of block 0x24 is encrypted with the TEA cipher using a key derived from the UID of the tag (so you'll need to read this first). Once you have the character id, you can look it up in the map: https://github.com/nathankellenicki/node-toypad/blob/master/data/minifigs.json If it's a vehicle, then the id is not encrypted and can be looked up in the map https://github.com/nathankellenicki/node-toypad/blob/master/data/vehicles.json There is additional data on the tag for vehicles (written by the game) which stores which in game vehicle upgrades the user has chosen. Character tags have those blocks write-locked out of the factory. Vehicle tags can be rewritten. Note that only those blocks are write-locked (or not). A lot of the other blocks are not locked, and not used by the game, meaning you can store arbitrary data in them without affecting their use in game. :D (I my have had some personal creative uses for this lol) Note: The TEA key being derived from the UID means it's pointless distributing dumps of the tags. They can't be cloned byte for byte onto another tag, as the UID will be different, and therefore decryption will fail ingame. It is however possible to write your own tags as they'll do the TEA encryption. There are Android and iOS apps for LEGO Dimensions that do this. As for Smart Play, I have some reverse engineering notes here, including some tag data https://github.com/nathankellenicki/node-smartplay/blob/main/research/notes/HARDWARE.md I haven't bothered to document all tags I have. Also as far as I know noone has managed to decrypt the data on the tags yet - it looks like AES, and the key appears baked into the ASIC on the Smart Brick. But, unlike LEGO Dimensions, the data isn't encrypted using a key derived from the UID, so you can successfully clone the Smart Tags/Minifigs onto blank tags, and they will work.

Exactly as you said, the Wii/PS3/PS4 Toy Pads are identical, with a pretty basic wire protocol running over USB HID. The Xbox 360/One version is different - the cable has an authentication chip in it that means it will only talk to Xbox consoles. It's pretty useless for any other purpose. The Toy Pad acts as a basic NFC reader (well, 3 NFC readers actually), allowing arbitrary reads of blocks from an NTAG213/214/215 tag, not just LEGO Dimensions tags. In fact, I've tested it with the pairing cards that came with LEGO Education Science/Computer Science & AI. It can read them just fine. Sadly, it cannot read Smart Play minifigures, as LEGO moved to NFC-V/ISO15693, which the Toy Pad cannot read. The most annoying part of the protocol is the TEA encryption used for decrypting the data on the LEGO Dimensions tags. This is required to read/write any game specific data to the tags, such as reading which character or vehicle ID was placed onto the Toy Pad. Other than that, nothing else is encrypted, just raw message payloads (ie. changing color, fading effects, reading UID's, etc). Though, if @Bliss wanted to add it, I'm sure Claude or Codex would make short work of it by pointing it at my Node.js library. :) https://github.com/nathankellenicki/node-toypad

Hello folks, Does anyone know if anyone has uploaded a scan of the teaching materials for the DACTA Intelligent House 9707? I believe the teaching materials were set 9708. I think it came with some software on a floppy as well. Thanks!

Yep definitely, MQTT is a complex beast, and running into a browser means you're limited to websockets or HTTP fetch. That's the reason I chose websockets for BrickLogo's pipe between nodes, as browsers can join too. I haven't bothered with wss (yet) - I figure most people are gonna run locally rather than over the internet, and wss setup comes with headaches for end users (certificates, needing to launch HTML files from a server instead of from disk, etc). End user friendliness definitely the end goal. Though, its nice to have some more complex functionality for those who need it! Great project, I look forward to playing with it more. :)

Yes, from a product perspective, the range is branded as Powered Up, but the devices are officially called LPF2 (and Powered UP as a product range name was introduced later!) You can see LEGO using the terminology in various places. I remember when Lego changed it, we were discussing it in the thread in the train forum on here back in 2017 and there was lots of confusion lol. https://assets.education.lego.com/v3/assets/blt293eea581807678a/blt23df304b05e587b2/5f8801ba721f8178f2e5e626/techspecs_technicforcesensor.pdf?locale=en-us https://education.lego.com/en-us/product-resources/wedo-2/troubleshooting/faqs/ But I digress! @Bliss Thanks for the kind words. I wanted to try to make docs as clear as possible, as not many people remember Logo I'm sure. :D I intentionally kept networking simple - replicated global variables. So you can set a variable based on sensor readings on one machine, and waituntil it becomes a certain value on another machine. I'm trying to keep it as OG Logo-like as possible. But it also means you can build other clients, ie. browser applications with websockets, and read/write those variables, to build UI's etc - it is quite a simple JSON based protocol. It would be awesome if Blockly could interact with the outside world too! MQTT publishes or something? Or allow websocket client connections to a server? You could even have Blockly and BrickLogo talking to each other.

* Powered UP, Control+, and SPIKE are LEGO product ranges * Powered UP, Control+, and SPIKE are also the names of apps of those respective product ranges * The hardware family for all this is most commonly known by the community as Powered UP, however LEGO calls it LEGO Power Functions 2.0 * The hubs all speak LEGO Wireless Protocol 3.0 (except the WeDo 2.0 hub, which speaks it's own dialect LEGO made it confusing for sure. You may be over thinking it though. It's just all one big homogeneous blob of devices. :D Yes, this is very true, Pybricks muddied the water by giving all those previous interfaces a "brain". But, as LEGO intended them, they are dumb interface devices, using a computer (a phone or tablet with an app) to interface with motors or sensors. But really, any microcontroller with a bit of storage is a brain with the right firmware! Well, if that's so and you don't mind, I've been working on BrickLogo - https://github.com/openbrickproject/BrickLogo/ It's an attempt to bring LEGO/Logo (LEGO TC Logo/LEGO DACTA Control Lab Logo) kicking and screaming onto modern computers, and supporting LEGO hardware both new and old, but with all the fun of Logo! And hopefully it's familiar to those who've played with Logo for those devices in the past. You can either type directly into the REPL and execute line by line (similarly to the original), or write .logo files in your IDE of choice (ie. VS Code) and execute them through the bricklogo CLI. It's compatible with Control Lab, RCX, WeDo 1.0, WeDo 2.0, Powered UP/Control+/SPIKE, Education Science, and the Raspberry Pi Build HAT. It's built in Rust and intended to be a single compiled binary/exe that you can run in the command line or terminal without any dependencies needing installed. Windows, macOS, or Linux (Raspberry Pi). https://github.com/openbrickproject/BrickLogo/releases There's some docs here - a small tutorial, a language reference guide, and a start at some info on some of the more advanced parts - networking, using multiple devices/hubs/interfaces, executing scripts, etc. https://github.com/openbrickproject/BrickLogo/tree/main/docs Maybe we can take inspiration from each other for Blockly and BrickLogo!

Ah, I was expecting it to be longer than that! Well RCX has two way communication (IR sensor readings, command replies, etc), but I assume latency via RF is a lot better than IR latency... or at least, I'd hope so...

This is such a cool thread to find, a really cool project you're working on @Bliss! Kind of an alternative to the https://code.legoeducation.com/ canvas but for supporting as many devices as possible. I've been working on my own project in a similar vein, but based around reviving Logo, not doing visual/block programming (but I won't talk about it in this thread, this is about your project!). It's great to see a revival of old hardware - I think there's been a great effort lately with regards to bringing back obsolete devices. Also, I just learned about Cybermaster. :) I mean, I knew about it previously, about 20 years ago, but it skipped my mind, and I completely forgot about it. Such a cool device, and a big improvement over the IR communication of the tower<>RCX. But, a different usecase I suppose. @Toastie Yes, exactly this. :) The WeDo 1.0, WeDo 2.0, Powered UP, Control+, SPIKE Essential, and even SPIKE Prime (after the firmware update that enabled LWP3) can also be considered Interface's, since they have no brain, and use computer control. Though, I consider the Raspberry Pi BuildHAT to be the true official Interface C. :D https://www.raspberrypi.com/news/raspberry-pi-build-hat-lego-education/

Just to point out, in this context share of the market is in terms of revenue, not in terms of number of participants. It could be that only 1% of the audience is kidults and 99% are children, but the kidults are spending a lot more. This is to say that there's an argument to be made that by just focusing on where the money is, we risk forgetting our core (and arguably most morally important) demographic. Thankfully I haven't noticed this too mucg yet with regards to Lego's products. For every $700 6,000 piece set there's an excellent looking $20 set for kids. See the latest Lego City wave. But it's a slippery slope.

The Pikachu looks a lot like the smart brick Mario. I dunno, I expected it to look different. Since I’ve heard they’re using the brick inside an X-Wing I thought it’d be shaped less like a character and more like a large normal brick. But, as has already been mentioned, that is clearly not the 18+ Pikachu. That’s a different set, a play set.

Lego has been experimenting with 3D printed elements for a few years now, specifically for elements that have motion built into them. I have a few of them. This particular 3D printed train has moving wheels, wheel linkages, and the smoke goes up and down when the train is pushed along and the wheels turn. This isn't multiple pieces that were put together, it was _printed_ together. I do agreed it's an odd choice to include in this set though - it seems like something a more hardcore Lego fan would appreciate than the mass market Lego Christmas set purchaser. I can't help but think how many of these they've printed, they must have dozens of printers going 24/7!

My theory is that at extremely low speeds the PWM duty cycle isn't long enough to actually move the motor. It then realises this (by virtue of the fact that it hasn't detected rotation) and applies a longer duty cycle, which makes it move, but at a higher speed than desired. It then detects it's moving too fast (again, through rotation having moved to far) and reduces the PWM again, causing it to not move once again. Repeat this cycle - leading to jerky motion. I'm thinking that both my motors have slightly different properties (ie. manufacturing variance?) that means that the required PWM duty cycle to start rotating differs between the two.

Thanks for that! Our code is similar, though my button mapping acts a little differently. Interesting that you have 45 as your minimum speed. Perhaps the video was playing tricks but I thought your locomotive was running slower than that. Incidentally, I tried with a second motor of mine. With the original motor, around 30 is the point where movement isn't "jerky". With the second motor, 20 is doable without jerkiness. I wonder if I run-in in the motors for 15-30 mins then slow speed performance will improve. Ps. I was wondering how the heck you fit front glass in with the wire going through the frame, but then I realised, you'd tucked it under. Great little design!