treczoks

I have exactly this chip as a module on the table, but I have not tried it (yet). I'm planning a PCB for an Arduino Nano and this bridge to run two (LEGO) motors and up to 4x2 LEDs.

No idea on the capacitor, but the PTC reset fuse is a 15V 500mA type. Source on Alibaba.com

This is actually not necessary. The Smart Hub has two very interesting features here: a) a "ramp" command to gradually change to a target speed, and b) the ability to queue commands. So you can e.g. send a command to "ramp up to 50%", followed by a "run at 50%", and it will ramp up and stay there automatically. Details will follow - as soon as I have time to work on my documentation again.... ;-(

Have you tried to read the firmware version? Maybe one of them is just outdated.

Just look at the chips datasheet, it can easily drop up to 4.7V under load, so if your input current is 12V, the output can be as low as 7.3V, and the remaining 4.7V times the power (let's say 1A) just feeds the heat sink. I stumbled over this primarily for the heat sink issue - I wanted to build a small controller board (Arduino Nano plus two H-bridges plus LED outputs), and had the L298 in mind, too (as I've got a few of those modules here). But the odd pinout and the need for the rather bulky heat sink made me think. Because the LEGO controllers don't have such a large heat sink and bulky H-bridges I asked around, and ended up with the Toshiba one. I don't know their voltage drop, but the SMD package does not need any extra cooling, so it can't be that much.

Not good if you're using batteries. The L298N is old, and wastes lots of energy. That's why you need cooling for it. I chose the Toshiba TB6612FNG for my project. It has the additional benefit of only needing one PWM per motor, i.e. you've got two "normal" pins telling the motor what to do, and a third PWM input that tells the chip how fast to go.

I'm testing a few things in the sensor department at the moment, and I'm on the same side here, they probably use the UART function over ID1/ID2. I guess they are using the inline resistors for two reasons: first, to take care of EMC issues, and second, to protect the chips' ports when probing the ID values of the "no-brainer" parts like train motor and LEDs. In order to replicate this interface, could you do me a favor and measure those inline resistors on the RX and TX signals? Has someone already taken apart the color/distance sensor? I'd like to know how they handle pins ID1 and ID2. The Boost motor has two inline resistors, and I expect the sensor to have the same. I'm curious about the resistors values. On another question: Has someone monitored the serial communication between the Smart Hub and the Sensor? I expect the sensor to come up with a "greeting/Identify" message at bootup/connect, and I remember that the communication between sensor and Smart Hub was basically identical to the BT telegrams. Has anyone gathered any intelligence/experience here?

Yes, like "Held der Steine" learned it a few weeks ago. He is one of the key influencers in Germany, doing a lot of interesting set reviews on YT, and with a 6-digit followership. Until LEGO "told" him. With a hard-handed letter from the legal department. Turned into a serious PR disaster here, he now produces reviews of clone sets on his channel now - with an audience of hundreds of thousands AFOLs. The LEGO legal department is not known for subtlety and quite often, not a hoard of common sense.

Even for a free project? Yes, they do. The legal department is, well, a legal department, and they have shown just a few weeks ago with "Held der Steine" that they follow the legal tradition of "one hammer fits all". Better be careful here. We like you, and we want to keep you around.

Not everywhere. Here, in Germany, they are still alive. But they also have competitive prices, something that TrU in the US was supposed to be lacking.

Has anybody tried to run this on Linux under Wine? If yes: Experiences? If no: I'll give it a try.

Patience, patience. I just ordered the motor modules for the prototype, and they will come sometime in February. And I'll use the AFOL Shopping date to buy a bunch of PF LEDs just to butcher them for parts (Cables and LEDs). I started programming yesterday, the base is there and working. Next step will be the command parser and job executer. They will be done way before I even have the prototype hardware on the table. Then some odd commands like "L0R>[10:100]@[50:500]" will be possible: "Do with LED 0: Run a ramp from the current brightness to a random value between 10 and 100 (of 255) over a random time between 50 and 500ms, and repeat." Or "M1R>127@10000;R#@20000;S", which reads "Do with motor 1: Run a ramp from the current speed and direction to half speed forward in 10000ms, keep that speed for 20000ms, and then STOP." One can do a simple blinking light "L1R255@500;R0@500", which basically blinks the LED 1 on and off for half a second each, infinitely, without further need of action on behalf of the master. One can ramp up a motor in a certain time, and then let it run forever (i.e. until the next command is sent: "M0R>-128@5000;R#" You can preset each command with a Job ID between 1 and 32767, and it will reply with status changes: "3:L2R>[10:100]@[500:5000]" might send you a "3:L2R>73@3281" immediately, then a "3:L2R>19@1729" three seconds later, etc. And when one does a "L2S" to switch it off, it will acknowledge the cancel with a "3:L2C". No job ID means that it will run, but it will not talk. Well, at last this are plans. I hope I can fit the parser and executer in this chip - it is way smaller than the stuff I usually work with, but on the other hand I had jobs done on even smaller chips. My current guesstimate is that it will just about fit.

Will do! Nope. I'm not going there anymore.

It is a simple custom-build I'm working on, nothing fancy (Base-board with a few components, and the Arduino and the H-Bridge as modules, as they are cheaper than buying the chips alone...). I will publish the design, and if you don't know which side of the soldering iron gets hot - well, we'll solve that, too. Maybe I'll do a run of 50 or so boards (first level of getting cheaper), and then we'll see how it goes. Yes, that would explain why one of my ideas didn't work. I thought about putting a line of tiles on the track to identify a number, with another color as a start symbol. Couldn't get it to work. A cooldown period would explain this. Thanks for the hint!

Have my vote for a Linux version. And keep the underlying framework flexible so adding other hardware is easy. I'm working on a simple hardware platform to drive two motors and a bunch of LEDs for cheap via USB+9V, which I will use to run all the track switches and signals on our layout.