Posts | Comments

Planet Arduino

Archive for the ‘serial’ Category

When you build one-off projects for yourself, if it doesn’t work right the first time, it’s a nuisance. You go back to the bench, rework it, and move on with life. The equation changes considerably when you’re building things to sell to someone. Once you take money for your thing, you have to support it, and anything that goes out the door busted is money out of your pocket.

[Brian Lough] ran into this fact of life recently when the widget he sells on Tindie became popular enough that he landed an order for 100 units. Not willing to cut corners on testing but also not interested in spending days on the task, he built this automated test jig to handle the job for him. The widget in question is the “Power BLough-R”, a USB pass-through device that strips the 5-volt from the line while letting the data come through; it’s useful for preventing 3D-printers from being backfed when connected to Octoprint. The tester is very much a tactical build, with a Nano in a breakout board wired to a couple of USB connectors. When the widget is connected to the tester, a complete series of checks make sure that there are no wiring errors, and the results are logged to the serial console. [Brian] now has complete confidence that each unit works before going out the door, and what’s more, the tester shaved almost a minute off each manual test. Check in out in action in the video below.

We’ve featured quite a few of [Brian]’s projects before. You may remember his Tetris-themed YouTube subscriber counter, or his seven-segment shoelace display.

[via r/Arduino]

A Raspberry Pi Zero (W) and Arduino are very different animals, the prior has processing power and connectivity while the latter has some analog to digital converters (ADCs) and nearly real-time reactions. You can connect them to one another with a USB cable and for many projects that will happily wed the two. Beyond that, we can interface this odd couple entirely through serial, SPI, I2C, and logic-level signaling. How? Through a device by [cburgess] that is being called an Arduino shield that supports a Pi0 (W). Maybe it is a cape which interfaces with Arduino. The distinction may be moot since each board has a familiar footprint and both of them are found here.

Depending on how they are set up and programmed, one can take control over the other, or they could happily do their own thing and just exchange a little information. This board is like a marriage counselor between a Raspberry Pi and an Arduino. It provides the level-shifting so they don’t blow each other up and libraries so they can speak nicely to one another. If you want to dig a bit deeper into this one, design files and code examples are on available.

Perhaps we’ll report on this board at the heart of a pinball machine retrofit, a vintage vending machine restoration, or maybe a working prop replica from the retro bar in Back to the Future II.

A Raspberry Pi Zero (W) and Arduino are very different animals, the prior has processing power and connectivity while the latter has some analog to digital converters (ADCs) and nearly real-time reactions. You can connect them to one another with a USB cable and for many projects that will happily wed the two. Beyond that, we can interface this odd couple entirely through serial, SPI, I2C, and logic-level signaling. How? Through a device by [cburgess] that is being called an Arduino shield that supports a Pi0 (W). Maybe it is a cape which interfaces with Arduino. The distinction may be moot since each board has a familiar footprint and both of them are found here.

Depending on how they are set up and programmed, one can take control over the other, or they could happily do their own thing and just exchange a little information. This board is like a marriage counselor between a Raspberry Pi and an Arduino. It provides the level-shifting so they don’t blow each other up and libraries so they can speak nicely to one another. If you want to dig a bit deeper into this one, design files and code examples are on available.

Perhaps we’ll report on this board at the heart of a pinball machine retrofit, a vintage vending machine restoration, or maybe a working prop replica from the retro bar in Back to the Future II.

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.

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’ve all been there: after assessing a problem and thinking about a solution, we immediately rush to pursue the first that comes to mind, only to later find that there was a vastly simpler alternative. Thankfully, developing an obscure solution, though sometimes frustrating at the time, does tend to make a good Hackaday post. This time it was [David Wehr] and AudioSerial: a simple way of outputting raw serial data over the audio port of an Android phone. Though [David] could have easily used USB OTG for this project, many microcontrollers don’t have the USB-to-TTL capabilities of his Arduino – so this wasn’t entirely in vain.

At first, it seemed like a simple task: any respectable phone’s DAC should have a sample rate of at least 44.1kHz. [David] used Oboe, a high performance C++ library for Android audio apps, to create the required waveform. The 8-bit data chunks he sent can only make up 256 unique messages, so he pre-generated them. However, the DAC tried to be clever and do some interpolation with the signal – great for audio, not so much for digital waveforms. You can see the warped signal in blue compared to what it should be in orange. To fix this, an op-amp comparator was used to clean up the signal, as well as boosting it to the required voltage.

Prefer your Arduino connections wireless? Check out this smartphone-controlled periodic table of elements, or this wireless robotic hand.

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?

A tachometer used to be an accessory added to the dash of only the sportiest of cars, but now they’re pretty much standard equipment on everything from sleek coupes to the family truckster. If your daily driver was born without a tach, fear not – a simple Arduino tachometer is well within your reach.

The tach-less vehicle in question is [deepsyx]’s Opel Astra, which from the video below seems to have the pep and manual transmission that would make a tach especially useful. Eschewing the traditional analog meter display or even a digital readout, [deepsyx] opted to indicate shift points with four LEDs mounted to a scrap of old credit card. The first LED lights at 4000 RPM, with subsequent LEDs coming on at each 500 RPM increase beyond that. At 5800 RPM, all the LEDs blink as a redline warning.  [Deepsyx] even provides a serial output of the smoothed RPM value, so logging of RPM data is a possible future enhancement.

The project is sensing engine speed using the coil trigger signal – a signal sent from the Engine Control Unit (ECU) which tells one of the ignition coilpacks to fire. The high voltage signal from the coilpack passes on to the spark plug, which ignites the air-fuel mixture in that cylinder. This is a good way to determine engine RPM without mechanical modifications to the car. Just make sure you modify the code for the correct number of cylinders in your vehicle.

Simple, cheap, effective – even if it is more of a shift point indicator than true tachometer, it gets the job done. But if you’re looking for a more traditional display and have a more recent vintage car, this sweeping LED tachometer might suit you more.

[via r/Arduino]


Filed under: Arduino Hacks, transportation hacks

This simple WiFi serial port monitor would have saved us a lot of trouble. We can’t count how many times where being hooked into an Arduino with USB just to get the serial out has nearly been more trouble than it’s worth. Times where we sat cross-legged on the floor and could choose comfort or accidentally shifting the set-up and ruining everything, but not both.

[Frenky]’s set-up is simple and clever. The Ardunio’s serial out is hooked to an ESP8266. The Arduino spams serial out to the ESP8266 in its usual way. The ESP8266 then pipes all that out to a simple JavaScript webpage. Connect to the ESP8266’s IP with any device in your house, and get a live stream of all the serial data. Neat.

As simple as this technique is, we can see ourselves making a neat little box with TX, RX, GND, and VCC screw terminals to free us from the nightmare of tethering on concrete floors just for a simple test. Video after the break.


Filed under: Arduino Hacks, wireless hacks

In the old days, a serial port often connected to an acoustic coupler that gripped a phone handset and allowed a remote connection to a far away serial port (via another phone and acoustic coupler) at a blistering 300 baud or less. The acoustic coupler would do the job of converting serial data to audio and reconstituting it after its trip through the phone lines. Modems advanced, but have mostly given way to DSL, Cable, Fiber, and other high speed networking options.

In a decidedly retro move, [James Halliday] and [jerky] put a modern spin on that old idea. They used the webaudio API to send serial data to a remote Arduino. The hack uses a FET, a capacitor, and a few resistors. They didn’t quite build a real modem with the audio. Instead, they basically spoof the audio port into sending serial data and recover it with the external circuitry. They also only implement serial sending (so the Arduino receives) so far, although they mention the next step would be to build the other side of the connection.

They say the data transmission is finicky, but it works (see the video below). We imagine using proper modem tones and decoders might work better, but would be a lot more effort. We’ve covered a 1200 baud modem before. We’ve also covered a bit of the theory behind them.


Filed under: Arduino Hacks, Network Hacks


  • 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