Known Issues

From Sketching with Hardware at LMU Wiki
Jump to navigation Jump to search

In our work and during the course a number of issues have come up ... and for some of them, there are also solutions.

PWM Output (for Servos)[edit]

Re-execution (basically executing a script more than once, without rebooting in between) may not work. PWM output will not switch off.

the workaround is to always deinit the PWM before using it, e.g.

1 servoPin = Pin(26, Pin.OUT)
2 pwm = PWM(servoPin, freq=50)
3 pwm.deinit()
4 pwm = PWM(servoPin, freq=50)


Servos and Power[edit]

Servos and motors are power-hungry and many of them will also require a higher voltage. A sign of the servo not having enough power is, that it does not move smoothly or that it only jitters.

Servos have in general 3 connections: GND, VCC/+, and PWM (the control pin).

A typical way to connect it is to connect PWM to the ESP32/ESP8266 (and to a PWM output pin). The GND is also connected to the ESP. VCC/+ is connected to the power supply, in the most simple case the 5V Pin of the ESP32/ESP3266 - this is connected to the 5V of the USB Port (and limited to 500mA with a fuse).

If you need more power you can use an external power supply, here it is important to connect 0V/-/GND to GND of the ESP and the VCC/+ of the supply to the VCC/+ of the servo.


Black Servo ES08MA II[edit]

The power (current and voltage) of many USB Ports connected to the ESP32/ESP8266 is not enough for the Servo ES08MA. It many cases it will not work.


Workaround: use the servo SG90.

ESP32 lableing[edit]

It seems there is a false marking on the additional labels that come in the box. On the left side the additional label says 5V - but the associated pin is actually 3.3V


RGB LEDs[edit]

There are two types of RGB LEDs.

There is the standard RGB LEDs (this is included in the LMUBox) - which is basically only 3 LEDs in parallel in one housing, see: RGB LED

There are also "intelligent" RGB LEDs and the are controlled like the NeoPixel Ring (or the WS2812 chip): LED Ring NeoPixel

netvar library[edit]

There are sometimes problem with return values that cannot be parsed - even so the should be OK. This may be a problem that occurs in the HTTP Request.

It would be good to catch this error in the library already.

"Hi, we are using 4 different Networkvariables: "kanban1_todo","kanban1_progress","kanban1_done" and "kanban1_working". We actually just write some int-values to them ("setNetVar") and also read them ("getNetVar"). The getting-part sometimes triggers the mentioned "ValueError: need more than 1 values to unpack.". Right now we are just catching the error, to avoid a crashing of the code, but it would be interesting to know, why it is triggered. "

There is also a second error being triggered by some get-requests:

 Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "<string>", line 301, in <module>
 File "", line 59, in getNetVar
 File "", line 25, in http_get
 OSError: [Errno 113] EHOSTUNREACH"

If you'd like to use a different port than 80, you'll need to adjust it in the http_get() function. Otherwise you might receive an OSError: -2.