Magnetic gears are surprisingly unknown and used only in a few niche applications. Yet, their popularity is on the rise, and they are one of the slickest solutions for transmitting mechanical energy, converting rotational torque and RPM. Sooner or later, you’re bound to stumble upon them somewhere, so let’s check them out to see what they are and what they are good for.
The ESP8266 is the reigning WiFi wonderchip, quickly securing its reputation as the go-to platform for an entire ecosystem of wireless devices. There’s nothing that beats the ESP8266 on a capability vs. price comparison, and this tiny chip is even finding its way into commercial products. It’s also a fantastic device for the hardware tinkerer, leading to thousands of homebrew projects revolving around this tiny magical device.
In every technical document, summary, and description of the ESP8266, the ESP8266 is said to be a 3.3V part. While we’re well into the age of 3.3V logic, there are still an incredible number of boards and hardware that still operate using 5V logic. Over on the Hackaday.io stack, [Radomir] is questioning this basic assumption. He’s wondering if the ESP8266 is 5V tolerant after all. If it is, great. We don’t need level converters, and interfacing the ESP to USB TTL serial adapters becomes much easier. Yes, you’ll still need to use a regulator if the rest of your project is running at 5V, but if the pins are 5V tolerant, interfacing the ESP8266 with a variety of hardware becomes very easy.
[Radomir]’s evidence for the possibility of 5V tolerant inputs comes from a slight difference in the official datasheet from Espressif, and the datasheet translated by the community before Espressif realized how many of these chips they were going to sell.
The best evidence of 5V tolerant pins might come from real-world experience — if you can drive a pin with 5V for months on end without it failing, there might be something to this claim. It’s not definitive, though; just because a device will work with 5V input pins for a few months doesn’t mean it won’t fail in the future. So far a few people have spoken up and presented ESPs directly connected to the 5V pin of an Arduino that still work after months of service. If this is evidence of 5V tolerant design or simply luck is another matter entirely.
While the official datasheet from Espressif lists a maximum VIH of 3.3V, maximum specs rarely are true maximums — you can always push a part harder without things flying apart at the seams. Unfortunately, unless we hear something from the engineers at Espressif, we won’t know if the ESP8266 was designed to be 5V tolerant, if it can handle 5V signals reliably, or if 5V signals are a really good way to kill a chip eventually.
Lucky for us — and this brings us to the entire point of an Ask Hackaday column — a few Espressif engineers read Hackaday. They’re welcome to pseudonymously chime in below along with the rest of the peanut gallery. Failing that, the ESP8266 has been decapped; are there any die inspection wizards who can back up a claim of 5V tolerance for the GPIO? We’d also be interested in hearing any ideas for stress testing pin tolerance.
If you’ve watched the tech news these last few months, you probably have noticed the rumors that Apple is expected to dump the headphone jack on the upcoming iPhone 7. They’re not alone either. On the Android side, Motorola has announced the Moto Z will not have a jack. Chinese manufacturer LeEco has introduced several new phones sans phone jack. So what does this mean for all of us?
This isn’t the first time a cell phone company has tried to design out the headphone jack. Anyone remember HTC’s extUSB, which was used on the Android G1? Nokia tried it with their POP Port. Sony Ericsson’s attempt was the FastPort. Samsung tried a dizzying array of multi-pin connectors. HP/Palm used a magnetic adapter on their Veer. Apple themselves tried to reinvent the headphone jack by recessing it in the original iPhone, breaking compatibility with most of the offerings on the market. All of these manufacturers eventually went with the tried and true ⅛” headphone jack. Many of these connectors were switched over during an odd time in history where Bluetooth was overtaking wired “hands-free kits”, and phones were gaining the ability to play mp3 files.
When you learn to solder, you are warned about the pitfalls of creating a solder joint. Too much solder, too little solder, cold joints, dry joints, failing to “wet” the joint properly, a plethora of terms are explained if you read one of the many online guides to soldering.
Unsurprisingly it can all seem rather daunting to a novice, especially if they are not used to the dexterity required to manipulate a tool on a very small-scale at a distance. And since the soldering iron likely to be in the hands of a beginner will not be one of the more accomplished models with fine temperature control and a good tip, it’s likely that they will experience most of those pitfalls early on in their soldering career.
As your soldering skills increase, you get the knack of making a good joint. Applying just the right amount of heat and supplying just enough solder becomes second nature, and though you still mess up from time to time you learn to spot your errors and how to rework and fix them. Your progression through the art becomes a series of plateaux, as you achieve each new task whose tiny size or complexity you previously thought rendered it impossible. Did you too recoil in horror before your first 0.1″ DIP IC, only to find it had been surprisingly easy once you’d completed it?
A few weeks ago we posted a Hackaday Fail of the Week, revolving around a soldering iron failure and confirmation bias leading to a lengthy reworking session when the real culprit was a missing set of jumpers. Mildly embarrassing and something over which a veil is best drawn, but its comments raised some interesting questions about bad solder joints. In the FoTW case I was worried I’d overheated the joints causing them to go bad, evaporating the flux and oxidising the solder. This was disputed by some commenters, but left me with some curiosity over bad solder joints. We all know roughly how solder joints go wrong, but how much of what we know is heresay? Perhaps it is time for a thorough investigation of what makes a good solder joint, and the best way to understand that would surely be to look at what makes a bad one.
If you’re a long-time Hackaday reader like we are, you’ll certainly remember a rash of projects from around ten years ago that all (mis-)used an LED as a light sensor. The idea wasn’t new, but somehow it made the rounds and insinuated itself into our collective minds. Around the same time, a cryptographic cipher with an exceptionally small memory footprint was also showing up in hacker projects: TEA (Tiny Encryption Algorithm).
This old project by [Marcin Bojanczyk], [Chris Danis], and [Brian Rogan] combines both the LED-as-light-sensor meme and TEA to make a door-entry keyfob that works over visible light. And they do so using almost nothing — a few LEDs and just over 2Kb of code. It’s pretty sweet.
Which brings us to the question: where are they (LED-sensors and TEA) now?
LED-as-light-sensor was just cool. We certainly loved the idea back in 2006. But [Forrest Mims] had been using the phenomenon for decades back then. It certainly makes sense when you’re trying to squeeze as much as possible out of as little as possible, or when budget is a main concern and you just can’t afford an extra photodiode.
But our own experience with LEDs as light sensors is that the results are extremely variable across different LEDs. Code that works with water-clear red LEDs might not work with the ones that come in red-tinted plastic, for instance. Is that why they went extinct?
Similarly, the TEA family of ciphers showed up in a bunch of projects around this time, from the badge for the HOPE conference in 2010 to a widely used RFM12B radio library. There are a couple of attacks on XXTEA, but they only affect reduced-round versions of the cipher, and rely on a tremendous amount of intercepted data — more than we’d see in a home-automation network over years.
Over the last five years or so, there’s been a lot more Internet of Things, which means using standard Internet-style encryption methods (AES and so on) that are widespread on non-memory-constrained computers. Is that what happened to XXTEA?
Anyway, we got tipped off to a project that combined a few of our favorite (old) ideas in one, so we thought that we’d share. Thanks [Blue Smoke] for the walk down memory lane. Any of you out there keeping the flame(s) alive? Have you used sensing LEDs or XXTEA? Are those projects still going, or do you have any future projects planned with these tricks still up your sleeve? Let us know in the comments below.
I could have sworn that we have asked this one before, but perhaps I’m thinking of our discussion of nuclear aircraft. In my mind the two share a similar fate: it just isn’t going to happen. But, that doesn’t mean flying cars can’t happen. Let me make my case, and then we want to know what you think.
[Steve] sent in a link to a Bloomberg article on Larry Page’s suspected investment in personal flying cars. It’s exciting to hear about test flights from a startup called Zee.Aero with 150 people on staff and a seemingly unlimited budget to develop such a fantastic toy. Surely
Bruce Wayne Mr. Page is onto something and tiny 2-person vehicles will be whizzing up and down the airspace above your street at any moment now? Realistically though, I don’t believe it. They definitely will build a small fleet of such vehicles and they will work. But you, my friend, will never own one.
Continue reading “Ask Hackaday: Where are the Flying Cars?”
With more and more previously industrial processes coming online in the home shop, people are finding that getting the information that was previously provided by the manufacturer of a hundred thousand dollar machine for their three hundred dollar Shenzen special is not easy.
A common example is this, a hacker purchased themselves a brand new 3D printer off amazon for a price too good to be true. After a week of tinkering with it, a small fire, and a few replacement parts later, they get it to work. After they’ve burned through, perhaps literally, the few hundred grams of filament that came with the printer at the setting recommended by the manufacturer, they do a small blanket order of the different filaments out there. Now comes the trouble, each printer is a little different and each filament has different properties. Most people find that the second spool of filament they feed into their printer doesn’t work at all. What’s the quickest way to get the right temperature, cooling, and feed settings for your printer configuration?
This isn’t a problem for the expensive machines. Epilog, a manufacturer of laser cutters, provides a grid of settings for each material you’re likely to cut, tuned to the different properties of each model of laser cutter they sell. Same goes for the expensive industrial 3D printers, each (very expensive) spool of material has the setting sitting in a chip in the casing. When the spool is slotted in the machine, it reads the settings and adjusts accordingly. All the work of tuning was done in a lab somewhere and the print is, theoretically, guaranteed.
While we were at the Bay Area Makerfaire 2016, we had a chance to talk to [Gauthier de Valensart] and buy him a beer at the Hackaday Meet-up. [Gauthier] is from Belgium where he is the founder of a start-up with one of those fancy new TLDs: filaments.directory. The goal of filaments.directory is to create a database of 3D printer materials and link that up with a user’s 3D printer settings. The eventual goal being, much like the industrial printers, a user would be able to simply scan a barcode, or wave the spool over an RFID reader to input the needed settings into his slicing software or printer.
This sounded familiar to me, not the least because I had started work on it as an extension for repables.com when that was a larger focus in my life. In fact, I remember, while I was kicking the idea around to people at MRRF, that they kept telling me someone else was working on a similar project. I wanted to introduce [Gauthier] to the person who was working on the project back then. Since I was at a bar full of people in the industry, I sort of helplessly rotated in my spot trying to find someone who might remember. I spied [whosawhatsis], a common attendee of MRRF, and asked him. Okay, that was easy, [whosawhatsis] informed us that is was his project… introduction complete. Goes to show you what a good networking event buying a bunch of nerds beer can be.
The project was called, “Universal Filament Identification System,” and it proposed to, “… eliminate the guess-work,” by, “…developing a method for tagging, tracking, and identifying filament for 3d printing in machine-readable formats…” The project appears to be mostly dead now and its domain is a placeholder. I think it suffered from the standard open source feature creep, but the idea is sound.
Which gets us to the questions. There are a lot of difficulties with creating such a system. The first being the data collection. Who should be responsible for measuring the filaments, the materials for laser cutting, or any other process that needs tuned settings? The ideal track, of course, would be for the manufacturers to hold themselves accountable and report on the settings for their filaments. However, many filament manufacturers rely on the ignorance of users to sell dodgy products, it’s only in the interest of a few top-quality ones to do so. If the users do so, then how will the information provided be vetted? You definitely don’t want someone’s ignorance about a faulty thermistor to encourage you to run PLA at 280C.
More and more difficulties arise. How should the information be transferred, etc. What properties should even be recorded? UFID was going as far as to use a color sensor to keep track of colors between batches from 3D printer manufacturers. In the end it’s about creating standards in a standard-less industry by using crowdsourcing. Either way, take a look at what [Gauthier]’s doing (and send him some feedback), read the backlogs of UFID, think about how annoying it was to get the right settings for a laser cutter the last time you used one, and let us know your thoughts in the comments.