How To Make An Electric Scooter Chain Sprocket With Nothing But Hand Tools

October 21, 2019 by Lewin Day 33 Comments

Sometimes, mechanical parts can be supremely expensive, or totally unavailable. In those cases, there’s just one option — make it yourself. It was this very situation in which I found myself. My electric scooter had been ever so slightly bested by a faster competitor, and I needed redemption. A gearing change would do the trick, but alas, the chain sprocket I needed simply did not exist from the usual online classifieds.

Thus, I grabbed the only tools I had, busied myself with my task. This is a build that should be replicable by anyone comfortable using a printer, power drill, and rotary tool. Let’s get to work!

Continue reading “How To Make An Electric Scooter Chain Sprocket With Nothing But Hand Tools” →

Open Hardware Month Hack Chat

October 21, 2019 by Dan Maloney No comments

Join us on Wednesday, October 23 at noon Pacific for the Open Hardware Month Hack Chat with Michael Weinberg!

It seems like everything and everyone has a special day set aside on the calendar. You know the drill – a headline declaring it National Grilled Cheese Day (sorry, you missed it – April 12) or National Bundt Pan Day (not even kidding, November 15). It seems only fair with all these silly recognition days floating around that we in the hacking community should have a day of our own, too, or even a whole month. That’s why the Open Source Hardware Association declared the entire month of October to be Open Hardware Month.

Open hardware is all about accessible, collaborative processes that let everyone see and understand the hardware they’re using. The technological underpinnings of our lives are increasingly hidden from us, locked away as corporate secrets. Open hardware tries to turn that on its head and open up devices to everyone, giving them the freedom to not only use their devices but to truly understand what’s happening in them, and perhaps repair, extend, and even modify them to do something new and useful. Celebrating that and getting the message out to the general public is certainly something worth doing.

Michael Weinberg is a board member at OSHWA, and he’ll be joining the Hack Chat on October 23 (National Boston Cream Pie Day) to discuss Open Hardware Month and open-source hardware in general. We’ll learn about some of the events planned for Open Hardware Month, how open hardware is perceived beyond the hacker community, and what’s on tap for the 10th anniversary Open Hardware Summit in 2020.

Our Hack Chats are live community events in the Hackaday.io Hack Chat group messaging. This week we’ll be sitting down on Wednesday, October 23 at 12:00 PM Pacific time. If time zones have got you down, 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.

A Drone Sprouts Wings

October 21, 2019 by Bryan Cockfield 5 Comments

While there are some fixed-wing drones in the hobby world, most of us around here think of the quadcopter when this word is mentioned. There have been some fixed-wings around, and lots of multi-rotors, but not much of a mix of the two. [Paweł] wanted to see what would happen if he mixed these two together, and created a quadcopter drone with retractable wings, essentially just to see what would happen.

This isn’t something that can convert from fixed-wing flight to helicopter-style hovering like a V22 Osprey or Harrier, either. The lift and thrust is entirely generated by the rotors, and the “wings” are essentially deployable air brakes that allow the drone to slow down quickly without consuming as much energy under propeller power alone. The air brake wings are designed to automatically deploy as a function of throttle position, too, so there’s a lot that could be built on this idea in the future, in theory.

[Paweł] notes that this design is somewhat controversial, and although few of us are in the drone racing community we can imagine how a functional change like this might impact in an arena such as that. He also only saw marginal performance increases and isn’t planning on perusing this idea much further. If you’re interested in a drone with “true” wings, though, check out this one which gets fired out of a grenade launcher.

Continue reading “A Drone Sprouts Wings” →

DNS-over-HTTPS Is The Wrong Partial Solution

October 21, 2019 by Maya Posch 51 Comments

Openness has been one of the defining characteristics of the Internet for as long as it has existed, with much of the traffic today still passed without any form of encryption. Most requests for HTML pages and associated content are in plain text, and the responses are returned in the same way, even though HTTPS has been around since 1994.

But sometimes there’s a need for security and/or privacy. While the encryption of internet traffic has become more widespread for online banking, shopping, the privacy-preserving aspect of many internet protocols hasn’t kept pace. In particular, when you look up a website’s IP address by hostname, the DNS request is almost always transmitted in plain text, allowing all the computers and ISPs along the way to determine what website you were browsing, even if you use HTTPS once the connection is made.

The idea of also encrypting DNS requests isn’t exactly new, with the first attempts starting in the early 2000s, in the form of DNSCrypt, DNS over TLS (DoT), and others. Mozilla, Google, and a few other large internet companies are pushing a new method to encrypt DNS requests: DNS over HTTPS (DoH).

DoH not only encrypts the DNS request, but it also serves it to a “normal” web server rather than a DNS server, making the DNS request traffic essentially indistinguishable from normal HTTPS. This is a double-edged sword. While it protects the DNS request itself, just as DNSCrypt or DoT do, it also makes it impossible for the folks in charge of security at large firms to monitor DNS spoofing and it moves the responsibility for a critical networking function from the operating system into an application. It also doesn’t do anything to hide the IP address of the website that you just looked up — you still go to visit it, after all.

And in comparison to DoT, DoH centralizes information about your browsing in a few companies: at the moment Cloudflare, who says they will throw your data away within 24 hours, and Google, who seems intent on retaining and monetizing every detail about everything you’ve ever thought about doing.

DNS and privacy are important topics, so we’re going to dig into the details here. Continue reading “DNS-over-HTTPS Is The Wrong Partial Solution” →

The Arduino IDE Finally Grows Up

October 21, 2019 by Al Williams 105 Comments

While the Arduino has a very vocal fan club, there are always a few people less than thrilled with the ubiquitous ecosystem. While fans may just dismiss it as sour grapes, there are a few legitimate complaints you can fairly level at the stock setup. To address at least some of those concerns, Arduino is rolling out the Arduino Pro IDE and while it doesn’t completely address every shortcoming, it is worth a look and may grow to quiet down some of the other criticisms, given time.

For the record, we think the most meaningful critiques fall into three categories: 1) the primitive development environment, 2) the convoluted build system, and 3) the lack of debugging. Of course, there are third party answers for all of these problems, but now the Pro IDE at least answers the first one. As far as we can tell, the IDE hides the build process just like the original IDE. Debugging, though, will have to wait for a later build.

Continue reading “The Arduino IDE Finally Grows Up” →

How A Secret Gaming Scene Emerged In Communist East Germany

October 21, 2019 by Sharon Lin 23 Comments

During the late 1980s, a gaming scene emerged in East Germany just before the fall of communism. Teenagers gathered in buildings like the “House of Young Talents” (HdjT), originally Palais Podewils, to watch and play Commodore 64 games. There were 20 similar clubs in Berlin alone, sometimes with more than 70 people crowded into a single room. Above all, the computers they were in possession of were all made in the West.

At a point in time when loyalties were frequently questioned, the club of self-proclaimed “freaks” soon attracted the attention of the Stasi, GDR (East Germany) intelligence agents who kept close tabs on the group. As one Stasi agent warned:

Given that there are also members within the interest groups or computer clubs with a verifiably negative attitude toward the socialist state and social order, there is a potential danger that the interest groups or computer clubs will go in a negative direction.

Domestically produced computers – the KC 85 from VEB Mikroelektronik Wilhelm Pieck Mühlhausen and the KC 87 from VEB Robotron – did not have the quality of C128 and C64s from Commodore. Surprisingly, even while microelectronics remained on the list of embargoed products imported to East Germany, C64s managed to make their way into the state. The GDR customs officials didn’t have any problem with Western imported hardware – what they were worried about was the software.

By the end of the 80s, modern data traffic over telephone lines had arrived in East Germany, causing fear that software would soon be disseminated without the need of a physical medium. For the gamers of GDR, however, many didn’t even have access to a phone line. They just wanted to go to computer clubs to swap software. Since computer games from the West were only available in government-run Intershop stores and not in normal shops, teenagers had to rely on the computer clubs to access these games. Games like Frogger and Rambo would be copied to cheaper cassette tapes – it wouldn’t even be violating the ~~saw~~ law since software was not protected by copyright within the country.

A few politically charged games – “Raid Over Moscow” and “Kremlin” – were forbidden to ensure that the HdjT wouldn’t be shut down. Towards the end of the GDR, the Stasi desperately tried to gain control of games “relating to the increasing activities of the political opponent”, but by this point the political situation was already heading towards the fall of the Wall. [Stefan Paubel], founder of the HdjT reflected that he was disappointed the Stasi didn’t try harder to report on the computer clubs.

They had everything critical in the reports: Swapping software, a complete list of all the games glorifying war and computers from the West.

It appeared that microelectronics were sacred to the GDR, since officials were trying to get more young people to engage with computers. The regime’s concern for their reputation led them to prioritize other forms of surveillance than technology. For a while after the fall of the Berlin Wall, the computer club continued to exist. It wasn’t until August 1990, two months before reunification, that the remaining members decided to dissolve the club.

[Thanks to Frank for the tip!]

Finding USB Bugs The Hard Way

October 20, 2019 by Sharon Lin 17 Comments

Sometimes debugging just doesn’t go the way you want it to. When USB problems arise, you can usually use a protocol analyzer to find the issue causing trouble. For [Paul Stoffregen], it was only the first step in a long process to find the culprit.

Procotol Analyzer

The complaint that came up was from a customer whose 2 port USB hub wasn’t working on their Teensy 3.6. The hub had been tested on Linux, Mac, and Windows, so it made sense to test what was different about the Teensy. Furthermore, all other USB hubs worked on the Teensy. As it turns out, these weren’t the most helpful assumptions to make when finding the bug.

Any protocol analyzer can be used, for instance the Beagle480. The way it works is by passing through USB communication, making a copy of the communication coming in and out, and sending it to the PC.

Normally, the analyzer has a small buffer memory and must sustain fast data flow. Unfortunately, this can occasionally cause software lockup. From what could be gathered from the verbose printing, USB descriptors were found for the hub. As it turns out, the faulty hub was a Multi-TT type hub, while most others are single TT (transaction translator).

Fixing Software Lockup

Since it was necessary to get the rest of the descriptor data, fixing the software lockup was the next step. Writing in a panic function – a breakpoint of sorts – into the code allowed the USB host’s power to terminate, and stepping through the program revealed that while the 2 port hub was initially being read, some issue arose afterwards.

As it turns out, the issue relied on USB split transactions, used only between USB hosts and hubs. Communication happens by tokens, which begins with a SPLIT-START token.

As it turns out, the issue was that the tokens weren’t being sent in the correct order. The other hubs seemed to be handle this nevertheless. By applying a fix to the C++ code of the bad hub, which had previously not been implementing the data structure for accessing register properly, the hub was able to work again.The hub appeared to be rejecting bad token, which was causing the issue in the first place.

All in all, while I’m sure this had to be a head scratching experience, at least it gives us some insight into the low-level design of USB communication.