downloads and an on-line mode
EBo
This looks so wicked cool I cannot wait to jump in...
I have a situation where I need dozens of data loggers for some
automated greenhouse experiments. For this to work out I will either
need it connected to a computer, or have it be able to actuate a
couple of devices like an SCR and/or digital-relay. Since it can
already do I2C, I might be able to get it to work as is, but there is
still the recording issue.
My original vision for my own device was connecting it via USB, but
any conventional IO would suffice. I read here that someone else is
interested in connecting the logger via bluetooth. Regardless of the
mode of communication I will need to download the data for later
statistical analysis. One interesting option with USB would be to
loose the AAA battery and go with a soldered in rechargeable. I am
not sure how much that would cost, or how feasible that would be, but
it might be interesting to investigate.
Is a USB variant of general interest?
Steve Chamberlin
The Logger Mini doesn't have any I/O pins other than the ISP programming header. After the AVR device is programmed, 4 of those pins could be used for SPI communication with an external device, or as general purpose I/Os with some limitations. (The other two pins are power and ground.) The ATmega hardware I2C pins aren't connected to any external pins, but you might be able to bit-bang I2C through software on those 4 pins if you really need I2C. You could theoretically bit-bang any other protocol that needs 4 or fewer wires too: serial, maybe even USB. Check out V-USB for an open source pure-software USB implementation for AVRs.
Steve
EBo
the same functionality in the other package. When I originally started
playing with stuff I was looking at I2C, but could switch. I'll think
about what I need to so and look at the schematics and see if it'll work
as is (here's to dreaming). If not, then I'll see if I can re-purpose
lines from the display or maybe break more out.
EBo --
Jay Lash
analysis - in my case I like to put a graph of the temperatures (and
now altitudes) into a slide show of the pictures from the trek.
Bluetooth with a serial port profile would be a nice mechanism. There
are also some tiny wifi modules available that interface like a serial
modem.
If I/O pins are an issue for an additional interface we could consider
a "headless" model. Replace the display with a Bluetooth module (or
select between the two on the fly) and connect to a phone for
downloading and/or displaying the info. Ive done some Android BT
development recently, it is pretty straight forward.
Steve Chamberlin
If lots of people feel strongly about having some kind of built-in download hardware instead of an add-on board, then I'd prefer to see it added to the Logger Classic rather than the Mini. The Classic has more physical space where extra hardware could be added, and logically it's the "big brother" of the two Logger versions. In contrast, the Mini was designed from the ground up to be as small and light as possible, geared towards a hiker/sportsman who wants to review data in the field but probably not do any fancy post-analysis. My other selfish reason for keeping the Mini is that I just invested in a run of more Mini PCBs, which would be obsoleted if the group moves to a different Mini design.
One other thought: you could get a poor-man's download functionality from the existing design, by using AVRDUDE or AVR Studio to read the contents of EEPROM memory with an AVR programmer, and then using a custom PC program to decode the data.
Lastly, it looks like I was wrong when I said 4 ISP pins could be used as general purpose I/Os. One of those pins is RESET, and if you turn the RESET pin into a GPIO, then the device can no longer be reset via the ISP, which means it can't be reprogrammed as-is. There are ways around this by using extra hardware to power-cycle the AVR in response to the ISP's reset signal, but the Logger hardware wasn't designed for that. So in practice you only have 3 GPIOs to work with from the ISP header: SPI clock, SPI data in, SPI data out. Is that enough to create a useful add-on board?
Jay Lash
I do have a strong preference for being able to download the data, but
dont have any real preference for how it is achieved. I agree with
minimizing the number of variants and with keeping the mini very
focused and letting the classic be the place for expansion.
On Oct 18, 3:51 pm, Steve Chamberlin <steve.chamber...@gmail.com>
wrote:
EBo
time to this -- life as a student intern...
When I posted my questions/comments it was in a rather scattergun
approach instead of a principled discussion. I think that maybe we need
to take a step back and come up with a grand vision -- which my read of
Steve's reply is leaning towards. His addon/daughter board approach is
very reminiscent of Arduino. There are many good reasons to do this,
and maybe some reasons not to -- I'll have to think about the
pros/cons...
One of the reasons I was originally thinking of going with I2C and/or
1-wire is the devices can be chained together and addressed on a single
bus. The SPI devices I had looked at in the past did not allow device
addressing. That might have been those particular devices, so I will
have to look into this further.
Like Steve I have an end application in mind that drives many of my
wants/needs. It is these desires which will drive some of the design
decisions I'll advocate for, and others I will not care for either way.
I'll outline some of the issues here for background and then explain why
I really liked Steve's two loggers as a starting point.
I do applied restoration ecology as an avocation, and have for decades.
I have some ongoing research collaborations with some restoration
ecologists. There is a series of classic experiments in seed-bank and
germination studies that I would like to replicate, but they are either
VERY time consuming to do by hand or EXPENSIVE to try to automate. The
functionality are simple -- accurately measure the water level, and
control a drain and/or pump. Drains and pumps can easily be controlled
via an addressable switch. As for the level measurements, the historic
studies made repeated daily measures at ~mm resolution and relative
depth. Automating the temporal accuracy is trivial with modern embedded
controllers, so I'll skip that. Measuring water dept over something
like a meter with mm precision (we will have to evaluate its accuracy
later) is more than a little tricky. The way most people want to do
level is with a ping sensor. This is good to ~1" precision *unless* you
correct for temperature, pressure AND humidity. With these correction
you can fine tune the time of flight and get it down to ~0.1mm
theoretical resolution given he available components and a 0.25mm
practical limit. There are some esoteric ways to assimilate the time of
flight to figure out the humidity, but if I am not mistaken those
techniques are all patented...
So now comes Steve's data loggers...when I looked at building an open
hardware controller which allowed me to hook up some I/O switches (for
pump, drain, heater/cooler/freezer, lights) and have the what I needed
for correcting the TOF, I was looking at well over $50 for the
components before looking at making/designing the board. The pressure
sensor at that time was nearly $20 itself...
For my own needs I see the device being operated in two modes: 1) as a
multi-sensor that I can hook up to a computer, and 2) as a programmable
standalone controller/logger. So for me a USB interface solved the
problem for downloading the data and providing me multi sensor interface
for a laptop. So, breaking out some basic GPIO's or a standard bus or
two is about all I was really looking for.
Anyway, that is where I was going with my dreams. I think Steve's
Classic would be a fine place to start. I'll have to read through the
schematic and see how well it would work out.
Well, that was the long winded contextual brain dump. I'm hoping that
what I want to do will be synergistic with the group. Either way,
Steves open source loggers are WAY cool!
EBo --