Download From NFC Datalogger, No App Required

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.

14 thoughts on “Download From NFC Datalogger, No App Required

    1. so you want to add a display to show always changing QR codes on a device that is meant to be low power consuming?
      I think nfc is the best option here, since it’s on demand and could be powered by the phone when in range. It also beat BLE, which is always on.

      1. Also good luck using that display for bidirectional communication. Or in an application that is severely size constrained, or needs to operate in severe conditions (like direct sunlight) for years without failing.

        But hey, they’re not trying to make a valid engineering point, it’s just a low-effort comment to tear down someone else’s hard work for their own gratification.

        1. How about a cheap eink display that has a fresh qrcode each hour? Surely that would be low power enough. Or push a button to refresh the code as eink displays don’t draw power with static content. Voila, no special phone required at all, infact, a second project could have a device with a camera just for collecting data. Say an esp32? pops it on an sd card and keeps appending data to a file per sensor.

      2. I actually have a sample device from a company called Logmore, and they did essentially the same thing as this project several years ago, except the Logmore device uses a 2cm by 2cm epaper display that it refreshes every hour or so. If I didn’t know better, I’d say this project was heavily inspired by the Logmore, especially in its usage of URLs for data uploading using a generic phone.

        1. Have you done much with the logmore? I’m hoping I can somehow steal the e-Eink display for use as it’s got the handy thermometer built in – however theres little documentation I can find on the logmore (for obvious reasons) in terms of it’s ability to be flashed with something else/whether the screen needs gubbins on the logmore pcb to operate

  1. Man I really feel NFC is extremely underrated, and not used in enough hobbyist projects.
    Granted, I myself have never used NFC, so I do not understand the limitations (I would imagine a limited data rate perhaps?)

    1. I agree, it is underrated. For me NFC technology by itself is not the problem but its developer usability (developer experience(?) is.

      If you need something more then just NDEF message (used in this project) you need to develop your own mobile application and you need to basically do it twice, one for Android and one for iOS. And NFC on iOS is very limited (maybe not that much in latest iOS but historically it was).

      One solution for this could be WebNFC API, but Apple claim that they will never implement this into Safari, bummer.

      If your use case does not utilize mobile phone and you would need to design both PICC and PCD side of thing, you lose big advantage and sexiness of NFC. Also, if you want to keep price of your project low, you need to design NFC antenna (coil) as part of PCB design. Design such an antenna is not trivial task.

      So, in summary, you need guy capable of design-controlled impedance PCB, programing MCUs, understanding NFC/RFID technology and be able to develop mobile applications. There is not much of such a guys out here probably, especially in hobby segment.

  2. It remembers me that today, after the browsers have inflated to the size of monsters (mozilla is a very appropriated name, btw) we went back, deep in the past, when you have to install a program (app) for every single little thing you want to do!
    Let alone that many apps are solely a browser inside a data mining shell. This is too bad, too wrong.

    1. Not even a browser inside a data mining shell – in android, apps can use chrome (in newer versions) or android system webview (in older ones) to display webpages within the app, so a lot of apps are basically a bundle of webpages with a wrapper – great for getting the filesize down, as you can piggyback off of the rendering/user/scripting engine that’s already there, while still having better offline stuff / easier storage/hardware access than a website

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.