AlecDGeneric

This most likely means you're holding the button down until the bootloader starts (purple flashes), which then connects to the phone (rgb flashes), then turning off because firmware is current (or the app does updates in another way, don't know as I have no devices able to run it). The solution? Simple: Just push the button for a short time like a mouseclick, the light should then flash white and connect to the phone.

Not just that, I own 4563, 4560 and 4551 (the latter retrofitted with Pup), and half of their instructions are for an alternate build. And looking online that was also the case for 4564 and 4558. Don't know why they dropped that for 4565 and 4559 since 4560 came out after them.

If you mean the one in front of the regulator then no, that's the standard one with the right side blending in with the regulator.

I for one am working on a turnkey software using color sensors mounted in the locomotive. Would mean you'd need Hub + sensor + motor per loco (78€ S@H), plus motor + hub for switches if you go purist. Look at other solutions, though, I'm a horrible procrastinator and been working on this since September 2019.

That's actually too tight, the plugs come out to the width of a 1 stud brick. So to acommodate the cables you need to put at least one of those L shapes in front (what Studio calls a Panel), though not directly in front as the plugs are too wide to fit inside of it.

From what I could tell from a quick look at my browser's devtools and without making assumptions about the forum-SW the only hard requirements are the height of 200px and the repeatability of the second image. The themes-backend may be more flexible than that but that's not something I can tell.

Why? With the receiver's dome between the sleepers I just reconfigure the sensor looking for tiles; that is switching it to mode ir_tx(7) when detecting yellow and back to mode color(0) after a second in my test, which actually works well (now did some testing) when the color detection is consistent, though I may have to test more configurations (speed, colors, duration of ir_tx).

For my automation software (release TBD) I'm looking into a driveby solution; my trains are all PuP with a color sensor looking down for colored plates so the idea is that when the train sees a specific tile it temporarily switches to IR-mode to control a receiver operating the upcoming switch. At least that's the theory, I have a test setup but yet to actually do any tests.

When I saw this I was like "wait a sec, isn't that...?" After some quick cross-referencing and testing I found that yes, the payload is just the LPF-RC protocol. Mode 7 reportedly takes a uint16, put into the message in LittleEndian this means it is {09 00 81 [port] [s&c info] 51 07 [(nibble2)(nibble3)] [0(nibble1)]}, with the nibble parts following this: https://www.philohome.com/pf/LEGO_Power_Functions_RC_v120.pdf Just for completions sake.

Querying the bootloader reveals a range of ≈236kib, so probably a 256kib flash? Unless I misread the return message. And on page 20 of this thread a picture shows the FW-versions to be upwards of 60k big.

Here's a solution I came up with (and tested, more on that later): Utilising three colors I use one one per end so the trains know which direction to take (typing this I also came up with a solution using the same color on both ends, though untested), and the third on both bypasses. The color events on both trains and for both ends stop the train, set a state to the appropiate direction (+/-1), set a state so the train will ignore the endcolor (otherwise it'd stop again after driving back over the plate), clear the state for waiting, wait for an amount of time, and then sets the speed to speedlevel * direction. When a train sees the color for the bypass it looks if the other train is waiting (wait state mentioned above) and if so just starts the other train. Otherwise it stops and sets its own wait state. I mentioned testing earlier because, while logically sound my test setup didn't work reliably. Sooner or later (3 reverses at the latest IIRC) one of the trains just doesn't see the bypass color (as in it doesn't even show up in the log); it's always the same train, even when I replaced it with another one. There's also a substantual lag between the train going over the tiles and reacting to it, sometimes up to a full track length. I don't know if this stems from BAP or it using the color/distance combination mode of the sensor since I did tests sending trains at full speed over 2 length color tiles in color mode and my software (nowhere near release ready) picked it up both immediately and reliably. So, take all that as you will, was nonetheless a fun undertaking in problem solving for me.

Byte 4 is the command that caused the error, with byte 5 identifying the type of error; in your case the message essentially reads "Command 0x6D not recognised".

@Toastie You can ask the devices for their capabilities. This is shown in 6.3.1 of the doc (connection info) though admittedly not quite as clearly as one would like. Basically the process would be: send 05 00 21 [port] 01 (3.15. Port Information Request) it replies with 43 (3.19. Port Information), of which byte 7 (counting the first as 1) denotes the number of modes, note this for each mode (or until you're satisfied) ask for the name with 06 00 22 [port] [mode] 00 (3.16. Port Mode Information Request; mode are [0 - number of modes) ), the reply 44 has the mode's name as ascii starting at byte 7 (not \0 terminated, 3.20.Port Mode Information); asking for the symbol (06 00 22 [port] [mode] 04) may also help since it would be relevant to the data (like probably g for accelerattion or DEG for tilt) with this you should now also have the relevant mode to subscribe to for your 41 message I used this method recently to map out the modes of the color/distance sensor, so this should work. Hope that helps.