Question: How similar is the code for the KnowFlow and the RIFFLE data loggers?

gretchengehrke is asking a question about riffle
Follow this topic

by gretchengehrke | November 13, 2017 17:24 | #15178

I'm curious if the KnowFlow data logger (see #knowflow and #data-logging) and the Riffle (see #riffle) are similar enough to operate using the same code. I know they are both Arduino based, but don't know how much of their respective code could be used on either device. Would the commands be the same, would they be easily adapted for the other device, or are they significantly different? Thanks!


I'm not familiar with the KnowFlow, but I would not expect there to be much overlap in the sketches which are typically used to run the two devices.

The Riffle is designed as a standalone datalogger which operates unattended for days or months. I think the KnowFlow is intended to be used manually to make individual measurements. So the entire structure of the code running the two devices would be quite different.

Each environmental sensor generally requires a specific library of functions, so unless each device had the same sensors attached the code to collect data from sensors would be substantially different.


I'd guess that there could be a lot of commonality in cases where you want to set up the same sensor on either device (or any Arduino). It could be really helpful for each team to clearly mark the sensor-specific code so that it can easily be re-used across!

Teams? There are going to be teams? Will they have T-shirts?

I'm still not sure overlapping code is relevant. If you have a working sketch for a KnowFlow and you want to start programming a Riffle, you don't start with the KnowFlow sketch. You find your friend's sketch for the Riffle and change what needs to be changed (hardware libraries, hardware initiations, hardware reads, sampling interval, variable names, pin assignments) depending on how your friend's hardware and goals differ from yours. If your Riffle uses the same sensor or RTC as your KnowFlow, you might be able to borrow a few lines of code.

Is this a question? Click here to post it to the Questions page.

Hey Chris - yep, the different groups developing these projects; i'd love to design t-shirts!

Modularizing and annotating code can go a very long way to ensuring reusability across platforms. If each team keeps their sensor-specific code clearly separated from the data-logging code, reusability should be possible.

I'm happy to help with this -- some approaches are:

  • use comment lines to mark sensor-specific sections of code: // -------- start conductivity probe code ---------- //
  • group code by purpose, and maintain a consistent API (say, wrap code in a function with named parameters) so that copying it into another file is easier, and you don't have to disentangle board-specific bits, so instead of a series of interleaved statements, you can use a standard function like getConductivityData()
  • you can separate code out into different files, which adds a little complexity in one sense, but helps maintain modularity and makes copying much easier

If we can list the different code examples we're working with here, i'm happy to suggest (and contribute pull requests for!) ways of modularizing!

Well-commented code is always helpful. At the novice level at which I work, good comments are sometimes hard to come by. I have often stolen uncommented code from the internet that works perfectly and I have no idea what it does.

One behavior to encourage is to include a URL for the libraries your sketch needs. People fork libraries all the time and often don't change the name. Some of my sketches use libraries which I would be hard-pressed to find again on the internet because there are several with the same name. Here is the library section of a sketch for the Nano Data Logger.

#include <SdFat.h> //
#include <SPI.h> //
#include <Wire.h> //
#include <RTClib.h> //
#include <Adafruit_BME280.h> //
#include <mlx90615.h> //
#include <LiquidCrystal_I2C.h> //

Great suggestions, Chris. Also:

I have often stolen uncommented code from the internet that works perfectly and I have no idea what it does.

This is more or less the idea behind a stable API -- you don't have to know how it works inside the box, as long as you can rely on it working the same way. If you were relying on a library in this way, and the author changed what it did, they'd be breaking the API, rendering your "downstream" code useless.

Some of the best comments can clearly delineate what a block of code does as it's "external interface" without having to go through explaining every line. Then anything inside that block could be changed, as long as it fulfills that external promise.

Reply to this comment...

I’m still waiting on my Riffle and I’m a rank beginner so this response needs to be accepted with a grain of salt. I believe that what Chris said is right on the point. I have coded both the KnowFlow and the mini-pearl. Beyond the obvious differences for discrete vs streaming sampling and given the same environmental sensor, there is considerable overlap in the code. That’s a fair number of caveats, but coding with one goes a long way toward coding the other. David

Cool. We'll have to get a third answer or Gretchen won't know what to think.

Reply to this comment...

A good question for @rockets and @shanlter too!

Reply to this comment...

Hi all, third answer here. Thanks for asking the question Gretchen, I actually have the same question. So this is not exact answer, I am hoping someone could correct me on this. The drawing is my understanding of the difference between products(brands). I don't think KnowFlow is a datalogger. I hope to change the arduino uno part of knowflow to Riffle, since it's cheaper, smaller, easier to put into bottles, etc.
concerning the code side, majority of KnowFlow's code is about control the sensors, I think can be used for other board as well.

@rockets, what's your opinion?



Is this a question? Click here to post it to the Questions page.

OMG, the image layout is horrible from my laptop, help needed @warren

:-) sorry, i'll push a new change which will fix this in a bit!

Fixed! Thanks for finding this issue!


the pic is great. crystal!

Reply to this comment...

Log in to comment