TshWatch is a project by [Ivan / @pikot] that he’s been working on for the past two years. [Ivan] explains that he aims to create a tool meant to help you understand your body’s state. Noticing when you’re stressed, when you haven’t moved for too long, when your body’s temperature is elevated compared to average values – and later, processing patterns in yourself that you might not be consciously aware of. These are far-reaching goals that commercial products only strive towards.
At a glance it might look like a fitness tracker-like watch, but it’s a sensor-packed logging and measurement wearable – with a beautiful E-Ink screen and a nice orange wristband, equipped with the specific features he needs, capturing the data he’d like to have captured and sending it to a server he owns, and teaching him a whole new world of hardware – the lessons that he shares with us. He takes us through the design process over these two years – now on the fifth revision, with first three revisions breadboarded, the fourth getting its own PCBs and E-Ink along with a, and the fifth now in the works, having received some CAD assistance for battery placement planning. At our request, he has shared some pictures of the recent PCBs, too!
Most of the design and engineering required to improve the efficiency of the data logger involve standard practices for low-power devices such as shutting off unnecessary components and putting the device to sleep when not actively running, but this build goes far beyond that. The Vcc pin on the RTC was clipped which disables some of its internal logic but still keeps its basic functionality intact.
All of the voltage regulators were removed or disabled in favor of custom circuitry that doesn’t waste as much energy. The status and power LEDs were removed where possible, and the entire data logger is equipped with custom energy-efficient code as well.
If you’re starting a low-power project, even one that isn’t a datalogger, it’s worth checking out this build to see just how far you can go if you’re willing to hack at a PCB with cutting tools and a soldering iron. As to why this data logger needed such a low power requirement, it turns out it’s part of a kit being used in classrooms and using a coin cell brought the price of the entire unit down tremendously. Even if you have lithium cells on hand, though, it’s still worthwhile to check out the low power modes of your microcontroller.
Many of us electronics hacker types tend to have at least the same common equipment on our benches, namely a multimeter, an oscilloscope, some sort of adjustable power supply, and maybe a logic analyzer. These are great tools covering many bases, but dealing with temperature measurements is often neglected. A sudden need for such often results in just buying a either dedicated measurement unit, or some cheap eBay thermocouple board and just rolling with a few hacks. [Jana Marie Hemsing] had a need for measuring the thermal side of things, and got fed up with hacking with piles of boards, and designed herself a proper instrument for the task.
The result is a very tidy four-channel thermocouple frontend, feeding the data into the host computer via USB. Each of the four channels can either be a K-type input or a NTC thermistor input, decided at board assembly time, but you could just build two units with four channels of each and cover all bases. The K-type thermocouple input is based around the MAX31855 series device. While the ‘KASA’ suffixed device is probably most common, if you need to dedicate some channels to handling one of the other six or so other common thermocouple types, that just needs the appropriate MAX31855 variant dropping in, and you’re good to go.
For the controller, [Jana] has chosen the common STM32F0x microcontroller, which handles all the USB protocol side of things. The extra functionality added allows direct driving of a heater controller via the DRV8837 H-Bridge, with a extra few open collector outputs for other things you might want to drive. This allows the logger to function as a kind-of thermal IO device. Firmware is written in good old fashioned STM32 HAL, using the standard STM32CubeMX and the GCC toolchain. It looks like the Makefile came via the STM32 Project Generator route. The firmware has a neat trick up its sleeve too; with a flick of the switch on the back, the firmware can switch between outputting CSV data over a standard USB CDC link (a virtual serial port), or it can present a SCPI terminal interface, enabling integration into existing SCPI-based test flows. Nice work!
The plethora of wireless technologies has made internet-connected devices the norm, but it’s not always necessary if you don’t need real-time updates. Whether it’s due to battery life, or location and range constraints, downloading data directly from the device whenever possible might be a viable solution. [Malcolm Mackay] demonstrates an elegant solution on the open source cuplTag temperature/humidity logger, using any NFC-enabled smartphone, without requiring a custom app.
The cuplTag utilizes the feature on NFC-enabled smartphones to automatically open a URL provided by the cuplTag. It encodes the sensor data from the sensor unit as a circular buffer in a ~1 kB URL, which automatically uploads to a web frontend that plots the data. (You can use their server or run your own.)
This means that data can be collected by anyone with the appropriate phone with zero setup. The data is displayed on the web app and can be downloaded as a CSV. To deter spoofing, each tag ships with a secret key which is used to generate a unique HMAC every time the circular buffer changes.
Battery life is a priority on the cuplTag, and it’s theoretically capable of running seven years on a single CR1220 coin cell using the current-sipping Texas Instruments MSP430 microcontroller. The hardware, firmware, and server-side frontend and backend code are all open source and available on GitHub.
Earlier this year, we held a data logging contest, and featured submissions that monitored everything from your garden’s moisture levels to your caffeine intake.
If a temperature sensor takes a measurement in the woods but there’s nobody around to read it, is it hot out?
If you’ve got a project that’s collecting data, you might have reasons to put it online. Being able to read your data from anywhere has its perks, after all, and it’s key to building smarter interconnected systems, too. Plus, you can tell strangers the humidity in your living room while you’re out at the pub, and they’ll be really impressed.
Taking the leap into the Internet of Things can be daunting however, with plenty of competing services and options from the basic to the industrial-strength available. Today, we’re taking a look at two options for logging data online that are accessible to the beginner. Continue reading “Easy IoT Logging Options For The Beginner”→
We’re all familiar with the “Black Box” used on commercial aircraft, the flight data recorder which captures the minutia of each and every flight on the off-chance that it’s needed in the event of an accident. But even in less dire circumstances, the complete record of the aircraft’s performance versus what was commanded of it by the pilot can be used to fine tune performance or detect faults before they become serious.
As a data engineer for professional motorsports, [Jussi Luopajärvi] knows similar recorders can be just as useful for vehicles stuck here on terra firma. His entry into the 2019 Hackaday Prize, TestLogger, aims to bring that same kind of technology to the world of RC racing. The gadget allows the driver to easily record a wealth of data about the vehicle during races, giving them valuable insight into the vehicle’s performance.
So what kind of variables are there to record on a 1/8th or 1/12th scale car? Don’t be fooled by their diminutive wheelbases, the modern RC car relies on an impressive amount of technical wizardry that benefits from a close eye.
Right now, [Jussi] says TestLogger can record not only obvious elements like battery level and throttle, but also more esoteric variables such as steering input, individual drive wheel speed, angular velocity, and even g-force in three dimensions. There’s also support for a trackside IR beacon that allows TestLogger to record lap times.
All of the data is stored on TestLogger’s SD card in standard CSV files, which makes it easy for us hacker types to parse and analyze. But for those who are more interested in driving than delimiting, there’s also a very slick website that will let users upload and compare their data. This complete user experience gives TestLogger a very professional feel, and we can’t wait to see where [Jussi] takes it from here.
It’s no secret that I rather enjoy connecting things to the Internet for fun and profit. One of the tricks I’ve learned along the way is to spin up simple APIs that can be used when prototyping a project. It’s easy to do, and simple to understand so I’m happy to share what has worked for me, using Web2Py as the example (with guest appearances from ESP8266 and NodeMCU).
Barring the times I’m just being silly, there are two reasons I might do this. Most commonly I’ll need to collect data from a device, typically to be stored for later analysis but occasionally to trigger some action on a server in the cloud. Less commonly, I’ll need a device to change its behavior based on instructions received via the Internet.
In the former case, my first option has always been to use IoT frameworks like Thingsboard or Ubidots to receive and display data. They have the advantage of being easy to use, and have rich features. They can even react to data and send instruction back to devices. In the latter case, I usually find myself using an application programming interface (API) – some service open on the Internet that my device can easily request data from, for example the weather, blockchain transactions, or new email notifications.
Occasionally, I end up with a type of data that requires processing or is not well structured for storage on these services, or else I need a device to request data that is private or that no one is presently offering. Most commonly, I need to change some parameter in a few connected devices without the trouble of finding them, opening all the cases, and reprogramming them all.
At these times it’s useful to be able to build simple, short-lived services that fill in these gaps during prototyping. Far from being a secure or consumer-ready product, we just need something we can try out to see if an idea is worth developing further. There are many valid ways to do this, but my first choice is Web2Py, a relatively easy to use open-source framework for developing web applications in Python. It supports both Python 2.7 and 3.0, although we’ll be using Python 3 today.