Tesla coils are beautiful examples of high voltage hardware, throwing sparks and teaching us about all kinds of fancy phenomena. They can also be quite intimidating to build. [William Fraser], however, has come up with a design using just three components.
It’s a simplified version of the “Slayer Exciter” design, which nominally features a transistor, resistor and LED, along with a coil, and runs on batteries. [William] learned that adding a capacitor in parallel with the batteries greatly improved performance, and allowed the removal of the LED without detriment. [William] also learned that the resistor was not necessary either, beyond starting the coil oscillating.
The actual 3-component build uses a 10 farad supercapacitor as a power source, hooked up to a 2N3904 NPN transistor and an 85-turn coil. It won’t start oscillating on its own, but when triggered by a pulse of energy from a piezo igniter, it jerks into life. The optimized design actually uses the shape of the assembled component leads to act as the primary coil. The tiny Tesla coil isn’t big and bold enough to throw big sparks, but it will light a fluorescent tube at close proximity.
If you like your Tesla coils musical, we have those too.
Continue reading “Build A Tesla Coil With Just Three Components”
These days Bluetooth-based gadgets are everywhere, including for car and solar batteries. After connecting them up to the battery, you download the accompanying app on your smartphone, open it up and like magic you can keep tabs on your precious pile of chemistry that keeps things ticking along. Yet as [haxrob] discovered during an analysis, many of these devices will happily pass your location and other information along to remote servers.
The device in question is a Bluetooth 4.0 Battery Monitor that is resold under many brands, and which by itself would seem to do just what it is said to do, from monitoring a battery to running crank tests. Where things get unpleasant is with the Battery Monitor 2 (BM2) mobile app that accompanies the device. It integrates a library called AMap which is “a leading provider of digital map in China” and part of Alibaba. Although the app’s information page claims that no personal information is collected, the data intercepted with Wireshark would beg to differ.
In part 2 of this series, the BM2 app is reverse-engineered, decompiling the Java code. The personal information includes the latitude and longitude, as well as GPS, cell phone tower cell IDs and WiFi beacon data, which understandably has people rather upset. In addition to leaking your personal info, the BM2 app seems to be also good at running constantly in the background, which ironically drains your phone’s battery at an alarming rate.
Cases like these should be both a warning to not just install any app on your smartphone, as well as a wake-up call to Google and others to prevent such blatant privacy violations.
(Thanks to [Drew] for the tip)
These days the dozen or so ECUs in an average car are joined by an infotainment system of some type, which are typically a large touch screen on the dashboard (the headunit) and possibly a couple of auxiliary units for the rear seats. These infotainment systems run anything from QNX to (Yocto) Linux or more commonly these days some version of Android. As [Eric McDonald] discovered with his 2021 Honda Civic, its headunit runs an archaic Android dating back to roughly 2012.
While this offers intriguing options with gaining root access via decade-old exploits that the car manufacturer never fixed, as [Eric] notes, this is an advantage that anyone who can gain access to the car’s CAN buses via e.g. the headlights, a wireless access point, or even inject an exploit via ADB radio can use to their advantage. Essentially, these infotainment systems are massive attack surfaces with all of their wired and wireless interfaces, combined with outdated software that you as the vehicle owner are forbidden to meddle with by the manufacturer.
Naturally taking this ‘no’ as a challenge as any civilized citizen would, [Eric] set out to not only root the glorified Android tablet that Honda seeks to pass off as a ‘modern infotainment system’, but also reverse-engineer the system as far as possible and documenting the findings on GitHub. As [Eric] also explains in a Hacker News discussion, his dream is to not only have documentation available for infotainment systems in general as a community effort, but also provide open source alternatives that can be inspected by security researchers rather than being expected to lean on the ‘trust me bro’ security practices of the average car manufacturer.
Although a big ask considering how secretive car manufacturers are, this would seem to be an issue that we should tackle sooner rather than later, as more and more older cars turn into driving security exploits just waiting to happen.
The ESPBoy was first built as a hackable open-source game engine and handheld console for educational purposes. However, it’s also a platform that can readily support all kinds of other uses. You can even turn the humble handheld device into a working walkie talkie.
The build relies on adding a SA868 transceiver module to the ESPBoy, along with a microphone, speaker, audio amplifier and antenna as supporting hardware. It then relies on the ESPBoy’s existing screen and buttons as a user interface for the radio. Assembled appropriately, it can then be used as a very basic and barebones walkie talkie for voice communication.
You won’t get coded squelch or other useful features, but it’s enough to let you talk over the air with other handheld radio users. The SA868 module can transmit on a variety of frequency bands, but the video shows it operating in the UHF band around 433 MHz. With a power on the order of 1.8W, it should get you a few kilometers of transmission range in an open field.
Check out our earlier coverage of the ESPBoy and its many different configurations. Video after the break.
Continue reading “ESPboy Turned Into Functional Walkie-Talkie”
Early on, railways primarily used wheels made of wood or iron. The former were cheap and relatively easy to manufacture, while the latter had far superior wear qualities. It may surprise you to learn, however, that some railways once used wheels made out of paper, as [Train of Thought] explains.
The wheels were pioneered by a man known as Richard N. Allen, in the 19th century. The wheels were constructed by layering up hundreds of sheets of paper with glue, compacting them with a press, and allowing them to cure for a few weeks. The solid paper disks were then machined to size, and were drilled to accept bolts that attached metal plates for protection. The wheels were given a cast-iron hub and a steel rim for wear reasons.
The benefit of the wheels was that their composite paper construction helped damp vibrations and noise from the wheels and rails. The North American Pullman railway ended up using the wheels for sleeper and dining carriages for the more luxurious ride they provided.
The paper wheels were short lived, however. While the wheels were up to the task when new, they would fail much sooner than solid metal wheels. A series of derailments led to the wheels being declared unsafe for use in the US by 1915.
The wheels serve as a good example of wheels and tires acting as a tuned part of a whole suspension system. Experimental wheel designs come and go, but there are reasons why we landed on certain designs for certain applications, after all. Video after the break.
Continue reading “Luxury Train Cars Used To Ride On Paper Wheels”
I had one of those experiences yesterday that seem so common these days: the arrival of a mystery Amazon package. You know the kind — you get a shipping notice from UPS with the faux-excited “Your package is arriving today!” message, but you’re sure you haven’t ordered anything in a while. You check your Amazon order history, find nothing pending, and puzzle over who could be sending you a package. What could it be? A gift from a secret admirer, perhaps?
And so it was with me as I waited for the UPS driver to make her rounds of our neighborhood and drop the package off on our front steps. Surprised at its size, I hurriedly brought it inside, zipped open the box, and pulled away the packing to reveal…
Continue reading “Podcast Feedback: Be Careful What You Ask For”
As auto manufacturers have brought self-driving features to their products, we’re told about how impressive their technologies are and just how much computing power is on board to make it happen. Thus it surprised us (and it might also surprise you too) that some level of self-driving can be performed by an Android phone. [Mankaran Singh] has the full details.
It starts with the realization that a modern smartphone contains the necessary sensors to perform basic self-driving, and then moves on to making a version of openpilot that can run on more than the few supported phones. It’s not the driver-less car of science fiction but one which performs what we think is SAE level 2 self driving, which is cruise control, lane centering, and collision warning. They take it out on the road in a little Suzuki on a busy Indian dual carriageway in the rain, and while we perhaps place more trust in meat-based driving, it does seem to perform fairly well
Self driving features are codified into a set of levels for an easy reference on what each is capable of doing. We’ve taken a look at it in the past, should you be interested.