At first glance, SawStop seems like a hacker’s dream. A garage tinkerer comes up with a great idea, builds a product around it, and the world becomes a better place. As time has gone on, other companies have introduced similar products. Recently, SawStop successfully stopped Bosch from importing saws equipped with their Reaxx safety system into the USA. This not only impacts sales of new saws, but parts for existing equipment. Who gets screwed here? Unfortunately, it’s the owners of the Bosch saws, who now have a safety feature they might not be able to use in the future. This has earned some bad press for SawStop in forums and on websites like Reddit, where users have gone as far as to call SawStop a patent troll. Is that true or just Internet puffery? Read on and decide for yourself.
Blinky LED projects: we just can’t get enough of them. But anyone who’s stared a WS2812 straight in the face knows that the secret sauce that takes a good LED project and makes it great is the diffuser. Without a diffuser, colors don’t blend and LEDs are just tiny, blinding points of light. The ideal diffuser scrambles the photons around and spreads them out between LED and your eye, so that you can’t tell exactly where they originated.
We’re going to try to pay the diffuser its due, and hopefully you’ll get some inspiration for your next project from scrolling through what we found. But this is an “Ask Hacakday”, so here’s the question up front: what awesome LED diffusion tricks are we missing, what’s your favorite, and why?
Remember all the talk about modular smart phones? They sounded amazing! instead of upgrading your phone you would just upgrade the parts a bit like a computer but more simplistic. Well it seems modular phones are dead (video, embedded below) even after a lot of major phone manufacturers were jumping on the bandwagon. Even Google got on-board with Google Ara which was subsequently cancelled. LG released the G5 but it didn’t fare too well. The Moto Z from Motorola seemed to suffer from the same lack of interest. The buzz was there when the concept of these modular phones was announced, and people were genuinely exited about the possibilities. What went wrong?
For a start people expect their phones to have everything on board already, whether it be cameras, GPS, WiFi, high-capacity batteries or high-resolution screens. Consumers expect these things to come as standard. Why would they go out and buy a module when other phones on the market already have these things?
Sure you could get some weird and wonderful modules like extra loud speakers or perhaps a projector, but the demand for these items was small. And because these extras are already available as separate accessories not locked down to one device, it was a non starter from the beginning.
When we did our user studies. What we found is that most users don’t care about modularizing the core functions. They expect them all to be there, to always work and to be consistent. — Lead engineer Project Ara
The hackability of these phones would have been interesting to say the least, had they come to the mainstream. It just seems the public want thin sleek aluminum phones that they treat more as a status symbol than anything else. Modular phones have to be more bulky to accommodate the power/data rails and magnets for the modules, so they’ll lose out in pocketability. Still, we hope the idea is revisited in the future and not left on the scrap-heap of obsolescence.
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
IDLE with interactive shell that has highlighting and code completion
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 has symbol view that isn’t shown all the time. CTRL-R brings it up and it uses a search style but you can also scroll through all symbols
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.
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.
At Hackaday, we’re tapped into Hacker Culture. This goes far beyond a choice of operating system (Arch Linux, or more correctly, ‘Arch GNU/Linux’, or as I’ve recently taken to calling it, ‘Arch GNU plus Linux’). This culture infects every fiber of our soul, from music (DEF CON’s station on Soma FM), our choice in outerwear (black hoodies, duh), and our choice in laptops (covered in stickers). We all wear uniforms, although a gaggle of computer science and electronics nerds all wearing black t-shirts won’t tell you that. We all conform, whether we’re aware of it or not.
Despite a standardized uniform for this subculture, one small detail of this Hacker Uniform has remained unresolved for decades. Are one-hole or three-hole balaclavas best for hacking? Which balaclava is best for stealing bank accounts and hacking into NASA computers? What offers the best protection from precipitating ones and zeros in a real-life Matrix screensaver?
We’ve seen a lot of hacks with the nRF24l01+ 2.4 GHz radio modules. The tiny chips pack a lot of bang for the buck. Since the radios can switch frequencies relatively quickly, [Shubham Paul] decided to take advantage of this feature to make a rudimentary frequency-hopping communications channel.
The code is actually incredibly simple. Both the transmitter and receiver simply scan up and down over the defined channels. Because the clock speeds of any given pair of Arduinos are likely to be slightly different, it’s not a surprise that the radios eventually drift out of sync. Right now, as a quickie solution, [Shubham] is using a serial-port resynchronization: both are connected to the same computer, and he just tells them to get on the same channel. That’s not a horribly satisfying workaround. (But it’s a great start!)
Keeping two radios that are continually swapping channels in sync is no easy task, but it could possibly be made easier by taking advantage of the nRF’s acknowledge mode. If the delay between a sent acknowledge message and a received one were constant, these events (one on TX and one on RX) could be used to re-sync the two hopping cycles. All of this would probably require more temporal resolution than you’re going to get out of a microprocessor running Arduino code, but should be possible using hardware timers. But this is pure speculation. We briefly looked around and couldn’t find any working demos.
So Hackaday, how would you remotely sync two nRF24s on the cheap? Or is this a crazy idea? It might help to make transmissions more reliable in the face of 2.4 GHz band interference. Has anyone implemented their own frequency hopping scheme for the nRF24l01+?
