Ask Hackaday: How Do You Python?

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.

Ask Hackaday: How Does This Air Particle Sensor Work?

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.

Ask Hackaday: Which Balaclava Is Best For Hacking?

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?

Continue reading “Ask Hackaday: Which Balaclava Is Best For Hacking?”

Ask Hackaday: Frequency Hopping on the nRF24l01+?

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+?

Ask Hackaday: Helping Hands

[ProtoG] sent us in this video (also below) where he demonstrates the use of machinist’s dial-gauge indicator arms as helping hands. I’ll admit that I got so jealous that I ordered a pair. I wouldn’t say that I need more tools to hold things in place, but I certainly want them. The rapid coarse placement combined with fine adjustment looks so sweet. Using them as scope-probe holders is brilliant.

Our own helping hands, purchased for $5 from a surplus shop, have seen nearly twenty years of use now. About ten years ago, I heat-shrinked and plasti-dipped the jaws, and since then they do less damage to cable insulation. The clips kept coming loose, but that was fixed with a little epoxy. I never used the magnifying glass, and by removing it I bought some more sliding room for the jaws, which was an easy win. The base has a “non-slip” coating of Shoe-Goo that keeps it in place on the desk. Cork might be classier.

For bigger holding, there’s always the desk vise, though I’ll admit that I mostly use it for holding PCBs while soldering, and that a better solution for that particular task wouldn’t hurt. [Mike Szczys] tells me that the Stickvise seen here is a handy thing to have on the bench. It started on Hackaday.io and we still carry it in the store.

For grabbing the fiddly little things, nothing beats a pair of hemostats and a range of tweezers. Hemostats in the desk vise make a great ad hoc holder. Good sharp tweezers pay for themselves with the first removed splinter, or placing SMT parts.

So, Hackaday, what do you use for holding things? What do you hold your PCBs with while soldering? What do you use to hold down SMD parts? What’s your third hand, or twenty-third? Continue reading “Ask Hackaday: Helping Hands”

Ask Hackaday: How Should Hackers Handle IP Agreements?

My buddy Harold recently landed a new job at a great technology company. It came at a perfect time for him, having just been laid off from the corporate behemoth where he’d toiled away as an anonymous cog for 19 years. But the day before he was to start, the new company’s HR folks sent him some last-minute documents to sign. One was a broad and vaguely worded non-compete agreement which essentially said he was barred from working in any related industry for a year after leaving the company.

Harold was tempted not to sign, but eventually relented because one needs to put food on the table. Thankfully he’s now thriving at the new company, but his experience got me thinking about all the complications hackers face with the day jobs that so many of us need to maintain. Non-competes and non-disclosures are bad enough, but there’s one agreement that can really foul things up for a hacker: the Intellectual Property Agreement.

Continue reading “Ask Hackaday: How Should Hackers Handle IP Agreements?”

Ask Hackaday: Bitten by the Crocodile Clip

I have a love/hate relationship with the crocodile clip. Nothing is so quick to lash together a few half-baked prototype boards on your desk, but nothing ends up in such a tangle so quickly, either. I love the range of pretty colors that crocodiles come in, as well as the easy ability to just clip on to the side of a PCB, or any old loose wire. But they come loose, they can have intermittent contacts, and we’re not even sure if there is such a thing as a current rating for them.

When [WarriorRocker] wrote in asking what we use instead of crocodile clips, he included a photo that sent a chill down my spine, from a review of some clips on Amazon. I’ve seen this one in real life. And what’s worse is the one with the loose wires that sometimes make contact with the spring-clip body and sometimes not.

After an hour-long debugging session about twelve years ago now, such an intermittent croc caused us to make a lifelong vow. All of our croco-clips have been disassembled, manually inspected, and many of them soldered together. When I buy new ones, I check them all before mixing them in with the known-goods. Even thinking about this now makes me want to pull back their little rubber booties just to make sure. Continue reading “Ask Hackaday: Bitten by the Crocodile Clip”