Posts with «microcontrollers» label

Energy Harvesting Design Doesn’t Need Sleep

Every scrap of power is precious when it comes to power harvesting, and working with such designs usually means getting cozy with a microcontroller’s low-power tricks and sleep modes. But in the case of the Ultra Low Power Energy Harvester design by [bobricius], the attached microcontroller doesn’t need to worry about managing power at all — as long as it can finish its job fast enough.

The idea is to use solar energy to fill a capacitor, then turn on the microcontroller and let it run normally until the power runs out. As a result, a microcontroller may only have a runtime in the range of dozens of microseconds, but that’s just fine if it’s enough time to, for example, read a sensor and transmit a packet. In early tests, [bobricius] was able to reliably transmit a 16-bit value wirelessly every 30 minutes using a small array of photodiodes as the power supply. That’s the other interesting thing; [bobricius] uses an array of BPW34 photodiodes to gather solar power. The datasheet describes them as silicon photodiodes, but they can be effectively used as tiny plastic-enclosed solar cells. They are readily available and can be arranged in a variety of configurations, while also being fairly durable.

Charging a capacitor then running a load for a short amount of time is one of the simplest ways to manage solar energy, and it requires no unusual components or fancy charge controllers. As long as the load doesn’t mind a short runtime, it can be an effective way to turn even indoor light into a figuratively free power source.

Mademoiselle Pinball Table Gets Rock ‘n Roll Makeover

Once upon a time, there was a music venue/artist collective/effects pedal company that helped redefine industry in Williamsburg, Brooklyn. That place was called Death By Audio. In 2014, it suffered a death by gentrification when Vice Media bought the building that DBA had worked so hard to transform. From the ashes rose the Death By Audio Arcade, which showcases DIY pinball cabinets made by indie artists.

Their most recent creation is called A Place To Bury Strangers (APTBS). It’s built on a 1959 Gottlieb Mademoiselle table and themed around a local noise/shoegaze band of the same name that was deeply connected to Death By Audio. According to [Mark Kleeb], this table is an homage to APTBS’s whiz-bang pinball-like performance style of total sensory overload. Hardly a sense is spared when playing this table, which features strobe lights, black lights, video and audio clips of APTBS, and a fog machine. Yeah.

[Mark] picked up this project from a friend, who had already cut some wires and started hacking on it. Nearly every bit of the table’s guts had to be upgraded with OEM parts or else replaced entirely. Now there’s a Teensy running the bumpers, and another Teensy on the switches. An Arduino drives the NeoPixel strips that light up the playfield, and a second Uno displays the score on those sweet VFD tubes. All four micros are tied together with Python and a Raspi 3.

If you’re anywhere near NYC, you can play the glow-in-the-dark ball yourself on July 15th at Le Poisson Rouge. If not, don’t flip—just nudge that break to see her in action. Did we mention there’s a strobe light? Consider yourself warned.

Want to get into DIY pinball on a smaller scale? Build yourself a sandbox and start playing.

Supersize DIY R/C Servos From Windscreen Wipers

We’re all familiar with the experience of buying hobby servos. The market is awash with cheap clones which have inflated specs and poor performance. Even branded servos often fail to deliver, and sometimes you just can’t get the required torque or speed from the small form factor of the typical hobby servo.

Enter [James Bruton] and his DIY RC servo from a windscreen wiper motor. Windscreen wiper motors are cheap as chips, and a classic salvage. The motor shaft is connected to a potentiometer via a pulley and some string, providing the necessary closed-loop feedback. Instead of using the traditional analog circuitry found inside a servo, an Arduino provides the brains. This means PID control can be implemented on the ‘duino, and tuned to get the best response from different load characteristics. There’s also the choice of different interfacing options: though [James]’ Arduino code accepts PWM signals for a drop-in R/C servo replacement, the addition of a microcontroller means many other input signal types and protocols are available. In fact, we recently wrote about serial bus servos and their numerous advantages.

We particularly love this because of the price barrier of industrial servomotors; sure, this kind of solution doesn’t have the precision or torque that off-the-shelf products provide, but would be sufficient for many hacks. Incidentally, this is what inspired one of our favourite open source projects: ODrive, which focuses on harnessing the power of cheap brushless motors for industrial use.

The Smaller, Tinier Arduino Platform

While many of the Arduino platforms are great tools for gaining easy access to microcontrollers, there are a few downsides. Price and availability may be the highest on the list, and for those reasons, some have chosen to deploy their own open-source Arduino-compatible boards.

The latest we’ve seen is the Franzininho, an Arduino Gemma-like board that’s based on the ATtiny85, a capable but tiny microcontroller by Atmel in a compact 8-pin configuration. This board has everything the Gemma has, including a built-in LED and breakout pins. One of the other perks of the Franzininho over the Gemma is that everything is based on through-hole components, making the assembly much easier than the surface mount components of the Gemma.

It’s worth noting that while these boards are open source, the Arduinos are as well. It’s equally possible to build your own 100% identical Arduino almost as easily. If you want more features, you can add your own by starting from one of these platforms and do whatever you want with it, like this semi-educational Atmel breakout board.

Thanks to [Clovis] for the tip!

A Crash Course In Reliable Communication

It’s probably fair to say that anyone reading these words understands conceptually how physically connected devices communicate with each other. In the most basic configuration, one wire establishes a common ground as a shared reference point and then the “signal” is sent over a second wire. But what actually is a signal, how do the devices stay synchronized, and what happens when a dodgy link causes some data to go missing?

All of these questions, and more, are addressed by [Ben Eater] in his fascinating series on data transmission. He takes a very low-level approach to explaining the basics of communication, starting with the concept of non-return-to-zero encoding and working his way to a shared clock signal to make sure all of the devices in the network are in step. Most of us are familiar with the data and clock wires used in serial communications protocols like I2C, but rarely do you get to see such a clear and detailed explanation of how it all works.

He demonstrates the challenge of getting two independent devices to communicate, trying in vain to adjust the delays on the receiving and transmitting Arduinos to try to establish a reliable link at a leisurely five bits per second. But even at this digital snail’s pace, errors pop up within a few seconds. [Ben] goes on to show that the oscillators used in consumer electronics simply aren’t consistent enough between devices to stay synchronized for more than a few hundred bits. Until atomic clocks come standard on the Arduino, it’s just not an option.

[Ben] then explains the concept of a dedicated clock signal, and how it can be used to make sure the devices are in sync even if their local clocks drift around. As he shows, as long as the data signal and the clock signal are hitting at the same time, the actual timing doesn’t matter much. Even within the confines of this basic demo, some drift in the clock signal is observed, but it has no detrimental effect on communication.

In the next part of the series, [Ben] will tackle error correction techniques. Until then, you might want to check out the fantastic piece [Elliot Williams] put together on I2C.

[Thanks to George Graves for the tip.]

Push it to the Limit: SSD1306 at 150 FPS

A good deal of the projects we cover here at Hackaday are not, in the strictest sense, practical endeavors. If we required that everything which graced our digital pages had a clear end result, the site would be in a rather sad state of affairs. Sometimes it’s enough just to do something for the challenge of it. But more often than not, you’ll learn something in the process which you can use down the line.

That’s precisely what pushed [Laurence Bank] to see how well he could optimize the frame rate on the popular SSD1306 OLED display. After several iterations of his code, he was able to achieve a blistering 151.5 FPS, with apparently still some room for improvement if he’s feeling up to the challenge. But considering his first attempt was only running at 5.5 FPS, we’d say he’s already more than earned his hacker cred on this one.

A few different tricks were used to achieve such incredible performance gains. To start with, while the official I2C specification says you’re supposed to wait for an acknowledgment back from the device when communicating with it, [Laurence] realized the SSD1306 didn’t actually care. He could continuously blast commands at the display without bothering to wait for an acknowledgment. He admits there are problems with this method, but you can’t argue with the results.

To really wring all the performance out of the system he could, [Laurence] donned his Assembly Cap and examined how the Arduino IDE compiler was interpreting his code. He identified a few areas where changing his C code would force the compiler to generate faster output. He notes that this wouldn’t normally be required when working with more advanced compilers, but that the Arduino toolchain needs its hand held occasionally.

This isn’t the first time we’ve seen somebody try and push more pixels through the very same OLED display, and it’s interesting to see the two very different approaches to the same goal.

The Adafruit Feather Is A Thing

A few years ago, Adafruit launched the Feather 32u4 Basic Proto. This tiny development board featured — as you would expect — an ATMega32u4 microcontroller, a USB port, and a battery charging circuit for tiny LiPo batteries. It was, effectively, a small Arduino clone with a little bit of extra circuitry that made it great for portable and wearable projects. In the years since, and as Adafruit has recently pointed out, the Adafruit Feather has recently become a thing. This is a new standard. Maxim is producing compatible ‘wings’ or shields. If you’re in San Fransisco, the streets are littered with Feather-compatible boards. What’s the deal with these boards, and why are there so many of them?

The reason for Adafruit’s introduction of the Feather format was the vast array of shields, hats, capes, clicks, props, booster packs, and various other standards. The idea was to bring various chipsets under one roof, give them a battery charging circuit, and not have a form factor that is as huge as the standard Arduino. The Feather spec was finalized and now we have three-phase energy monitors, a tiny little game console, LoRaWAN Feathers, and CAN controllers.

Of course, the Feather format isn’t just limited to Adafruit products and indie developers. The recently introduced Particle hardware is built on the Feather format, giving cellular connectivity to this better-than-Arduino format. Maxim is producing some development boards with the same format.

So, do we finally have a form factor for one-off embedded development that isn’t as huge or as wonky as the gigantic Arduino with weirdly offset headers? It seems so.

Reviving an Electron Microscope with Arduino

We don’t know about you, but when our friends ask us if we want to help them fix something, they’re usually talking about their computer, phone, or car. So far it’s never been about helping them rebuild an old electron microscope. But that’s exactly the request [Benjamin Blundell] got when a friend from a local hackerspace asked if he could take a look at a vintage Cambridge Stereoscan 200 they had found abandoned in a shed. Clearly we’re hanging out with the wrong group of people.

As you might imagine, the microscope was in desperate need of some love after spending time in considerably less than ideal conditions. While some of the hackerspace members started tackling the hardware side of the machine, [Benjamin] was tasked with finding a way to recover the contents of the scope’s ROM. While he’s still working on verification, the dumps he’s made so far of the various ROMs living inside the Stereoscan 200 have been promising and he believes he’s on the right track.

The microscope uses a mix of Texas Instruments 25L32 and 2516 chips, which [Benjamin] had to carefully pry out after making sure to document everything so he knew what went where. A few of the chips weren’t keen on being pulled from their home of 30-odd years, so there were a few broken pins, but on the whole the operation was a success.

Each chip was placed in a breadboard and wired up to an Arduino Mega, as it has enough digital pins to connect without needing a shift register. With the wiring fairly straightforward, [Benjamin] just needed to write up some code to read the contents of the chip, which he has graciously provided anyone else who might be working on a similar project. At this point he hasn’t found anything identifiable in his ROM dumps to prove that they’ve been made successfully, all he really knows right now is that he has something. At least it’s a start.

More and more of these older electron microscopes are getting a second lease on life thanks to dedicated hackers in their home labs. Makes you wonder if there’s ever going to be a piece of hardware the hacker community won’t bend to their will.

Debugging with Serial Print at 5333333 Baud

Debugging with printf is something [StorePeter] has always found super handy, and as a result he’s always been interested in tweaking the process for improvements. This kind of debugging usually has microcontrollers sending messages over a serial port, but in embedded development there isn’t always a hardware UART, or it might already be in use. His preferred method of avoiding those problems is to use a USB to Serial adapter and bit-bang the serial on the microcontroller side. It was during this process that it occurred to [StorePeter] that there was a lot of streamlining he could be doing, and thanks to serial terminal programs that support arbitrary baud rates, he’s reliably sending debug messages over serial at 5.3 Mbit/sec, or 5333333 Baud. His code is available for download from his site, and works perfectly in the Arduino IDE.

The whole thing consists of some simple, easily ported code to implement a bare minimum bit-banged serial communication. This is output only, no feedback, and timing consists of just sending bits as quickly as the CPU can handle, leaving it up to the USB Serial adapter and rest of the world to handle whatever that speed turns out to be. On a 16 MHz AVR, transmitting one bit can be done in three instructions, which comes out to about 5333333 baud or roughly 5.3 Mbit/sec. Set a terminal program to 5333333 baud, and you can get a “Hello world” in about 20 microseconds compared to 1 millisecond at 115200 baud.

He’s got additional tips on using serial print debugging as a process, and he’s done a followup where he stress-tests the reliability of a 5.3 MBit/sec serial stream from an ATMega2560 at 16 MHz in his 3D printer, and found no missed packets. That certainly covers using printf as a debugger, so how about a method of using the debugger as printf?

Entropy and The Arduino: When Clock Jitter is Useful

What do you do, when you need a random number in your programming? The chances are that you reach for your environment’s function to do the job, usually something like rand() or similar. This returns the required number, and you go happily on your way.

A shift register configured as a pseudo-random
number generator. [by KCAuXy4p CC0 1.0]
Except of course the reality isn’t quite that simple, and as many of you will know it all comes down to the level of randomness that you require. The simplest way to generate a random number in software is through a pseudo-random number generator, or PRNG. If you prefer to think in hardware terms, the most elementary PRNG is a shift register with a feedback loop from two of its cells through an XOR gate. While it provides a steady stream of bits it suffers from the fatal flaw that the stream is an endlessly repeating sequence rather than truly random. A PRNG is random enough to provide a level of chance in a computer game, but that predictability would make it entirely unsuitable to be used in cryptographic security for a financial transaction.

There is a handy way to deal with the PRNG predictability problem, and it lies in ensuring that its random number generation starts at a random point. Imagine the  shift register in the previous paragraph being initialised with a random number rather than a string of zeros. This random point is referred to as the seed, and if a PRNG algorithm can be started with a seed derived from a truly unpredictable source, then its output becomes no longer predictable.

Selecting Unpredictable Seeds

Computer systems that use a PRNG will therefore often have some form of seed() function alongside their rand() function. Sometimes this will take a number as an argument allowing the user to provide their own random number, at other times they will take a random number from some source of their own. The Sinclair 8-bit home computers for example took their seed from a count of the number of TV frames since switch-on.

The not-very-random result of a thousand analogRead() calls.

The Arduino Uno has a random() function that returns a random number from a PRNG, and as you might expect it also has a randomSeed() function to ensure that the PRNG is seeded with something that will underpin its randomness. All well and good, you might think, but sadly the Atmel processor on which it depends has no hardware entropy source from which to derive that seed. The user is left to search for a random number of their own, and sadly as we were alerted by a Twitter conversation between @scanlime and @cybergibbons, this is the point at which matters start to go awry. The documentation for randomSeed() suggests reading the random noise on an unused pin via analogRead(), and using that figure does not return anything like the required level of entropy. A very quick test using the Arduino Graph example yields a stream of readings from a pin, and aggregating several thousand of them into a spreadsheet shows an extremely narrow distribution. Clearly a better source is called for.

Noisy Hardware or a Jittery Clock

As a slightly old-school electronic engineer, my thoughts turn straight to a piece of hardware. Source a nice and noisy germanium diode, give it a couple of op-amps to amplify and filter the noise before feeding it to that Arduino pin. Maybe you were thinking about radioactive decay and Geiger counters at that point, or even bouncing balls. Unfortunately though, even if they scratch the urge to make an interesting piece of engineering, these pieces of hardware run the risk of becoming overcomplex and perhaps a bit messy.

The significantly more random result of a thousand Arduino Entropy Library calls.

The best of the suggestions in the Twitter thread brings us to the Arduino Entropy Library, which uses jitter in the microcontroller clock to generate truly random numbers that can be used as seeds. Lifting code from the library’s random number example gave us a continuous stream of numbers, and taking a thousand of them for the same spreadsheet treatment shows a much more even distribution. The library performs as it should, though it should be noted that it’s not a particularly fast way to generate a random number.

So should you ever need a truly random number in your Arduino sketch rather than one that appears random enough for some purposes, you now know that you can safely disregard the documentation for a random seed and use the entropy library instead. Of course this comes at the expense of adding an extra library to the overhead of your sketch, but if space is at a premium you still have the option of some form of hardware noise generator. Meanwhile perhaps it is time for the Arduino folks to re-appraise their documentation.

The subject of entropy and generating random numbers is one that has appeared on these pages many times. [Voja Antonic] made a in-depth study using uninitialized RAM as an entropy source for microcontrollers. If you have an insatiable appetite for understanding Linux entropy, we point you at [Elliot Williams]’ comprehensive examination of the subject.

[Arduino image: DustyDingo Public domain]


Filed under: Arduino Hacks, Hackaday Columns, Microcontrollers, Skills