What are the default units? I'm thinking about how the CSV will be uploaded and graphed. Looks great!

Looks great! Two thoughts: (1) definitely important comment by Jeff about units and potentially a post-data-retrieval function for units conversion if you upload a calibration curve to the graphing platform, (2) do you have a "best practices" guideline or materials-sourcing for attaching the water bottle housing and keeping it submerged at a specified depth?

Great point! @warren and @gretchengehrke Need to figure out those default units. Was actually just musing about that, and wrote this: https://publiclab.org/notes/donblair/12-15-2015/universal-hardware-registry :)

And that "best practices" guideline sounds like a great document to jam on!

The basic trade-off I see is that: it's actually a pain to reprogram the device with calibration corrections every time you do calibration, even though it seems like it makes it easier in the beginning to get simple units off the device. So what I've heard suggested often is that you always just get "raw values", and they need to be associated with units outside the device. So we could maybe just say "parameter 1, parameter 2, parameter 3", and then keep metadata, updated regularly, that describes how to get units from those parameters.

All that said, to begin with (Beta), to make things easy, we could e.g. say "Temperature in C, and conductivity in frequency" and then you have to convert frequency using a conversion factor to standard conductivity units, like microSiemens / cm -- and you understand that sometimes you'll want to have a correction factor for the temperature, too.

Hi Don, I was assuming the output would be in frequency for both, but there would be an algorithm before the graphing step to do a unit conversion, factoring in temperature and calibration. I think that is how Hobos work, but I'm not 100% sure.

Ah, great -- yes, that's what seems most sensible to me, too. TMI: By frequency I meant the "555 timer output frequency" for the conductivity reading ... for temperature the "raw" value would actually be a voltage measurement, given how we're measuring temperature (with a thermistor) currently. But I've also modified our sensor board so that it can use a digital temperature probe, which would output Celsius units directly -- but would still (ideally) need to be corrected via calibration. So sometimes a "raw, uncalibrated" can so far be a frequency (requiring conversation, including correction), voltage (requiring conversion, including correction) and degrees celsius (requiring correction). Hah, isn't the world of sensors fun :)

It'll be nice to work out a consistent language for this ... or adopt one that's already in place ... maybe we just use "signal", as in "signal #3" to refer to the third output in e.g. the CSV that the microcontroller records to microSD? And then we can map conversion schemes onto signals.

I like the idea of not using units on the microcontroller directly, actually ... using something like "signal" gives folks / user the heads up that there is further interpretation / processing required if they want to assign meaning to that signal :) But maybe there's a better word than signal?

+1 to not putting units on the CSV file. The 'signal' that this data needs further work/calibration is important and I think well articulated here.

Is it ok to have the temperature sensor inside the bottle, or does it need to be outside? are the lag of the bottle and heat of electronics not a major problem?

Alligator clips are the most likely part to be dislodged in the design. I'd like to see them replaced with stud rings held down by nuts:

Minor language thing: "water bottle" isn't a very standard size, and water bottle cap threads are of varying sizes. I think we should specify the cap size we're designing for: "bottles with a standard 28mm cap (found in soda bottles, most water bottles)".

Serious safety thing: 2Li + H2O = Li2O + H2 + trouble. We should test out whether a sealed bottle with a battery in it that gets water inside doesn't degrade the lithium, produce hydrogen, then produce a low-pressure bottle explosion that throws electronic shrapnel.

Just a quick note - found these sorta interesting "solderless" connectors - you just shove a wire in -- and they're surface-mount, too. I tried them out and they're surprisingly secure -- even difficult to pull out. Dunno if it's helpful, but re: the discussion about solderability and SMD:

http://www.ledgroupbuy.com/solderless-true-violet-led-405nm/

@mathew -- great stuff! I really like the stud ring + nut replacement for the alligator clips. More secure, and likely available at a typical hardware store, too, yes? Perfect.

Re: temperature probe inside / outside the enclosure -- not sure how this'll change the response time of the temperature measurement / be affected by the electronics. If keeping the probe inside the bottle avoids the use of adhesives, then it seems like it's worth seeing whether we can get away with it for our measurements.

One idea might be: to attach the temperature probe inside the enclosure to a third metal screw, with the idea that the metal would better conduct heat, and otherwise insulate (with tape?) the rest of the probe.

One easy experiment to do soon is to test various options in a temperature-controlled heat bath, and look at the response time differences. @lperovich has done some great work towards this sort of analysis ...

• Re: language -- yes, good point -- and sounds great to specify the enclosure by opening size. Basically, we've designed the datalogger to fit inside one of the most ubiquitous, cheapest water-tight enclosure we could find -- 28mm cap water bottles -- which also happens to be the smallest water bottle 'mouth' out there. Good stuff

• The "2Li + H2O = Li2O + H2 + trouble" experiment also sounds like fun! :)

@warren -- wow, this looks really great. Is there a link to the part, perchance? Would love to order some and play ... if they're secure enough, it would mean that e.g. the sensor board wouldn't require through-hole soldering, or a screwdriver. And great re: desktop lab instrumentation, in any case ...

No, sorry - it just came on another product.

here are some blanks for the riffle+CT board housing-- just a rectangle that is 134mm with screw holes centered in the 106mm riffle section at 65mm centers. There's also a 18650 battery cell cylinder blank:

riffle-blank.zip

files above didn't prep for print right. Updated: riffle-blank2.zip

re: do we need to pop the thermistor outside the cap?

the smallest , most easily filled hole would be a 'vented' screw. You'd probably want a 6-32 to match the other two screws, and to measure the thickness of the thermistor lead: http://www.mcmaster.com/#hollow-screws/=10c951z

Note: fixed the broken link to the riffle datalogger, above. Cheers!

Would it be possible to have a variant using standard batteries? It's not too big of a deal to order a special battery, but in some places and situations it might be an obstacle to replace.

@pdhixenbaugh -- the latest version of the Riffle (Beta 0.1.1) will have two battery ports -- one for rechargeable Lipos, and one that can take in any battery chemistry (with no recharging) -- thanks for pinging about this -- I think it was an earlier request of yours that prompted us to make the tweak, and it's a really good idea re: accessibility.

By the way, here's a snap of the latest version of the board (hand model: Emilie) w/out any parts on it yet:

You can see the twin battery ports on the bottom of the board.

Cheers!