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!
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.
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.
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.