We love little tricks like this. Suppose that you want to generate an IR remote’s signal. It’s easy, because most of the codes are known. But it can be slightly harder because most IR remotes and receivers modulate the on pulses with a square wave at roughly 38 kHz for background lighting immunity.
With a competent PWM generator on a microcontroller, you can create this carrier modulation easily enough yourself. Set the PWM frequency to 38 kHz and the duty cycle somewhere in the 33%-50% range, and you’re set. But what if you don’t have a competent PWM generator? Such was the case that prompted [AnalysIR Blog] to fake it, with USART.
Here’s the trick. You set up the serial port to communicate at ten times the desired carrier frequency, and then transmit “special” data. (The number ten comes from eight bits of data plus a start and a stop bit.) If you want a 50% duty cycle, you simply send
0b11110000, as fast as the microcontroller will allow, for a mark and nothing for a space.
There’s some extra detail with inverting the signal if, as most do, your USART idles high. But that’s really it. It’s a cute trick for when you’re desperate enough to need it. And if you’d like to brush up some more on your asynchronous serial skills, check out our guide on troubleshooting USART, and the great comments that ensued.
It’s the easiest thing in the world — simple, straightforward serial data. It’s the fallback communication protocol for nearly every embedded system out there, and so it’s one that you really want to work when the chips are down. And yet! When you need it most, you may discover that even asynchronous serial can cost you a few hours of debugging time and add a few gray hairs to your scalp.
In this article, I’m going to cover most (all?) of the things that can go wrong with asynchronous serial protocols, and how to diagnose and debug this most useful of data transfer methods. The goal is to make you aware enough of what can go wrong that when it does, you’ll troubleshoot it systematically in a few minutes instead of wasting a few hours.
Continue reading “What Could Go Wrong: Asynchronous Serial Edition”
There’s a reason that the bog-standard serial port will never die. It’s just so robust and simple. When you need a console that will absolutely work with minimal software and hardware, UART is the way to go. Because of this, UART hacks abound. Here’s a new one to us, and a challenge to our readers.
[Tiziano Bacocco] decided to use UART signals as a type of PWM to create audio. That’s right, he’s plugging the serial TX line straight into a speaker. This gives you eight possible PWM output voltage levels. The trick is using some Python code (using the awesome pyserial module) to down-quantize the audio data to fit these eight possible values and then push them out at the correct sampling rate.
ffmpeg is used to pre-process the files.
Continue reading “Audio Out Over UART”
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.
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.
Continue reading “Monitor A Serial Port From Anywhere”
When it comes to electronic hobbyists and EEs, there is no company that deserves a few raised eyebrows than FTDI. They made their name with USB converter chips, namely USB to serial chips that are still very popular today. So popular, in fact, that clones of these chips are frequently found in the $2 Arduinos from China, and other very low-cost devices. A little more than a year ago, a few clever people noticed FTDI drivers were bricking these counterfeit chips by setting the USB PID to 0000. The Internet reacted to this move and FTDI quickly backed down from that position. The Windows driver was fixed, for about a year until the same shenanigans were found again.
Adafruit recently sat down with [Fred Dart], CEO of FTDI, giving us all the first facts and figures that aren’t from people frustrated with Windows’ automatically updated drivers. The most interesting information from [Fred Dart] is how FTDI first found these counterfeit chips, what FTDI chips are being counterfeited, and how many different companies are copying these chips.
The company first realized they were being cloned when they couldn’t reproduce results of a Chinese-made ‘FTDI’ USB to RS232 cable that behaved strangely. A sample of the cables were shipped to FTDI and after inspecting the chip inside, FTDI found it was a clone with a significantly different architecture than a genuine chip.
So far, the counterfeiters appear to only be counterfeiting the SSOP version of the FT232RL and occasionally the older FT232BL chip. From what FTDI has seen, there appears to be only one or two companies counterfeiting chips.
As the CEO of FTDI, [Fred] has a few insights into what can be done to stop counterfeiters in China. The most important is to trademark the logo. This isn’t just the logo for a webpage, but one that can be laser etched onto the plastic package of the chip. US Customs has been very amenable to identifying counterfeit components, and this has led to several shipments being destroyed. Legal action, however, is a bit hard in China, and FTDI is dealing with a gang that counterfeits more than FTDI chips; there’s a high likelihood this gang was responsible for the fake Prolific PL23o3 chips a few years ago.
As far as FTDI bricking counterfeit chips is concerned, [Fred Dart] wasn’t silent on the issue, he merely wasn’t asked the question and didn’t bring it up himself.
One of the most useful tools in the hardware hackers toolbox is a USB to serial adapter. With this, you can flash new firmware to routers, and ply the vast binary seas of embedded hardware. The common form of the USB to Serial adapter is an FTDI breakout board. This requires drivers, though, and there is actually a simpler – and wireless – solution: the ESP8266 WiFi module.
Despite being the best little IoT device on the block, the ESP8266 was originally designed to be a USB to WiFi adapter. In our haste to build WiFi throwies, WiFi blinkies, and freaking WiFi server farms, we seem to have forgotten that there’s still a use for a device that turns a 3.3V TTL into a WiFi connection. It’s the perfect device for reflashing a cheap WiFI router with new firmware, or just providing you with wireless serial connections to go along with your wireless Internet.
This project uses jeelabs’ ESP-link firmware for the ESP8266. It’s a simple bridge between WiFi and serial, and can function as an AVR programmer in a pinch. The web interface for this firmware is very nice, but you really don’t need it; the entire purpose of this firmware is to be even more transparent than an FTDI USB to serial adapter. For the next time you’re flashing a router with OpenWRT, don’t bother digging out the USB adapter; an ESP is all you need.
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.
Continue reading “Serial Data from the Web to an Arduino”