Re: [DIYbio] Re: Does Anyone Know Of A Submersible Arduino/RaspberryPI Compatible Spectrometer?

If you have PoE then a minimal embedded unix board is a good choice.
Raspberry Pi is still not a great choice because it is made for
video-display applications and burns power comparable to that. If you
are sending data immediately through the PoE network then local
storage space is not needed thus Raspberry Pi's main benefit of having
a huge microSD Card + great file system support does not add benefits,
considering the tradeoff in power.  Even the Pi Zero burns too much.
The Pi is not a microcontroller, it is a graphics/video
microprocessor.  Talk about vendor lock-in, the Pi SOC internals are
obscure enough that they are either secret or might as well be secret.
There won't be much recourse if you run into a hardware/low level
software glitch with interfacing your sensors.

I can't imagine that any sensor board "made for Pi" would be limited
to only working with the Pi.  Because, the Pi has relatively generic
peripheral bus support.  Any other board will have GPIO or I2C.
Personally I wouldn't trust the Pi builds to be real time in any sense
(important for sampling and calibration), or bug free in the IO
drivers, regardless of it's linux kernel configuration.  Would it skew
measurements if the logging rate is every 1 minute?  Yes, possibly, so
that choice depends on if you want to live with +/- 2% error just from
random timing slip.


One great board I used (UBW32), has micro BSD open source kernel
ported to it (called retro BSD) and SD card + BSD filesystem, it is
PIC32 so very low power, and every peripheral you could reasonably
think of.  You could use simple serial.  Writing unix drivers for your
sensor would be straightforward.  Writing user apps, obviously very
simple.   micropython could be a good way to go in userland
regardless, because it supports basic hardware access while allowing
general python programming.  micropython does not imply using the
thousands of broken open source python libraries out there, because
they are likely not supported anyway, and are superfluous on embedded
hardware, but it does provide serial, io, math, and basic python
coding which is probably faster to iterate than C.  You could check to
see what other boards micro BSD has been ported to.  These are open
boards, not proprietary lock-in (not much lock-in is possible with a
microcontroller anyway, it's just the SOC on a card).  It is always
handy to have a remote terminal on the device itself and all your code
would be nice POSIX.  One thing to look for in the hardware, is either
a real time clock (better if with battery, like coin cell) or at least
a dedicated timer, so that you can timestamp your samples precisely,
and also not need to constantly set or reset the system time.

I'd say you would want to cache the sampled data locally and send it
to the remote server in larger periodic chunks (as slow as every 1 hr
or more, with retry mechanism).  That way you have built-in
reliability and redundancy, i.e. don't lose valuable data when your
comms has problems (for example, transmission problem, or if the
server process restarts, etc).  This kind of thing is simple in unix
with a cron job, shell script, and rzsz, as old school as that seems
(or uucp if you do ppp over the serial).

I agree with the other comment on the thread regarding sensor cleaning.


On 9/6/17, Cory Geesaman <co...@geesaman.com> wrote:
> I'm adding to this since it seems I worded the original very poorly based
> on responses (and the concept has been refined a bit since then.)
>
> To start, my application is not a data logger meant to sit out in a pond or
>
> swamp somewhere, it will be wired into a (hopefully PoE if I can keep the
> wattage low enough) connection tied directly to a server with decent
> storage and processing power, but am very against any form of closed
> hardware (not in the least of which because I use FreeBSD for servers and
> nobody making proprietary code likes to talk to them, but also because I've
>
> never had a pleasant experience with vendor lock-in.)
>
> I'm aiming for a water monitoring probe which can detect a very wide range
> of ions, this would be coupled with tubidity, D.O., ORP, conductivity, pH,
> and temperature sensors taking measurements every minute or 10 minutes,
> depending on the size of the data.  Given the other data available and the
> fact ion detectors tend to be designed per-ion with a focus on
> membrane-based techniques and run about $1,000-$1,500 (per ion) with a
> shelflife numbered in months under continuous use (at best), that option
> isn't on the table.
>
> This has gotten me looking into spectrophotometers, and it seems if I can
> measure reflection, adsorption, and fluorescence spectra independently over
>
> a wide band (and of course one at a time for fluorescence
> spectrophotometry) it should be feasible to pick out just about any ion
> concentration with a high degree of accuracy and a decent server to parse
> the information.  It even has the added benefit that I can add ions as
> needed by finding the relevant data and having the computer check for
> matches across the entire history of the dataset rather than just having
> big holes in the data before a particular sensor was added.
>
> To this end I've thus far narrowed down the possible light source
> combination at the end of this post, which should yield a very large set of
>
> possible fluorescence spectrophotometry readings when they are switched on
> 1 wavelength at a time with individual snapshots taken (just listing these
> in case anyone else is working on a similar project, it took about a day to
>
> find a set of LEDs with fairly well-matched half-amplitude-wavelengths and
> similar amplitude at a 15-degree radius, the number at the start is the
> number needed to balance the amplitude to the others for a 15 degree angle,
>
> then what it is, then the price each, then the source.)
>
> To get the adsorption spectra is pretty easy - just shine a light through
> something and see what doesn't make it.  To get the reflection spectra is a
>
> little trickier, in that you need to measure from the side you are shining
> the light from, and to get the fluorescence spectra you switch on 1 group
> at a time and see what other wavelengths you get out of it.  My best idea
> for this thus far is actually pretty painful to implement: take a fiber
> with two Y-shaped splices (so more like an X with an elongated center) and
> for one pair have an input going to a cavity with all the LEDs embedded in
> the walls pointed at a pigtailed cosine corrector (diffuser plate over top
> of a piece of glass which effectively opens a single mode fiber aperture to
>
> about 4mm across.)  On the other side of the input pair you would actually
> have your output, going to a diffraction grating with a camera pointed at
> it.  On the other pair you would have the sample cavity and a reference
> signal going back to a different y coordinate on the diffraction grating.
>  Then you would have 1 more fiber on the opposite side the cavity for
> adsorption detection which again goes to the diffraction grating - for a
> total of two fibers going to the probe.  This is probably really hard to
> decipher so I've added a diagram below (sorry for the quality of it in
> advance), and would welcome better ideas to achieve the same because at the
>
> moment it looks like I'll need to get a fusion splicer to make the X-shaped
>
> section and attach the components to it, plus have a cavity milled or hack
> one together with epoxy.
>
> Diagram: https://i.imgur.com/52NgfBD.png
>
> 1 351 +/- 10nm LED 18.99
> http://www.ledsupply.com/leds/5mm-led-ultra-violet-351nm-15-degree-viewing-angle
> 1 361 +/- 10nm LED 3.79
> http://www.ledsupply.com/leds/5mm-led-ultra-violet-361nm-15-degree-viewing-angle
> 1 380 +/- 15nm LED 0.895
> http://www.ledsupply.com/leds/5mm-led-ultra-violet-361nm-15-degree-viewing-angle
> 1 405 +/- 15nm LED 0.694
> http://www.mouser.com/ProductDetail/VCC/VAOL-5GUV0T4/
> 1 430 +/- 15nm LED 2.04 http://www.mouser.com/ProductDetail/VCC/4304H6/
> 1 461 +/- 15nm LED 0.55
> http://www.mouser.com/ProductDetail/Kingbright/WP7083QBD-G/
> 1 475 +/- 15nm LED 0.2
> http://www.mouser.com/ProductDetail/Lite-On/LTL17KTBS3KS/
> 1 494 +/- 6nm LED 1.89 http://www.mouser.com/ProductDetail/BIVAR/3UTC-F/
> 1 520 +/- 20nm LED 0.314
> http://www.mouser.com/ProductDetail/Kingbright/WP710A10LZGCK/
> 1 565 +/- 25nm LED 0.322
> http://www.mouser.com/ProductDetail/Vishay/TLHP5800/
> 1 600 +/- 20nm LED 0.39
> http://www.mouser.com/ProductDetail/Broadcom-Limited/HLMP-C415/
> 1 630 +/- 5nm LED 0.36
> http://www.mouser.com/ProductDetail/Broadcom-Limited/HLMP-Y601-J0000/
> 1 638 +/- 8nm LED 0.435
> http://www.mouser.com/ProductDetail/Broadcom-Avago/HLMP-AD06-P0000/
> 21 697 +/- 50nm LED 0.048
> http://www.mouser.com/ProductDetail/Lite-On/LTL-4211N/
> 1 767 +/- 20nm LED 26.75
> https://www.thorlabs.com/thorproduct.cfm?partnumber=LED780E
> 1 850 +/- 20nm LED 1.15
> http://www.mouser.com/ProductDetail/Wurth-Electronics/15400385A3590/
> 1 904 +/- 20nm LED 8.45
> https://www.thorlabs.com/thorproduct.cfm?partnumber=LED910E
> 1 935 +/- 30nm LED 11.5
> https://www.thorlabs.com/thorproduct.cfm?partnumber=LED940E
> 1 1050 +/- 40nm LED 17.8
> https://www.thorlabs.com/thorproduct.cfm?partnumber=LED1050E
> 1 1205 +/- 80nm LED 19
> https://www.thorlabs.com/thorproduct.cfm?partnumber=LED1200E
>
> --
--
## Jonathan Cline
## jcl...@ieee.org
## Mobile: +1-805-617-0223
########################