Hackaday Links: September 6, 2020

That was a close shave! On Tuesday, asteroid 2011 ES4 passed really close to the earth. JPL’s close approach data pegs its nominal distance from earth at about 0.00081083276352288 au! Yeah, we had to look it up too: that’s around 75,000 miles (120,000 kilometers), just ten times the diameter of the earth and only about one-third the distance from the earth the moon. It got within about 52,000 miles of the moon itself. Bookworms who made it all the way through Seveneves are surely sweating right now.

There’s a low current arms race when it comes to lighting up LEDs. The latest salvo in the field comes from [Christoph Tack] who boasts a current of 1.36 µA at 3 V for a green LED that is roughly 10x brighter than a phosphorescent watch dial. Of course, the TritiLED is the design being chased, which claims to run 17.6-20.2 years on a single CR2032 coin cell.

Proving once again that Hanna and Barbera were indeed future-tech prophets, flying cars are now a thing. Sky Drive Inc. made a four-minute test flight of a single passenger octo-rotor aircraft. Like a motorcycle of the sky (and those are a thing too) this thing is single-passenger and the cockpit is open air. The CNN article mentions that “The company hopes to make the flying car a part of normal life and not just a commodity”. Yeah, we’re sure they do, but in an age when electric cars are demonized for ranges in the low hundreds of miles, this is about as practical for widespread use as self-balancing electric unicycles.

Just when you thought the Marble Machine X project couldn’t get any bigger, we find out they have a few hundred volunteers working to update and track CAD models for all parts on the machine. Want a quick-start on project management and BOM control? These are never seen as the sexy parts of hardware efforts, but for big projects, you ignore them at your own peril.

Google and Apple built a COVID-19 contact tracing framework into their mobile platforms but stopped short of building the apps to actually do the work, anticipating that governments would want to control how the apps worked. So was the case with the European tracing app as Elliot Williams recently covered in this excellent overview. However, the United States has been slower to the game. Looks like the tech giants have become tired of waiting and have now made it possible for the framework itself to work as a contact tracing mechanism. To enable it, local governments need to upload a configuration file that sets parameters and URLs that redirect to informational pages from local health departments, and users must opt-in on their phone. All other tracing apps will continue to function, this is meant to add an option for places that have not yet adopted/developed their own app.

And finally, it’s time to take back responsibility for your poor spelling. Auto-correct has been giving us sardines instead of teaching how to fish for them ourselves. That ends now. The Autocorrect Remover is an extension for Google Docs that still tells you the word is wrong, but hides the correct spelling, gamifying it by having you guess the right spelling and rewarding you with points when you get it right.

Hackaday Podcast 079: Wobble Sphere, Pixelflut, Skeeter Traps, And Tracing Apps

Hackaday editors Mike Szczys and Elliot Williams gaze upon the most eye-popping projects from the past week. Who would have known that springy doorstops could be so artistic? Speaking of art, what happens if you give everyone on the network the chance to collectively paint using pixels? There as better way to catch a rat, and a dubious way to lure mosquitoes. We scratch our heads at sending code to the arctic, and Elliot takes a deep look at the contact tracing apps developed and in use throughout Europe.

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 (~65 MB)

Places to follow Hackaday podcasts:

Continue reading “Hackaday Podcast 079: Wobble Sphere, Pixelflut, Skeeter Traps, And Tracing Apps”

COVID Tracing Apps: What Europe Has Done Right, And Wrong

Europe has been in COVID-containment mode for the last month, in contrast to the prior three months of serious lockdown. Kids went back to school, in shifts, and people went on vacation to countries with similarly low infection rates. Legoland and the zoo opened back up, capped at 1/3 capacity. Hardware stores and post offices are running “normally” once you’ve accommodated mandatory masks and 1.5 meter separations while standing in line as “normal”. To make up for the fact that half of the tables have to be left empty, most restaurants have sprawled out onto their terraces. It’s not really normal, but it’s also no longer horrible.

But even a country that’s doing very well like Germany, where I live, has a few hundred to a thousand new cases per day. If these are left to spread unchecked as before, the possibility of a second wave is very real, hence the mask-and-distance routine. The various European COVID-tracing apps were rolled out with this backdrop of a looming pandemic that’s tenuously under control. While nobody expects the apps to replace public distancing, they also stand to help if they can catch new and asymptomatic cases before they get passed on.

When Google and Apple introduced their frameworks for tracing apps, I took a technical look at them. My conclusion was that the infrastructure was sound, but that the implementation details would be where all of the dragons lay in wait. Not surprisingly, I was right!

Here’s an update on what’s happened in the first month of Europe’s experience with COVID-tracing apps. The good news is that the apps seem to be well written and based on the aforementioned solid foundation. Many, many people have installed at least one of the apps, and despite some quite serious growing pains, they seem to be mostly functioning as they should. The bad news is that, due to its privacy-preserving nature, nobody knows how many people have received warnings, or what effect, if any, the app is having on the infection rate. You certainly can’t see an “app effect” in the new daily cases rate. After a month of hard coding work and extreme public goodwill, it may be that cellphone apps just aren’t the panacea some had hoped.

Continue reading “COVID Tracing Apps: What Europe Has Done Right, And Wrong”

ESP32 Turned Open Source COVID-19 Contact Tracer

Over the past few months we’ve heard a lot about contact tracers which are designed to inform users if they’ve potentially come into close proximity with someone who has the virus. Generally these systems have been based on smartphone applications, but there are also hardware solutions that can operate independently for those who are unable or unwilling to install the software. Which is precisely what [Tom Bensky] has implemented using an ESP32 and a USB battery bank.

The idea is simple: the software generates a unique ID which is broadcast out by the ESP32 over Bluetooth Low Energy. Appended to that ID is a code that indicates the person’s current physical condition. There’s no centralized database, each user is expected to update their device daily with any symptoms they may be experiencing. If your tracker is blinking, that means somebody has come in close enough proximity that you should look at the collected data and see how they were feeling at the time.

It’s not a perfect system, of course, as for one thing the number of people that are willing and able to flash this firmware onto a spare ESP32 and carry the thing around with them all day is going to be extremely small. This might have filled an interesting niche if we were still going to hacker and maker cons this summer, but all of those have gone virtual anyway. That said, it’s an interesting look at how a decentralized contact tracing system can be implemented cheaply and quickly.

Another detail worth taking a look at is how [Tom] handled the user experience in his firmware. In an effort to make the tracer as easy as possible to configure, he’s using the Web Bluetooth capability of Google Chrome. Just open up the local web page in your browser, and it will handle talking to the hardware for you. Even if you’re not in the market for a contract tracer, we think this is a great example for how to handle end-user configuration on the ESP32.

We’ve already looked at contact tracer APIs from Google and Apple, dedicated COVID-19 hardware tokens, and even other open source attempts at decentralized proximity tracking. It’s a lot to process, and everyone seems to have their own idea on how it should be done. In the end, the most practical solution is probably to just stay at home as much as possible.

Teardown Of The Singaporean COVID-19 TraceTogether Token

A large part of fighting against the SARS-CoV-2 pandemic is the practice of contact tracing, where the whereabouts of an infected person can be traced and anyone who has been in contact with that person over the past days tested for COVID-19. While smartphone apps have been a popular choice for this kind of tracing, they come with a range of limitations, which is what the TraceTogether hardware token seeks to circumvent. Now [Sean “Xobs” Cross] has taken a look at the hardware that will be inside the token once it launches.

The Simmel COVID-19 contact tracer.

Recently, [Sean] along with [Andrew “bunnie” Huang] and a few others were asked by GovTech Singapore to review their TraceTogether hardware token proposal. At its core it’s similar to the Simmel contact tracing solution – on which both are also working – with contacts stored locally in the device, Bluetooth communication, and a runtime of a few months or longer on the non-rechargeable batteries.

The tracing protocol used is BlueTrace, which is an open application protocol aimed at digital contact tracing. It was developed by the Singaporean government, initially for use with their TraceTogether mobile app.

This smartphone app showed a number of issues. First is that Apple does not allow for iOS apps to use Bluetooth in the background, requiring the app to be active in the foreground to be useful. Apple has its own tracing protocol, but it does not cover the requirements for building a full contact graph, as [Andrew] covers in more detail. Finally, the app in general is not useful to those who do not have a recent (compatible) smartphone, or who do not have a smartphone at all.

A lot of the challenges in developing these devices lie in making them low-power, while still having the Bluetooth transceiver active often enough to be useful, as well as having enough space to store interactions and the temporary tokens that are used in the tracing protocol. As Simmel and the TraceTogether tokens become available over the coming months, it will be interesting to see how well these predictions worked out.

Hackaday Links: April 26, 2020

Gosh, what a shame: it turns out that perhaps 2 billion phones won’t be capable of COVID-19 contact-tracing using the API that Google and Apple are jointly developing. The problem is that the scheme the two tech giants have concocted, which Elliot Williams expertly dissected recently, is based on Bluetooth LE. If a phone lacks a BLE chipset, then it won’t work with apps built on the contact-tracing API, which uses the limited range of BLE signals as a proxy for the physical proximity of any two people. If a user is reported to be COVID-19 positive, all the people whose BLE beacons were received by the infected user’s phone within a defined time period can be anonymously notified of their contact. As Elliot points out, numerous questions loom around this scheme, not least of which is privacy, but for now, something like a third of phones in mature smartphone markets won’t be able to participate, and perhaps two-thirds of the phones in developing markets are not compatible. For those who don’t like the privacy-threatening aspects of this scheme, pulling an old phone out and dusting it off might not be a bad idea.

We occasionally cover stories where engineers in industrial settings use an Arduino for a quick-and-dirty automation solution. This is uniformly met with much teeth-gnashing and hair-rending in the comments asserting that Arduinos are not appropriate for industrial use. Whether true or not, such comments miss the point that the Arduino solution is usually a stop-gap or proof-of-concept deal. But now the purists and pedants can relax, because Automation Direct is offering Arduino-compatible, industrial-grade programmable controllers. Their ProductivityOpen line is compatible with the Arduino IDE while having industrial certifications and hardening against harsh conditions, with a rich line of shields available to piece together complete automation controllers. For the home-gamer, an Arduino in an enclosure that can withstand harsh conditions and only cost $49 might fill a niche.

Speaking of Arduinos and Arduino accessories, better watch out if you’ve got any modules and you come under the scrutiny of an authoritarian regime, because you could be accused of being a bomb maker. Police in Hong Kong allegedly arrested a 20-year-old student and posted a picture of parts he used to manufacture a “remote detonated bomb”. The BOM for the bomb was strangely devoid of anything with wireless capabilities or, you know, actual explosives, and instead looks pretty much like the stuff found on any of our workbenches or junk bins. Pretty scary stuff.

If you’ve run through every binge-worthy series on Netflix and are looking for a bit of space-nerd entertainment, have we got one for you. Scott Manley has a new video that goes into detail on the four different computers used for each Apollo mission. We knew about the Apollo Guidance Computers that guided the Command Module and the Lunar Module, and the Launch Vehicle Digital Computer that got the whole stack into orbit and on the way to the Moon, but we’d never heard of the Abort Guidance System, a backup to the Lunar Module AGC intended to get the astronauts back into lunar orbit in the event of an emergency. And we’d also never heard that there wasn’t a common architecture for these machines, to the point where each had its own word length. The bit about infighting between MIT and IBM was entertaining too.

And finally, if you still find yourself with time on your hands, why not try your hand at pen-testing a military satellite in orbit? That’s the offer on the table to hackers from the US Air Force, proprietor of some of the tippy-toppest secret hardware in orbit. The Hack-A-Sat Space Security Challenge is aimed at exposing weaknesses that have been inadvertantly baked into space hardware during decades of closed development and secrecy, vulnerabilities that may pose risks to billions of dollars worth of irreplaceable assets. The qualification round requires teams to hack a grounded test satellite before moving on to attacking an orbiting platform during DEFCON in August, with prizes going to the winning teams. Get paid to hack government assets and not get arrested? Maybe 2020 isn’t so bad after all.

Hackaday Podcast 064: The COBOL Cabal, The Demoscene Bytes, And The BTLE Cure

Hackaday editors Elliot Williams and Mike Szczys pan for gold in a week packed with technological treasure. The big news is Apple/Google are working on contact tracing using BTLE. From adoption, to privacy, to efficacy, there’s a lot to unpack here and many of the details have yet to take shape. Of course the episode also overflows with great hacks like broken-inductor bike chain sensors, parabolic basketball backboards, bizarre hose clamp tools, iron-on eTextile trials, and hot AM radio towers. We finish up discussing the greatest typing device that wasn’t, and the coming and going of the COBOL crisis.

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 064: The COBOL Cabal, The Demoscene Bytes, And The BTLE Cure”