The worst kind of bug

The worst kind of bug is the one which is not there. I spent a big chunk of today trying to figure out why MQTT settings weren’t being transferred correctly from the server into my embedded device. The idea is that you plug a brand new ESP8266 or ESP32 powered device your computer, visit the Connected Little Boxes website and all the firmware and settings are loaded into the device automagically. It was working fine with test messages, but not when I tried to use it to actually connect a device.

I built more complex tests, added diagnostics and still the system didn’t work. I was getting more and more confused until I realised one of the messages that I was sending had the wrong thing in it. In other words the transport mechanism was fine but because of a formatting error the setting wouldn’t work in the device. Silly me.

I’m not too unhappy though. The code is now a lot more tested than it was, and it has some diagnostic output which will be useful at some point. And it does indeed work now. The only thing you have to do is enter your WiFi credentials into the webpage so that the device can connect to the network. The device is configured and then added to the list of devices that you own. The next step is to add configuration pages for the internal device interfaces so that owners can make them into lights, buttons, dials, inputs, displays or whatever.

Restoring Arduino servo movement

Servos are a great, cheap, way of giving your devices a bit of physical movement. You can pick little ones up for around a pound each and a single Arduino can control quite a few servos. You can make a Connected Little Box control a servo. In the example shown above you turn the knob on the left and the servo on the box on the right turns, tracking it. However, there are two bad things that a servo can do:

1. Not move as far as you might want it to.

2. Burst into flames trying to move to a point that it can’t get to.

The writers of the Arduino servo library have decided that point 2 is actually more important than point 1. So they’ve changed the way that the servo libraries work. This caused some of our servos to misbehave. How did we fix them? Read on…..

When you want a servo to move you give it a pulse of a particular length. The servo converts this pulse into a value which is matched against one that represents the position of the servo output shaft. The servo attempts to turn the shaft so that the two values are the same, causing it to move to a particular position. If something tries to move the shaft away from this position the servo will push back. If the pulse size changes the servo will move the output shaft in response. So far, so wonderful.

But what happens if the computer gives a pulse that is converted to a value that the servo shaft can’t match? The answer is that the servo will try to move to that position and get stuck on the way, stubbornly pushing until coils heat up and melt, gears break and so on. And then you have to buy a new servo.

The original Arduino libraries for the servo assumed a range of movement that some servos can’t match. So they’ve reduced this range. The range boils down to two values that used to be 544-2400 but are now 1000-2000. The new range makes servos a lot safer, there is less chance that they will move into dangerous positions, but it does significantly reduce the amount of movement that you get. The good news is that you can override the pre-set values when you attach to your servo:

servo = new Servo();
servo.attach(2,544, 2400);

The statements above show you how to do this. The first statement creates the servo. The second attaches the server to GPIO pin 2 and restores the range of movement to the values used in the bad old dangerous days.