PyOBD Gets Python3 Upgrades

One of the best things about open source software is that, instead of being lost to the ravages of time like older proprietary software, anyone can dust off an old open source program and bring it up to the modern era. PyOBD, a python tool for interfacing with the OBD system in modern vehicles, was in just such a state with its latest version still being written in Python 2 which hasn’t had support in over three years. [barracuda-fsh] rewrote the entire program for Python 3 and included a few other upgrades to it as well.

Key feature updates with this version besides being completely rewritten in Python 3 include enhanced support for OBD-II commands as well as automating the detection of the vehicle’s computer capabilities. This makes the program much more plug-and-play than it would have been in the past. PyOBD now also includes the python-OBD library for handling the actual communication with the vehicle, while PyOBD provides the GUI for configuring and visualizing the data given to it from the vehicle. An ELM327 adapter is required.

With options for Mac, Windows, or Linux, most users will be able to make use of this software package provided they have the necessary ELM327 adapter to connect to their vehicle. OBD is a great tool as passenger vehicles become increasingly computer-driven as well, but there are some concerns surrounding privacy and security in some of the latest and proposed versions of the standard.

Open-Source Cell Phone Based On ESP32

Over the past decade or so, smartphones have exploded in popularity and seamlessly integrated themselves into nearly every aspect of most people’s lives. Although that comes with a few downsides as well, with plenty of people feeling that the smart phone makes it a little too easy to waste time and looking to switch to something simpler, like an older-style flip phone. If this style of phone is more your speed, take a look at this DIY cell phone which takes care of everything a phone really needs to do. (Google Translate from French)

The phone uses an ESP32 at its core, with a SIM800L GSM modem to interact with the cell network, including retrieving the system time. A small battery is included as well as all of the support circuitry for charging it as well as a USB interface that can communicate to a PC. The operating system for the phone is built from the ground up as well, with a touch screen interface allowing the user to make phone calls, send text messages, store contacts, and a few other basic features. There’s also a GPS application though, allowing the phone to know basic location information.

Another perk of this device is that its creator, [Gabriel], made the design schematics, print files for the case, and the operating system software completely open source for anyone to build this phone on their own. Everything is available on the project’s GitHub page. It’s a fairly remarkable achievement, especially considering [Gabriel] is only 16. And, if you’re not one to eschew modern smart phone technology there are some DIY smart phones available to build as well.

Thanks to [come2] for the tip!

An Open-Source, Free Circuit Simulator

The original circuit simulation software, called the Simulation Program with Integrated Circuit Emphasis, or SPICE as it is more commonly known, was originally developed at the University of Califorina Berkeley in the 1970s with an open-source license. That’s the reason for the vast versions of SPICE available now decades after the original was released, not all of which are as open or free as we might like. Qucs is a GPL circuit simulator. And if you want the GUI option, you might want to try out QucsStudio, which uses Qucs under the hood, and is free to use, but binary-only.

(Editor’s note: the author was confused between the GPL open-source Qucs and the closed-source, binary-only QucsStudio. We’ve cleaned that up.)

QucsStudio supports a wide range of circuit components and models much in the same fashion as other more popular SPICE programs, including semiconductor devices, passive components, and digital logic gates. Qucs also utilizes SPICE-based simulation, which can model various types of circuit behavior, such as DC, AC, transient, and small-signal analysis.

Unfortunately there are only Windows versions available, and although some might have some success running it under WINE. There are plenty of other options for those of us running non-Windows operating systems though. Here’s a review of 30 of them.

Thanks to [Electroagenda] for the tip!

A Deep Dive On Battery Life

There are all kinds of old wives’ tales surrounding proper battery use floating around in the popular culture. Things like needing to fully discharge a battery every so often, unplugging devices when they’re fully charged, or keeping batteries in the fridge are all examples that have some kernel of truth to them but often are improperly applied. If you really want to know the truth about a specific battery, its behavior, and its features, it helps to dig in and actually take some measurements directly like [Tyler] has done with a vast array of embedded batteries in IoT devices.

[Tyler] is a firmware engineer by trade, so he is deeply familiar with this type of small battery. Battery performance can change dramatically under all kinds of scenarios, most important among them being temperature. But even the same type of battery can behave differently to others that are otherwise identical, which is why it’s important to have metrics for the batteries themselves and be able to measure them to identify behaviors and possible problems. [Tyler] has a system of best practices in place for monitoring battery performance, especially after things like firmware upgrades since small software changes can often have a decent impact on battery performance.

While working with huge fleets of devices, [Tyler] outlines plenty of methods for working with batteries, deploying them, and making sure they’re working well for customers. A lot of it is extremely useful for other engineers looking to develop large-scale products like this but it’s also good knowledge to have for those of us rolling out our own one-off projects that will operate under battery power. After all, not caring for one’s lithium batteries can have disastrous consequences.

Suc Aims To Replace Slack In Five Lines Of Bash

The design philosophy of Unix is fairly straightforward. Software should do one thing as simply as possible, and do that one thing only. As a design principle this is sound advice even well outside of the realm of Unix, and indeed software in general, but that doesn’t stop modern software packages from being too large for their own good. So, if you’re tired of bloated chat programs like Slack or Mattermost with their millions of lines of code, you might instead favor something like Simple Unix Chat (suc).

The idea is that suc can perform almost all modern chat functions in only five lines of Bash, supporting rich-text chat, file sharing, access control, and encryption. These five lines, though, only perform the core function of suc — which is to write text to a file on the system. Indeed, suc makes liberal use of plenty of other Unix services which do not add to the line counts, such as the use of SSH to handle authentication. It also relies on some other common Unix system features to handle things like ownership and access for the text files that host the text for the chat.

As channels are simply text files, it makes writing bots or other tools exceptionally simple. You can also easily pipe the output of commands directly into suc with one-liners that can do things like dump the output of make into a specific channel if compilation fails.

While it’s not likely that everyone will ditch tools like Slack to switch to something like this, it’s still an impressive demonstration of what can be done when designing around the Unix philosophy and taking advantage of system tools that already exist rather than reinventing the wheel and re-programming all of those tools into the application. Practices like this might decrease development time and increase the ease of developing cross-platform applications but they often also produce a less than desirable user experience.

The Other Way To Fight Software Rental

It’s been a distressing trend over the last decade, that of taking commercial software from a paid-for licence model and moving into the cloud and onto a rental model. In out line, we’ve seen this with CAD packages and notably with EAGLE PCB CAD, but it’s hit other sectors in exactly the same way. The art and design communities, in particular, are feeling the pinch from Adobe Suite going towards a rental model, and now the artist and perennial thorn in the side of anyone who seeks to own a colour, [Stuart Semple] is doing something about it. He’s launching a competing suite called provocatively, Abode, which will follow an affordable paid-for licence model. It’s a development that raises interesting questions for the open source community, so it’s definitely worth a second look from that perspective.

Taking on software rental can only be a good thing, and we hope that the new package gains a foothold for that reason. But since we’re sure that there will be open-source enthusiasts asking the question: why are the established open-source equivalents such as GIMP and Inkscape not the obvious alternatives to the Adobe suite? In there may be some uncomfortable moments of soul searching for the software libre world around usability and interfaces.

Whatever your take on open source versus paid software, it’s extremely encouraging to have somebody mount a high-profile challenge to the software rental model. We hope that Abode makes it to market and that it succeeds in making the graphics software market a little more open. Meanwhile, we’ve mentioned [Stuart Semple] before for his colour activism over the blackest of blacks, and for previously taking on Adobe over Pantone pricing.

Computer Speed Gains Erased By Modern Software

[Julio] has an older computer sitting on a desk, and recorded a quick video with it showing how fast this computer can do seemingly simple things, like open default Windows applications including the command prompt and Notepad. Compared to his modern laptop, which seems to struggle with even these basic tasks despite its impressive modern hardware, the antique machine seems like a speed demon. His videos set off a huge debate about why it seems that modern personal computers often appear slower than machines of the past.

After going through plenty of plausible scenarios for what is causing the slowdown, [Julio] seems to settle on a nuanced point regarding abstraction. Plenty of application developers are attempting to minimize the amount of development time for their programs while maximizing the number of platforms they run on, which often involves using a compatibility layer, which abstracts the software away from the hardware and increases the overhead needed to run programs. Things like this are possible thanks to the amount of computing power of modern machines, but not without a slight cost of higher latency. For applications developed natively, the response times would be expected to be quite good, but fewer applications are developed natively now including things that might seem like they otherwise would be.  Notepad, for example, is now based on UWP.

While there are plenty of plausible reasons for these slowdowns in apparent speed, it’s likely a combination of many things; death by a thousand cuts. Desktop applications built with a browser compatibility layer, software companies who are reducing their own costs by perhaps not abiding by best programming practices or simply taking advantage of modern computing power to reduce their costs, and of course the fact that modern software often needs more hardware resources to run safely and securely than equivalents from the past.