Unable to get NeoPixels working on LMS-ES32 Tutorial: BluePad library for PyBricks

[Gun-neR]

Unable to get any RGB LED strip to work .

I don't have the 24LED ring as in the demo, but I do have other NeoPixels strips, including the ones I purchased on Anton's website (and yes, they all work on other microcontroller projects). I have of course adjusted values for different GPIO and LED counts as I tested all I have on hand.

The joystick, servo and even the LEGO HUB screen work just fine... just no NeoPixels.

Wondering if there have been changes to the library since the YouTube video went out a few days ago? In fact I have tried every bluepad.py code I could find across your's and Anton's various repositories. And to add to the confusion, depending on the bluepad.py used, some examples run fine... but of course, no RGB action... or the examples get this msg when it hits the bp.neopixel_fill() command.

bp.neopixel_init(6,12)
bp.neopixel_fill(30,0,0)

The program was stopped (SystemExit).
Traceback (most recent call last):
  File "bluepad_example.py", line 13, in <module>
TypeError: neopixel_fill() takes 3 positional arguments but 4 were given

I am fairly new with python and tend to require examples to get my head around something, thus difficult to learn new stuff when the only demos don't work as shown :) Too much for this old groggy brain to learn something new while also trying to troubleshoot it, so any assistance appreciated :)

[Gun-neR]

OK, the "different" bluepad.py codes I can see appear mostly to do with something called tuples... I don't think that is the main "No worky RGB" issue, but does explain why I have to use the "correct" bluepad.py for some examples.

https://github.com/antonvh/PUPRemote/blob/main/src/bluepad.py

https://github.com/ste7anste7an/bluepad32_arduino/blob/main/BP32_PyBricks/bluepad.py

[Gun-neR]

Update... to ensure my own sanity about the hardware, LED strip, GPIO, wiring, etc, I flashed the LMS-ES32 with a FastLED demo using Arduino... and it worked!!

So I guess there really is something with the library??

[ste7anste7an]

I will have a look into it. Good that you tried this and unfortunate, that you encountered problems. But at least, you identified something that goes wrong. Keep you updated on this.

[ste7anste7an]

I found the problem. Somehow, the PyBricks PUPDevice class has been changed. They force all byte values passed to a sensor to be within -128<x<127. If the value is larger than 127, it becomes 127. For the NeoPixels I use the first byte to send the command. For a fill command e.g. this is 0x90 (144). This gets clipped to 127. I had an older PyBricks version running on a technic hub and that works fine. I need to make a work-around. But be assured that this is not your problem. The code you showed is 100% OK. And I admit, that when examples and demo's are not correctly working, it is hard to get up to speed!
So, as soon as I have time, I will fix the pupremote library and I will send a message here.

[ste7anste7an]

I put a workaround in the latest pupremote.py and pupremote_hub,py. It should work now. Can you retest your examples?

[Gun-neR]

Yes, it seems to work better now. Thanks.. looks nicer with RGB's :D

Possibly unrelated, but as I am currently testing with only a 6 element strip, I have set my init accordingly. It works, but it is clearly accounting for more as I miss a large range on the joysticks and get a scrolling error whenever "lighting" a non-existent LED.

error neopixel_set: led_nr larger than number of leds!
error neopixel_set: led_nr larger than number of leds!
error neopixel_set: led_nr larger than number of leds!
error neopixel_set: led_nr larger than number of leds!
error neopixel_set: led_nr larger than number of leds!...

But the program does keep running, so that is good :)

I haven't found where the low limit of LED's is set in bluepad.py... or is it elsewhere?

[Gun-neR]

Ah... forget it.. I found multiple references to "24" in the examples. Changing them and the init pixel count to a variable seems to work better.

Still a small gap in the joystick/pixel relationship, and no pixel visible when leaving a joystick in a neutral position, but no errors... So probably just a math artifact between the angle formulas you use compared to my minuscule number of pixels in my test.

All is good then as for this issue.