The Crystal (Testing) Method

October 20, 2018 by 19 Comments

It used to be any good electronics experimenter had a bag full of crystals because you never knew what frequency you might need. These days, you are likely to have far fewer because you usually just need one reference frequency and derive all the other frequencies from it. But how can you test a crystal? As [Mousa] points out in a recent video, you can’t test it with a multimeter.

His approach is simple: Monitor a function generator with an oscilloscope, but put the crystal under test in series. Then you move the frequency along until you see the voltage on the oscilloscope peak. That frequency should match the crystal’s operating frequency.

Continue reading “The Crystal (Testing) Method” →

I2C Bootloader For ATtiny85 Lets Other Micros Push Firmware Updates

October 20, 2018 by 14 Comments

There are a few different ways of getting firmware onto one of AVR’s ATtiny85 microcontrollers, including bootloaders that allow for firmware to be updated without the need to plug the chip into a programmer. However, [casanovg] wasn’t satisfied with those so he sent us a tip letting us know he wrote an I2C bootloader for the ATtiny85 called Timonel. It takes into account a few particulars of the part, such as the fact that it lacks a protected memory area where a bootloader would normally reside, and it doesn’t have a native I2C interface, only the USI (Universal Serial Interface). He’s just released the first functional version for the ATtiny85, but there’s no reason it couldn’t be made to work with the ATtiny45 and ATtiny25 as well.

Timonel is designed for systems where there is a more powerful microcontroller or microprocessor running the show (such as an ESP8266, Arduino, or even a board like a Raspberry Pi.) In designs where the ATtinys are on an I2C bus performing peripheral functions such as running sensors, Timonel allows the firmware for these peripheral MCUs to be updated directly from the I2C bus master. Embedded below is a video demo of [casanovg] sending simple serial commands, showing a successful firmware update of an AVR ATtiny85 over I2C.

Continue reading “I2C Bootloader For ATtiny85 Lets Other Micros Push Firmware Updates” →

E-ink Typewriter Is Refreshingly Slow

October 20, 2018 by 31 Comments

It’s pretty hard to use the internet to complete a task without being frequently distracted. For better or worse, there are rabbit holes at every turn and whilst exploring them can be a delight, sometimes you just need to focus on a task at hand. The solution could be in the form of distraction-blocking software, razor-sharp willpower, or a beautifully crafted modern “typewriter”. The constraint and restriction of a traditional typewriter appealed to [NinjaTrappeur], but the inability to correct typos and share content online was a dealbreaker. A hybrid was the answer, with a mechanical keyboard commanding an E-ink display driven by a Raspberry Pi.

The main point of interest in this build is the E-ink screen. Though it’s easy to acquire theses displays in small sizes, obtaining a screen greater than four inches proved to be a challenge. Once acquired, driving the screen over SPI was easy, but the refresh rate was horrific. The display takes three seconds to redraw, and whilst [NinjaTrappeur] was hoping to implement a faster “partial refresh”, he was unable to read the appropriate values from the onboard flash to enable manual control of the drawing stages. Needless to say, [NinjaTrappeur] asks if people have had success driving these displays at a more usable rate, and would love to hear from you if so.

Some auxiliary hacks come in the form of terminal emulator adaptation, porting the E-ink screen library from C++ to C, and capturing the keyboard input. A handmade wooden case finishes it off.

If it’s old-school typewriters that float your boat, we’ve got you covered: this solenoid-actuated typewriter printer eventually became a musical instrument, and this daisy wheel machine produces ASCII art from a live camera.

[Via Boing Boing]

Hacking Nature’s Musicians

October 20, 2018 by 3 Comments

We just wrapped up the Musical Instrument Challenge in the Hackaday Prize, and for most projects that meant replicating sounds made by humans, or otherwise making musicians for humans. There’s more to music than just what can be made in a DAW, though; the world is surrounded by a soundscape, and you only need to take a walk in the country to hear it.

For her Hackaday Prize entry, [Kelly] is hacking nature’s musicians. She’s replicating the sounds of the rural countryside in transistors and PCBs. It’s an astonishing work of analog electronics, and it sounds awesome, too.

The most impressive board [Kelly] has been working on is the Mother Nature Board, a sort of natural electronic chorus of different animal circuits. It’s all completely random, based on a Really, Really Random Number Generator, and uses a collection of transistors and 555 timers to create pulses sent to a piezo. This circuit is very much sensitive to noise, and while building it [Kelly] found that not all of her 2N3904 transistors were the same; some of them worked for the noise generator, some didn’t. This is a tricky circuit to design, but the results are delightful.

So, can analog electronics sound like a forest full of crickets? Surprisingly, yes. This demonstration shows what’s possible with a few breadboards full of transistors, caps, resistors, and LEDs. It’s an electronic sculpture of the sounds inspired by the nocturnal soundscape of rural Virginia. You’ve got crickets, cicadas, katydids, frogs, birds, and all the other non-human musicians in the world. Beautiful.

The HackadayPrize2018 is Sponsored by:

Wired Wireless Over Coax

October 19, 2018 by 68 Comments

If it’s stupid and it works, then it’s not stupid. There’s no better evidence of that than [Manawyrm]’s networking setup.

She recently had to distribute Ethernet through a building, and there are a few ways to do that. You can use regular old twisted pair, or fiber, but in this case running new cables wasn’t possible. WiFi would be the next obvious choice, but the distance was just a bit too far for ‘regular’ WiFi links. Ethernet over power lines was an option, but there are amateur radio operators in the house, and power lines put out a bunch of interference and noise. The solution was to mis-use existing 75 Ohm satellite TV coax that was just sitting around.

The correct way to do this would be to use a standard DOCSIS modem and become your own cable Internet provider. The equipment to do this is expensive, and if you’re already considering running WiFI over coax, you’re too deep down the rabbit hole to spend real money. Instead, [Manawyrm] simply made a few u.FL to F-connector adapters from u.FL to SMA, then SMA to F-connector adapters.

There are some problems with this plan. WiFi is 50 Ohms, TV coax cable is 75 Ohms. Only one MIMO channel will be available meaning the maximum theoretical bandwidth will be 433 Mbps. WiFi is also at much higher frequencies than what coax is designed for.

With two WiFi antenna to coax adapters, [Manawyrm] simply connected the coax directly to a router set up to bridge Ethernet over WiFi. The entire thing worked, although testing showed it was only getting about 60 Mbps of throughput. That’s not bad for something that was cobbled together out of old parts and unused wiring. Is it surprising that this worked? No, not really, but you’ve probably never seen anyone actually do it. Here’s the proof it does work, and if you’re ever in a bind, this is how you make WiFi wired.

Which Wireless Is Right Wireless?

October 19, 2018 by 24 Comments

Back in the early days of Arduino proliferation (and before you ask, yes we realize there was a time before that too), wireless was a strange and foreign beast. IR communication was definitely a thing. And if you had the funds there was this cool technology called ZigBee that was available, often in funny blue house-shaped XBee boards. With even more funds and a stomach for AT commands you could even bolt on a 2G cell radio for unlimited range. WiFi existed too, but connecting it to a hobbyist ecosystem of boards was a little hairier (though maybe not for our readership).

But as cell phones pushed demand for low power wireless forward and the progression of what would become the Internet of marking Terms (the IoT, of course) began, a proliferation of options appeared for wireless communication. Earlier this week we came across a great primer on some of the major wireless technologies which was put together by Digikey earlier in the year. Let’s not bury the lede. This table is the crux of the piece:

There are some neat entries here that are a little less common (and our old friend, the oft-maligned and never market-penetrating ZigBee). It’s actually even missing some entries. Let’s break it down:

  • Extremely short range: Just NFC. Very useful for transferring small amount of sensitive information slowly, or things with high location-relevance (like between phones that are touching).
  • Short range: BLE, Zigbee, Z-Wave, etc. Handy for so-called Personal Area Networks and home-scale systems.
  • Medium/long range: Wifi, Bluetooth, Zigbee, Z-Wave, LoRaWAN: Sometimes stretching for a kilometer or more in open spaces. Useful for everything from emitting tweets to stitching together a mesh network across a forrest, as long as there are enough nodes. Some of these are also useful at shorter range.
  • Very Long range/rangeless: Sigfox, NB-IoT, LTE Category-0. Connect anywhere, usually with some sort of subscription for network access. Rangeless in the sense that range is so long you use infrastructure instead of hooking a radio up to a Raspberry Pi under your desk. Though LoRa can be a fun exception to that.

You’re unlikely to go from zero to custom wireless solution without getting down into the mud with the available dev boards for a few different common protocols, but which ones? The landscape has changed so rapidly over the years, it’s easy to get stuck in one comfortable technology and miss the appearance of the next big thing (like how LoRaWAN is becoming new cool kid these days). This guide is a good overview to help catch you up and help decide which dev kits are worth a further look. But of course we still want to hear from you below about your favorite wireless gems — past, present, and future — that didn’t make it into the list (we’re looking at you 433 MHz).

An Open Controller For Woodwind Instruments

October 19, 2018 by 6 Comments

Engineers, hackers, and makers can most certainly build a musical gadget of some kind. They’ll build synths, they’ll build aerophones, and they’ll take the idea of mercury delay line memory, two hydrophones, and a really long tube filled with water to build the most absurd delay in existence. One thing they can’t seem to do is build a woodwind MIDI controller. That’s where [J.M.] comes in. He’s created the Open Woodwind Project as an open and extensible interface that can play sax and clarinet while connected to a computer.

Early prototype to test out variable resistive pressure pads

If you want to play MIDI, there are plenty of options for keyboards, drum sets, matrix pads, and even strings. If you want to play a MIDI saxophone, there aren’t many options. Keytars, for example, are more popular than MIDI woodwind controllers. [J.M.] is changing this with a MIDI controller that recreates electronic aerophones electronically.

The controller itself uses a Teensy 3.2 loaded up with an ARM Cortex M4, two MPR121 touch controllers for 24 channels of capacititve touch capability, and a pressure sensor to tell the computer how strong the user is blowing. All of this works, and [J.M.] has a few videos showing off the capabilities of his homemade controller. It’s a great piece of work, and there are a few extentions that make this really interesting: there’s the possibility of adding CV out so it can be connected to modular synths, and the addition of accelerometers to the build makes for some very interesting effects.

Check out the video below.

Continue reading “An Open Controller For Woodwind Instruments” →