AVR-Chat

Hi all,

I'm getting way ahead of myself vs. my understanding of programming 
as I have only started to read the C programming book.

I was wondering if there is a way to connect a uC to a PC via SC 
(serial cable) and input constants ?

What I am thinking about is making a timer.
I would input a value of say 1 minute to get the program running and 
then later, if I wanted to change the value, I'd like to only input 
that new value from a PALM or PC or something like that.

The idea is to not re-program the chip, but to only change a value or 
two.

I was thinking of using a jumper or switch to tell the AVR to look 
for the new values.

I'm just not sure how easy it would be to use a PC to change some 
values in the micro.

My goal is to create a data logger and to be able to set the time 
between each reading from a PC.  I would have 8 to 10 points that 
would need to be read and each would be a seperate timing value.

This is for a greenhouse and we would want soil moisture sampes only 
a few times a day but humidity and temperature samples much more 
frequently.

I am not sure if this is something that can be done from a existing 
software, or if I also need to learn Visual Basic......

Also, how-come-is-it that the more I learn, the father away my goal 
seems to get ?   When I started, it was really simple !

Dave

At 04:31 PM 7/14/04 +0000, you wrote:
>I'm getting way ahead of myself vs. my understanding of programming
>as I have only started to read the C programming book.
>
>I was wondering if there is a way to connect a uC to a PC via SC
>(serial cable) and input constants ?
>
>What I am thinking about is making a timer.
>I would input a value of say 1 minute to get the program running and
>then later, if I wanted to change the value, I'd like to only input
>that new value from a PALM or PC or something like that.

The short answer is yes.

The longer answer (you knew there was a longer answer) is you need to write 
something at the microcontroller end to have a 'conversation' over the 
serial port to get the new values and store them somewhere (EE 
maybe?).  The microcontroller would parse an input string of something like 
this

a 100

which it would interpret as setting value a to 100.  It would then sore 
that somewhere for the control program in the micro to read.

>I was thinking of using a jumper or switch to tell the AVR to look
>for the new values.

That will work.


>I'm just not sure how easy it would be to use a PC to change some
>values in the micro.

Not difficult, but given that you are just starting I'd suggest that you 
simulate it in a console window on a PC just using getchar and putchar (or 
similar).  The debugging facilities are generally better and you will be 
able to figure out how to deal with the parsing issues more quickly.


>My goal is to create a data logger and to be able to set the time
>between each reading from a PC.  I would have 8 to 10 points that
>would need to be read and each would be a seperate timing value.
>
>This is for a greenhouse and we would want soil moisture sampes only
>a few times a day but humidity and temperature samples much more
>frequently.
>
>I am not sure if this is something that can be done from a existing
>software, or if I also need to learn Visual Basic......

Quite doable.  Add a little local storage and the PC could pick up the data 
once a day or so.  A serial terminal would do just fine for that.  You 
could get fancier but for a simple datalog that gathers data for future 
viewing/analysis that will work just fine.

I've used similar techniques for debugging control SW.


>Also, how-come-is-it that the more I learn, the father away my goal
>seems to get ?   When I started, it was really simple !

Why do forests appear more complex when you get close enough to see the 
individual trees ;)


Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

--- In AVR-Chat@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> At 04:31 PM 7/14/04 +0000, you wrote:
> >I'm getting way ahead of myself vs. my understanding of programming
> >as I have only started to read the C programming book.
> >
> >I was wondering if there is a way to connect a uC to a PC via SC
> >(serial cable) and input constants ?
> >
> >What I am thinking about is making a timer.
> >I would input a value of say 1 minute to get the program running 
and
> >then later, if I wanted to change the value, I'd like to only input
> >that new value from a PALM or PC or something like that.
> 
> The short answer is yes.
> 
> The longer answer (you knew there was a longer answer) is you need 
to write 
> something at the microcontroller end to have a 'conversation' over 
the 
> serial port to get the new values and store them somewhere (EE 
> maybe?).  The microcontroller would parse an input string of 
something like 
> this
> 
> a 100
> 
> which it would interpret as setting value a to 100.  It would then 
sore 
> that somewhere for the control program in the micro to read.


Makes sense.

If I have 10 timing loops and want each to be indivudually set, I can 
declare a constant for each

a = 100  ; seconds
b = 900
c = 60
 and so on

then input a string of 

a 100 b 900 c 60 (and so on) so that these would be altered in the 
program and used for the timing counts.

I know the format is not correct, but the idea is that I would 
probaly have to send all the values each time, or maybe just the ones 
I want to change.  (guess this is that trees in the forest thing)


Is there anyone who does something similar ?   The end result will be 
that students will be able to set the timing for the data logging and 
then put them into the greenhouse and take readings.

Hortocultural students are not electronicaly inclined so the screen 
on the PC would need to be simple.  Maybe even a spreadsheet layout 
with the names of the things and the timing values.

Dave

Although the docs lead me to believe this will work, the hardware in hand is trying to convince me otherwise. 

Does anyone here know for sure, if the AVRISP will work in a 3V system?

--- In AVR-Chat@yahoogroups.com, "James Wagner" <jim_d_wagner@a...> 
wrote:
> You really DON'T need to think of "constants".
> 
> There are only two issues. 
> 
> 1. Where is the value stored? It can be stored as part of a
> table in program code and that is a real constant, for most
> practical purposes unchangeable. It can be stored in SRAM.
> In this case, it is highy changeable and goes away every
> time power is turned off. It can be stored in EEPROM. It is
> still changeable, but you don't want to do it really often.
> And, it stays when the power goes off. The operations used
> to read each is similar but slightly different.
> 
> 2. What determines the value? A constant is determined at
> the time that code is written. While it can be changed
> later, it makes little sense in this kind of application.
> All of the other kinds of data have to be determined some
> other way; it might be by receiving data over the serial
> port. It might by by reading a constant at startup and copy
> to the memory location (ie, a "default" value). 
> 
> My point is that thinking about "constants" is not really
> very useful or productive in this kind of application. A
> number is a number.
> 
> Jim
> 
> 
> ---------------------------------------------------------------
> The Think Different Store
> http://www.thinkdifferentstore.com/
> For All Your Mac Gear
> ---------------------------------------------------------------



Hi Jim,

I am just on low end of the learnig  curve.  To me, at this point, a 
variable is something that changes all the time, like soil moisture 
or air temperature.  A constant is a more fixed number that I am 
thinking is a set value that does not change unless the chip is re-
programmed.

As far as the place it is stored, I would not have a problem if I 
needed to use a button battery to keep an a memory chip from losing 
any values.

But if the internal eeprom is similar to eeprom chips the limit is 
something on the order of 100,000 writes ?  That would allow three 
changes every day for the next --- 100 years ?   I would expect a 
change once or twice a week.

I guess simplicity would be a key factor.  what is the easiest way to 
send the AVR the data and what is the easiest way to keep it thru a 
power loss.

The button battery would keep a memory chip alive for some 10 or more 
years so that would eleminate any power issues if sram was much 
easier.

Eventually, this will be connected to a memory card like a MMC or SD 
or CF, but I think one could not put program variables on that ?

Dave
(realizing the trees have branches......)

> The simplest method I have run into is to use FRAM. The write speed 
of 
> SRAM, the non-volatile nature of EE and an endurance of something 
like 1e9 
> cycles.  Ramtron now makes serial FRAMs in up to 256Kb (thats bits).
> 

I have read a little on the Ramtron chips.  they also have a real 
time clock AND FRAM on a chip so that starts to use less parts as 
well as make it easier to write the data.

It seems that for some EEPROM chips, one needs to write a whole page 
and others, one can address individual bits.  At this point, it seems 
to write a page would be simplier as far as keeping track of 
addresses.

But, your comment about the possibility of putting the variables on a 
Memory card seems like a much easier way.  that would make only one 
connection to the PC, and it would also allow each student to carry 
their own timings.

When looking at chips, the low memory count is the thing that limits 
the total duration of a data logger.  By using a memory card, the 
huge storage allows a 'just read every point all the time' method and 
then one can pick out the data when it is back in the spreadsheet.

I have been looking at a brighness device to log how bright the sun 
is over daylight hours.  This would be a once a minute log.  with 
things like soil moisture changing hourly, it seems like a waste of 
memory to store 10 points each minute for a week or two.

If my math is correct, 10 points per minute is 600 points per hour or 
14,400 per day and 100,800 per week.  If 7 points are hourly, that 
drops to around 30,000 points per week.  If each point is a byte, 
then there would be 800,000 bits or 240,000 bits.   That starts to 
get important with a EEPROM or FRAM chip, but not important with a 
memory card.

This is a good discussion for my level of interest although it is 
somewhat over my head for programming.

Dave

You really DON'T need to think of "constants".

There are only two issues. 

1. Where is the value stored? It can be stored as part of a
table in program code and that is a real constant, for most
practical purposes unchangeable. It can be stored in SRAM.
In this case, it is highy changeable and goes away every
time power is turned off. It can be stored in EEPROM. It is
still changeable, but you don't want to do it really often.
And, it stays when the power goes off. The operations used
to read each is similar but slightly different.

2. What determines the value? A constant is determined at
the time that code is written. While it can be changed
later, it makes little sense in this kind of application.
All of the other kinds of data have to be determined some
other way; it might be by receiving data over the serial
port. It might by by reading a constant at startup and copy
to the memory location (ie, a "default" value). 

My point is that thinking about "constants" is not really
very useful or productive in this kind of application. A
number is a number.

Jim


---------------------------------------------------------------
The Think Different Store
http://www.thinkdifferentstore.com/
For All Your Mac Gear
---------------------------------------------------------------

At 07:13 PM 7/14/04 +0000, you wrote:
>--- In AVR-Chat@yahoogroups.com, Robert Adsett <subscriptions@a...>
>wrote:
> > The longer answer (you knew there was a longer answer) is you need
>to write
> > something at the microcontroller end to have a 'conversation' over
>the
> > serial port to get the new values and store them somewhere (EE
> > maybe?).  The microcontroller would parse an input string of
>something like
> > this
> >
> > a 100
> >
> > which it would interpret as setting value a to 100.  It would then
>sore
> > that somewhere for the control program in the micro to read.
>
>
>Makes sense.
>
>If I have 10 timing loops and want each to be indivudually set, I can
>declare a constant for each
>
>a = 100  ; seconds
>b = 900
>c = 60
>  and so on
>
>then input a string of
>
>a 100 b 900 c 60 (and so on) so that these would be altered in the
>program and used for the timing counts.
>
>I know the format is not correct, but the idea is that I would
>probaly have to send all the values each time, or maybe just the ones
>I want to change.  (guess this is that trees in the forest thing)

Depends on how you write the parser.  But something like that.

Maybe something like

switch( cmd) {
     case 'a':
           store_timer( 1, value);
           break;

     case 'b':
           store_timer( 1, value);
           break;

       :
       :

      case 'z':
           dump_data();
           break;

      default:
           print_serial( "Unknown Command\r\n");
            break;

      }

The details of parsing the input to get cmd and value are left as an 
exercise ;)

Your main program would do something like:

acquire_data()
{
recall_timers();
run_data_schedule();
}

One of the keys here (especially at the beginning) is to strictly limit the 
level of complexity you will accept, realize there will be things you 
cannot do (especially in your first rev) and use it as a learning 
experience to figure out what works and what doesn't.  Sometimes what 
appears to be awkward to begin with works well enough that there is no real 
desire to change it.  For example you may find it is simpler to gather 
everything at the same rate and simple ignore the extra data later.  Serial 
data chips are not terribly expensive.

>Is there anyone who does something similar ?   The end result will be
>that students will be able to set the timing for the data logging and
>then put them into the greenhouse and take readings.
>
>Hortocultural students are not electronicaly inclined so the screen
>on the PC would need to be simple.  Maybe even a spreadsheet layout
>with the names of the things and the timing values.

I used to do something similar for some control data logging.  We just 
dumped the data to the terminal as a csv type file that could then be 
imported directly into a spreadsheet.  Something like

A text description to give a short explanation of what the data came from.

nameforcol1,nameforcol2,nameforcol3
1,2,3
4,5,6



It's possible you would need quotes on the column names.  But if you 
capture that in a serial terminal program you can then import that into a 
spreadsheet and you will end up with columns of data with names at the top 
of the columns.  It will probably be easier if you use something other than 
hyperterminal but it will work in a pinch.

If all your data inputs are running at different sample rates it may be 
simpler to dump each one in turn.

You will have to judge if the terminal interface is too difficult for your 
students to master and thus whether you will need to invest in a building a 
menu driven interface.  The menu driven interface could still use the ascii 
serial hookup.

Welcome to the jungle :)
Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

Dave -

In programming, especially embedded processors (like AVR),
the term "constant" has a specific meaning. Almost always,
it is a quantity that is defined at the time the program is
written and does not change again. For example, If you
count seconds with a timer and want to determine minutes,
you would divide seconds by 60 and that "60" you specify in
code is a constant.

"Variable" encompases virtually all other data (with a few
somewhat esoteric exceptions). It could be something that
changes on every pass through the "main" loop; it could be
a return address that is pushed onto the stack to service
an interrupt. It could be something that changes once in a
while. It just is not "fixed" at the time the program is
compiled.

For something of the sort you are discussing, saving in
EEProm would be just fine. And, it makes a lot of sense. 

Now, there is, admittedly, a "grey area". If you have a
table of values in program memory and select ONE depending
on some condition, then those are constants as far as
coding is concerned. But, as soon as loaded into a register
or SRAM to use, they are, for all practical purposes,
variables. 

My point is not to criticise you! Far from it. It is simply
to point out that the term "constant" has a rather well
defined meaning in the context of programming.

Sounds like an interesting project...

Jim
 
---------------------------------------------------------------
The Think Different Store
http://www.thinkdifferentstore.com/
For All Your Mac Gear
---------------------------------------------------------------

> 
> OK a weeks worth is ~ 100K at max sampling.  Using the largest FRAM 
chips 
> that would be 4, maybe 5 per board.  Probably doable on space.  
Would need 
> to check cost though.  I suspect it's no more expensive that a MMC 
> connector + card.  Might well be cheaper.  If it's for a student 
device 
> does it need a full week?
> 
> The bigger issue I see is you are talking about an awful lot of 
data for 
> the students to analyze.  For the 1/min you are talking about 42000 
> points.  Will your spreadsheet (or whatever analysis program) 
handle 
> that?  And if it does will it do it w/o slowing to a crawl?  It 
would be 
> easy to create a dummy data file to check that out.


oh, so you're saying there are leaves on those twigs ?

 



> One last data question.  What are you trying to track with the 
brightness 
> measurement?  Do you really expect to see a significant change in 1 
> minute?  I would have guessed a 5 minute period made more sense 
(maybe even 
> longer at night).

A bush in shade will see light when the blocking thing moves 
relitaive to the sun.  Imagine tree or tree trunk that acks like 
gnomon.  as the Earth rotates, the Gnomon will appear to move and the 
plant will be blocked for some period.

How much sun a leaf gets from being in shade vs a cloudy day.  That 
sort of thing.

Dave

At 08:14 PM 7/14/04 +0000, you wrote:
>But if the internal eeprom is similar to eeprom chips the limit is
>something on the order of 100,000 writes ?  That would allow three
>changes every day for the next --- 100 years ?   I would expect a
>change once or twice a week.

For things like sampling time I expect that would be true.  For data 
maybe/maybe not.

>I guess simplicity would be a key factor.  what is the easiest way to
>send the AVR the data and what is the easiest way to keep it thru a
>power loss.

The simplest method I have run into is to use FRAM. The write speed of 
SRAM, the non-volatile nature of EE and an endurance of something like 1e9 
cycles.  Ramtron now makes serial FRAMs in up to 256Kb (thats bits).


>Eventually, this will be connected to a memory card like a MMC or SD
>or CF, but I think one could not put program variables on that ?

Sure you could, then you could set up the sample schedule on an MMC and 
plug it in and record the collected data back to it.  You may want to save 
that complexity for a second iteration though.

>(realizing the trees have branches......)

Branches have twigs :)

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

At 09:10 PM 7/14/04 +0000, you wrote:

> > The simplest method I have run into is to use FRAM. The write speed
>of
> > SRAM, the non-volatile nature of EE and an endurance of something
>like 1e9
> > cycles.  Ramtron now makes serial FRAMs in up to 256Kb (thats bits).
> >
>
>I have read a little on the Ramtron chips.  they also have a real
>time clock AND FRAM on a chip so that starts to use less parts as
>well as make it easier to write the data.

Some of them do, but they have a family that is just data storage.  An FRAM 
with an RTC might make sense as a place to store your parameters.

>It seems that for some EEPROM chips, one needs to write a whole page
>and others, one can address individual bits.  At this point, it seems
>to write a page would be simplier as far as keeping track of
>addresses.

One of the reasons I like FRAMs for simple work, you just pick an address 
and write to it.  That and you don't need to check to see when it's done 
programming.  That speed makes using them simpler (It also narrows the 
window during which they are vulnerable to externally induced change but 
that shouldn't be an issue for you).


>But, your comment about the possibility of putting the variables on a
>Memory card seems like a much easier way.  that would make only one
>connection to the PC, and it would also allow each student to carry
>their own timings.

Ah but then you are back to timing issues, and building a file system.  It 
does have advantages but I suspect you want to start simpler.


>When looking at chips, the low memory count is the thing that limits
>the total duration of a data logger.  By using a memory card, the
>huge storage allows a 'just read every point all the time' method and
>then one can pick out the data when it is back in the spreadsheet.
>
>I have been looking at a brighness device to log how bright the sun
>is over daylight hours.  This would be a once a minute log.  with
>things like soil moisture changing hourly, it seems like a waste of
>memory to store 10 points each minute for a week or two.
>
>If my math is correct, 10 points per minute is 600 points per hour or
>14,400 per day and 100,800 per week.  If 7 points are hourly, that
>drops to around 30,000 points per week.  If each point is a byte,
>then there would be 800,000 bits or 240,000 bits.   That starts to
>get important with a EEPROM or FRAM chip, but not important with a
>memory card.

OK a weeks worth is ~ 100K at max sampling.  Using the largest FRAM chips 
that would be 4, maybe 5 per board.  Probably doable on space.  Would need 
to check cost though.  I suspect it's no more expensive that a MMC 
connector + card.  Might well be cheaper.  If it's for a student device 
does it need a full week?

The bigger issue I see is you are talking about an awful lot of data for 
the students to analyze.  For the 1/min you are talking about 42000 
points.  Will your spreadsheet (or whatever analysis program) handle 
that?  And if it does will it do it w/o slowing to a crawl?  It would be 
easy to create a dummy data file to check that out.

There is an intermediate step between all channels at full rate and all 
channels at independent rates where you keep two or 3 separate logs at 
different rates.  That reduces the total storage but still leaves you with 
that 42K points for your fastest.


>This is a good discussion for my level of interest although it is
>somewhat over my head for programming.

That's the main reason I'd suggest starting with something simple like an 
FRAM and restrict the size of problem you are willing to deal with on the 
first iteration.  If it works out successfully but more data looks like a 
good idea you can always do another iteration with more complex and larger 
storage.  Starting simple with a new solution also means you can try 
something and see if it works from a human point of view (this is where you 
find out that every student pressure washes them :)

One last data question.  What are you trying to track with the brightness 
measurement?  Do you really expect to see a significant change in 1 
minute?  I would have guessed a 5 minute period made more sense (maybe even 
longer at night).

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

David VanHorn wrote:
> Although the docs lead me to believe this will work, the hardware in hand is trying to convince me otherwise. 
> 
> Does anyone here know for sure, if the AVRISP will work in a 3V system?

As long as the internal micro can run at 3.3V, it should. RS232 levels are
+/-3V min.

http://www.serasidis.gr/circuits/avr_isp/avr_isp.htm
http://www.lammertbies.nl/comm/info/RS-232_specs.html
http://www.rs485.com/rs485spec.html

David VanHorn wrote:
> Although the docs lead me to believe this will work, the hardware in hand is trying to convince me otherwise. 
> 
> Does anyone here know for sure, if the AVRISP will work in a 3V system?

Since when does markiting give a flying F*&K about engineering ?

Yes the docs say so, No in my experiance :(

Kat (who is now learning VB as she landed a massive multi year VB 
contract from home (I love my new clients, they take ME out to dinner)


-- 
---------------------------------------------------------------
K.A.Q. Electronics	Website: www.kaqelectronics.dyndns.org
IM: Yahoo: PinkyDwaggy  MSN: katinka@kaqelectronics.dyndns.org
For Everything Electronics     Phone: 0419 923 731
---------------------------------------------------------------

At 01:30 PM 7/15/2004 +1000, Russell Shaw wrote:

>David VanHorn wrote:
>> Although the docs lead me to believe this will work, the hardware in hand is trying to convince me otherwise. 
>> 
>> Does anyone here know for sure, if the AVRISP will work in a 3V system?
>
>As long as the internal micro can run at 3.3V, it should. RS232 levels are
>+/-3V min.
>
>http://www.serasidis.gr/circuits/avr_isp/avr_isp.htm
>http://www.lammertbies.nl/comm/info/RS-232_specs.html
>http://www.rs485.com/rs485spec.html

It's running, but I'm having some flaky behaviour when I first start studio.
Once it finds the programmer, everything seems ok.

At 10:35 PM 7/14/04 +0000, you wrote:
> > The bigger issue I see is you are talking about an awful lot of
>data for
> > the students to analyze.  For the 1/min you are talking about 42000
> > points.  Will your spreadsheet (or whatever analysis program)
>handle
> > that?  And if it does will it do it w/o slowing to a crawl?  It
>would be
> > easy to create a dummy data file to check that out.
>
>
>oh, so you're saying there are leaves on those twigs ?

I'm not sure we've got to the leaves yet.  BTW, I just checked the 
spreadsheet I use for this sort of thing and it has a max of 8K rows.  If I 
want to seriously play with the data the program I use for that has an even 
smaller limit.



> > One last data question.  What are you trying to track with the
>brightness
> > measurement?  Do you really expect to see a significant change in 1
> > minute?  I would have guessed a 5 minute period made more sense
>(maybe even
> > longer at night).
>
>A bush in shade will see light when the blocking thing moves
>relitaive to the sun.  Imagine tree or tree trunk that acks like
>gnomon.  as the Earth rotates, the Gnomon will appear to move and the
>plant will be blocked for some period.
>
>How much sun a leaf gets from being in shade vs a cloudy day.  That
>sort of thing.

Yep, I'm just questioning the need for a 1 minute resolution.  Assuming you 
are at a reasonable mid latitude, taking measurements in the winter with 
the day getting no shorter than about 8 hours (I'm making this up as I go 
along). 1 minute represents 1/480 or a little more than 0.2% of the 
daylight hours.  Do you reasonably expect to see the difference from even a 
1% drop in light?  Or perhaps more to the point what is the minimum light 
difference you expect to cause a difference in what you are measuring?

In either case you will need a low pass filter to avoid aliasing (now we 
are getting to the leaves). Given the time scales the larger part of that 
is most effectively done in software.

You can quite easily track the average exposure during the sampling period 
(It could even be a no-linear 'average' like an RMS) without needing to 
store results from high frequency sampling.

What I'm getting at is if one plant is exposed to 50% intensity for 5 
minutes and another to 100% for 2.5 min and 0% for 2.5 minutes can you tell 
the difference in the plants responses?

Actually I wouldn't be surprised if you could get away with even longer 
sample intervals.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

>
>Kat (who is now learning VB as she landed a massive multi year VB 
>contract from home (I love my new clients, they take ME out to dinner)

COOL!

I did a front end diagnostic package for that battery charger, in VB. 
Plots voltage, current, temperature, and voltage and temperature deltas, and controls charge and discharge cycles, using a USB data aquisition pod, PMD-1208-LS

It all fits in an older halliburton case, with 1 and 2 A constant current dischargers, and all the other hoo-ha.  I even took it up to canada as a carry-on, which was kind of amazing.

On Thursday 15 July 2004 11:39, Robert Adsett wrote:
> At 10:35 PM 7/14/04 +0000, you wrote:

> >A bush in shade will see light when the blocking thing moves
> >relitaive to the sun.  Imagine tree or tree trunk that acks like
> >gnomon.  as the Earth rotates, the Gnomon will appear to move and the
> >plant will be blocked for some period.
> >
> >How much sun a leaf gets from being in shade vs a cloudy day.  That
> >sort of thing.

> Yep, I'm just questioning the need for a 1 minute resolution.
> Assuming you are at a reasonable mid latitude, taking measurements
> in the winter with the day getting no shorter than about 8 hours
> (I'm making this up as I go along). 1 minute represents 1/480 or a
> little more than 0.2% of the daylight hours.  Do you reasonably
> expect to see the difference from even a 1% drop in light?  Or
> perhaps more to the point what is the minimum light difference you
> expect to cause a difference in what you are measuring?

I gather that a great deal of compression could be achieved if only
changed values and when they occurred were stored.

"Integration" over longer intervals may be more useful in terms of
plants. One could store hourly "integrals" by simply accumulating
the per-second readings.

The "minute" details are only required if you're looking at
isolating a causal issue. Which is unlikely in this scanario.

-- 
/"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia
\ /  ASCII ribbon campaign | I'm a .signature virus!
 X   against HTML mail     | Copy me into your ~/.signature
/ \  and postings          | to help me spread!

Hi!

 I use ordinary 90S8535 with 3,3V suply voltage and
8MHz clock speed. ISP work fine and there wasn't any
trouble. One extra thing was level translator witch
separate 5V programer and 3,3V uP.

                        Grzesiek



		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Awhile back, when developing a homebrew logging system, I ran acorss the
documenting what temperature the wort reached a certain temp.

At first I thought of recording the temperature every minute. Then, for me,
I had a brain storm. In a loop continue taking the temperature readings.
When the temperature increased by 1 degree F log the temp and time. For
those that are familiar with homebrewing know that the wort, in an all-grain
brew, starts at well above 100 F. Probably above 112 F. Going from 112 F to
a boil at 212 F, we are talking about 101 readings.

I didn't read all the thread on this but somewhere I saw someone talking
about 100%. If you only log the time when a certain amount of change is is
make you should know ahead how many readings you will have logged.

This may give you a different approch to documenting when changes happen.
Doing this you will probably have to log both the time and reading because,
like the temperature above, sometimes the temperature would increase 2
degrees.

Hope I'm not being redundant,
Mike

----- Original Message ----- 
From: "Robert Adsett" <subscriptions@aeolusdevelopment.com>
To: <AVR-Chat@yahoogroups.com>
Sent: Wednesday, July 14, 2004 11:39 PM
Subject: Re: [AVR-Chat] Re: variable/constant input from a PC ?


> At 10:35 PM 7/14/04 +0000, you wrote:
> > > The bigger issue I see is you are talking about an awful lot of
> >data for
> > > the students to analyze.  For the 1/min you are talking about 42000
> > > points.  Will your spreadsheet (or whatever analysis program)
> >handle
> > > that?  And if it does will it do it w/o slowing to a crawl?  It
> >would be
> > > easy to create a dummy data file to check that out.
> >
> >
> >oh, so you're saying there are leaves on those twigs ?
>
> I'm not sure we've got to the leaves yet.  BTW, I just checked the
> spreadsheet I use for this sort of thing and it has a max of 8K rows.  If
I
> want to seriously play with the data the program I use for that has an
even
> smaller limit.
>
>
>
> > > One last data question.  What are you trying to track with the
> >brightness
> > > measurement?  Do you really expect to see a significant change in 1
> > > minute?  I would have guessed a 5 minute period made more sense
> >(maybe even
> > > longer at night).
> >
> >A bush in shade will see light when the blocking thing moves
> >relitaive to the sun.  Imagine tree or tree trunk that acks like
> >gnomon.  as the Earth rotates, the Gnomon will appear to move and the
> >plant will be blocked for some period.
> >
> >How much sun a leaf gets from being in shade vs a cloudy day.  That
> >sort of thing.
>
> Yep, I'm just questioning the need for a 1 minute resolution.  Assuming
you
> are at a reasonable mid latitude, taking measurements in the winter with
> the day getting no shorter than about 8 hours (I'm making this up as I go
> along). 1 minute represents 1/480 or a little more than 0.2% of the
> daylight hours.  Do you reasonably expect to see the difference from even
a
> 1% drop in light?  Or perhaps more to the point what is the minimum light
> difference you expect to cause a difference in what you are measuring?
>
> In either case you will need a low pass filter to avoid aliasing (now we
> are getting to the leaves). Given the time scales the larger part of that
> is most effectively done in software.
>
> You can quite easily track the average exposure during the sampling period
> (It could even be a no-linear 'average' like an RMS) without needing to
> store results from high frequency sampling.
>
> What I'm getting at is if one plant is exposed to 50% intensity for 5
> minutes and another to 100% for 2.5 min and 0% for 2.5 minutes can you
tell
> the difference in the plants responses?
>
> Actually I wouldn't be surprised if you could get away with even longer
> sample intervals.
>
> Robert
>
> " 'Freedom' has no meaning of itself.  There are always restrictions,
> be they legal, genetic, or physical.  If you don't believe me, try to
> chew a radio signal. "
>
>                          Kelvin Throop, III
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
> ---
> [This E-mail scanned for viruses by Declude Virus]
>
>

---
[This E-mail scanned for viruses by Declude Virus]

--- In AVR-Chat@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> At 08:32 AM 7/15/04 -0400, you wrote:
> >I didn't read all the thread on this but somewhere I saw someone 
talking
> >about 100%. If you only log the time when a certain amount of 
change is is
> >make you should know ahead how many readings you will have logged.
> 
> That assumption is valid for monotonically changing systems.  Since 
we 
> talking about daylight over a period of a week the signal is 
certainly not 
> monotonic (well on most of the globe).


This idea has some valid points. 
soil temperature and soil moisture will be very slow change variables 
so even with a time stamp, it would be a valid concept.

as for light, this brings up an interesting study and probably one 
that will gain students interests and that is comparing the growth 
rate of identical plants in varying conditions.

Will a tomato plant for instance, grow faster with 4 hours of direct 
sun or with 8 hours of the the same total light intensity ?

I think there could be two seperate data loops. one continuous and 
one calculated.  Even with the time stamp, the calculated same would 
only change about 50 times a day at maximum so the total samples will 
be small.

Dave

"Patriotism is supporting your country all the time, and your 
government when it deserves it" 
-Mark Twain

At 08:32 AM 7/15/04 -0400, you wrote:
>I didn't read all the thread on this but somewhere I saw someone talking
>about 100%. If you only log the time when a certain amount of change is is
>make you should know ahead how many readings you will have logged.

That assumption is valid for monotonically changing systems.  Since we 
talking about daylight over a period of a week the signal is certainly not 
monotonic (well on most of the globe).


>This may give you a different approch to documenting when changes happen.
>Doing this you will probably have to log both the time and reading because,
>like the temperature above, sometimes the temperature would increase 2
>degrees.

Which leads to the other issue.  If the signal changes frequently (and if 
you include the effects of shadows it certainly can) then it takes more 
room to store delta+time than it does just to store the signal.

On the other hand I would expect the plants themselves to be rather 
effective low pass filters (There is a high school science project in that 
assumption), and recording some sort of filtered average of the light 
intensity over a longer sample period should be as illuminating as 
recording higher frequency intensity samples.

I did a quick search (via google) and the one abstract I found suggested a 
hyperbolic response to light intensity.  That would suggest an RMS filter 
would be quite appropriate.  I didn't find any references to periodic light 
variations (of periods < 24 hrs anyway) having any effect but it really was 
a rather cursory search.

>Hope I'm not being redundant,

I don't think so, this approach probably would work for the moisture 
sensors.  I suspect the soil/plant system has a low frequency response.


" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

<snip>
> >soil temperature and soil moisture will be very slow change 
variables
> >so even with a time stamp, it would be a valid concept.
> 
> Actually no, the idea as stated was that the signal started at one 
value 
> and went in a monotonic fashion to another (no up and downs) and 
therefor 
> the total number of samples could be computed in advance even if 
the time 
> span is not known.  True, but it doesn't work for your inputs.
> The extension suggested (basically a difference encoding) would 
work for 
> some of your inputs, but not for light

I think we are agreeing that somethings like soil temperature, that 
will take hours to change under normal circumstances can be run thru 
a differential calculation and only when the answer is not zero, 
would it record the data.

The only fast change I can forsee is watering.  When one waters a 
plant, the soil temperature changes rapidly and with large variations 
from the previous point.



> >as for light, this brings up an interesting study and probably one
> >that will gain students interests and that is comparing the growth
> >rate of identical plants in varying conditions.
> >
> >Will a tomato plant for instance, grow faster with 4 hours of 
direct
> >sun or with 8 hours of the the same total light intensity ?
> 
> More interestingly what effect is there if the 4 hours is 
distributed in 
> say 5 minute segments (ie 5 on 5 off)?  Is that any different from 
4 
> on/4off at 8 at 50%.


ah, the nature of research...  who knows what the answer will be.  
Seems to be a simple project though.

Dave

At 06:51 PM 7/15/04 +0000, you wrote:
>I think there could be two seperate data loops. one continuous and
>one calculated.  Even with the time stamp, the calculated same would
>only change about 50 times a day at maximum so the total samples will
>be small.

You are going to need software filtering even on your fastest sampling on 
the light (maybe not on your other measurements), otherwise aliasing is 
very likely to be an issue.  I expect humidity and temperature change 
slowly enough that aliasing is not likely to be an issue if you are careful 
about your minimum sampling frequency.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

I just got an obsolete part notice from digikey, on the 2343.

ATMEL CORPORATION                       
   Description: IC MCU 2K FLSH 10MHZ IT 8DIP    
   Manufacturer Part No: AT90S2343-10PI                          
   Digi-Key Part No: AT90S2343-10PI-ND   
   Your Most Recent P.O. No:                     

For more information on possible substitutes, please click on this link
http://dkc1.digikey.com/scripts/us/obs_part.cgi?pn=AT90S2343-10PI-ND   

IMHO a mistake, as this particular mix of features isn't available elsewhere.

--- In AVR-Chat@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> At 06:51 PM 7/15/04 +0000, you wrote:
> >I think there could be two seperate data loops. one continuous and
> >one calculated.  Even with the time stamp, the calculated same 
would
> >only change about 50 times a day at maximum so the total samples 
will
> >be small.
> 
> Speaking of small amounts of data, have you checked to see how your 
> analysis program responds to the amount of data you've been talking 
about yet?

No.

The most likely candidates will be a spreadsheet or an Access 
database.
The most common use will be to print a full graph and then sections 
of interesting parts of it.

Dave

At 06:51 PM 7/15/04 +0000, you wrote:
>--- In AVR-Chat@yahoogroups.com, Robert Adsett <subscriptions@a...>
>wrote:
> > At 08:32 AM 7/15/04 -0400, you wrote:
> > >I didn't read all the thread on this but somewhere I saw someone
>talking
> > >about 100%. If you only log the time when a certain amount of
>change is is
> > >make you should know ahead how many readings you will have logged.
> >
> > That assumption is valid for monotonically changing systems.  Since
>we
> > talking about daylight over a period of a week the signal is
>certainly not
> > monotonic (well on most of the globe).
>
>
>This idea has some valid points.
>soil temperature and soil moisture will be very slow change variables
>so even with a time stamp, it would be a valid concept.

Actually no, the idea as stated was that the signal started at one value 
and went in a monotonic fashion to another (no up and downs) and therefor 
the total number of samples could be computed in advance even if the time 
span is not known.  True, but it doesn't work for your inputs.

The extension suggested (basically a difference encoding) would work for 
some of your inputs, but not for light (At least not without further 
restrictions on the setup to restrict the variability of the light).

>as for light, this brings up an interesting study and probably one
>that will gain students interests and that is comparing the growth
>rate of identical plants in varying conditions.
>
>Will a tomato plant for instance, grow faster with 4 hours of direct
>sun or with 8 hours of the the same total light intensity ?

More interestingly what effect is there if the 4 hours is distributed in 
say 5 minute segments (ie 5 on 5 off)?  Is that any different from 4 
on/4off at 8 at 50%.


" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

At 03:42 PM 7/15/04 -0400, you wrote:
>Actually no, the idea as stated was that the signal started at one value
>and went in a monotonic fashion to another (no up and downs) and therefor
>the total number of samples could be computed in advance even if the time
>span is not known.  True, but it doesn't work for your inputs.

Hmm, that's a little overdone.  Technically correct but probably a reaction 
to what you wrote as opposed to what you meant.  Sorry

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

At 06:51 PM 7/15/04 +0000, you wrote:
>I think there could be two seperate data loops. one continuous and
>one calculated.  Even with the time stamp, the calculated same would
>only change about 50 times a day at maximum so the total samples will
>be small.

Speaking of small amounts of data, have you checked to see how your 
analysis program responds to the amount of data you've been talking about yet?

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

At 08:58 PM 7/15/04 +0000, you wrote:
>The only fast change I can forsee is watering.  When one waters a
>plant, the soil temperature changes rapidly and with large variations
>from the previous point.

The differential approach would catch that just fine though.  The only 
question would be the time resolution you would want.  You could sample 
fairly quickly and only record those that change more than x% from the 
previous record.  When sudden changes due to watering occurred you might 
get sample every 30sec or so rather than every 20min.  As a refinement you 
might want to set a minimum frequency of data collection so that slowly 
changing parameters are profiled more precisely.  IE something like

last = getAD(SOILMOISTURE);
last_measured = 0;
interval = 0;
while( keep_running != 0) {
    wait( 1ms)
    interval++;
    nextval = getAD(SOILMOISTURE);
    if( ((nextval > ((last*11)/10)) || (nextval < ((last*9)/10)) || 
(interval > MAX_PERIOD)) {
         last = nextval;
         last_measured += interval;
         interval = 0;
         store_data( last_measured, last);
         }
    }

>ah, the nature of research...  who knows what the answer will be.
>Seems to be a simple project though.

I have some suspicions.  But you are right it should be simple and it might 
even provide some real insight into the plant's biology.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

At 09:40 PM 7/15/04 +0000, you wrote:
>--- In AVR-Chat@yahoogroups.com, Robert Adsett <subscriptions@a...>
>wrote:
> > Speaking of small amounts of data, have you checked to see how your
> > analysis program responds to the amount of data you've been talking
>about yet?
>
>No.
>
>The most likely candidates will be a spreadsheet or an Access
>database.
>The most common use will be to print a full graph and then sections
>of interesting parts of it.

Definitely check real soon now.  I strongly suspect this will limit your 
data collection more than your ability to store it locally as you collect 
it.  I've used both 1-2-3 and Excel for those (And Quatro many moons 
ago).  I have a ~2000 row item in a 1-2-3 spreadsheet and it takes a few 
seconds to create a graph from that (not bad really).  I've done some with 
Excel and it took longer than that for a few hundred points (not 
necessarily a fair comparison, 1-2-3 had more memory available, Excel was 
on a faster processor).  From what I've seen/heard Access would be a bad 
choice for this.  It's a database and this really isn't a database 
application (you never want to perform a lookup on the data).

The version of 1-2-3 I'm using has a row limit of ~8K items, Excel 2003 
spec claims 64K rows.  In any case create a maximum size data file and see 
how it behaves.  Usually at some boundary even if the data fits performance 
will drop dramatically (what used to take seconds takes minutes or even 
hours).  You will want to know if you are going to hit that boundary.

Memory constraints may slow it down more than processor speed.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

--- In AVR-Chat@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> At 09:40 PM 7/15/04 +0000, you wrote:
> >--- In AVR-Chat@yahoogroups.com, Robert Adsett <subscriptions@a...>
> >wrote:
> > > Speaking of small amounts of data, have you checked to see how 
your
> > > analysis program responds to the amount of data you've been 
talking
> >about yet?
> >
> >No.
> >
> >The most likely candidates will be a spreadsheet or an Access
> >database.
> >The most common use will be to print a full graph and then sections
> >of interesting parts of it.
> 
> Definitely check real soon now.  I strongly suspect this will limit 
your 
> data collection more than your ability to store it locally as you 
collect 
> it. 

On my CNC computer in the basement, the Compac 166 with 64 meg of 
memory. Win98se

Excel shows 65,536 lines and reports that 32,000 points is the limit 
for a single column for a chart.

It takes about 3 seconds to get a graph of the 32,000 points.

With a small amount of mathematical reduction, that offers a 
highlight  of the points of interest.

A single point reading once a minute is 10,080 readings per week.  
That means that a reading once each 10 seconds would be 60,480 points 
and would fit in one spreadsheet column.

I did a little more on Excel.  12 columns of 24,000 readings per 
column and it takes almost a minute to render the graph.

Since it is not possible to print a graph of any value with that many 
points, mathematical reduction will be reguired.

But, hourly and daily totals and averages will be easily done and 
those graphs are printable if the massive data points are available 
for reference.

This means the brute force method of 'just log everything all the 
time' could be done, but with something on the order of 130,000 
readings per week including a time stamp. All the points can be 3 
digit integers including the time. 

I'm thinking that means the brute force reading will eclipse the 
limit of a ram or eeprom.

But, from this information, this does not seem to be a stop on the 
project.

Finding time to learn C is ! 

Dave

At 04:19 AM 7/16/04 +0000, you wrote:
>Excel shows 65,536 lines and reports that 32,000 points is the limit
>for a single column for a chart.
>
>It takes about 3 seconds to get a graph of the 32,000 points.
>
>With a small amount of mathematical reduction, that offers a
>highlight  of the points of interest.
>
>A single point reading once a minute is 10,080 readings per week.
>That means that a reading once each 10 seconds would be 60,480 points
>and would fit in one spreadsheet column.
>
>I did a little more on Excel.  12 columns of 24,000 readings per
>column and it takes almost a minute to render the graph.
<snip>

>This means the brute force method of 'just log everything all the
>time' could be done, but with something on the order of 130,000
>readings per week including a time stamp. All the points can be 3
>digit integers including the time.

OK, that sounds quite doable.  That was my big worry.


>I'm thinking that means the brute force reading will eclipse the
>limit of a ram or eeprom.

I doubt space will be a problem, with even sampling (the just log 
everything approach) you can get rid of the time column and you are just 
under 128K which would fit into 4 of Ramtron's biggest FRAMs.  Not a lot of 
room for extra but some and 4 so-8's won't take much room.  That might be a 
little pricey but I haven't checked that.

Alternatively there are flash packages of serial memory that are more than 
big enough The downside is they have the same complexity issues of 
EE.  Both Atmel and ST have such devices.  For example ST's M25P series a 4 
Mbit (512K) so-8 is about 3.25 at Digikey in singles.  They go up to 32Mbit 
(4M) in a single package. The downside is that write have to occur in pages 
so you would have to buffer the writes. ST also has the M45PE series which 
has fewer write restrictions (only one family member so far 8Mbits (1M)), 
but I didn't see the price on that.

Since you can handle the data I'd say go for it, sample everything at the 
same rate using a low pass filter on the light (just so they don't get 
aliased with any transient shadows)  and let the user do any further 
decimation and filtering with the acquired data.  They'll learn more about 
data handling that way than they would repeating the measurements because 
they set the sampling too slow.

Uniform sampling and a slightly more complex storage mechanism is probably 
easier than multiple sampling rates and a simple storage technique.  It 
should be easy to reduce the data on a PC.

That just leaves, finding time to learn how to do it :)

Good luck, this sounds like an interesting project.  If you want any 
feedback or suggestions while you are doing it let me know.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III