Posts | Comments

Planet Arduino

Archive for the ‘microcontrollers’ Category

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.

A few months ago we brought word that [Electronoobs] was working on his own open source alternative to pocket-sized temperature controlled soldering irons like the TS100. Powered by the ATMega328p microcontroller and utilizing a 3D printed enclosure, his version could be built for as little as $15 USD depending on where you sourced your parts from. But by his own admission, the design was held back by the quality of the $5 replacement soldering iron tips he designed it around. As the saying goes, you get what you pay for.

But [Electronoobs] is back with the second version of his DIY portable soldering iron, and this time it’s using the vastly superior HAKKO T12 style tip. As this tip has the thermocouple and heating element in series it involved a fairly extensive redesign of the entire project, but in the end it’s worth it. After all, a soldering iron is really only as good as its tip to begin with.

This version of the iron deletes the MAX6675 used in V1, and replaces it with a LM358 operational amplifier to read the thermocouple in the T12 tip. [Electronoobs] then used an external thermocouple to compare the LM358’s output to the actual temperature at the tip. With this data he created a function which will return tip temperature from the analog voltage.

While the physical and electrical elements of the tip changed substantially, a lot of the design is still the same from the first version. In addition to the ATMega328p microcontroller, version 2.0 of the iron still uses the same 128×32 I2C OLED display, MOSFET, and 5V buck converter from the original iron. That said, [Electronoobs] is already considering a third revision that will make the iron even smaller by replacing the MOSFET and buck converter. It might be best to consider this an intermediate step before the DIY iron takes on its final form, which we’re very interested in seeing.

The first version of the DIY Arduino soldering iron garnered quite a bit of attention, so it seems there’s a decent number of you out there who aren’t content with just plunking down the cash for the TS100.

[Thanks to BaldPower for the tip.]

When you show up at a party wearing this bare PCB watch, there are effectively two possible reactions you might receive from the other people there. Either they are going to snicker at the nerd who’s wearing a blinking circuit board on their wrist in public, or they are going to marvel at the ridiculously low part count. We’ll give you one guess as to which reaction you’d likely get at any event Hackaday is involved in.

Designed and built by [Electronoobs], this extremely simple watch consists of a ATmega328P microcontroller, a dozen LEDs with their associated 200 Ω resistors, and a battery. There’s also a single push button on the front which is used to not only set the watch, but turn the LEDs on when you want to check the time. Short of dropping down to one LED and blinking out the time, it’s hard to imagine a timepiece with fewer components than this.

You’re probably wondering how [Electronoobs] pulled this off without an external clock source for the ATmega328P chip. The chip actually has an internal 8 MHz oscillator that can be used, but you need to flash the appropriate bootloader to it first. Accordingly, the backside of the PCB has both SPI and a UART solder pads for external bootloader and firmware programming.

As you might expect, there’s a downside to using the internal oscillator: it’s not very good. The ATmega328P spec sheet claims a factory calibrated accuracy of ±10%, and [Electronoobs] has found that equates to a clock drift of around 15 seconds per day. Not exactly great, but considering the battery only lasts for two days anyway, it doesn’t have much of an impact in this case.

Compared to other “analog” LED watches we’ve seen, the simplicity of this build is really quite remarkable. The closest competitor we’ve seen so far is this slick binary watch.

I’ve always appreciated simulation tools. Sure, there’s no substitute for actually building a circuit but it sure is handy if you can fix a lot of easy problems before you start soldering and making PCBs. I’ve done quite a few posts on LTSpice and I’m also a big fan of the Falstad simulator in the browser. However, both of those don’t do a lot for you if a microcontroller is a major part of your design. I recently found an open source project called Simulide that has a few issues but does a credible job of mixed simulation. It allows you to simulate analog circuits, LCDs, stepper and servo motors and can include programmable PIC or AVR (including Arduino) processors in your simulation.

The software is available for Windows or Linux and the AVR/Arduino emulation is built in. For the PIC on Linux, you need an external software simulator that you can easily install. This is provided with the Windows version. You can see one of several videos available about an older release of the tool below. There is also a window that can compile your Arduino code and even debug it, although that almost always crashed for me after a few minutes of working. As you can see in the image above, though, it is capable of running some pretty serious Arduino code as long as you aren’t debugging.

Looks and sounds exciting, right? It is, but be sure to save often. Under Linux, it seems to crash pretty frequently even if you aren’t debugging. It also suffers from other minor issues like sometimes forgetting how to move components. Saving, closing the application, and reopening it seems to fix that. Plus, we assume they will squash bugs as they are reported. One of my major hangs was solved by removing the default (old) Arduino IDE and making sure the most recent was on the path. But the crashing was frequent and seemed more or less random. It seemed that I most often had crashes on Linux with occasional freezes but on Windows it would freeze but not totally crash.

Basic Operation

The basic operation is pretty much what you’d expect. The window is broadly divided into three panes. The leftmost pane shows, by default, a palette of components. You can use the vertical tab strip on the left to also pick a memory viewer, a property inspector, or a file explorer.

The central pane is where you can draw your circuit and it looks like a yellow piece of engineering paper with a grid. Along the top are file buttons that do things like save and load files.

You’ll see a similar row of buttons above the rightmost pane. This is a code editor and debugging window that can interface with the Arduino IDE. It looks like it can also interface with GCBasic for the PIC, although I didn’t try that.

You drag components from the left onto the circuit. Wiring isn’t a distinct operation. You just let the mouse float over the connection until the cursor makes a cross. Click and then drag to the connection point and click again. Sometimes the program forgets to make the cross cursor and then I’ve had to save and restart.

Most of the components are just what you think they are. There are some fun ones including a keypad, an LED matrix, text and graphic LCDs, and even stepper and servo motors. You’ll also find several logic functions, 7400-series ICs, and there are annotation tools like text and boxes at the very bottom. You can right click on a category and hide components you never want to see.

At the top, you can add a voltmeter, an ammeter, or an oscilloscope to your circuit. The oscilloscope isn’t that useful because it is small. What you really want to do is use a probe. This just shows the voltage at some point but you can right click on it and add the probe to the plotter which appears at the bottom of the screen. This is a much more useful scope option.

There are a few quirks with the components. The voltage source has a push button that defaults to off. You have to remember to turn it on or things won’t work well. The potentiometers were particularly frustrating. The videos of older versions show a nice little potentiometer knob and that appears on my Windows laptop, too. On Linux the potentiometer (and the oscilloscope controls) look like a little tiny joystick and it is very difficult to set a value. It is easier to right click and select properties and adjust the value there. Just note that the value won’t change until you leave the field.

Microcontroller Features

If that’s all there was to it, you’d be better off using any of a number of simulators that we’ve talked about before. But the big draw here is being able to plop a microcontroller down in your circuit. The system provides PIC and AVR CPUs that are supported by the simulator code it uses. There’s also four variants of Arduinos: the Uno, Nano, Duemilanove, and the Leonardo.

You can use the built-in Arduino IDE — just make sure you have the real Arduino software on your path and it is a recent version. Also, unlike the real IDE, it appears you must save your file before a download or debug will notice the changes. In other words, if you make a change and download, you’ll compile the code before the change if you didn’t save the file first. You don’t have to use the built-in IDE. You can simply right click on the processor and upload a hex file. Recent Arduino IDEs have an option to export a hex file, and that works with no problem.

When you have a CPU in your design, you can right click it and open a serial monitor port which shows virtual serial output at the bottom of the screen and lets you provide input.

The debugging mode is simple but works until it crashes. Even without debugging, there is an option to the left of the screen to watch memory locations and registers inside the CPU.

Overall, the Arduino simulation seemed to work quite well. Connecting to the Uno pins was a little challenging at certain scales and I accidentally wired to the wrong pin on more than one occasion. One thing I found odd is that you don’t need to wire the voltage to the Arduino. It is powered on even if you don’t connect it.

Besides the crashing, the other issue I had was with the simulation speed which was rather slow. There’s a meter at the top of the screen that shows how slow the simulation is compared to real-time and mine was very low (10% or so) most of the time. There is a help topic explaining that this depends if you have certain circuit elements and ways to improve the run time, but it wasn’t bad enough that I bothered to explore it.

My first thought was that it would be difficult to handle a circuit with multiple CPUs in it since the debugging and serial monitors are all set up for a single CPU. However, as the video below shows, you can run multiple instances of the program and connect them via a serial port connection. The only issue would be if you had a circuit where both CPUs were interfacing with interrelated circuitry (for example, an op amp summing two signals, one from each CPU).

A Simple Example

As an experiment, I created a simple circuit that uses an Uno. It generates two PWM signals, integrates them with an RC circuit and then either drives a load or drives a load through a bipolar emitter follower. A pot lets you set the PWM percentages which are compliments of each other (that is, when one is at 10% the other is at 90%). Here’s the circuit:

Along with the very simple code:

int v;

const int potpin=0;
const int led0=5;
const int led1=6;

void setup() {
Serial.begin(9600);
Serial.println("Here we go!");
}

void loop() {
int v=analogRead(potpin)/4;
Serial.println(v);
analogWrite(led0,v);
analogWrite(led1,255-v);
delay(250);
}

Note that if the PWM output driving the transistor drops below 0.7V or so, the transistor will shut off. I deliberately didn’t design around that because I wanted to see how the simulator would react. It correctly models this behavior.

There’s really no point to this other than I wanted something that would work out the analog circuit simulation as well as the Arduino. You can download all the files from GitHub, including the hex file if you want to skip the compile step.

If you use the built-in IDE on the right side of the screen, then things are very simple. You just download your code. If you build your own hex file, just right click on the Arduino and you’ll find an option to load a hex file. It appears to remember the hex file, so if you run a simulation again later, you don’t have to repeat that step unless you moved the hex file.

However, the IDE doesn’t remember settings for the plotter, the voltage switches, or the serial terminal. You’ll especially want to be sure the 5V power switch above the transistor is on or that part of the circuit won’t operate correctly. You can right click on the Arduino to open the serial monitor and right click on the probes to bring back the plotter pane.

The red power switch at the top of the window will start your simulation. The screenshots above show close-ups of the plot pane and serial monitor.

Lessons Learned

This could be a really great tool if it would not crash so much. In all fairness, that could have something to do with my PC, but I don’t think that fully accounts for all of them. However, the software is still in pretty early development, so perhaps it will get better. There are a lot of fit and finish problems, too. For example, on my large monitor, many of the fonts were too large for their containers, which isn’t all that unusual.

The user interface seemed a little clunky, especially when you had to manipulate potentiometers and switches. Also, remember you can’t right-click on the controls but must click on the underlying component. In other words, the pot looks like a knob on top of a resistor. Right clicks need to go on the resistor part, not the knob. I also was a little put off that you can’t enter multiplier suffixes directly in component values. That is, you can’t enter a resistor value as 1K. You can enter 1000 or you can enter 1 and then change the units in a separate field to Kohms. But that’s not a big deal. You can get used to all of that if it would quit crashing.

I really wanted the debugging feature to work. While you can debug directly with simuavr or other tools, you can’t easily simulate all your I/O devices like you can with this tool. I’m hoping that becomes more robust in the future. Under Linux it would work for a bit and crash. On Windows, I never got it to work.

As I always say, though, simulation is great, but the real world often leads to surprises that don’t show up in simulation. Still, a simulation can help you clear up a host of problems before you commit to heating up the soldering iron or pulling out the breadboard. Simuide has the potential to be a great tool for simulating the kind of designs we see most on Hackaday.

If you want to explore other simulation options, we’ve talked a lot about LTSpice, including our Circuit VR series. There’s also the excellent browser-based Falstad simulator.

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.



  • 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