When you think of microcontroller development, you probably picture either a breadboard with a chip or a USB-connected circuit board. But Tim Ansell pictured an ARM dev board that is almost completely hidden inside of a USB port. His talk at the 2018 Hackaday Superconference tells that story and then some. Check out the newly published video, along with more details of the talk, after the break.
Continue reading “How A Microcontroller Hiding In A USB Port Became An FPGA Hiding In The Same”
Classes are over at Cornell, and that means one thing: the students in [Bruce Land]’s microcontroller design course have submitted their final projects, many of which, like this flight control system for Google Earth’s flight simulator, find their way to the Hackaday tips line.
We actually got this tip several days ago, but since it revealed to us the previously unknown fact that Google Earth has a flight simulator mode, we’ve been somewhat distracted. Normally controlled by mouse and keyboard, [Sheila Balu] decided to give the sim a full set of flight controls to make it more realistic. The controls consist of a joystick with throttle, rudder pedals, and a small control panel with random switches. The whole thing is built of cardboard to keep costs down and to make the system easy to replicate. Interestingly, the joystick does not have the usual gimbals-mounted potentiometers to detect pitch and roll; rather, an IMU mounted on the top of the stick provides data on the stick position. All the controls talk to a PIC32, which sends the inputs over a serial cable to a Python script on the PC running Google Earth; the script simulates the mouse and keyboard commands needed to fly the sim. The video below shows [Sheila] taking an F-16 out for a spin, but despite being a pilot herself since age 16, she was curiously unable to land the fighter jet safely in a suburban neighborhood.
[Bruce]’s course looks like a blast, and [Sheila] clearly enjoyed it. We’re looking forward to the project dump, which last year included this billy-goat balancing Stewart platform, and a robotic ice cream topping applicator.
Continue reading “Microcontroller And IMU Team Up For Simple Flight Sim Controls”
[Paul Gallagher] has spent years separating his tasks into carefully measured out blocks, a method of time management known as the Pomodoro Technique. If that’s not enough proof that he’s considerably more organized and structured than the average hacker, you only need to take a look at this gorgeous Pomodoro Timer he’s entered into the Circuit Sculpture Contest. Just don’t be surprised if you suddenly feel like your own time management skills aren’t cutting it.
While [Paul] has traditionally just kept mental note of the hour-long blocks of time he breaks his work into, he thought it was about time he put together a dedicated timer to make sure he’s running on schedule. Of course he could have used a commercially available timer or an application on his phone, but he wanted to make something that was simple and didn’t cause any distractions. A timer that was easy to start, reliable, and didn’t do anything extraneous. We’re not sure if looking like the product of a more advanced civilization was part of his official list of goals, but he managed to achieve it in any event.
The timer is broken up into two principle parts: the lower section which has the controls, USB port, a handful of passive components, and an ATmega328 microcontroller, and the top section which makes up the three digit LED display. The two sections are connected by a header on the rear side which makes it easy for [Paul] to take the timer apart if he needs to get back into it for any reason. Notably absent in the design is a RTC; the relatively short duration of the timer (up to a maximum of 95 minutes) means the ATmega328 can be trusted to keep track of the elapsed time itself with an acceptable amount of drift.
The display side of the timer is really a sight to behold, with the legs of each LED soldered to a pair of carefully bent copper wires so they match the angle of the front panel. The associated resistors have been artfully snipped so that their bodies sit flat on the PCB while their leads reach out to the perfect length. It looks like a maintenance nightmare in there, but we love it anyway.
As we near the half-way mark of the Circuit Sculpture Contest, there’s still plenty of time to submit your own piece of functional art. If you’ve got a project that eschews the printed circuit board for a chance to bare it all, write it up on Hackaday.io and be sure to send it in before the January 8th, 2019 deadline.
Continue reading “A Perfectly Orderly Way To Manage Your Time”
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. Continue reading ““DB” = Abbreviated Microcontroller Debugging”
The Internet of Things is eating everything alive, and the world wants to know: how do you make a small, battery-powered, WiFi-enabled microcontroller device? This is a surprisingly difficult problem. WiFi is not optimized for low-power operations. It’s power-hungry, and there’s a lot of overhead. That said, there are microcontrollers out there with WiFi capability, but how do they hold up to running off of a battery for days, or weeks? That’s what [TvE] is exploring in a fantastic multi-part series of posts delving into low-power WiFi microcontrollers.
The idea for these experiments is set up in the first post in the series. Basically, the goal is to measure how long the ESP8266 and ESP32 will run on a battery, using various sleep modes. Both the ESP8266 and ESP32 have deep-sleep modes, a ‘sleep’ mode where the state is preserved, a ‘CPU only’ mode that turns the RF off, and various measures for sending and receiving a packet.
The takeaway from these experiments is that a battery-powered ESP8266 can’t be used for more than a week without a seriously beefy battery or a solar panel. Run times are much longer with an open network as compared to a secured network, and that security eats up a ton of power: connecting to a secure network every now and again means your ESP might only run for a day, instead of a week.
There is another option, though: the ESP32. While the ’32 is vastly more powerful and more capable than the ESP8266, it also has a few improved features that help with power consumption. Importantly, there’s a bug in the ESP8266 where it drops into modem sleep instead of light sleep about half the time. This error was fixed in the ESP32, but all that power does come at a cost. On the whole, if you’re concerned about security, the ESP32 is slightly better, simply because it does the ‘security’ part of connecting to a WiFi network faster. This is really a remarkable amount of testing that’s gone into this write-up, so if you’re developing something battery-powered with any ESP, it’s well worth the read.
Fruit can be a tricky thing: if you buy it ripe you’ll be racing against time to eat the pieces before they turn into a mushy mess, but if you buy the ones which are a bit before their prime it’s not always easy to tell when they’re ready to eat. Do you smell it? Squeeze it? Toss it on the counter to see if it bounces? In the end you forget about them and they go bad anyway. That’s why here at Hackaday we sustain ourselves with only collected rainwater and thermo-stabilized military rations.
But thankfully Cornell students [Christina Chang], [Michelle Feng], and [Russell Silva] have come up with a delightfully high-tech solution to this decidedly low-tech problem. Rather than rely on human senses to determine when a counter full of fruit has ripened, they propose an automated system which uses a motorized spectrometer to scan an arrangement of fruit. The device measures the fruit’s reflectance at 678 nm, which can be used to determine the surface concentration of chlorophyll-a; a prime indicator of ripeness.
If that sounds a bit above your pay grade, don’t worry. The students were able to build a functional prototype using a 1980’s era plotter, a Raspberry Pi, and a low-cost AS7263 NIR spectral sensor from SparkFun which just so happens to have a peak responsivity of 680 nm. The scanning is performed by a PIC32MX250F128B development board with an attached TFT LCD display so the results can be easily viewed. The Raspberry Pi is used in conjunction with a Adafruit PCA9685 I2C PWM driver to control the plotter’s stepper motors. The scanning and motor control could be done with the PIC32 alone, but to save time the students decided to use the Raspberry Pi to command the PCA9685 as that was what the documentation and software was readily available for.
To perform a scan, the stepper motors home the AS7263 sensor module, and then passes it under the fruit which is laying on a clear acrylic sheet. Moving the length of the acrylic sheet, the sensor is able to scan not only multiple pieces of fruit but the entirety of each piece; allowing it to determine for example if a section of a banana has already turned. The relative ripeness of the fruit is displayed to the user on the LCD display as a heatmap: the brighter the color the more ripe it is.
At the end of their paper, [Christina], [Michelle], and [Russell] note that while the scanner worked well there’s still room for improvement. A more scientific approach to calculating how ripe each fruit is would make the device more accurate and take out the guess work on the part of the end user, and issues with darker colored fruit could potentially be resolved with additional calibration.
While a spectrometer might sound like the kind of equipment that only exists in multi-million dollar research laboratories, we occasionally see projects like this which make the technology much more accessible. This year we saw a compact spectrometer in the Hackaday Prize, and going a bit farther back in time we even featured a roundup of some of the most impressive spectrometer builds on Hackaday.io.
Continue reading “Vintage Plotter Turned Fruit Spectrometer”
Communicating with microcontrollers and other embedded systems requires a communications standard. SPI is a great one, and is commonly used, but it’s not the only one available. There’s also I2C which has some advantages and disadvantages compared to SPI. The problem with both standards, however, is that modern computers don’t come with either built-in. To solve that problem and allow easier access to debugging in SPI, [James Bowman] built the SPIDriver a few months ago, and is now back by popular demand with a similar device for I2C, the I2CDriver.
Much like the SPIDriver, the I2C driver is a debugging tool that can be used at your computer with a USB interface. Working with I2C is often a hassle, with many things going on all at once that need to sync up just right in order to work at all, and this device allows the user to set up I2C devices in a fraction of the time. To start, it has a screen built in that shows information about the current device, like the signal lines and a graphical decoding of the current traffic. It also shows an address space map, and has programmable pullup resistors built in, and can send data about the I2C traffic back to its host PC for analysis.
The I2CDriver is also completely open source, from the hardware to the software, meaning you could build one from scratch if you have the will and the parts, or make changes to the code on your own to suit your specific needs. If you’re stuck using SPI still, though, you can still find the original SPIDriver tool to help you with your debugging needs with that protocol as well.
