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.

Be careful, this is a 28AWG, and anything but a "power cable". This is not the kind of cable I'd use to drive a LEGO motor. The original LEGO PF cable is more like 20-22AWG range for a reason.

There is actually a technical reason for this! The light brick has batteries that provide a voltage of 3V. Red/green/yellow/orange LEDs can live with that (their "forward current" is usually in the 1.8-2.6V range). But with 3V you won't get anything blue or white, they need at least 3.3V (if they are extra low voltage), but the more common (and affordable) values are in the 3.4 to 3.6V range. So basically, without completely redesign the brick (and make it larger) to hold more batteries, a blue or white light brick will just not happen.

As someone who does not have a FB account, how could I?

Yes. there is. Speed 0 is "float", speed 1 to 100 and speed -1 to -100 are, well, speeds. And speed 127 is a hard break.

Wow. Very interesting. Sadly, it's running on Windows. Nonetheless, there are some things I'd like to know about this project: a) Does it support the PUP remotes, too? Maybe both for controlling trains and controlling switches? b) Would it be possible to add other devices, too? I'm working on an Arduino Nano based device that offers two motor connectors and a bunch of LEDs and input pins. It will be connected to the "host" via USB UART. c) Would a Linux port be possible?

At the bottom of the page you can find an interesting tidbit: "Warning USA ATTENTION: not for children under 15 years". So, what markets are they aiming at? The design is clearly aimed at kids, not teenagers. Or maybe it is actually aimed at and build for kids, but to dangerous for American kids for some reason? Nonetheless, Märklin and others are basically on life support. Ten years ago, we were drafted to do "LEGO Fanwelt" in Cologne as an add-on to a thriving, long-established model railroad exhibition/fair. Last year, that part was basically dead - just a handful of old men on a mostly empty show floor. In 2016, I talked to a guy from a model train club showing their creations, and he told me that he was the "baby" of the club, despite being five years older than me. And I'm 50...

I simply use the UART over USB. Plain text commands. One key problem I found early on is which /dev/ttyUSBx is which Nano (Linux renumbers them more or less arbitrary after a boot - but so does windows), but that's easily solved: I use three analog in ports on the Arduino, and tie them either to GND, VCC, or to 1/3 VCC or 2/3 VCC. Which gives me two bits per pin. So each Nano has it's individual ID of six bits set by hardware. The Nano plus the LEDs can easily be fed from USB power, and for that I can use the four ports of the RPi 3B+. The BT and Wifi is already on board and don't eat up USB slots. If I ever need more - up to 64 - Nano boards, I can use USB hubs. I use the Nano because it is dirt cheap and small. I don't need a big or fast brain for this. The software is a stupid "read command from UART and execute" thing, so the Nano is more than sufficient. I can also use a 5m USB cable without problem to control the Nano, as it's USB2 and not that sensitive. In parallel to the USB, I've got a 9V (actually 10V, but it does not hurt) power line that I feed into the MOSFET bridge for the motor. The Nano is somewhere in the 4-5 € range, the Bridge is about 3-4 €, so the complete controller for one of my modules is well below 10€. The whole show is run from a power supply with 10V/20A for the motors and 5V USB/3A for the RPi. Sometimes, I use a Nano as a standalone system e.g. for running LEDs. I power them through USB, as it is readily available, and if I don't have a 220V socket available for the wall wart, I can easily use a power bank instead - it contains enough power to run our Classic Space launch pads for a week, even if I cannot recharge it.

Which reads as Version 1.0.01 and 1.0.03. The latter seems to be the version after connecting to the PuP app, at least the Android version I've got does this. I've got a bunch of "fresh" Smart Hubs which I will check, too. That is my target platform, too. The RPi will run the main program, will control the large TV display with the track schematics, a small, local display showing all the technical status information (like battery levels), and will also control a bunch of Arduino Nano "slaves" that each control up to two motors, a bunch of sensors, and some LEDs. Now, nothing for the squeamish: I'm going to buy a bunch of 8870 Power Functions LEDs, just to butcher them. The two LEDs with their cable get small DuPont connectors so I can drive them (with an 820 ohm resistor) from an Arduino's pin, the PF cable and connector get a larger DuPont connector and will be used to drive PF motors over a MOSFET bridge. I can run up to two motors and eight LEDs from an Arduino Nano+MOSFET bridge combo for way less than 10€, and can hook up to 64 of them to the controlling RPi.

Yes, there is - if you have Linux+BT. I have no idea how this works under windows. If you don't know your hubs MAC address already find it with "hcitool lescan" (might need a "sudo"). The device you are looking for is called "HUB NO.4" or "Smart Hub". I use my Smart Hubs address in the following example: 90:84:2B:05:B1:C6 Enter "gatttool -b 90:84:2B:05:B1:C6 -I" to open the gatttool (yes, three t's!), it will give you a prompt like "[90:84:2B:05:B1:C6][LE]>", at which you enter "connect". The gatttool should reply "Attempting to connect" and then "Connection successful", and the LED on the hub should change from blinking to on. Now enter "char-write-req 000f 0100" to request messages, and then "char-write-req 000e 0500010305" to read the firmware version. The Smart Hub will reply with something like "Notification handle = 0x000e value: 09 00 01 03 06 00 00 03 10". The telegram 09 00 01 03 06 00 00 03 10 can be read as follows: 1. Byte 09: Message Length 2. Byte 00: Hub ID, always 0 3. Byte 01: Command ID for "Hub Property" 4. Byte 03: Kind of property requested, here: 03=Firmware Version 5. Byte 06: Sub-ID for "this is an information update" 6. and 7. Byte 0000: 4-digit BCD Build Number: V-.-.--/0000 8. Byte 03: 2-digit BCD Bug Fixing Number: V-.-.03/---- 9. Byte 10: Major (Bits 6..4) and Minor (Bits 3..0) Version Number: V1.0.--/---- So my Smart Hub has a version number of "V1.0.03/0000" - Build Numbers seem to be missing. Which I can understand, merging build numbers right into a binary build took some thinking back when I needed to do this... You can then "disconnect" from the hub, and "quit" the gatttool. Hope this helps. Maybe someone here can provide a Windows-way to do this.

Both the Color Sensor and the Boost Motor need a UART connection to work. The Color Sensor communicates its settings and readings over this channel, the Boost Motor uses it for speed or angle data. My educated guess (from programming such embedded devices for a living): They either only have one UART interface on the chip and thus just don't have the resources to communicate to two smart devices, or allocation/mapping or driver of the second device has a bug. All in all, if one Boost Motor and one Color Sensor don't work, and two Boost Motors don't work too, then I would expect two Color Sensors to fail in a similar manner. Regardless of what the problem actually is, I would report this to LEGO Customer Service.