logging

12 Articles

Remote Water Quality Monitoring

March 20, 2023 by 8 Comments

While it can be straightforward to distill water to high purity, this is rarely the best method for producing water for useful purposes. Even drinking water typically needs certain minerals in it, plants may need a certain pH, and wastewater systems have a whole host of other qualities that need to be measured. Measuring water quality is a surprisingly complex endeavor as a result and often involves a wide array of sensors, much like this water quality meter from [RowlesGroupResearch].

The water quality meters that they are putting to use are typically set up in remote locations, without power, and are targeting natural bodies of water and also wastewater treatment plants. Temperature and pH are simple enough to measure and grasp, but this device also includes sensors for total dissolved solids (TDS) and turbidity which are both methods for measuring various amounts and types of particles suspended in the water. The build is based around an Arduino so that it is easy for others to replicate, and is housed in a waterproof box with a large battery, and includes data logging to an SD card in order to make it easy to deploy in remote, outdoor settings and to gather the data at a later time.

The build log for this device also goes into detail about all of the steps needed to set this up from scratch, as well as a comprehensive bill of materials. This could be useful in plenty of professional settings such as community wastewater treatment facilities but also in situations where it’s believed that industrial activity may be impacting a natural body of water. For a water quality meter more focused on drinking water, though, we’d recommend this build that is trained on its own neural network.

More Software-Defined Radio Projects Using DragonOS

November 3, 2021 by 14 Comments

DragonOS, a Debian-based Linux distribution specifically packaged for software-defined radio functionality, roared onto the wavelengths during the beginnings of the various pandemic lockdowns last year. Since then [Aaron], the creator of the OS, has been busy adding features to the distribution as well as creating plenty of videos which show off its capabilities and also function as how-tos for people who might want to learn about software-defined radio. The latest is a video about using this software to detect radio signals in certain specified spectrums.

This build uses two  RTL-SDR devices paired with the DragonOS software suite to automatically detect active frequencies within a specified frequency range and that aslo exceed a threshold measured above the average noise floor. The video includes the setup of the software and its use in detecting these signals, but also includes setup of influxdb and Grafana which provide logging capabilities as well. Using this setup, multiple receivers either local or over the internet can then be configured to dump all the identified frequencies, powers, and time stamps into DragonOS.

[Aaron] has also been helping developers to build the SDR4space.lite application which includes GPS support, so he hopes that in a future video a user will be able to easily associate location to identified frequencies. Projects like these also serve as a reminder that getting into software-defined radio is as easy as buying a $10 USB radio receiver and configuring some free software to do anything that you can imagine like tracking ships and airplanes in real time.

Continue reading “More Software-Defined Radio Projects Using DragonOS” →

Beyond Printf(): Better Logging Practices For Faster Debugging

July 21, 2020 by 27 Comments

All of us who do some programming know that logging is a time-tested way to output messages about the internal state of our code. With varying degrees of adjustable granularity, these messages allow us to keep track of not only the state of the application, but also its overall health. When things do end up going FUBAR, these log messages are usually the first thing we look at as a software equivalent of a Flight Data Recorder in an airplane.

Spending some time and care in not only designing the logging system, but also in deciding what should be logged and at what level, can make our future self appreciate life a lot more. We’re all familiar with the practice of ‘printf-debugging’, where logging is added as part of the usual post-crash autopsy as one tries to figure out what exactly went wrong. It’s one way of doing it, and eventually it works, but we can do much better.

People are lazy, and you’re only going to stick to good logging practices if they are at least as easy if not easier than sprinkling printf() statement throughout the code. Yet at the same time we want to be able to handle things like log levels and newlines without too much extra typing. The most successful logging libraries are built with this

Continue reading “Beyond Printf(): Better Logging Practices For Faster Debugging” →

A Super-Brain For An E-bike

March 7, 2020 by 12 Comments

There’s no better way of improving a project than logging data to make informed decisions on future improvements. When it came to [Brian]’s latest project, an electric bike, he wanted to get as much data as he could from the time he turned it on until the time he was finished riding. He turned to a custom pyBoard-based device (and wrote it up on Hackaday.io), but made it stackable in order to get as much information from his bike as possible.

This isn’t so much an ebike project as it is about a microcontroller platform that can be used as a general purpose device. All of the bike’s controls flow through this device as a logic layer, so everything that can possibly be logged is logged, including the status of the motor and battery at any given moment. This could be used for virtually any project, and the modular nature means that you could scale it up or down based on your specific needs. The device is based on an ARM microcontroller so it has plenty of power, too.

While the microcontroller part is exceptionally useful ([Brian] talks about some of its other uses here and gives us even more data on his personal webpage), we shouldn’t miss the incredible bike that [Brian] built either. It has a 3 kW rear hub motor and can reach speeds of around 60 mph. While we let the commenters below hash out the classic argument of “bicycle vs. motorcyle” we’ll be checking out some electric vehicles that are neither.

Give Your Raspberry Pi SD Card A Break: Log To RAM

April 8, 2019 by 82 Comments

The fragility of SD cards is the weak link in the Raspberry Pi ecosystem. Most of us seem to have at least one Pi tucked away somewhere, running a Magic Mirror, driving security cameras, or even taking care of a media library. But chances are, that Pi is writing lots and lots of log files. Logging is good — it helps when tracking down issues — but uncontrolled logging can lead to problems down the road with the Pi’s SD card.

[Erich Styger] has a neat way to avoid SD card logging issues on Raspberry Pi, he calls it a solution to reduce “thrashing” of the SD card. The problem is that flash memory segments wear out after a fairly low number of erase cycles, and the SD card’s wear-leveling algorithm will eventually cordon off enough of the card to cause file system issues. His “Log2Ram” is a simple Unix shell script that sets up a mount point for logging in RAM rather than on the SD card.

The idea is that any application or service sending log entries to /var/log will actually be writing them to virtual log files, which won’t rack up any activity on the SD card. Every hour, a cron job sweeps the virtual logs out to the SD card, greatly reducing its wear. There’s still a chance to lose logging data before it’s swept to disk, but if you have relatively stable system it’s a small price to pay for the long-term health of a Pi that’s out of sight and out of mind.

One thing we really like about [Erich]’s project is that it’s a great example of shell scripting and Linux admin concepts. If you need more information on such things, check out [Al Williams’] Linux-Fu series. It goes back quite a way, so settle in for some good binge reading.

“DB” = Abbreviated Microcontroller Debugging

December 20, 2018 by 19 Comments

We’ve all been there. When debugging a microcontroller project, we just want to put in a print statement to figure out what’s going on with the microcontroller in real time. However, advanced embedded programmers know that printf statements are verboten: they’re just too SLOW. While not fixing this plight entirely, [Atakan Sarioglu] has come up with a clever way to create readable debug messages with minimal runtime overhead.

[Atakan Sarioglu]’s innovation, called BigBug (Github), is a dynamically-generated codebook. The codebook translates abbreviated messages sent over serial (UART here) to longer-form human-readable messages. To generate the codebook, BigBug automatically parses your comments to create a lookup between an abbreviation and the long-form message. When you are running your program on the microcontroller, BigBug will translate the short codes to long messages in real-time as you send log/debug data over serial. Continue reading ““DB” = Abbreviated Microcontroller Debugging” →

Card Reader Lockout Keeps Unauthorized Tool Users At Bay

May 20, 2018 by 19 Comments

It’s a problem common to every hackerspace, university machine shop, or even the home shops of parents with serious control issues: how do you make sure that only trained personnel are running the machines? There are all kinds of ways to tackle the problem, but why not throw a little tech at it with something like this magnetic card-reader machine lockout?

[OnyxEpoch] does not reveal which of the above categories he falls into, if any, but we’ll go out on a limb and guess that it’s a hackerspace because it would work really well in such an environment. Built into a sturdy steel enclosure, the guts are pretty simple — an Arduino Uno with shields for USB, an SD card, and a data logger, along with an LCD display and various buttons and switches. The heart of the thing is a USB magnetic card reader, mounted to the front of the enclosure.

To unlock the machine, a user swipes his or her card, and if an administrator has previously added them to the list, a relay powers the tool up. There’s a key switch for local override, of course, and an administrative mode for programming at the point of use. Tool use is logged by date, time, and user, which should make it easy to identify mess-makers and other scofflaws.

We find it impressively complete, but imagine having a session timeout in the middle of a machine operation would be annoying at the least, and potentially dangerous at worst. Maybe the solution is a very visible alert as the timeout approaches — a cherry top would do the trick!

There’s more reading if you’re one seeking good ideas for hackerspace. We’ve covered the basics of hackerspace safety before, as well as insurance for hackerspaces.

Continue reading “Card Reader Lockout Keeps Unauthorized Tool Users At Bay” →