We always enjoy [NileRed’s] videos. His latest shows how he made some relatively high-temperature superconducting ceramic. After finding what appeared to be some really good instructions on the Internet, [NileRed] found there were some things in the paper that didn’t make sense. You can watch the video, below.

The superconductor was YCBO, sometimes known as 123 because of the ratio of its components. Turns out that most of the materials were available online, except for one exotic chemical that he had to buy from a more conventional source.

The purity of some of the chemicals was in doubt, so he purified some of it and did find some contaminants in it. If you want to do this yourself, you are going to need some chemical handling gear and we’d suggest reading the safety sheets on all the material involved.

If you don’t have the tools, you are going to have to arrange for vacuum chambers, an 8-ton press, furnaces, and more mundane things like stirring hot plates and lab glassware. You might even need a blender.

Of course, you also need to handle liquid nitrogen to cool things off enough to see the superconducting effect. [NileRed] actually had to buy a furnace for this effort–spending about $2,000– and had a bit of a challenge getting it in one piece, as you’ll see, along with hitting it with twice the rated voltage.

Even though we might not have had to repair the furnace, we doubt we are going to make any superconductors anytime soon. But it is reassuring to know that it is in the realm of what you could do in your garage if you wanted to.

We’ve talked about some of the projects that [NileRed] found for inspiration. While we were impressed with the process, we aren’t sure this material is up to making a practical hoverboard.

source https://hackaday.com/2020/08/04/nilered-makes-superconductors/

We don’t really miss going out to bars all that much, unless you’re talking about the one downtown with all the pinball machines. Don’t get us wrong — pinball emulators have gotten crazy good, and you can find exact digital replicas of most machines to play on your phone or whatever. But it just doesn’t compare to the thrill of playing a real cabinet.

Don’t despair, because for the next couple of weeks, you can queue up to play on a real Oktoberfest pinball machine that’s sitting in Espoo, Finland. The controls are hooked up to a Raspberry Pi 4 through a custom HAT, along with a camera pointed at the playfield and another focused on the backglass screen. The game development/video streaming company Surrogate is hosting a tournament over the internet, and will be giving prizes to the top ten high rollers.

We usually have to wait until the holiday season to come across these remote-reality gaming opportunities. Having played it several times now, we recommend spamming the flippers until you get a feel for the lag. Also, just holding the flippers up while the ball is in the upper half of the playfield will catch a lot of balls that you might otherwise lose due to flipper lag, and sometimes they end up back in front of the launcher to shoot again. After the break, check out a brief but amusing video of setting up the cameras and Pi that includes a taste of the Oktoberfest music.

The tournament runs until the end of August, which should be enough time for somebody to set up CV and a keyboard to play this automatically. Need inspiration? Here’s an open-source pinball machine that can play itself.

 

source https://hackaday.com/2020/08/03/iot-pinball-puts-oktoberfest-fun-on-tap/

We don’t really miss going out to bars all that much, unless you’re talking about the one downtown with all the pinball machines. Don’t get us wrong — pinball emulators have gotten crazy good, and you can find exact digital replicas of most machines to play on your phone or whatever. But it just doesn’t compare to the thrill of playing a real cabinet.

Don’t despair, because for the next couple of weeks, you can queue up to play on a real Oktoberfest pinball machine that’s sitting in Espoo, Finland. The controls are hooked up to a Raspberry Pi 4 through a custom HAT, along with a camera pointed at the playfield and another focused on the backglass screen. The game development/video streaming company Surrogate is hosting a tournament over the internet, and will be giving prizes to the top ten high rollers.

We usually have to wait until the holiday season to come across these remote-reality gaming opportunities. Having played it several times now, we recommend spamming the flippers until you get a feel for the lag. Also, just holding the flippers up while the ball is in the upper half of the playfield will catch a lot of balls that you might otherwise lose due to flipper lag, and sometimes they end up back in front of the launcher to shoot again. After the break, check out a brief but amusing video of setting up the cameras and Pi that includes a taste of the Oktoberfest music.

The tournament runs until the end of August, which should be enough time for somebody to set up CV and a keyboard to play this automatically. Need inspiration? Here’s an open-source pinball machine that can play itself.

 

source https://hackaday.com/2020/08/03/iot-pinball-puts-oktoberfest-fun-on-tap/

We don’t really miss going out to bars all that much, unless you’re talking about the one downtown with all the pinball machines. Don’t get us wrong — pinball emulators have gotten crazy good, and you can find exact digital replicas of most machines to play on your phone or whatever. But it just doesn’t compare to the thrill of playing a real cabinet.

Don’t despair, because for the next couple of weeks, you can queue up to play on a real Oktoberfest pinball machine that’s sitting in Espoo, Finland. The controls are hooked up to a Raspberry Pi 4 through a custom HAT, along with a camera pointed at the playfield and another focused on the backglass screen. The game development/video streaming company Surrogate is hosting a tournament over the internet, and will be giving prizes to the top ten high rollers.

We usually have to wait until the holiday season to come across these remote-reality gaming opportunities. Having played it several times now, we recommend spamming the flippers until you get a feel for the lag. Also, just holding the flippers up while the ball is in the upper half of the playfield will catch a lot of balls that you might otherwise lose due to flipper lag, and sometimes they end up back in front of the launcher to shoot again. After the break, check out a brief but amusing video of setting up the cameras and Pi that includes a taste of the Oktoberfest music.

The tournament runs until the end of August, which should be enough time for somebody to set up CV and a keyboard to play this automatically. Need inspiration? Here’s an open-source pinball machine that can play itself.

 

source https://hackaday.com/2020/08/03/iot-pinball-puts-oktoberfest-fun-on-tap/

Despite being cooked up by Compuserve back in the late 1980s, GIFs have seen a resurgence on the modern internet, mostly because they’re fun. However, all our small embedded systems are getting color screens these days, and they’d love to join in the party. [Larry Bank] has whipped up a solution for just that reason, letting embedded systems play back short animated GIFs with limited resources.

[Larry] does a great job of explaining how the GIF format works, using LZW compression and variable-length codes. He talks about how the design of the format presents challenges, particularly when working with microcontrollers. Despite this, the final code works well, and is able to work with most animated GIFs of the right dimensions and construction. 24K of RAM is required, and image width is limited to 320 pixels. Images can be loaded from flash, memory, or SD cards, and he notes that best performance is gained with a microcontroller with fast SPI for writing to screens quickly.

It’s a great piece of software that promises to add a lot of charm, or silliness, to microcontroller projects. It also simplifies the use of animations, which can now be designed on computers rather than by using onboard graphics libraries. GIF really is the format that never seems to die; we’ve featured cameras dedicated to the form before. Video after the break.

 

 

source https://hackaday.com/2020/08/03/optimizing-gif-playback-for-microcontrollers/

We are saddened to report that William English, co-inventor of the computer mouse, died July 26 in San Rafael, California. He was 91 years old.

Every piece of technology starts with a vision, a vague notion of how a thing could or should be. The computer mouse is no different. In fact, the mouse was built to be an integral part of the future of personal computing — a shift away from punch cards and mystery toward a more accessible and user-friendly system of windowed data display, hyperlinks, videoconferencing, and more. And all of it would be commanded by a dot on the screen moving in sync with the operator’s intent, using a piece of hardware controlled by the hand.

The stuff of science fiction becomes fact anytime someone has the means to make it so. Often times the means includes another human being, a intellectual complement who can conjure the same rough vision and fill in the gaps. For Douglas Engelbart’s vision of the now-ubiquitous computer mouse, that person was William English.

William English was born January 27, 1929 in Lexington, Kentucky. His father was an electrical engineer and William followed this same path after graduating from a ranch-focused boarding school in Arizona. After a stint in the Navy, he took a position at Stanford Research Institute in California, where he met Douglas Engelbart.

Engelbart showed William his notes and drawings, and he built the input device that Englebart envisioned — one that could select characters and words on the screen and revolutionize text editing. The X/Y Position Indicator, soon and ever after called the mouse: a sort of rough-yet-sleek pinewood derby car of an input device headed into the future of personal computing.

William’s mouse was utilitarian: a wooden block with two perpendicular wheels on the bottom, and a pair of potentiometers inside to interpret the wheels’ X and Y positions. The analog inputs are converted to digital and represented on the screen. The first mouse had a single button, and the cord was designed to run out the bottom, not the top.

This controller was designed to steer Engelbart’s magnum opus, an experimental computer dubbed oN-Line System, later NLS, which turned out to be a great prognosticator of modern networked computing. Engelbart and English presented the many facets of the NLS in a legendary demonstration given December 9th, 1968 in San Francisco. This event, known as the mother of all tech demos, was well covered by our own [Dan Maloney] in a biographical/Retrotechtacular mash-up marking the 50th anniversary. By the time they gave the demo, the mouse had three buttons and sat atop a stately chair-mounted lap console designed by Herman Miller. This NLS console contained an IBM Selectric keyboard and held a 5-button chording keyboard on the left side.

Bill designed all the audio-visuals for the demo, set everything up, and staged the 90+ minute presentation by speaking to Englebart and others through headsets. The show was only possible from a technical standpoint because Bill had a chance encounter with a Silicon Valley phone technician and convinced him to set up a wireless link for voice and video between the hall and their lab some 30 miles away in Menlo Park. That, plus the giant Eidophor projector they borrowed from NASA to show the demo to the hundreds of engineers in attendance. English and Englebart discuss the NLS, the Eidophor, and much more in the interview embedded below, but the topic is worth much a much deeper dive (something Mike Harrison did for his talk at the 2016 Hackaday Belgrade conference).

In 1971, Bill left Stanford Research Institute for Xerox’s famed Palo Alto Research Center (PARC) where he continued to develop the features of the NLS into the Alto. You likely know the story from here — Bill Gates and Steve Jobs both toured PARC, both saw the Alto, and both steered the personal computer toward their own vision.

Main and thumbnail images via NYT

source https://hackaday.com/2020/08/03/william-english-computer-mouse-co-creator-has-passed/

We are saddened to report that William English, co-inventor of the computer mouse, died July 26 in San Rafael, California. He was 91 years old.

Every piece of technology starts with a vision, a vague notion of how a thing could or should be. The computer mouse is no different. In fact, the mouse was built to be an integral part of the future of personal computing — a shift away from punch cards and mystery toward a more accessible and user-friendly system of windowed data display, hyperlinks, videoconferencing, and more. And all of it would be commanded by a dot on the screen moving in sync with the operator’s intent, using a piece of hardware controlled by the hand.

The stuff of science fiction becomes fact anytime someone has the means to make it so. Often times the means includes another human being, a intellectual complement who can conjure the same rough vision and fill in the gaps. For Douglas Engelbart’s vision of the now-ubiquitous computer mouse, that person was William English.

William English was born January 27, 1929 in Lexington, Kentucky. His father was an electrical engineer and William followed this same path after graduating from a ranch-focused boarding school in Arizona. After a stint in the Navy, he took a position at Stanford Research Institute in California, where he met Douglas Engelbart.

Engelbart showed William his notes and drawings, and he built the input device that Englebart envisioned — one that could select characters and words on the screen and revolutionize text editing. The X/Y Position Indicator, soon and ever after called the mouse: a sort of rough-yet-sleek pinewood derby car of an input device headed into the future of personal computing.

William’s mouse was utilitarian: a wooden block with two perpendicular wheels on the bottom, and a pair of potentiometers inside to interpret the wheels’ X and Y positions. The analog inputs are converted to digital and represented on the screen. The first mouse had a single button, and the cord was designed to run out the bottom, not the top.

This controller was designed to steer Engelbart’s magnum opus, an experimental computer dubbed oN-Line System, later NLS, which turned out to be a great prognosticator of modern networked computing. Engelbart and English presented the many facets of the NLS in a legendary demonstration given December 9th, 1968 in San Francisco. This event, known as the mother of all tech demos, was well covered by our own [Dan Maloney] in a biographical/Retrotechtacular mash-up marking the 50th anniversary. By the time they gave the demo, the mouse had three buttons and sat atop a stately chair-mounted lap console designed by Herman Miller. This NLS console contained an IBM Selectric keyboard and held a 5-button chording keyboard on the left side.

Bill designed all the audio-visuals for the demo, set everything up, and staged the 90+ minute presentation by speaking to Englebart and others through headsets. The show was only possible from a technical standpoint because Bill had a chance encounter with a Silicon Valley phone technician and convinced him to set up a wireless link for voice and video between the hall and their lab some 30 miles away in Menlo Park. That, plus the giant Eidophor projector they borrowed from NASA to show the demo to the hundreds of engineers in attendance. English and Englebart discuss the NLS, the Eidophor, and much more in the interview embedded below, but the topic is worth much a much deeper dive (something Mike Harrison did for his talk at the 2016 Hackaday Belgrade conference).

In 1971, Bill left Stanford Research Institute for Xerox’s famed Palo Alto Research Center (PARC) where he continued to develop the features of the NLS into the Alto. You likely know the story from here — Bill Gates and Steve Jobs both toured PARC, both saw the Alto, and both steered the personal computer toward their own vision.

Main and thumbnail images via NYT

source https://hackaday.com/2020/08/03/william-english-computer-mouse-co-creator-has-passed/

For many of us, this whole pandemic thing has produced some unexpected upsides. One of [George Turvey]’s was finding a nice new scenic route to work that goes by a lake with bike trails. [George] thought it might be nice to go fishing after work, and use a folding bike to cover a lot of ground while looking for good spots on the shore. There was just one problem — riding a bike while transporting tackle is awkward.

The bike comes with a front mount that’s meant to hold the special bags they make, so that became square one for designing a rod and tackle holder. Then [George] had to weigh the pros and cons of additive vs. subtractive methods for prototyping the holder, or at least the connection between it and the mount on the bike.

Milling won out, at least for the initial proof of concept, and result is a modular mock-up that combines a milled Kydex connector and tackle box holder with a double-barrel PVC rod holder. This way, [George] had a prototype in a fraction of the time it would have taken to design and print it. Cast your line past the break to see how fast [George] can switch gears into fishing mode.

3D printing definitely has a place in the fishing world. How else are you gonna design your own lures?

source https://hackaday.com/2020/08/03/hack-a-folding-bike-to-help-you-catch-some-pike/

Digital security is always a moving target, with no one device or system every being truly secure. Whether its cryptographic systems being compromised, software being hacked, or baked-in hardware vulnerabilities, it seems there is always a hole to be found. [Max Justicz] has a taste for such topics, and decided to explore the possibility of creating a secure communications device using a pair of LCDs.

In a traditional communications system, when a message is decrypted and the plaintext is displayed on screen, there’s a possibility that any other software running could capture the screen or memory state, and thus capture the secret data. To get around this, [Max]’s device uses a concept called visual cryptography. Two separate, independent systems with their own LCD each display a particular pattern. It is only when the two displays are combined together with the right filters that the message can be viewed by the user, thanks to the visual XOR effect generated by the polarized nature of LCDs.

The device as shown, working with both transparent OLEDs and traditional LCDs, is merely a proof of concept. [Max] envisions a device wherein each display is independently sourced, such that even if one is compromised, it doesn’t have the full message, and thus can’t compromise the system. [Max] also muses about the problem of side-channel attacks, and other factors to consider when trying to build a truly secure system.

We love a good discussion of cryptography and security around here; [John McMaster]’s talk on crypto ignition keys was a particular hit at Supercon last year. Video after the break.

source https://hackaday.com/2020/08/03/cryptographic-lcds-use-the-magic-of-xor/

Imagine that you want to output multiple lines of text in Bash, or any shell script. Maybe it’s for a help string for a particularly convoluted shell script you’re writing. You could have a separate echo command for each line.  Or you could use the “here document“.

The “here document” construction takes the text between two delimiters and passes it, as if it were piped, to a command.

if [[$# == 0 ]] || [[ "$1" == "-h" ]]; then
cat << EOF
This is my help message. There are many like it but this one is mine.
My help message is my best friend.
EOF

All of the text, as written, with line breaks and spaces and all, get passed to cat and your helpful formatted message is printed to the user.

You can use here documents interactively at the command prompt, and you can use them in functions:

#!/bin/bash
help() {
    cat << EOF
Here is your help.
EOF
}

More About Here Documents

More than just writing help scripts, here documents are useful any time that you want to enter multiple lines and have them piped to a command. We use them most often from the shell directly. There are a few nuances, however.

You probably figured out that the “EOF” string in the above examples marks the beginning and end of the here document. There’s nothing special about it. You can use any word that doesn’t appear in your document. So “<< END_OF_HERE_DOC” would work.

The end of document string has to be at the beginning of a line, and by itself. You should not have whitespace before or after it. It is usually a good idea to use something odd and more than a few characters as the end string, although — in theory — you could use even a single character.

But that requirement messes up code indentation — see the help() function above.  If you put a dash between the redirection brackets and the string, the shell will consume any leading tab characters (but not spaces!). That lets you indent your message so it doesn’t all run together. But here, you have to be careful about spaces in the declaration: cat <<- EOF and cat <<-EOF work, while cat << -EOF doesn’t.  (It expects the delimiter “-EOF”.)  Still, it lets you indent your code if you can get it right, and use tabs instead of spaces.

 
#!/bin/bash 
help() { 
    cat <<- EOF 
        Here is your help. 
    EOF 
} 

Substitution

One thing that might not be obvious is that the here document can handle variable expansion. Try typing:

cat << EOF
Your path is $PATH
Your prompt is $PS1
EOF

Your path is /usr/local/sbin:/usr/local/bin:...
Your prompt is ($HOSTNAME \w)\$

That even works with things like command substitution. So you could put things in like $(ls), for example. Sometimes you don’t want that, though. In those cases, just quote the end string. For example:

cat << "EOF"
Your path is $PATH
Your prompt is $PS1
EOF

Your path is $PATH
Your prompt is $PS1

Peculiarities

You can even send the input to a program that does nothing like : which might seem odd. But some people use that to comment out large blocks of script for debugging or other purposes. It is a bit wasteful, because the lines you don’t want get put in a temporary file and fed to the input of a program that will ignore them, but you might see it done.

Clearly, here documents are niche. I use them a lot for writing help strings in scripts, but they’re just the ticket when you need to pass multiple lines in a script or to a script as you typed multiple lines into stdin.

 

source https://hackaday.com/2020/08/03/linux-fu-help-messages-for-shell-scripts-and-here-documents/