DIY Neuroscience Hack Chat

Join us on Wednesday, February 24 at noon Pacific for the DIY Neuroscience Hack Chat with Timothy Marzullo!

Watch a film about a mad scientist from the golden age of Hollywood and chances are good that among the other set pieces, you’ll see human brains floating in jars of cloudy fluid wired up to electrodes and fancy machines. It’s all made up, of course, but tropes work because they’re based on a kernel of truth, and we in the audience know that our brains and the other parts of our nervous system do indeed work on electricity. Or more precisely, excitable tissues in our nervous systems pass electrochemical signals between themselves as waves of potential across cell membranes.

Studying this electrical world locked away inside our heads is a challenging, but by no means impossible, pursuit. Usable signals can be picked up, amplified, digitized, and recorded to help us understand what’s going on when we think, feel, move, sleep, wake, or just be. Neuroscience has made tremendous strides looking at these signals, but the equipment to do so has largely remained the province of large universities and teaching hospitals with ample budgets, leaving the amateur neuroscientist out of luck.

Tim Marzullo, co-founder of Backyard Brains, is looking to change all that. While working on his Ph.D. in neuroscience at the University of Michigan, he and Greg Gage looked for ways to make the tools of neuroscience research affordable to everyone. The result is the Neuron SpikerBox, a low-cost bioamplifier that can tap into the “spikes” of action potential in live neurons. Open-source tools like these have helped educators bring neuroscience experiments to STEM students, and even helped other scientists set up novel, low-cost experiments.

Tim will join us on the Hack Chat to talk about doing DIY neuroscience and designing the instruments that make it possible. Bring your “mad scientist” questions as we push back the veil of ignorance on how our brains work, one neuron at a time.

join-hack-chatOur Hack Chats are live community events in the Hackaday.io Hack Chat group messaging. This week we’ll be sitting down on Wednesday, February 24 at 12:00 PM Pacific time (UTC-8). If time zones have you tied up, we have a handy time zone converter.

Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about.

 

Continue reading “DIY Neuroscience Hack Chat”

Hackaday Links Column Banner

Hackaday Links: February 21, 2021

Well, that was quite a show! The Perseverance rover arrived on Mars Thursday. Don’t tell the boss, but we spent the afternoon watching the coverage in the house on the big TV rather than slaving away in the office. It was worth it; for someone who grew up watching Jules Bergman and Frank Reynolds cover the Apollo program and the sometimes cheesy animations provided by NASA, the current coverage is pretty intense. A replay of the coverage is available – skip to about the 1:15:00 mark to avoid all the filler and fluff preceding the “Seven Minutes of Terror” main event. And not only did they safely deliver the package, but they absolutely nailed the landing. Perseverance is only about 2 km away from the ancient river delta it was sent to explore for signs of life. Nice shooting!

We’re also being treated to early images from Jezero crater. The first lowish-rez shots, from the fore and after hazard cameras, popped up just a few seconds after landing — the dust hadn’t even settled yet! Some wags complained about the image quality, apparently without thinking that the really good camera gear was stowed away and a couple of quick check images with engineering cameras would be a good idea while the rover still had contact with the Mars Reconnaissance Orbiter. Speaking of which, the HiRISE camera on the MRO managed to catch a stunning view of Perseverance’s descent under its parachute; the taking of that photo is an engineering feat all by itself. But all of this pales in comparison to a shot from one of the down-looking cameras in the descent stage, show Perseverance dangling from the skycrane just before touchdown. It was a really good day for engineering.

Would that our Earthly supply chains were as well-engineered as our Martian delivery systems. We’ve been hearing of issues all along the electronics supply chain, impacting a wide range of industries. Some of the problems are related to COVID-19, which has sickened workers staffing production and shipping lines. Some, though, like a fire at the AKM semiconductor plant in Japan, have introduced another pinch point in an already strained system. The fire was in October, but the impact on the manufacturer depending on the plant’s large-scale integration (LSI) and temperature-compensated crystal oscillators (TCXO) products is only just now being felt in the amateur radio market. The impact is likely not limited to that market, though — TCXOs pop up lots of gear, and the AKM plant made LSI chips for all kinds of applications.

What do you get when you combine a 3D-printer, a laser cutter, a CNC router, and a pick-and-place robot? Drones that fly right off the build plate, apparently. Aptly enough, it’s called LaserFactory, and it comes from MITs Computer Science and Artificial Intelligence Lab. By making different “bolt-on” tools for a laser cutter, the CSAIL team has combined multiple next-generation manufacturing methods in one platform. The video below shows a drone frame being laser-cut from acrylic, to which conductive silver paste is added by an extruder. A pick-and-place head puts components on the silver goo, solders everything together with a laser, and away it goes. They also show off ways of building up 3D structures, both by stacking up flat pieces of acrylic and by cutting and bending acrylic in situ. It’s obviously still just a proof of concept, but we really like the ideas presented here.

And finally, as proof that astronomers can both admit when they’re wrong and have fun while doing so, the most remote object in the Solar System has finally received a name. The object, a 400-km diameter object in a highly elliptical orbit that takes it from inside the orbit of Neptune to as far as 175 astronomical units (AU) from the Sun, is officially known as 2018 AG37. Having whimsically dubbed the previous furthest-known object “Farout,” astronomers kept with the theme and named its wayward sister “Farfarout.” Given the rapid gains in technology, chances are good that Farfarout won’t stay the Sun’s remotest outpost for long, and we fear the (Far)nout trend will eventually collapse under its own weight. We therefore modestly propose a more sensible naming scheme, perhaps something along the lines of “Farthest McFaraway.” It may not scale well, but at least it’s stupid.

It Ain’t Broke, But Should I Fix It?

Five years ago, I wrote a series on getting started with your own MQTT-based home information/automation network. Five years is a long while in Hackaday time. Back then, the ESP8266 was a lot newer, and the 8266 Arduino port wasn’t fully in shape yet, and the easiest software framework to get MQTT up and running was NodeMCU; so that’s what I used for the article series, and as a consequence a handful of devices around my house run minor modifications of that basic “hello world”, but doing useful stuff.

Since then, NodeMCU has changed a bunch of its libraries and the ESP32 has replaced the ESP8266 in my parts drawer. If you tried to run my code, you’d find that it won’t run on an ESP8266 without porting or compiling an old version of NodeMCU for yourself anyway, and it won’t run on an ESP32 at all. When [Chris Lott] tried to follow my guide, he discovered that Micropython is probably a better language choice in 2021. To minimize lines of code, I’d agree, although the Arduino and Espressif’s own native IDF have grown into the job just about as well. In short, anything but NodeMCU.

Built in an hour, survived for five years.

But my home automation system doesn’t care. Those little guys are running 24/7, flipping bits like it was still 2016. Thermometers, light sensors, and power meters haven’t changed much in five years, and although I’ve revamped the databasing, display, and user control a number of times since then, using a fixed communication transport protocol means that they’re still talking the same language. Indeed, even if NodeMCU is dead to me, the MQTT content of my original series is all still valid, and installing a broker on a Raspberry Pi has only become easier in the intervening five years.

So I’ve got a bunch of legacy code running within the walls of my own home, and it makes me nervous. If the devices fail, or maybe when they eventually fail, it’s not going to be “just flash another ESP8266 and replace it”, because even though I have some ancient NodeMCU binaries sitting around, I know when to throw in the towel. But there’s no good reason to pull them down and start reflashing either. Except that it makes me a little bit itchy, just knowing that there’s orphaned, dead-end code running all around me. Surrounding me. Staring deep into my hacker’s heart.

I know better than to tear down a running system, even though I could do it one device at a time, and each module would surely be a simple, independent fix; even though I’d love the excuse to play around with Micropython and its MQTT implementation on the ESP8266, or maybe even swap some of them out for ESP32s; even though these were all temporary quick hacks that have somehow served for five (5!) years. I certainly know better, right? (Right?)

Hackaday Podcast 106: Connector Kerfuffle, Tuning Fork Time, Spinach Contact Prints, And Tesla’s Permanent Memory

Hackaday editors Elliot Williams and Mike Szczys recount the coolest hacks from the past week. Most clocks keep time with a quartz crystal, but we discuss one that uses a tuning fork… like the kind you use to tune a piano. Ghidra is a powerful reverse engineering tool developed by the NSA that was recently put to good use changing an embedded thermometer display from Celsius to Fahrenheit. We talk turkey on the Texas power grid problems and Tesla’s eMMC failures. And of course there’s some room for nostalgia as we walk down memory lane with the BASIC programming language.

Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Direct download (~60 MB)

Places to follow Hackaday podcasts:

Continue reading “Hackaday Podcast 106: Connector Kerfuffle, Tuning Fork Time, Spinach Contact Prints, And Tesla’s Permanent Memory”

This Week In Security: ISNs, Patch Tuesday, And Clubhouse

Let’s talk TCP. Specifically, how do the different TCP connections stay distinct, and how is a third party kept from interrupting a connection? One of the mechanisms that help accomplish this feat is the TCP sequence number. Each of the two endpoints of a TCP connection tracks an incrementing 32-bit number, corresponding to the bytes sent in the connection. It’s handy, because each side can use that value to track what parts of the data stream they have received. On missing packets, a message can be sent requesting bytes 7-15 to be resent, for instance.

Each side of the connection sets their own Initial Sequence Number (ISN), and it’s important that this number is unique, as collisions can cause stream confusion. That statement should make your security spidey sense tingle. If a collision can cause problems when it happens by chance, what can a hacker do with it intentionally? Potentially quite a bit. Knowing the current sequence number, as well as a couple other pieces of information, a third party can close a TCP stream or even inject data. The attack has been around for years, originally known as the Mitnick Attack. It was originally possible because TCP implementations used a simple counter to set the ISN. Once the security ramifications of this approach were understood, the major implementations moved to a random number generation for their ISNs.

Now to this week’s story: researchers at Forescout took the time to check 11 TCP/IP stacks for vulnerability to the old Mitnick Attack (PDF Whitepaper). Of the eleven embedded stacks texted, nine have serious weaknesses in their ISN generation. Most of the vulnerable implementations use a system time value as their ISN, while several use a predictable pseudorandom algorithm that can be easily reversed.

CVEs have been assigned, and vendors notified of “NUMBER:JACK”, Forescout’s name for the research. Most of the vulnerable software already has patches available. The problem with embedded systems is that they often never get security updates. The vulnerable network stacks are in devices like IP cameras, printers, and other “invisible” software. Time will tell if this attack shows up as part of a future IoT botnet.
Continue reading “This Week In Security: ISNs, Patch Tuesday, And Clubhouse”

James West Began 40 Years At Bell Labs With World-Changing Microphone Tech

I’d be surprised if you weren’t sitting within fifty feet of one of James Edward Maceo West’s most well-known inventions — the electret microphone. Although MEMS microphones have seen a dramatic rise as smartphone technology progresses, electret microphones still sit atop the throne of low-cost and high-performance when it comes to capturing audio. What’s surprising about this world-changing invention is that the collaboration with co-inventor Gerhard Sessler began while James West was still at university, with the final version of the electret springing to life at Bell Labs just four years after his graduation.

A Hacker’s Upbringing

James’ approach to learning sounds very familiar: “If I had a screwdriver and a pair of pliers, anything that could be opened was in danger. I had this need to know what was inside.” He mentions a compulsive need to understand how things work, and an inability to move on until he has unlocked that knowledge. Born in 1931, an early brush with mains voltage started him on his journey.

Continue reading “James West Began 40 Years At Bell Labs With World-Changing Microphone Tech”

Minimal MQTT With Micropython

I have been meaning to play around with MQTT for some time now, and finally decided to take the plunge one evening last week. I had three cheap home temperature and humidity sensors, and was bothered that they often didn’t agree. Surprisingly, while the analog one had a calibration adjustment in the back, I have no idea how to calibrate the two digital ones. I took this as a sign that it was time to learn MQTT and be able to install my own, accurate sensors. Of course, I began by ordering the cheapest sensors I could find, but I can always upgrade later on.

Three Cheap Sensors

While we have written quite a bit about MQTT in Hackaday, I had to go all the way back to 2016 to find this introductory four-part series by Elliot Williams. Five years is a long time in the tech world, but I decided to give it a try anyway. Continue reading “Minimal MQTT With Micropython”