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

The EV3 Classroom program works fine for me. I would guess that there is something physically wrong with the robot that could be interfering, like wires pushing on something.

You can change the name of the hub.

The NXT motors don't have any microcontrollers in them. Your guess that the feedback signal is not working is probably right. I actually repaired an EV3 motor that had the same problem. https://lechnology.com/2018/07/how-to-repair-the-rotation-sensor-on-a-lego-mindstorms-ev3-motor/

It means the battery is low.

On Powered Up, pins 5 and 6 on motors with position feedback are UART like EV3 sensors rather than EV3 motors. So to detect rotation, these pins would have to be connected to an input port on the EV3 rather than an output port. If you want to drive the motor with the EV3, pins 1 and 2 would have to be connected to an output port on the EV3. Also, the comment about 5V vs. 3.3V on pin 4 still applies. On EV3, pins 3 and 4 on both input and output ports are the same. I also don't know how the motors would respond to EV3 sensor mode requests since on Powered Up they are used exclusively in multi-mode to get speed, position and absolute position all at the same time. EV3 would only be able to read one of these at a time. Theoretically it should work, but I doubt that part of the motor firmware was ever tested much.

Kind of. EV3 has 5V on pin 4 whereas Powered Up has 3.3V on pin 4. So you would need to be sure that this won't damage the sensor (LEGO education has some technical specs on the sensors that might give some insight). Also, the Powered Up sensors have expanded the UART sensor protocol, so EV3 won't be able to do things like enable multi-mode on the sensors. Also, sensors with lights need battery power on pin 1. The EV3 is technically capable of doing this, but existing software only enables this feature for NXT I2C sensors, not UART sensors.

Sounds like a bug in the software to me.

It could also be milliGs where 1G = 9.81 m/s/s. This is a common unit of measurement used on accelerometer chips. I think this experiment would be difficult since there is usually a short period of rapid acceleration followed by long period of constant velocity. The period of acceleration would need to be significantly longer than the sample rate of the accelerometer and the acceleration would need to be very smooth.

I'm guessing that the motor is still "running". Stop.HOLD still applies feedback control to the motor to keep it from moving. If you have more questions about how Pybricks motor control works, I would suggest asking at https://github.com/pybricks/support/discussions

the batteries are probably low