LEGO Education 2025 Science Hardware?

[tomalphin]

This thread is threefold:

1. Find out what is known (if anything) about the four new Bluetooth accessories which debuted in the 2025 LEGO Science kits. (all four are included in Set #45622 which is aimed at grades 6-8 and costs $500.) --- For example, do we know if they connect using the same LWP protocol used for earlier products?

2. Can PyBricks connect to them? - Can we connect to these accessories via bluetooth from existing hubs running PyBricks? (Bluetooth peer-to-peer)

3. Will It PyBricks? Are any of the accessories candidates to run the Pybricks firmware? The larger module with two motors could be useful, especially if it can connect directly to other modules via BT.

Thanks,
—Tom

P.S. The reason I am curious is that I am trying to finish my upcoming print edition of my LEGO Parts Guide. I already plan to mention PyBricks as a way to make the most of your current hardware. I am also trying to include preliminary info on this new hardware to ensure the initial release contains up-to-date info, especially since I think the guide will be very useful for educators.

[tomalphin]

Related Question - do we expect that Part 115901 (Remote Control, Science) will be functionally similar to Bluetooth Speed Remote (Part 28739) ?

It seems like they would be, since they both appear to allow us to control a different module over Bluetooth (P2P) without a PC. I aim to clarify this as well in order to determine if the older Speed Remote should move into my new category for bluetooth-only LWP accessories.

[laurensvalk]

For example, do we know if they connect using the same LWP protocol used for earlier products?

I expect the protocol to be completely different. The LWP3 protocol is mostly designed to be a dedicated connection between two things (like your phone and the hub). This new system seems to be a distributed network where everything talks everything, since all devices are wireless and there isn't a central hub.

Can PyBricks connect to them? - Can we connect to these accessories via bluetooth from existing hubs running PyBricks? (Bluetooth peer-to-peer)

It might be possible to control them from other hubs that run Pybricks, but we haven't tried yet.

Will It PyBricks?

It is unlikely that we could run Pybricks on them. All recent LEGO devices (like the Technic Race Hub) are locked down and can't be updated without a special password. I don't expect these to be any different, but I hope to be proven wrong.

This seems to be a trend in most consumer electronics, and aside from a few voices on right to repair, people just seem to be resigned to this. For all the fuss about sustainability on bricks and packaging, this doesn't seem to apply to electronic LEGO parts apparently. We're working on it.

[tomalphin]

Super helpful, thank you. I will keep my initial writeup on the new system minimal until we learn more about compatibility, interoperability and protocols.

Good luck with continued efforts to put PyBricks on the EV3. I think this will be one of the most important developments in continuing to support the AFOL community by maintaining modern app support for reasonably-priced retired hardware. I will consider mentioning PyBricks specifically in future updates as a way to use EV3 with modern PC hardware.

[dlech]

Well, I couldn't resist. 😁 The new LEGO Science kit arrived today. Everything that Laurens said is correct. And here are some more technical details...

The hubs communicate via BLE advertisement data. The protocol is not the same as the advertisement data protocol that was used on MINDSTORMS Robot Inventor. And it is not the same as the Powered Up remote as that uses LWP3 protocol using a connection rather than advertisement data.

It consists of 12 bytes of "service data" with service UUID of 0xFD02. Only the input devices broadcast (color sensor and remote control). So presumably the motors only observe.

This means that it won't work with Pybricks currently, but it shouldn't be too difficult to add a new broadcast and observe type to make it compatible. We just need to reverse-engineer what each byte is.

So far, I have:

N	Description	Notes
0	Device identifier. 0x02 = color sensor, 0x03 = remote control.	Motors don't broadcast, so their IDs are unknown.
1	Assigned color code. 0x01 = 🩷, 0x02 = 🟪, 0x08 = 🔶.	The set only came with 3 cards, I'm sure there are others.
2	Unknown.	So far I've only seen 0x00.
3 - 4	The card number printed on the color card. 16-bit little-endian integer. 🩷 = 0x041A (1050), 🟪 = 0x03F2 (1010), 🔶 = 0x01B5 (0437).
5	For color sensor 0x02 = purple, 0x03 = blue, 0x06 = green, 0x07 = yellow/orange, 0x09 = red, 0x0A = white, 0xFF = black/no object near. For remote control, upper 4 bits seem to be momentary forward (0x1), center (0x0) back (0xF) of the left control that immediately return to 0x0 even while still holding the position. The lower 4 bits are low resolution analog position of the right control 0x3 (all the way forward), 0x2, 0x1, 0x0 (center), 0xF, 0xE, 0xD (all the way back)	Remote control left-right orientation is with light/USB port facing away from you.
6	For color sensor, always 0x00. For remote control, this is similar to above except the upper 4 bits are momentary right position and the lower 4 bits are analog left position.
7	Always 0x00 for both sensors.	Possibly reserved for additional sensor data on future sensors.
8 - 11	Timer/counter. 32-bit little-endian integer.	The MSB (11) can be seen to be constantly increasing. Byte 10 looks a bit random. Byte 9 also seems to be constantly increasing, possibly due to aliasing. And Byte 8 seems to stay the same, fluctuation only 1 or two bits, also likely due to aliasing.

In addition to broadcasting, it is possible to connect via BLE. There is one vendor-specific characteristic, but it doesn't have the same UUID as the LEGO Wireless Protocol seen on other hubs. So without an app that makes use of this that we can spy on, it could be quite difficult to reverse engineer the protocol. But maybe we could get lucky and it is just the LWP3 protocol with a different UUID?

There is also a firmware update mode. You can get to this by plugging in USB while holding the button. It does the usual red/green/blue flashing that we've seen other other hubs. The BLE service/characteristics in firmware update mode look similar to, but not the same as the Nintendo character hubs and the Technic Move hub. They use an over the air update mechanism from TI (OAD). So it is very likely this requires signed firmware. Without an official app where we can spy on the firmware download, we can't do any reverse engineering on this yet.

In summary, running Pybricks firmware is highly unlikely but communicating with other hubs running Pybricks is highly likely.

And here is a script for any others interested in reverse engineering the BLE advertisements:

import asyncio

from bleak import BleakScanner
from bleak.uuids import normalize_uuid_16

LEGO_SHORT_UUID = normalize_uuid_16(0xFD02)


async def main():
    async with BleakScanner() as scanner:
        async for _device, data in scanner.advertisement_data():
            service_data = data.service_data.get(LEGO_SHORT_UUID)
            if service_data is None:
                continue
            print(service_data.hex(":"))


if __name__ == "__main__":
    asyncio.run(main())

[tomalphin]

Awesome. I will consider this update cautiously optimistic, and continue with my plans to add these parts to my LEGO Parts Guide. Even if folks need to use 3p PyBricks firmware to control them from existing LEGO hubs, or control directly from phone/tablet/pc, they will have general utility for MOC builders.

Were you able to determine if they continue to work while plugged-in to a USB-C charger? This is also useful info as it might be an easy way to get long-running modules like a GBC to run forever in a convention context.

[dlech]

Were you able to determine if they continue to work while plugged-in to a USB-C charger?

Yes, I did determine. No, the motors do not continue to work. They stop when USB is plugged in.