Cheating at 5V WS2812 Control to Use 3.3V Data

If you’re looking to control WS2812 (or Neopixel) LEDs using a microcontroller running at 3.3 volts, you might run into some issues. The datasheet tells us that a logic high input will be detected at a minimum voltage of 0.7 * Vcc. If you’re running the LED at 5V, this means 5 V * 0.7 = 3.5 V will be needed for the WS2812 to detect a ‘1’ on the data line. While you might get away with using 3.3 V, after all the specification in the data sheet is meant to be a worst case, it’s possible that you’ll run into reliability issues.

So usually we’d say “add a level shifter to convert 3.3V to 5V” and this post would be over. We even have a whole post on building level shifters which would work fine for this application. However [todbot] at CrashSpace came up with a nifty hack that requires fewer components yet ensures reliability.

bigbutton-front-backFor the Big Button project at CrashSpace, [todbot] used an ESP8266 running at 3.3 volts and WS2812 LEDs running at 5 V. To perform the level shift, a signal diode is placed in series with the power supply of the first LED. This drops the first LED to 4.3 V, which means a 4.3 V * 0.7 = 3.01 V signal can be used to control it. The logic out of this LED will be at 4.3 V, which is enough to power the rest of the LEDs running at 5 V.

This little hack means a single diode is all that’s needed to control 5 V LEDs with a 3.3 V microcontroller. The first LED might be a little less bright, since it’s operating at a lower voltage, but that’s a trade off [todbot] made to simplify this design. It’s a small part of a well-executed project so be sure to click-through and enjoy all the thought [todbot] put into a great build.

Autodesk Moves EAGLE to Subscription Only Pricing

EAGLE user? We hope you like subscription fees.

Autodesk has announced that EAGLE is now only available for purchase as a subscription. Previous, users purchased EAGLE once, and used the software indefinitely (often for years) before deciding to move to a new version with another one-time purchase. Now, they’ll be paying Autodesk on a monthly or yearly basis.

Lets break down the costs. Before Autodesk purchased EAGLE from CadSoft, a Standard license would run you $69, paid once. The next level up was Premium, at $820, paid once. The new pricing tiers from Autodesk are a bit different. Standard will cost $15/month or $100/year, and gives similar functionality to the old Premium level, but with only 2 signal layers. If you need more layers, or more than 160 cm^2 of board space, you’ll need the new Premium level, at $65/month or $500/year.

New Subscription Pricing Table for Eagle
New Pricing Table for EAGLE

This is a bad deal for the pocket book of many users. If you could have made do with the old Standard option, you’re now paying $100/year instead of the one-time $69 payment. If you need more space or layers, you’ll likely be up to $500/year. Autodesk also killed the lower cost options for non-commercial use, what used to be a $169 version that was positioned for hobbyists.

The free version still exists, but for anyone using Eagle for commercial purposes (from Tindie sellers to engineering firms) this is a big change. Even if you agree with the new pricing, a subscription model means you never actually own the software. This model will require licensing software that needs to phone home periodically and can be killed remotely. If you need to look back at a design a few years from now, you better hope that your subscription is valid, that Autodesk is still running the license server, and that you have an active internet connection.

On the flip side of the coin, we can assume that Eagle was sold partly because the existing pricing model wasn’t doing all it should. Autodesk is justifying these changes with a promise of more frequent updates and features which will be included in all subscriptions. But sadly, Autodesk couldn’t admit that the new pricing has downsides for users:

“We know it’s not easy paying a lump sum for software updates every few years. It can be hard on your budget, and you never know when you need to have funds ready for the next upgrade.”

In their press release, they claim the move is only good for customers. Their marketing speak even makes the cliche comparison to the price of a coffee every day. Seriously.

[Garrett Mace] summarized his view on this nicely on Twitter: “previously paid $1591.21 for 88 months == $18.08/mo. Moving to $65/mo? KICAD looks better.”

We agree [Garrett]. KiCad has been improving steadily in the past years, and now is definitely a good time for EAGLE users to consider it before signing on to the Autodesk Subscription Plan™.

Tracking Planes with an ESP8266

While there are apps that will display plane locations, [squix78] wanted to build a dedicated device for plane spotting. The ESP8266 PlaneSpotter Color is a standalone device that displays a live map with plane data on a color TFT screen. This device expands on his PlaneSpotter project, adding a color display and mapping functions.

First up, the device needs to know where planes are. The ADS-B data that is transmitted from planes contains useful data including altitude, velocity, position, and an identifier unique to the aircraft. While commercial services exist for getting this data, the PlaneSpotter uses ADS-B Exchange. You can set up a Raspberry Pi to record this data, and provide it to ADS-B Exchange.

With the plane data being received from the ADS-B Exchange API, it’s time to draw to the screen. The JPEGDecoder fork for ESP8266 is used for drawing images, which are fetched from the MapQuest API as JPEGs.

Finally, geolocation is needed to determine where in the world the PlaneSpotter is. Rather than adding a GPS module, [squix78] went with a cheap solution: WiFi geolocation. This uses identifying information and signal strengths from nearby WiFi access points to determine location. This project uses a public API by [Alexander Mylnikov], which returns a JSON object with longitude and latitude.

This project demonstrates what the ESP8266 is capable of, and brings together some neat techniques. If you’re looking to geolocate or display maps on an ESP8266, the code is available on Github.

Continue reading “Tracking Planes with an ESP8266”

PSA: Don’t Let Kids Eat Lithium Batteries

We get a lot of press releases at Hackaday, but this one was horrific enough that we thought it was worth sharing. Apparently, some kids are accidentally eating lithium coin cell batteries. When this happens with bigger cells, usually greater than 20 millimeters (CR2032, CR2025, and CR2016) really bad things happen. Like burning esophaguses, and even death.

The National Capital Poison Center has done some research on this, and found that 14% of batteries swallowed over the past two years came from flameless candles like the ones above. We know some of our readers also deal with batteries in open trays, which are apparently pretty dangerous for children.

The National Capital Poison Center’s website has an entire page dedicated to battery safety, which is probably worth a read if you deal with batteries and small children on a regular basis. Should an incident occur, there’s even a hotline to call for assistance.

So, please, don’t swallow batteries, or let children put them in their mouths. After the break, a Canadian PSA song about not putting things in your mouth.

Continue reading “PSA: Don’t Let Kids Eat Lithium Batteries”

Counting Laps and Testing Products with OpenCV

It’s been about a year and a half since the Batteroo, formally known as Batteriser, was announced as a crowdfunding project. The premise is a small sleeve that goes around AA and AAA batteries, boosting the voltage to extract more life out of them. [Dave Jones] at EEVblog was one of many people to question the product, which claimed to boost battery life by 800%.

Batteroo did manage to do something many crowdfunding projects can’t: deliver a product. Now that the sleeves are arriving to backers, people are starting to test them in the wild. In fact, there’s an entire thread of tests happening over on EEVblog.

One test being run is a battery powered train, running around a track until the battery dies completely. [Frank Buss] wanted to run this test, but didn’t want to manually count the laps the train made. He whipped up a script in Python and OpenCV to automate the counting.

The script measures laps by setting two zones on the track. When the train enters the first zone, the counter is armed. When it passes through the second zone, the lap is recorded. Each lap time is kept, ensuring good data for comparing the Batteroo against a normal battery.

The script gives a good example for people wanting to play with computer vision. The source is available on Github. As for the Batteroo, we’ll await further test results before passing judgement, but we’re not holding our breath. After all, the train ran half as long when using a Batteroo.

A DIY Vacuum Pickup Tool for $75

If you’re assembling prototypes of SMD boards on your own, placing the parts accurately can be a pain. Of course, it’d be nice to have a full pick and place machine, but those are rather expensive and time consuming to set up, especially for a small run of boards. Instead, a vacuum pickup tool can help you place the parts quickly and accurately by hand.

The folks over at Ohmnilabs have put together their own DIY pickup tool for about $75, and it’s become part of their in-house prototyping process. They grew tired of placing components with tweezers, which require you to remove parts from the tape before lifting them, and have a tendency to flip parts over at the worst time.

The build consists of a couple parts that can be bought from Amazon. An electric vacuum pump does the sucking, and the vacuum level is regulated with an adjustable buck converter. A solid foot switch keeps your hands free, and syringe tips are used to pick the parts up.

This looks like a simple afternoon build, but if you’re prototyping, it could save you tons of time. To see it in action, check out the video after the break.

Continue reading “A DIY Vacuum Pickup Tool for $75”

Give Your RPi a Cool FPGA Hat

Need additional, custom IO for your Raspberry Pi? Adding an FPGA is a logical way to expand your IO, and allow for high speed digital interfaces. [Eric Brombaugh]’s Icehat adds a Lattice iCE5LP4K-SG48 FPGA in a package that fits neatly on top of the Raspberry Pi Zero. It also provides a few LEDs and Digilent compatible PMOD connectors for adding peripherals. The FPGA costs about six bucks, so this is one cheap FPGA board.

The FPGA has one time programmable memory, but can also be programmed over SPI. This allows the host Pi to flash the FGPA with the latest bitstream at boot. Sadly, this particular device is not supported by the open source Icestorm toolchain. Instead, you’ll need Lattice’s iCEcube2 design software. Fortunately, this chip is supported by the free license.

Icehat is an open source hardware design, but also includes a software application for flashing a bitstream to the FPGA from the Pi and an example application to get you started. All the relevant sources can be found on Github, and the PCB is available on OSHPark.

While this isn’t the first pairing of a Raspberry Pi and FPGA we’ve seen, it is quite possibly the smallest, and can be built by hand at a low cost.