Posts | Comments

Planet Arduino

Archive for the ‘microcontrollers’ Category

We always think it is interesting that a regular DC motor and a generator are about the same thing. Sure, each is optimized for its purpose, but inefficiencies aside, you can use electricity to rotate a shaft or use a rotating shaft to generate electricity. [Andriyf1] has a slightly different trick. He shows how to use a stepper motor as an encoder. You can see a video of the setup below.

It makes sense. If the coils in the stepper can move the shaft, then moving the shaft should induce a current in the coils. He does note that at slow speeds you can miss pulses, however. Again, the device isn’t really optimized for this type of operation.

The circuit uses an opamp-based differential amplifier to read the pulses from the coil. Two opamps on two coils produce a quadrature signal just like a normal encoder. When the shaft turns in one direction, one pulse will lead the other. In the other direction, the lead pulse will be reversed.

There’s code to let an Arduino read the pulses, but we were disappointed it was behind a Patreon paywall. However, there’s plenty of code that will read quadrature on an Arduino or other processors, and that really isn’t the point of the post, anyway. We’ve seen similar hacks done with hard drive motors which are quite similar, by the way.

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.

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.

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.]

We admit, we see a lot of weather stations. What makes [Mike Diamond’s] take on this old favorite interesting is that it is tiny enough to carry with you, and uses your cell phone as a hotspot to deliver its data. Of course, that assumes you have a phone that can act as a hotspot.

The parts are straightforward, a power supply, an ESP8266, and a weather sensor board. It looks as though you could easily slip the whole affair into a tube or maybe a 3D printed enclosure. We were a little concerned about the bare wire used, but as [Mike] points out you can use insulated wire if you like, and we’d encourage you to do so.

There are some modifications required including removing the pin headers. [Mike] uses the old trick of smacking your hand on the table after melting the pins. You can also heat up each pin and pull it out with pliers. Or, if you have a hot air gun, get all the pins molten at once — just don’t heat up more of the board than you need.

On the data end, the ESP8266 uses Cayenne to transmit data which is the same kind of IoT backend we see a lot lately. On the one hand, this allows you to distribute it without developing a phone application. On the other hand, we would have been tempted to just make the ESP8266 a web server and populate a simple web page. Of course, you could still do that if you wanted to.

We’ve seen plenty of weather stations, but a lot of them are not nearly as compact. If you want to go old school, there’s always the TI 99/4A weather station.

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.

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?

There’s no question that you can get a lot done with the classic multimeter; it’s arguably the single most capable tool on your bench. But the farther down the rabbit hole of hacking and reverse engineering you go, the more extravagant your testing and diagnostic gear tends to get. For some of us that’s just an annoying reality of the game. For others it’s an excuse to buy, and maybe even build, some highly specialized equipment. We’ll give you one guess as to which group we fall into here at Hackaday.

[Akshay Baweja] is clearly a member of the second group. He’s recently published a guide on building a very slick intelligent Integrated Circuit tester with a total cost of under $25 USD. Whether you’re trying to identify an unknown chip or verifying your latest parts off the slow-boat from China actually work before installing them in your finished product, this $25 tool could end up saving you a lot of time and aggravation.

[Akshay] walks readers through the components and assembly of his IC tester, which takes the form of a Shield for the Arduino Mega 2560. The custom PCB he designed and had manufactured holds the 20 Pin ZIF Socket as well as the 2.4 inch TFT touch screen. The screen features an integrated micro SD slot which is important as you need the SD card to hold the chip database.

With an IC to test inserted into the ZIF socket, the user can have the tester attempt to automatically ID the chip or can manually enter in a part number to lookup. The source code for the Arduino as well as the chip ID database is up on GitHub for anyone looking to add some more hardware to the device’s testing repertoire.

The importance of good test equipment simply cannot be overstated. Between highly specialized gear like this IC tester to classic instruments such as the oscilloscope, your bench is going to be full of weird and wonderful pieces of equipment before too long.

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.
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 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 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

If you’ve been hanging around microcontrollers and electronics for a while, you’re surely familiar with the concept of the breakout board. Instead of straining to connect wires and components to ever-shrinking ICs and MCUs, a breakout board makes it easier to interface with the device by essentially making it bigger. The Arduino itself, arguably, is a breakout board of sorts. It takes the ATmega chip, adds the hardware necessary to get it talking to a computer over USB, and brings all the GPIO pins out with easy to manage header pins.

But what if you wanted an even bigger breakout board for the ATmega? Something that really had some leg room. Well, say no more, as [Nick Poole] has you covered with his insane RedBoard Pro Micro-ATX. Combining an ATmega32u4 microcontroller with standard desktop PC hardware is just as ridiculous as you’d hope, but surprisingly does offer a couple tangible benefits.

RedBoard PCB layout

The RedBoard is a fully compliant micro-ATX board, and will fit in pretty much any PC case you may have laying around in the junk pile. Everything from the stand-off placement to the alignment of the expansion card slots have been designed so it can drop right into the case of your choice.

That’s right, expansion slots. It’s not using PCI, but it does have a variation of the standard Arduino “shield” concept using 28 pin edge connectors. There’s a rear I/O panel with a USB port and ISP header, and you can even add water cooling if you really want (the board supports standard LGA 1151 socket cooling accessories).

While blowing an Arduino up to ATX size isn’t exactly practical, the RedBoard is not without legitimate advantages. Specifically, the vast amount of free space on the PCB allowed [Nick] to add 2Mbits of storage. There was even some consideration to making removable banks of “RAM” with EEPROM chips, but you’ve got to draw the line somewhere. The RedBoard also supports standard ATX power supplies, which will give you plenty of juice for add-on hardware that may be populating the expansion slots.

With as cheap and plentiful as the miniITX and microATX cases are, it’s no surprise people seem intent on cramming hardware into them. We’ve covered a number of attempts to drag other pieces of hardware kicking and screaming into that ubiquitous beige-box form factor.

Filed under: Arduino Hacks, computer hacks, Microcontrollers

  • 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