Yet Another Rigol DS1054Z Viewer

May 26, 2021 by Chris Lott 22 Comments

Tired of squinting at the small numbers on the oscilloscope display, [Alfred] aka [Gaze@] decided to take matters into his own hands and wrote yet another tool to remotely view images from a Rigol DS1054Z. At least that was the initial idea. But, it grew unexpectedly — as [Alfred] says, “the more the project turned out to be fun, the more it got out of hand”. We know the feeling well.

In addition to being able to simply view and export the screen, the program implements waveform measurements (we’re not sure if it is using the measurement ability of the ‘scope, or actually performing measurements in the program). And as you can see in the animated GIF of the program in operation over on the GitHub repository, the numbers are certainly clear and legible. His problem of squinting at the small screen has indeed been solved.

This is coded in Pascal (FPC Lazarus), but we weren’t able to browse the program because [Alfred] hasn’t posted the source code yet. It is written only for Linux, and he has tested it on Ubuntu, Debian, Fedora, and Manjaro. The project relies on Python, PyVisa, and gtk2, and talks to your DS1054Z over USB or LAN. The installation instructions are well documented, but as [Alfred] himself warns, if you encounter trouble arising from subtle dependency version conflicts, you may need to be a nerd and/or a pensioner with unlimited time on your hands to solve them. There is no users guide nor extensive help according to [Alfred]. However, simple hints might be found in hover text or by pressing F1. Disclaimers aside, this looks like an interesting project to try out.

As [Alfred] notes, there are many other tools available to fetch data and images from your Rigol oscilloscope. [Jenny List] wrote a two-part series on using Python to control your test instruments, and here’s an example of a simple Python script that does a screen grab. Do you have a favorite way to remotely operate your oscilloscope? Let us know in the comments below.

Running Modern Linux From A Single Floppy Disk

May 24, 2021 by Tom Nardi 34 Comments

There was a time when booting Linux from a floppy disk was the norm, but of course, those days are long gone. Even if you still had a working 3.5 inch drive, surely the size of the modern kernel alone would far exceed the 1.44 MB capacity of the disks, to say nothing of all the support software required to create a usable operating system. Well that’s what we thought, anyway.

But then [Krzysztof Krystian Jankowski] dropped Floppinux, a live Linux OS that boots from just a single floppy. There’s even a few hundred KB left over on the disk, allowing the user to tuck a few of their own programs and scripts onboard before booting it up. But most impressively, the project doesn’t rely on ancient software releases like so many other embedded systems do. Every component of Floppinux is pulled directly from the cutting edge, including version 5.13.0-rc2 of the Linux kernel which is literally just a few days old.

Of course some concessions had to made in order cram the latest Linux kernel and build of BusyBox into slightly north of 1 MB, so Floppinux certainly isn’t what anyone would call a daily driver. The kernel is stripped down the absolute minimum, and is targeted for the decidedly poky i486. [Krzysztof] had to be very selective about which programs actually made the cut as well, so once the system is booted, there’s not a whole lot you can do with it outside of writing some shell scripts. But then, that was sort of the goal to begin with.

If you’re wondering how [Krzysztof] pulled it off, you don’t have to. He walks you though the entire process, down to the commands he used to do everything from pull down and compile the source code to creating the final disk image. Even if you don’t own a floppy drive, it’s well worth following his guide and booting the image up in QEMU just to say you’ve officially built a Linux system from scratch. It’s good for more than just bragging rights; learning how all the components of a minimal install like this fits together will no doubt come in handy the next time you find yourself poking around inside an embedded Linux device.

Otters Deliver A High Power Stationary Audio Experience

May 12, 2021 by Kerry Scharfglass 20 Comments

Our favorite raft of otters is back at it again with another display of open source audio prowess as they bring us the OtterCastAmp, the newest member of the OtterCast family of open source audio multitools. If you looked at the previous entry in the series – the OtterCastAudio – and thought it was nice but lacking in the pixel count or output power departments then this is the device for you.

The Amp is fundamentally a very similar device to the OtterCastAudio. It shares the same Allwinner S3 Cortex-A application processor and runs the same embedded Linux build assembled with Buildroot. In turn it offers the same substantial set of features and audio protocol support. It can be targeted by Snapcast, Spotify Connect or AirPlay if those are your tools of choice, or act as a generic PulseAudio sink for your Linux audio needs. And there’s still a separate line in so it source audio as well.

One look at the chassis and it’s clear that unlike the OtterCastAudio this is not a simple Chromecast Audio replacement. The face of the OtterCastAmp is graced by a luscious 340×800 LCD for all the cover art your listening ear can enjoy. And the raft of connectors in the back (and mountain of inductors on the PCBA) make it clear that this is a fully fledged class D amplifier, driving up to 120W of power across four channels. Though it may drive a theoretical 30W or 60W peak across its various outputs, with a maximum supply power of 100W (via USB-C power delivery, naturally) the true maximum output will be a little lower. Rounding out the feature set is an Ethernet jack and some wonderfully designed copper PCB otters to enjoy inside and out.

As before, it looks like this design is very close to ready for prime time but not quite there yet, so order at your own risk. Full fab files and some hints are linked in the repo mentioned above. If home fabrication is a little much it looks like there might be a small manufacturing run of these devices coming soon.

Linux Fu: Mixing Bash And Python

May 4, 2021 by Al Williams 24 Comments

Although bash scripts are regularly maligned, they do have a certain simplicity and ease of creation that makes them hard to resist. But sometimes you really need to do some heavy lifting in another language. I’ll talk about Python, but actually, you can use many different languages with this technique, although you might need a little adaptation, depending on your language of choice.

Of course, you don’t have to do anything special to call another program from a bash script. After all, that’s what it’s mainly used for: calling other programs. However, it isn’t very handy to have your script spread out over multiple files. They can get out of sync and if you want to send it to someone or another machine, you have to remember what to get. It is nicer to have everything in one file.

Continue reading “Linux Fu: Mixing Bash And Python” →

Linux Fu: A Little Bit Of (Network) History Repeating Itself

April 26, 2021 by Al Williams 5 Comments

These days, embedded systems often have networks and that can make them significantly more complex. Networks are usually pretty nondeterministic and there are a variety of oddball conditions. For example, when your public-access pick and place machine gets written up on Hackaday and you suddenly get a 50X surge in traffic, how does your network stack handle it? While there’s no silver bullet for network testing, there are some tricks that can make it easier and one of those is the tcpreplay utilities that allow you to record complex network traffic and then play it back in a variety of ways. This has many benefits, especially if you manage to capture that one thing that triggers bad behavior sporadically. Being able to play it back on demand can speed up diagnostics considerably.

General Idea

You probably know that tcpdump allows you to grab packet captures from a network interface and save them to a file. If you prefer a GUI, you probably use Wireshark, which uses the same underlying library (libpcap) to grab the data. In fact, you can capture data using tcpdump and look at it with Wireshark, although there are other tools like tcptrace or Ngrep that can work with the output, also.

While the output of the command can be a little cryptic without tool support, a program called tcpreplay can take that data and feed it back in a variety of ways. Of course, you can modify the file first — there are tools to make that easier and — if you need to — you can craft your own network traffic by hand or using one of a variety of tools. This process is often called “packet crafting.”

Continue reading “Linux Fu: A Little Bit Of (Network) History Repeating Itself” →

AI Makes Linux Do What You Mean, Not What You Say

April 20, 2021 by Al Williams 30 Comments

We are always envious of the Star Trek Enterprise computers. You can just sort of ask them a hazy question and they will — usually — figure out what you want. Even the automatic doors seemed to know the difference between someone walking into a turbolift versus someone being thrown into the door during a fight. [River] decided to try his new API keys for the private beta of an AI service to generate Linux commands based on a description. How does it work? Watch the video below and find out.

Some examples work fairly well. In response to “email the Rickroll video to Jeff Bezos,” the system produced a curl command and an e-mail to what we assume is the right place. “Find all files in the current directory bigger than 1 GB” works, too.

Continue reading “AI Makes Linux Do What You Mean, Not What You Say” →

Linux Fu: Shell Script File Embedding

April 9, 2021 by Al Williams 25 Comments

You need to package up a bunch of files, send them somewhere, and do something with them at the destination. It isn’t an uncommon scenario. The obvious answer is to create an archive — a zip or tar file, maybe — and include a shell script that you have to tell the user to run after unpacking.

That may be obvious, but it assumes a lot on the part of the remote user. They need to know how to unpack the file and they also need to know to run your magic script of commands after the unpack. However, you can easily create a shell script that contains a file — even an archive of many files — and then retrieve the file and act on it at run time. This is much simpler from the remote user’s point of view. You get one file, you execute it, and you are done.

In theory, this isn’t that hard to do, but there are a lot of details. Shell scripts are not compiled — at least, not typically — so the shell only reads what it needs to do the work. That means if your script is careful to exit, you can add as much “garbage” to the end of it as you like. The shell will never look at it, so it’s possible to store the payload there.

Continue reading “Linux Fu: Shell Script File Embedding” →