A Touchscreen From 1982, That Could Kill With A Single Finger Press

Over the pond here in the UK we used to have a TV show called Tomorrow’s World, It was on once a week showing all the tech we would have been using in 10 years time (or so they said). In 1982 they ran with a story about a touch screen computer. Perhaps not what you would recognize today as a touchscreen but given the date and limited technology someone had come up with a novel idea for a touchscreen that worked sort of.

It was a normal CRT screen but around the edges where photodiodes pointing inwards as if to make an invisible infrared touch interface just half an inch in front of the screen. Quite impressive technology giving the times. As they go through the video showing us how it works a more sinister use of this new-fangled touch screen computer rears its ugly head, They turned it into a pretty cool remote-controlled gun turret complete with a motorized horizontal and vertical axis upon which an air pistol was placed along with a camera. You could see an image back from the camera on the screen, move the gun around to aim the weapon, then with a single finger press on the screen, your target has been hit.

Guess what’s going on at the end of the month? The Vintage Computer Festival Southeast is happening April 29th and 30th. The event is being held at the Computer Museum of America and is, by all accounts, a really cool show.

Walk into any package sorting facility or Amazon fulfillment center and you’ll find a maze of conveyor belts, slides, and ramps that move boxes from one point to another. Conveyor belts are so last century, so here’s a fleet of robots.

In 2017, the CITES treaty — an international treaty for the protection of endangered species — changed a lot. While the original treaty protected individual species, in 2017, enforcement of this treaty on tropical hardwoods changed to an entire genus. This is a problem when it comes to rosewood; previously only Dalbergia nigra was covered under CITES, now the entire Dalbergia genus is covered. This sucks for guitar makers, but a Dutch guy is making guitars out of newspaper. We’re probably looking at some sort of micarta thing here, but it sounds acceptable.

Where did Apple’s Spinning Beach Ball of Death come from? 1984, or thereabouts. The ubiquitous Apple ‘wait’ cursor is from the first versions of the Macintosh Toolbox, and it has remained mostly unchanged all this time. This is Apple Wait, a demonstration of this first spinny ball of death. It’s a Raspberry Pi connected to an Apple monochrome monitor that just displays a spinny wait logo. Check out the video.

How do you make strips of RGB LEDs turn a corner? Wire, usually. Here are some corner pieces for WS2812B LED strips. It looks very handy if you’re building a gigantic RGB LED matrix.

SHA2017 is an outdoor hacker conference that’s happening this summer. They’re working on a badge, but they need some help. They’re looking for some funding for their ESP32-powered, touch controller, sunlight-readable ePaper badge. If you have a job that likes to sponsor stuff like this, it’s a worthy cause.

Python is the Arduino of software projects. It has a critical mass of libraries for anything from facial recognition and neural networks to robotics and remote sensing. And just like Arduino, I have yet to find the killer IDE for Python. Perhaps I just haven’t tried the right one yet, but it could be that I’m just doing Python wrong.

For Years I’ve Been IDLE

I’m a Linux-only type of a guy so using IDLE for Python is a natural fit. It’s in the repositories for super quick and easy install and there’s basically zero configuration to be done. Generally speaking my preferred development environment is text editor and command line compiler. IDLE is just one step above that. You get a separate window for the shell and each Python file you’re working on. Have IDLE run your code and it saves the file, then launches it in the shell window.

For me, there are two important features of IDLE’s shell. The first is that it keeps an interactive session open after you run your Python code. This means that any globals that your script uses are still available, and that you can experiment with your code by calling functions (and classes, etc) in real time. The second desirable feature is that while using this interactive shell, IDLE supports code completion and docstring support (it gives you hints for what parameters a function accepts/requires).

But simplicity has a tough time scaling. I’m working on larger and larger projects spread over many files and the individual nature of IDLE editor windows and lack of robust navigation has me looking to move forward.

The Contenders

I’ve tried perhaps a half-dozen different Python IDEs now, spending the most time on two of them: Geany and Atom. Both are easy to install on Linux and provide the more advanced features I want for larger projects: better navigation, cross-file code completion (and warnings), variable type and scope indication.

The look of Geany brings to mind an “IDE 1.0” layout style and theme. It’s the familiar three-pane layout that places symbols to the left, code to the right, and status along the bottom. When you run your program it launches in an interactive terminal, which I like, but you lose all IDE features at this point, which I despise. There is no code completion, and no syntax highlighting.

I have been using Atom much more than Geany and have grown to like it enough to stick with it for now. I’d call Atom the “IDE 2.0” layout. It launches with a dark theme and everything is a tab.

Atom depends heavily on packages (plugins that anyone may write). The package management is good, and the packages I’ve tried have been superb. I’m using autocomplete-python and tabs-to-spaces, but again I come up short when it comes to running Python files. I’ve tried platformio-ide-terminal, script, and runner plugins.  The first brings up a terminal as a bottom pane but doesn’t automatically run the file in that terminal. Script also uses a bottom pane but I can’t get it to run interactively. I’m currently using runner which has an okay display but is not interactive. I’ve resorted to using a “fake” python file in my projects as a workaround for commands and tests I would normally run in the interactive shell.

Tell Us How You Python

It’s entirely possible I’ve just been using Python wrong all these years and that tinkering with your code in an interactive shell is a poor choose of development processes.

What do you prefer for your Python development? Does an interactive shell matter to you? Did you start with IDLE and move to a more mature IDE. Which IDE did you end up with and what kind of compromises did you make during that change. Let us know in the comments below.

Say It With Me: Root-Mean-Square

If you measure a DC voltage, and want to get some idea of how “big” it is over time, it’s pretty easy: just take a number of measurements and take the average. If you’re interested in the average power over the same timeframe, it’s likely to be pretty close (though not identical) to the same answer you’d get if you calculated the power using the average voltage instead of calculating instantaneous power and averaging. DC voltages don’t move around that much.

Try the same trick with an AC voltage, and you get zero, or something nearby. Why? With an AC waveform, the positive voltage excursions cancel out the negative ones. You’d get the same result if the flip were switched off. Clearly, a simple average isn’t capturing what we think of as “size” in an AC waveform; we need a new concept of “size”. Enter root-mean-square (RMS) voltage.

To calculate the RMS voltage, you take a number of voltage readings, square them, add them all together, and then divide by the number of entries in the average before taking the square root: $\sqrt{\frac{1}{n} \left(v_1^2 + v_2^2 +...+ v_n^2\right)}$. The rationale behind this strange averaging procedure is that the resulting number can be used in calculating average power for AC waveforms through simple multiplication as you would for DC voltages. If that answer isn’t entirely satisfying to you, read on. Hopefully we’ll help it make a little more sense.

Friday Hack Chat: Open Source Silicon

This Friday, Hackaday.io will be graced with purveyors of Open Source Silicon. Join us in the Hackaday.io Hack Chat this Friday, April 14 at noon PDT (19:00 UTC) for a conversation with SiFive, an ‘Open’ silicon manufacturer.

This week, we’re sitting down with SiFive, a fabless semiconductor company and makers of the HiFive1, an Open Hardware microcontroller that you can just go out and buy. Late last year, SiFive released the HiFive1, an Arduinofied version of SiFive’s FE310 System on Chip. This SoC is a RISC-V core and one of the first microprocessors that is completely Open Source. It is an affront to Stallmanism, the best hope we have for truly Open hardware, and it’s pretty fast, to boot.

SiFive isn’t only working on Open Hardware microcontrollers — their business plan is pretty much, ‘OSH Park, but for silicon’. If you have a design for a new type of chip, they’ll work with foundries to turn your design into a cute little epoxy impregnated blob. It’s a fascinating business plan, and you’re going to hear all about it this Friday in the Hack Chat.

Here’s How To Take Part:

Our Hack Chats are live community events on the Hackaday.io Hack Chat group messaging.

Log into Hackaday.io, visit that page, and look for the ‘Join this Project’ Button. Once you’re part of the project, the button will change to ‘Team Messaging’, which takes you directly to the Hack Chat.

You don’t have to wait until Friday; join whenever you want and you can see what the community is talking about.

Upcoming Hack Chats

We’ve got a lot on the table when it comes to our Hack Chats. On April 21st, we’re going to be talking magnets with Nanomagnetics. Making magnets, collecting magnets, playing with magnets, it’ll all be over on the Hack Chat.

The hardware coming out of [Dr. Peter Jansen]’s lab is the craziest stuff you can imagine. He’s built a CT scanner out of plywood, and an MRI machine out of many, many turns of enamel wire. Perhaps his best-known build is his Tricorder – a real, all-sensing device with permission from the estate of [Gene Roddenberry] to use the name. [Peter]’s tricorder was one of the finalists for the first Hackaday Prize, but that doesn’t mean he’s stopped working on it. Sensors are always getting better, and by sometime in the 23rd century, he’ll be able to fit a neutrino detector inside a tiny hand-held device.

One of the new sensors [Peter] is working with is the MAX30105 air particle sensor. The marketing materials for this chip say it’s designed for smoke detectors and fire alarms, but this is really one of the smallest dust and particle sensors on the market. If you want a handheld device that detects dust, this should be the chip you’re looking at.

Unfortunately, Maxim is being very, very tight-lipped about how this particle sensor works. There is a way to get access to raw particle counts and the underlying algorithms, and Maxim is more than willing to sell those algorithms through a third-party distributor. That’s simply not how we do things around here, so [Peter] is looking for someone with a fancy particle sensor to collect a few hours of data so he can build a driver for this chip.

Here’s what we know about the MAX30105 air particle sensor. There are three LEDs inside this chip (red, IR, and green), and an optical sensor underneath a piece of glass. The chip drives the LEDs, light reflects off smoke particles, and enters the optical sensor. From there, magic algorithms turn this into a number corresponding to a particle count. [Peter]’s hackaday.io log for this project has tons of data, math, and statistics on the data that comes out of this sensor. He’s also built a test rig to compare this sensor with other particle sensors (the DSM501A and Sharp sensors). The data from the Maxim sensor looks good, but it’s not good enough for a Tricorder. This is where you, o reader of Hackaday, come in.

[Peter] is looking for someone with access to a fancy particle sensor to collect a few hours worth of data with this Maxim sensor in a test rig. Once that’s done, a few statistical tests should be enough to verify the work done so far and build a driver for this sensor. Then, [Peter] will be able to play around with this sensor and hopefully make a very cheap but very accurate air particle sensor that should be hanging on the wall of your shop.