Automatic Naptime With BabyBjorn Bouncing Servo

Any parent with a baby and deep pockets– or friends with deep pockets– will probably sing the praises of the BabyBjorn rocking sling chair. A simple spring-loaded sling seat allows you to rock a child to sleep like magic– but you do have to rock the child. In the tradition of fathers everywhere since the stone age, [Ceyhun Karataş] saw that as something to tinker around, creating his Automatic BabyBjorn Bouncer/Rocker with a servo, an Arduino, and some 3D printed parts.

You still can’t leave your child unattended with this hack, [Ceyhun] takes pains to point out, but it will free a hand so you can keep junior happy while tinkering up other toys for him or her. Music players are a popular staple, for example.

You should have plenty of time for such projects, because it won’t take long for you to replicate [Ceyhun]’s invention– it’s only as complicated as it needs to be, which is not very. The servo, a Futaba S3003 which is mounted to the bottom of the rocker in a 3D printed case, reels the baby in with a string tied to the bouncing seat portion.  The BabyBjorn’s built-in spring bounces junior back up. As stated, Arduino Nano controls the servo, with two potentiometers in the build allowing you to control the speed and amplitude of the bounce independently to get the perfect naptime ratio. Everything you need to get started — aside from the hardware and the child– is available at the link above. You can see it in action in the video below, which in spite what you may fear from the Turkish thumbnail, does have authentic English audio, not AI auto-dubbing.

If you’ve got the baby but not the bouncy chair, have a gander at this mechatronic crib that does something similar on a much larger budget.

Thanks to [Ceyhun] for overcoming the new-parent sleep deprivation to document this project and send in a tip.

Continue reading “Automatic Naptime With BabyBjorn Bouncing Servo”

Uninvasive EEG Interface Could Be Used To Play Games

These days, most of us interface with our computing devices in the same old-fashioned ways—via keyboards, mice, and touchscreens. The idea of a more direct brain-to-machine interface remains appealing to many. [Ildar Rakhmatulin] and [Youssef El Abbass] have been working on just such a device, with an eye to using it for gaming.

The device is referred to as Octopus 16, so named because it combines sixteen EEG electrodes into a single compact package, along with the required common reference and ground. The contacts themselves are pogo pins, assembled into a coin-sized cluster. The device is strapped to the head, pushing the contacts against the scalp, and data from the electrodes is then siphoned off to a host machine via Bluetooth Low Energy. The EEG signals are picked up with a pair of Texas Instruments ADS131M08 ADCs, each with 8 channels, with a resolution of 24-bits to capture fine detail in whatever the brain is doing. An ESP32 microcontroller is responsible for grabbing the ADC output and trucking it out over Bluetooth.

The rig is designed for use with the PiEEG software platform. The team have experimented with the device, showing it off by using the EEG signals to detect an individual’s focus state and using that to feed into simple game environments.

Ultimately, what has been shown so far is not so different from the old Force Trainer toy, but the design might prove useful if you’re looking into doing EEG experiments on a budget. Just do your due diligence to make sure you’re getting more signal than noise out of those lovely 24-bit ADCs. Video after the break.

Continue reading “Uninvasive EEG Interface Could Be Used To Play Games”

Hackaday Podcast Episode 382: Glueballs, Borg Cubes, And Supersonic Trebuchets

It’s still hot on both sides of the Atlantic, but Kristina has a new secret weapon for staying cool without making noise. Will Elliot and the others follow suit? Time will tell.

In Hackaday news, well, there’s a lot of it. For starters, Supercon Ten tickets went on sale Thursday morning, but chances are good that by the time you read this, the early bird offering will be all pecked out. But, never fear! More tickets will be released soon enough.

Don’t want to buy a ticket, but still want to go? Submit a talk proposal that gets accepted, and you’ll be welcomed in free of charge. Lucky for you, we just extended the deadline by two weeks to August 26th.

After exhausting the news, Elliot reached into the ol’ Mailbag and found a funny anecdote from [Vik Olliver]. (Funny in that it’ll make you go ‘hmm’.) A brief discussion about imperial vs. metric ensued, but then it was on to the hacks.

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Download in lovely MP3.

Continue reading “Hackaday Podcast Episode 382: Glueballs, Borg Cubes, And Supersonic Trebuchets”

Snooping Flume Water Monitor Data On The Wire

[Stephen] had an interesting piece of hardware at home—namely, a Flume water monitor. It’s a smart device which reports usage data to Flume’s servers, and the water utility in turn. He’d previously determined how the device worked mechanically to monitor water flow, but he had a greater goal—figuring out how to sniff the reported data as it passed through his network on its way to Flume servers.

The Flume rig has a sensor installed in the water line, which communicates to a bridge device that then hooks up to the Internet. [Stephen] had an early win, figuring out how to trick the bridge unit of the Flume water sensor into sending data in plaintext. This was as simple as corrupting the public key in the device’s flash. However, this wasn’t a perfect solution—as the corrupt key stopped the device from authenticating with Flume’s servers. Further diving into the LibHydrogen encryption implementation, however, revealed that the device was apparently authenticating without using session keys, relying only on a static device secret key which can be harvested from the onboard flash. This allowed [Stephen] to build a tool to sit in between the bridge and the Flume servers, forwarding traffic seamlessly while decrypting and saving it locally at the same time.

With this setup, [Stephen] was able to locally log water flow and status data from the sensor. It does come with a caveat, that the man-in-the-middle setup could block the hardware from receiving firmware updates in future. It’s also worth checking out [Stephen’s] earlier work on demystifying the Flume hardware, too. The relay tool is available on GitHub for the curious.

We love seeing hackers figure out how to interface utility meters and similar devices, in legal and appropriate manners, of course. If you’re tinkering in this realm yourself, feel free to let us know on the tipsline!

This Week In Security: BugTraq, AI Hacks, And Being Dumb On Planes

After a multi-year hiatus, the venerable BugTraq mailing list is back!

For decades, BugTraq was the place where vulnerabilities were disclosed, from the early days when nearly all vendors viewed all security research as a hostile force, through to the modern era of working with vendors to coordinate disclosing bugs. With the rise of bug bounty programs and other social changes, the mailing list slowly died: what started in 1993 ended in 2021 is returning. The new maintainer, Jonathan Brossard, says in his announcement “The mission is unchanged: full disclosure, researcher-first, no corporate filter.”

Don’t Be Dumb on Planes

In the unlikely event anyone here needs to be told: Don’t do dumb things on planes.

It seems that someone coming home from from the DEF CON hacker conference in Las Vegas decided to mess with the in-plane WiFi, and is likely now in the “find out” phase of doing something dumb. There hasn’t been any public followup beyond the original reports: a passenger on a Delta flight leaving Las Vegas brought up a fake WiFi hotspot named “Delta WiFi FAST” to trick other passengers into connecting, and attempted to disable the in-flight WiFi using a denial of service attack.

Continue reading “This Week In Security: BugTraq, AI Hacks, And Being Dumb On Planes”

ShieldFont: Bludgeoning AI Scrapers That Disrespect Robots.txt

In the more innocent days of the World Wide Web you could simply put a robots.txt file in the root of your website that search engine indexing bots and similar would consult for the indexing wishes of the site owner. In this brave new world of LLM training data indexing such pleasantries are however rarely respected, leaving site owners to resort to increasingly more involved ways to bludgeon so-called AI scrapers, with ShieldFont being one of the most recent methods.

Its basic functioning is detailed in the white paper, explaining their use of ligatures. These are normally used to join multiple graphemes or letters into a single glyph which are rendered in the final text. By substituting about a quarter of the words in a text with such ligature-based versions in an intelligent, dictionary-based manner, the HTML version – as typically parsed by a scraper – will read as grammatically valid but nonsensical text, while the rendered font version will look normal.

Naturally, there are some disadvantages to this, such as screen readers for the visually impaired needing to also use the rendered font version, and it’s just as effective on legitimate search engine indexing bots. That said, if you apply this to static, archived content, or content marked as ‘do not follow’ in said robots.txt, then it might just be one way to make ChatGPT and friends spit out really funny output in the future now that the novelty of wood glue on pizza and eating rocks has somewhat worn off.

While LLM scrapers can adapt to this by also parsing the rendered text, this makes the scraping effort significantly more expensive. Together with maze traps like Nepenthes and Cloudflare’s offerings that seek to keep these scrapers busy scraping dynamically generated content through infinite linked pages, the tools available to combat the menace of these scrapers keep developing.

Mauchly And Eckert’s Other Computers

If you ask a random person who [John Mauchly] or [J. Presper Eckert] were, you’d probably get a blank stare. Ask a Hackaday reader, and you have a better shot. People who know will tell you that the two were behind the famous ENIAC, which may or may not have been the first computer, but was certainly influential in kicking off the modern computer era. They worked at Penn, and now [Holly Mengel] of Penn’s Kislak Center for Special Collections, Rare Books, and Manuscripts wants to introduce us to the other computers they worked on after ENIAC.

We will admit that we knew about EDVAC and UNIVAC. But we’ll also confess we didn’t know about BINAC or Skeduflo, a computer in a rather large suitcase. BINAC can claim to be the first digital computer that was commercialized, although you could argue that since it was fairly limited and, reportedly, never worked after it was delivered. Supposedly, the customer disassembled it, shipped it to a secure facility, and hired a freshly graduated engineer to rebuild it, which didn’t go very well.

We couldn’t find much about Skeduflo, other than that it was a 75-pound analog computer made for critical path method (CPM) analysis. You set up the problem with a patchboard and potentiometers, and the result came out on an analog plotter. Those details are from a PMI interview with [Morgan Walker] and [Jim Kelley].

It makes sense that these inventors didn’t just finish off ENIAC and retire to a tropical island. While UNIVAC had a good bit of success and EDVAC was very influential, the others are arguably fairly obscure. UNIVAC even has a Disney connection.