Posts | Comments

Planet Arduino

Archive for the ‘microcontrollers’ Category

We’ve all seen those chess computers that consist out of a physical playing field, and a built-in computer that would indicate where you should put its pieces while inputting the position of your pieces in some way. These systems are usually found in a dusty cardboard box in a back room’s closet, as playing like this is fairly cumbersome, and a lot depends on the built-in chess computer.

This take by [andrei.erdei] on this decades-old concept involves an ATmega328p-based Arduino Pro Mini board, a nice wooden frame, and 4 WS2812-based 65×65 mm RGB 8×8 LED matrices, as well as some TTP223 touch sensors that allow one to control the on-board cursor. This is the sole form of input: using the UP and RIGHT buttons to select the piece to move, confirm with OK, then move to the new position. The chess program will then calculate its next position and indicate it on the LED matrix.

Using physical chess pieces isn’t required either: each 4×4 grid uses a special pattern that indicates the piece that occupies it.  This makes it highly portable, but perhaps not as fun as using physical pieces. It also kills the sheer joy of building up that collection of enemy pieces when you’ve hit that winning streak. You can look at the embedded gameplay video after the break and judge for yourself.

At the core of the chess program is [H.G. Muller]’s micro-Max project. Originally ported to the Arduino Uno, this program outputs the game to the serial port. After tweaking it to use the LED matrix instead, [andrei.erdei] was then faced with the lack of memory on the board for the most common LED libraries. In the end, the FAB_LED library managed to perform the task with less memory, allowing it and the rest of the program to fit comfortably into the glorious 2 kB of SRAM that the ATmega328p provides.

Classic 8-bit chess engines are marvels of software engineering. Ever wonder how they stack up against modern chess software? Check out this article!

It is a common situation in electronics to have a control loop, that is some sort of feedback that drives the input to a system such as a motor or a heater based upon a sensor to measure something like position or temperature. You’ll have a set point — whatever you want the sensor to read — and your job is to adjust the driving thing to make the sensor read the set point value. This seems easy, right? It does seem that way, but in realitythere’s a lot of nuance to doing it well and that usually involves at least some part of a PID (proportional, integral, derivative) controller. You can bog down in math trying to understand the PID but [Electronoobs] recent video shows a very simple test setup that clearly demonstrates what’s going on with an Arduino, a motor, a distance sensor, and a ping-pong ball. You can see the video below.

Imagine for a moment heating a tank of water as an example. The simple approach would be to turn on the heater and when the water reaches the setpoint, turn the heater off. The problem there is though that you will probably overshoot the target. The proportional part of a PID controller will only turn the heater fully on when the water is way under the target temperature. As the water gets closer to the right temperature, the controller will turn down the input — in this case using PWM. The closer the sensor reads to the setpoint, the lower the system will turn the heater.

For some applications, this is enough. But what if there are very small errors? Perhaps the set point is 90 degrees and you are 89.8. That won’t correct quickly in a proportional-only control loop because the heater won’t be on very much due to the small error. The integral part of the loop will react to small errors over time, adding a small bit each time the system isn’t in the right state. The derivative part is the opposite. It affects the output in reaction to sudden changes such as an ice cube landing in the tank.

The example rig is a seesaw-like balance beam and uses a lot of 3D printed parts and some plywood. The input driver to the system is an RC servo that can tip the seesaw to a different angle. An IR sensor determines how far the ping-pong ball is from the edge of the beam. With everything wired to the Arduino, you have a pretty good testbed for a controller.

If is common to “tune” a PID by setting Kp, Ki, and Kd constants that determine the “strength” of each action. With the beam, you can watch how tuning affects the system. By setting a constant to zero you can turn off that part of the algorithm, and it is very instructive to see what each part of the equation does to the ping-pong ball.

Even if you have used PID before, you will enjoy seeing this illustrative demo. It would be great in the classroom.  If you want to see a temperature example, we’ve seen that done with an Arduino, too. PID is integral — sorry — to flight control systems and self-balancing robots, too.

Reading the temperature of your environment is pretty easy right? A quick search suggests the utterly ubiquitous DHT11, which speaks a well documented protocol and has libraries for every conceivable microcontroller and platform. Plug that into your Arduino and boom, temperature (and humidity!) readings. But the simple solution doesn’t hit every need, sometimes things need to get more esoteric.

The technique summarized by an image from Microchip Appnote AN685

For years we’ve been watching [Edward]’s heroic efforts to build accessible underwater sensing hardware. When we last heard from him he was working on improving the accuracy of his Arduino’s measurements of the humble NTC thermistor. Now the goal is the same but he has an even more surprising plan, throw the ADC out entirely and sample an analog thermistor using digital IO. It’s actually a pretty simple trick based on an intuitive observation, that microcontrollers are better at measuring time than voltage. 

The basic circuit

The circuit has a minimum of four components: a reference resistor, the thermistor, and a small capacitor with discharge resistor. To sense you configure a timer to count, and an edge interrupt to capture the value in the timer when its input toggles. One sensing cycle consists of discharging the cap through the discharge resistor, enabling the timer and interrupt, then charging it through the value to measure. The value captured from the timer will be correlated to how long it took the cap to charge above the logic-high threshold when the interrupt triggers. By comparing the time to charge through the reference against the time to charge through the thermistor you can calculate their relative resistance. And by performing a few calibration cycles at different temperatures ([Edward] suggests at least 10 degrees apart) you can anchor the measurement system to real temperature.

For all the gory details, including tips for how to save every last joule of energy, check out [Edward]’s post and the Microchip appnote AN685 he references. Besides this series [Edward]’s Cave Pearl Project has already yielded an impressive number of Hackday posts. For more great hardware writeups check out a general hardware build for a single sensing node, or the “temperature sensor” [Edward] made with no external parts at all!

For years [Edward] has been building professional grade underwater sensing nodes at prices approachable for an interested individual without a government grant. An important component of these is temperature, and he has been on a quest to get the highest accuracy temperature readings from whatever parts hit that sweet optimum between cost and complexity. First there were traditional temperature sensor ICs, but after deploying numerous nodes [Edward] was running into the limit of their accuracy. Could he use clever code and circuitry to get better results? The short answer is yes, but the long answer is a many part series of posts starting in 2016 detailing [Edward]’s exploration to get there.

Orange is 12 bits, red is 24

The first step is a thermistor, a conceptually simple device: resistance varies with temperature (seriously, how much more simple can a sensor get?). You can measure them by tapping the center of a voltage divider the same way you’d measure any other resistance, but [Edward] had discarded this idea because the naive approach combined with his Arduino’s 10 bit ADC yielded resolution too poor to be worthwhile for his needs. But by using the right analog reference voltage and adjusting the voltage divider he could get a 20x improvement in resolution, down to 0.05°C in the relevant temperature range. This and more is the subject of the first post.

What comes next? Oversampling. Apparently fueled by a project featured on Hackaday back in 2015 [Edward] embarked on a journey to applying it to his thermistor problem. To quote [Edward] directly, to get “n extra bits of resolution, you need to read the ADC four to the power of n times”. Three bits gives about an order of magnitude better resolution. This effectively lets you resolve signals smaller than a single sample but only if there is some jitter in the signal you’re measuring. Reading the same analog line with no perturbation gives no benefit. The rest of the post deals with the process of artificially perturbing the signal, which turns out to be significantly complex, but the result is roughly 16 bit accuracy from a 10 bit ADC!

What’s the upside? High quality sensor readings from a few passives and a cheap Arduino. If that’s your jam check out this excellent series when designing your next sensing project!

Even though machine learning AKA ‘deep learning’ / ‘artificial intelligence’ has been around for several decades now, it’s only recently that computing power has become fast enough to do anything useful with the science.

However, to fully understand how a neural network (NN) works, [Dimitris Tassopoulos] has stripped the concept down to pretty much the simplest example possible – a 3 input, 1 output network – and run inference on a number of MCUs, including the humble Arduino Uno. Miraculously, the Uno processed the network in an impressively fast prediction time of 114.4 μsec!

Whilst we did not test the code on an MCU, we just happened to have Jupyter Notebook installed so ran the same code on a Raspberry Pi directly from [Dimitris’s] bitbucket repo.

He explains in the project pages that now that the hype about AI has died down a bit that it’s the right time for engineers to get into the nitty-gritty of the theory and start using some of the ‘tools’ such as Keras, which have now matured into something fairly useful.

In part 2 of the project, we get to see the guts of a more complicated NN with 3-inputs, a hidden layer with 32 nodes and 1-output, which runs on an Uno at a much slower speed of 5600 μsec.

This exploration of ML in the embedded world is NOT ‘high level’ research stuff that tends to be inaccessible and hard to understand. We have covered Machine Learning On Tiny Platforms Like Raspberry Pi And Arduino before, but not with such an easy and thoroughly practical example.

[Mirko Pavleski] has put together a little weather station for himself that combines Internet-sourced forecasts with physical sensor data to give him a complete view of his local conditions. There’s no shortage of weather applications for our smartphones and computers that will show us the current local conditions and the forecast for the next couple of days. It’s so easy to pull weather data from the various APIs out there that you even see the functionality “baked in” to different gadgets these days. Of course, you can dig through every weather API in the world and not find the temperature and humidity inside your office; for that, you need your own sensors.

[Mirko] took a somewhat unconventional approach by essentially building two totally separate weather devices and packing them into one enclosure, which gives the final device a rather unique look thanks to the contrasting display technologies used.

Local conditions are detected by an Arduino Nano connected to a BMP180 sensor and displayed on a Nokia 5110 LCD. The screen shows not only real-time temperature and barometric pressure, but the change in pressure over the last several hours. The three-day forecast, on the other hand, is provided by a NodeMCU ESP8266 development board connected to the increasingly ubiquitous 0.96 inch OLED.

If you’re not into the whole duality thing and would rather do it all on the same device, you might be interested in one of the ESP8266 weather monitors we’ve seen in the past.

[Mirko Pavleski] has put together a little weather station for himself that combines Internet-sourced forecasts with physical sensor data to give him a complete view of his local conditions. There’s no shortage of weather applications for our smartphones and computers that will show us the current local conditions and the forecast for the next couple of days. It’s so easy to pull weather data from the various APIs out there that you even see the functionality “baked in” to different gadgets these days. Of course, you can dig through every weather API in the world and not find the temperature and humidity inside your office; for that, you need your own sensors.

[Mirko] took a somewhat unconventional approach by essentially building two totally separate weather devices and packing them into one enclosure, which gives the final device a rather unique look thanks to the contrasting display technologies used.

Local conditions are detected by an Arduino Nano connected to a BMP180 sensor and displayed on a Nokia 5110 LCD. The screen shows not only real-time temperature and barometric pressure, but the change in pressure over the last several hours. The three-day forecast, on the other hand, is provided by a NodeMCU ESP8266 development board connected to the increasingly ubiquitous 0.96 inch OLED.

If you’re not into the whole duality thing and would rather do it all on the same device, you might be interested in one of the ESP8266 weather monitors we’ve seen in the past.

We’ve all been there. When debugging a microcontroller project, we just want to put in a print statement to figure out what’s going on with the microcontroller in real time. However, advanced embedded programmers know that printf statements are verboten: they’re just too SLOW. While not fixing this plight entirely, [Atakan Sarioglu] has come up with a clever way to create readable debug messages with minimal runtime overhead.

[Atakan Sarioglu]’s innovation, called BigBug (Github), is a dynamically-generated codebook. The codebook translates abbreviated messages sent over serial (UART here) to longer-form human-readable messages. To generate the codebook, BigBug automatically parses your comments to create a lookup between an abbreviation and the long-form message. When you are running your program on the microcontroller, BigBug will translate the short codes to long messages in real-time as you send log/debug data over serial.

For example (not restricted to Arduino-only), if you write Serial.println("HW") //@BB[HW] Hello World!, BigBug will translate the received characters HW\n to Hello World!. In this simple example, the abbreviation uses 3 characters while the fully readable message uses 13 characters, for a savings of ~75% with no loss of clarity. More advanced usage lets you log data: Serial.println("DT 1 1") //@BB[DT] Today's Date is: {0}/{1} becomes Today's Date is 1/1. You can also use enumerated variables (last example could showToday's Date is Jan. 1 with the same print command).

In terms of real-world benefit, using a 115200 baud connection (with 8N1 encoding) this is 115200 bits per second /(8+1) bits per byte = 12800 bytes/sec = 1 byte every 80 microseconds. Sending 13 bytes of Hello World!\n (in a naive, blocking UART implementation) takes ~1 ms of CPU time. With the shortcode HW\n, it would take ~0.25 ms to send essentially the same message (then decoded by BigBug). Note that because this just operates on serial data, BigBug is language independent

If you’ve been constrained by serial throughput for debugging, this looks like a well-polished tool to solve your problems. If you are just using an Arduino and throughput is no issue, then try this tool to debug Arduino programs. Or you could always double-down and use a microcontroller to debug another microcontroller.

There’s a school of thought that says that to fully understand something, you need to build it yourself. OK, we’re not sure it’s really a school of thought, but that describes a heck of a lot of projects around these parts.

[Tim] aka [mitxela] wrote kiloboot partly because he wanted an Ethernet-capable Trivial File Transfer Protocol (TFTP) bootloader for an ATMega-powered project, and partly because he wanted to understand the Internet. See, if you’re writing a bootloader, you’ve got a limited amount of space and no device drivers or libraries of any kind to fall back on, so you’re going to learn your topic of choice the hard way.

[Tim]’s writeup of the odyssey of cramming so much into 1,000 bytes of code is fantastic. While explaining the Internet takes significantly more space than the Ethernet-capable bootloader itself, we’d wager that you’ll enjoy the compressed overview of UDP, IP, TFTP, and AVR bootloader wizardry as much as we did. And yes, at the end of the day, you’ve also got an Internet-flashable Arduino, which is just what the doctor ordered if you’re building a simple wired IoT device and you get tired of running down to the basement to upload new firmware.

Oh, and in case you hadn’t noticed, cramming an Ethernet bootloader into 1 kB is amazing. If doing big things in small codespaces floats your boat, check out the winners from our own 1kB challenge.

Speaking of bootloaders, if you’re building an I2C slave device out of an ATtiny85¸ you’ll want to check out this bootloader that runs on the tiny chip.

It used to be that Web browsing was simple. You asked a server for some text, which was duly sent, and then formatted by your browser. Now a web page is as likely to be a full-blown application that is reading mail, editing text, or lots of other things and may use WebSockets to create a back channel to the server. Thanks to affordable hardware like the ESP8266 one of those things a modern web browser can do is sense and control the real world. [Acrobotic] has an interesting video about using WebSockets to allow a browser to talk to an ESP8266 web server in real time. You can see his simple demo in the video below.

Of course, you’ll use the usual language you use on the ESP8266 — [Acrobotic] uses C++ in the Arduino IDE. On the browser side you’ll use JavaScript, although that will be embedded in your C++ program which acts as a web server.

It’s as well to remember that there are several other ways you could do this. You could, for example ask for a different URL, or pass data in a query string. The problem here is that the performance would suffer as you have to establish a new connection every time. you want to transact with the server. You could also use AJAX methods but they are not as efficient either since they are primarily aimed at updating a portion of a web page dynamically. The web socket is simple enough and as you can see in the video, the performance is quite good. It also facilitates non-browser based clients that use the same service.

We’ve seen this technique used to fly a quadcopter. WebSockets have been around for a while, so your browser should support them. If it doesn’t, though, you can always use this hack — at least in one direction.



  • Newsletter

    Sign up for the PlanetArduino Newsletter, which delivers the most popular articles via e-mail to your inbox every week. Just fill in the information below and submit.

  • Like Us on Facebook