If you’ve ever tried to cut a piece of acrylic with a tool designed to cut wood or metal, you know that the plastic doesn’t cut in the same way that either of the other materials would. It melts at the cutting location, often gumming up the tool but always releasing a terrible smell that will encourage anyone who has tried this to get the proper plastic cutting tools instead of taking shortcuts. Other tools that heat up plastic also have this problem, as Gizmodo reported recently, and it turns out that the plastic particles aren’t just smelly, they’re toxic.
The report released recently focuses on 3D printers which heat plastic of some form or other in order to make it malleable and form to the specifications of the print. Similar to cutting plastic with the wrong tool, this releases vaporized plastic particles into the air which are incredibly small and can cause health issues when inhaled. They are too small to be seen, and can enter the bloodstream through the lungs. The study found 200 different compounds that were emitted by the printers, some of which are known to be harmful, including several carcinogens. The worst of the emissions seem to be released when the prints are first initiated, but they are continuously released throuhgout the print session as well.
Perhaps it’s not surprising that aerosolized plastic is harmful to breathe, but the sheer magnitude of particles detected in this study is worth taking note of. If you don’t already, it might be good to run your 3D printer in the garage or at least in a room that isn’t used as living space. If that’s not possible, you might want to look at other options to keep your work area safe.
Thanks to [Michael] for the tip!
In systems where there are multiple participants who need to interact with a shared resource some sort of concurrency protection is usually appropriate. The obvious technique is to use locking (and fun words like “mutex”) but this adds a constant performance hit as every participant needs to spend time interacting with the lock regardless of the number of other participants. It turns out this is actually a Big Problem that garners original research, but there are techniques that can yield great effect without a PhD. Years ago [Marc] posted a great walkthrough of one such method, exponential backoff with jitter, to Amazon’s AWS blog which is a great introduction to one such solution.
The blog post was written specifically to deal systems using a specific technique called optimistic concurrency control (OCC) but that doesn’t mean the advice isn’t generally applicable. OCC refers to a method where each writer checks for a write collision only after performing the write (but before committing it), which works well in scenarios where writes are relatively uncommon. [Marc] observed that even in systems where this is a safe assumption things bog down significantly when there are too many writers clamoring for attention all at once.
The traditional solution to such a problem is for each writer to pause for an exponentially increasing amount of time before trying again, but as writers come back in big groups the same problem can recur. He provides a discussion of simple modifications to that strategy which result in significantly reduced wait times for writers.
Problems like this are not especially relevant for single Arduino sensor networks, but even small groups of systems can have concurrency trouble and it’s nice to see such an accessible write up with solutions which are viable even for simple systems. Bonus points to [Marc] for posting source to his test tool online. It doesn’t require anything outside of your computer to run (no AWS required) so if you have any brainwaves about speeding up multi-writer environments it might make a nice test environment! Maybe don’t mention the blog post in your PhD applications though.
Speakers are one of those components that are simple to use, but difficult to simulate. Most of us have used a simple resistor to do the job. But a speaker’s response is much more complex, and while that might be enough for a simple simulation the fidelity is nowhere near close. [Sourav Gupta] recently shared his technique for modeling speakers and it looks as though it does a credible job.
[Sourav] shows how a simple resistor and an inductor can do the job, but for better fidelity you need more components to model some mechanical effects. The final model has six components which keeps it easy enough to construct but the problem lies in finding the values of those six components. [Sourav] shows how to use the Thiele-Small parameters to solve that problem. Speaker makers provide these as a guide to low frequency performance, and they capture things such as Q, mass, displacement, and other factors that affect the model.
If you can find those parameters — often known as TSP — then you can use the formulae provided to get the component values. There’s even a real-word example for a specific speaker. We would have been interested to see how the simulation stacked up to a real speaker, but this is still an interesting post.
Of course, if you grab a surplus speaker you may or may not be able to find the TSP data. At that point, you could make some guesses or measurements, but it certainly won’t be as easy.
The techniques in the post were not simulator-specific, so they ought to work with whatever tool you use. Our favorite browser simulator, Falsted, doesn’t have a speaker (but it does have an audio output port). The same tricks should work in LT Spice, too.
Have you ever wondered how many, for example, Commodore 64s it would take to equal the processing power in your current PC? This site might not really answer that, but it does show that your machine can easily duplicate all the old 8-bit computers from Commodore, Sinclair, Acorn, and others. By our count, there are 86 emulators on the page, although many of those are a host machine running a particular application such as Forth or Digger.
If you are in the US, you might not recognize all the references to the KC85, this was an East German computer based on a Z80 clone. Very few of these were apparently available for personal purchase, but they were very popular in schools and industry. These were made by Robotron, and there are some other Robotron models on the page, too.
If you aren’t interested in period games, there is still Forth, Basic, and even assembler for several of the machines. The emulation isn’t very snappy but probably is still faster than the real things. If you get stuck, it might pay to know that the Esc key is mapped to the break key.
Speaking of keyboards, the KC85 was notorious for having a very cheaply made “chiclet” keyboard. So using one with your full PC mechanical gaming keyboard feels like cheating. Of course, you don’t need a full PC to emulate an old computer. We’ve even seen the Commodore and the PC XT emulated on the ubiquitous ESP8266.
We have to admit that this retasked retro phone wins on style points alone. The fact that it’s filled with so much functionality is icing on the cake.
The way [SuperKris] describes his build sounds like a classic case of feature creep. Version 1 was to be a simple doorbell, but [SuperKris] would soon learn that one does not simply replace an existing bell with a phone and get results. He did some research and found that the ringer inside the bakelite beauty needs much more voltage than the standard doorbell transformer supplies, so he designed a little H-bridge circuit to drive the solenoids. A few rounds of “while I’m at it” later, the phone was stuffed with electronics, including an Arduino and an NFR24 radio module that lets it connect to Domoticz, a home automation system. The phone’s rotary dial can now control up to 10 events and respond to alarms and alerts with different ring patterns. And, oh yes – it’s a doorbell too.
In general, we prefer to see old equipment restored rather than gutted and filled with new electronics. But we can certainly get behind any effort to retask old phones with no real place in modern telecommunications. We’ve seen a few of these before, like this desk telephone that can make cell calls.
Posted in arduino nano, Bakelite, Domoticz, home automation, home hacks, NRF24, phone hacks, retro, ringer, solenoid, telephone
Why in the world does helium kill iPhones and other members of the Apple ecosystem? Enquiring minds want to know, and [Ben Krasnow] has obliged with an investigation of the culprit: the MEMS oscillator. (YouTube, embedded below.)
When we first heard about this, courtesy in part via a Hackaday post on MRI-killed iPhones, we couldn’t imagine how poisoning a micro-electromechanical system (MEMS) part could kill a phone. We’d always associated MEMS with accelerometers and gyros, important sensors in the smartphone suite, but hardly essential. It turns out there’s another MEMS component in many Apple products: an SiT 1532 oscillator, a tiny replacement for quartz crystal oscillators.
[Ben] got a few from DigiKey and put them through some tests in a DIY gas chamber. He found that a partial pressure of helium as low as 2 kPa, or just 2% of atmospheric pressure, can kill the oscillator. To understand why, and because [Ben] has a scanning electron microscope, he lapped down some spare MEMS oscillators to expose their intricate innards. His SEM images are stunning but perplexing, raising questions about how such things could be made which he also addresses.
The bottom line: helium poisons MEMS oscillators in low enough concentrations that the original MRI story is plausible. As a bonus, we now understand MEMS devices a bit better, and have one more reason never to own an iPhone.
The wildfires in California are now officially the largest the state has ever seen. Over 50,000 people have been displaced from their homes, hundreds are missing, and the cost in property damage will surely be measured in the billions of dollars when all is said and done. With a disaster of this scale just the immediate effects are difficult to conceptualize, to say nothing of the collateral damage.
While not suggesting their situation is comparable to those who’ve lost their homes or families, Electric Imp CEO [Hugo Fiennes] has recently made a post on their blog calling attention to the air quality issues they’re seeing at their offices in Los Altos. To quantify the problem so that employees with respiratory issues would know the conditions before they came into work, they quickly hacked together a method for displaying particulate counts in their Slack server.
The key to the system is one of the laser particle sensors that we’re starting to see more of thanks to a fairly recent price drop on the technology. A small fan pulls air to be tested into the device, where a very sensitive optical sensor detects the light reflected by particles as they pass through the laser beam. The device reports not only how many particles are passing through it, but how large they are. The version of the sensor [Hugo] links to in his blog post includes an adapter board to make it easier to connect to your favorite microcontroller, but we’ve previously seen DIY builds which accomplish the same goal.
[Hugo] then goes on to provide firmware for the Electric Imp board that reads the current particulate counts from the sensor and creates a simple web page that can be viewed from anywhere in the world to see real-time conditions at the office. From there, this data can be plugged into a Slack webhook which will provide an instantaneous air quality reading anytime a user types “air” into the channel.
We’ve covered a number of air quality sensors over the years, and it doesn’t look like they’re going to become any less prevalent as time goes on. If anything, we’re seeing a trend towards networks of distributed pollution sensors so that citizens can collect their own data on their air they’re breathing.
[Thanks to DillonMCU for the tip.]
[Mare] has a visual guide and simple instructions for making DIY mini helical 868 MHz antennas for LoRa applications. 868 MHz is a license-free band in Europe, and this method yields a perfectly serviceable antenna that’s useful where space is constrained.
A metric 5 mm drill bit makes a convenient core.
The process is simple and well-documented, but as usual with antenna design it requires attention to detail. Wire for the antenna is silver-plated copper, salvaged from the core of RG214U coaxial cable. After straightening, the wire is wound tightly around a 5 mm core. 7 turns are each carefully spaced 2 mm apart. After that, it’s just a matter of measuring and bending the end for soldering to the wireless device in question. [Mare] has used this method for wireless LoRa sensors in space-constrained designs, and it also has the benefit of lowering part costs since it can be made and tested in-house.
Antennas have of course been made from far stranger things than salvaged wire; one of our favorites is this Yagi antenna made from segments of measuring tape.
When it comes to guitar effects pedals, the industry looks both back and forward in time. Back to the 50’s and 60’s when vacuum tubes and germanium transistors started to define the sound of the modern guitar, and forward as the expense and rarity of parts from decades ago becomes too expensive, to digital reproductions and effects. Rarely does an effects company look back to the turn of the 19th century for its technological innovations, but Zvex Effects’ “Mad Scientist,” [Zachary Vex], did just that when he created the Candela Vibrophase.
At the heart of the Candela is the lowly tea light. Available for next to nothing in bags of a hundred at your local Scandinavian furniture store, the tea light powers the Zvex pedal in three ways: First, the light from the candle powers the circuit by way of solar cells, second, the heat from the candle powers a Stirling engine, a heat engine which powers a rotating disk. This disc has a pattern on it which, when rotated, modifies the amount of light that reaches the third part of the engine – photoelectric cells. These modulate the input signal to create the effects that give the pedal its name, vibrato and phase.
Controls on the engine adjust the amount of the each effect. At one end, the effect is full phasor, at the other, full vibrato. In between a blend of the two. A ball magnet on a pivot is used to control the speed of the rotating disk by slowing the Stirling engine’s flywheel as it is moved closer.
While more of a work of art than a practical guitar effect, if you happen to be part of a steam punk inspired band, this might be right up your alley. For more information on Stirling engines, take a look at this post. Also take a look at this horizontal Stirling engine.
When life hands you lemons, lemonade ends up being your drink of choice. When life hands you non-standard components, however, you’ve got little choice but to create your own standard to use them. Drinking lemonade in such a situation is left to your discretion.
The little audio record and playback modules [Fran Blanche] scored from eBay for a buck a piece are a good example. These widgets are chip-on-board devices that probably came from some toy manufacturer and can record and playback 20 seconds of audio with just a little external circuitry. [Fran] wants to record different clips on a bunch of these, and pictured using the card-edge connector provided to plug them the recording circuit. But the pad spacing didn’t fit any connector she could find, so she came up with her own. The module and a standard 0.1″ (2.54 mm) pitch header are both glued into a 3D-printed case, and the board is connected to the header by bonding wires. It makes a nice module that’s easily plugged in for recording, and as [Fran] points out, it’s pretty adorable to boot. Check it out in the video below.
Sure, the same thing could have been accomplished with a custom PCB breaking out the module’s pins to a standard card-edge connector. But [Fran] knows a thing or two about ordering PCBs, and our guess is she wanted to get this done with what was on hand rather than wait for weeks. There’s something to be said for semi-instant gratification, after all. And lemonade.