David Lechner

BTStack is the Bluetooth library so you can't use Pybricks without it. I don't think there would be an issue with making videos about it though. It would only be an issue if you were redistributing the firmware for commercial purposes.

Logging Bluetooth packets with Wireshark is really the best way to see what is going on. Pybricks Code is open source. You can build from source and host on your own https server if you want to keep using an older version.

Please gather as much information as you can on how to reproduce the problem and collect logs as described in https://github.com/pybricks/support/discussions/270. If none of the tips there (like turning off all other bluetooth devices) don't help work around the problem then find an existing issue at https://github.com/pybricks/support/issues that matches your problem or start a new issue if there isn't a matching one already and share as much information as you can so we can try to understand the problem better.

You can save the calibration values to a file. In the calibration program, add something like this: import ujson calibration = {} calibration['value1'] = ... calibration['value2'] = ... calibration['value3'] = ... with open('calibration', 'w') as f: ujson.dump(calibration, f) In the main program, add something like this: import ujson with open('calibration', 'r') as f: calibration = ujson.load(f) value1 = calibration['value1'] value2 = calibration['value2'] value3 = calibration['value3']

At this point in time, I think buying a Powered Up Light (88005) and cutting off the lights is about the same cost as 3rd-party cables and will fit much better.

We currently don't have plans to implement this.

You can set the name when you flash the firmware in Pybricks Code, but not at runtime.

The position feedback of NXT/EV3 motors is not compatible with SPIKE, so it limits the usefulness of doing this.

text_width() is a method on the font object, not the screen/image object. so width = small_font.text_width(text)

It is possible to set it with the pybricksdev command line tool, but not with Pybricks Code currently.

Looks like I didn't do my math right. There are 8 bytes of overhead, so of course 31 - 8 = 23 bytes.

For the reverse engineering fans, something to keep an eye on: https://github.com/NStrijbosch/RevEng-hub2hub-word-blocks It looks like the first byte increases by one with each broadcast.

I used a Bluetooth sniffer to see what is going on. It uses Bluetooth Low Energy advertising. So your conjecture about classroom could have some merit. There are only 3 channels used for advertising data, so all hubs would be competing for these 3 channels (compared to 37 data channels for connected devices). But if the broadcasts are spaced out enough, this probably won't be noticeable. Interestingly though, all hubs would be listening to all other hubs, so if everyone in the class made the same program with the same broadcast/receive name (e.g. "Motor1"), then everyone would be trying control everyone else's hubs. But I don't think the Robot Inventor is aimed at classroom use anyway. Using advertising data also means that data is limited to 31 byte, including overhead (so probably something like 28 bytes). Try sending a long string and see what happens. It also looks like LEGO didn't quite get the format of the advertising data correct (this is why it says "Malformed Packet"). The actual advertising data is the part highlighted in blue in the screenshot. The first byte is supposed to be the size of the advertising data segment that follows. This is missing and the first byte (which should be the 2nd byte) is the data type. 0xFF means manufacturer-specific advertising data. It is followed by 0x0397 which is the LEGO company identifier. The remaining data is defined by LEGO, so we will have to do some reverse engineering to decode it. The last 3 bytes as an ASCII string are "296", so I'm guessing that is the motor position being sent as text. There are 5 bytes before this. I'm guessing this somehow encodes the "Motor1" name as some sort of hash. I would expect a hash to be an even number of bytes, so there seems to be at least 1 more byte for something else.

Pybricks is a 3rd-party firmware for LEGO MINDSTORMS and Powered Up hubs. It was actually created before the official LEGO MicroPython. Pybricks is documented at https://docs.pybricks.com. But it looks like you are using the official LEGO software. For documentation on the official LEGO firmware and MicroPython, see https://bricks.stackexchange.com/a/15844/3498

answered at https://bricks.stackexchange.com/q/16418/3498