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.
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.
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”→
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!
[G6EJD] wanted to design a low power datalogger and decided to look at the power consumption of an ESP32 versus an ESP8266. You can see the video results below.
Of course, anytime someone does a power test, you have to wonder if there were any tricks or changes that would have made a big difference. However, the relative data is interesting (even though you could posit situations where even those results would be misleading). You should watch the videos, but the bottom line was a 3000 mAh battery provided 315 days of run time for the ESP8266 and 213 days with the ESP32.
The Bus Pirate is one of our favorite tool for quick-and-dirty debugging in the microcontroller world. Essentially it makes it easy to communicate with a wide variety of different chips via a serial terminal regardless of the type of bus that the microcontroller uses. Although it was intended as a time-saving prototyping device, there are a lot of real-world applications where a Bus Pirate can be employed full-time, as [Scott] shows us with his Bus Pirate data logger.
[Scott] needed to constantly measure temperature, and the parts he had on hand included an LM75A breakout board that has a temperature sensor on board. These boards communicate with I2C, so it was relatively straightforward to gather data from the serial terminal. From there, [Scott] uses a Python script to automate the process of gathering the data. The process he uses to set everything up using a Raspberry Pi is available on the project site, including the code that he used in the project.
[Scott] has already used this device for a variety of different projects around his house and it has already proven incredibly useful. If you don’t already have a Bus Pirate lying around there are a few other ways to gather temperature data, but if you have an extra one around or you were thinking about purchasing one, then [Scott]’s project is a great illustration of the versatility of this device.
Between Tesla Motors’ automobiles and SpaceX’s rockets, Elon Musk’s engineers just have to be getting something right. In part, SpaceX’s success in landing their first stage rockets is due to analysis of telemetry data. You can see some of the data from their launch vehicles on the live videos and there is surely a lot more not shown.
An article in MIT Technology Review provides similar insights in how Tesla came from behind in autonomous vehicle operation by analyzing telemetry from their cars. Since 2014 their Model S received an increasing number of sensors that all report their data over the vehicle’s always-on cellular channel. Sterling Anderson of Tesla reported they get a million miles of data every 10 hours.
The same approach can help us to improve our systems but many believe creating a log of key data is costly in time and resources. If your system is perfect (HA HA!) that would be a valid assessment. All too often such data becomes priceless if analysis explains why your drone or robot wanted to go left into a building instead of right into the open field.