AVR Freaks

Not a bad idea! It might work at the 100Hz sample rate.

Thinking .....

Just thought - at the present time, I am filtering each component, THEN constructing the magnitude-squared of equivalent "transient" vector from the 3 transient components. I am only squaring to avoid doing a square root (squaring the comparison threshold value, also). I am wondering if I can get that squared-magnitude of the unfiltered (e.g. background "DC" plus high frequency) then do something (maybe some filtering) as part of the squaring. That squaring is a nonlinear process so maybe some kind of "mixing" at that point could work. At the very least, filtering the squared magnitude would reduce the computation and maybe allow more time to work at a higher resolution in the filter.

Thanks

Jim

There is a problem, there, that shows up at low thresholds. It is the temperature coefficient of the sensor's zero offset. Even using the internal temperature sensor is not sufficient to correct because the magnitude and sign of the tempco can be different on each axis! 

For thresholds above 0.25g or so, that is adequate. 

The challenge is that this thing is being used on really big trees (Amazon rain forest) with VERY low sway frequencies. That means that even with a given peak displacement, the acceleration is really low. Second derivative w.r.t. time of a sine (displacement) to get acceleration is proportional to the square of the frequency. So compared to 1Hz, sway at 0.1Hz (10 second period) has 1/100 of the peak acceleration amplitude. In turn, that generates the need for very low trigger thresholds which run, head-on, into the temperature variation. It can actually change quite rapidly (minute-scale) when the edge of a shade shadow moves across the unit. Then, at low levels, if you should happen to measure that correction value near the peak of a sway cycle, everything gets messed up. (Yes, I've been there, and tried something very similar).

Thanks!

Jim

It is an existing product that is being retrofitted. NEXT one will have 4808.

I am normalizing the fixed point value. All the coefficients are less than 1 and greater than 1/2. So, I am multiplying by an integer number between 128 and 255, summing the parts, then dividing by 256.

Jim

Thanks, for both of you!

KitCarlson: Does your process work only for unipolar signals? I am thinking particularly of the "square of the sum" term. Is there a name for this algorithm? I don't quite understand, when you talk about variance, that implies to me use of multiple samples So, when you write sum of squares, is that squares of a number of samples? My sum of squares is for the purpose of finding the magnitude-squared of the vector represented by the three (X,Y,Z) components, not RMS. So, I am a bit confused.

avrcandies: I don't think that I'll pursue variable sensitivity at this point but I could see it importance in a moving vehicle. 

Best wishes

Jim

Here is an example of data from tree sway. In this installation, the top is X in the gravity direction, middle is Y is one horizontal axis, bottom is Z the other horizontal axis. Each panel represents approximately +/-1g. 1 pixel per sample at 10Hz. This happens to be a maple tree about 25' tall, so you get movement both in the bulk tree and the individual branches, each at its own frequency according to branch length and effective mass. The sensor is located about 1/3 of the way up the tree.

Each data file is 24 hours, and a 24 hour mean is determined for each axis (you can do this post-recording). In this display, the 24 hour axis mean is subtracted from the axis data. It shows you how much the local zero can differ from the mean; I believe this is due to temperature variation of the offset. 

I believe that the local X axis departure from the mean during this event is due to the fact that the sensor is tilting with respect to the gravity vector, so there is a cosine variation as the trunk of the tree movies horizontally.

The display software is a data analyzer written in XOJO, which has been mentioned a few times in this forum.

Jim

Sure -

Here is the format of the attached file. It is a plain text csv file.

1. Starts with a header

AL100 Accleration Logger
Version: 1.3
Sample Rate: 100Hz/10
Full Scale: +/- 2g
Factory S/N: 1050
User S/N: 
Label: Maple budbreak high
Date/Time: 2016-04-13 18:21:31
Time stamp: 5 sec with temperature
 

2. Followed by an empty line, then a field label line: 

###,  X,  Y,  Z

3. Then CSV lines. most are of the form:

samplenum, X axis, Y axis, Z axis

Acceleration values are generated at 10Hz rate. Values are the result of summing 10 x 100Hz samples and integer dividing by 8, not 10, to get more resolution. The raw values (that go into the "averager") are signed 16 bit though only 14 bits are significant; the top two are sign extended padding.

4. There are also timestamp lines every 5 seconds that always begin with "T" and look like: 

T,3,18

First number is elapsed seconds and second is temperature in C

5. Files are 24 hours long.

Please don't forget that the challenge is to trigger on events in REAL TIME. A small number of samples at the beginning of the event can be missed and the recorder runs for a preset time (set by the user) after the trigger. If a new trigger happens while recording, the timer is reset, so that it records the preset time after the last recognized trigger. The user can also set a trigger threshold value (from a few mg to 1.5g on the +/- 2g scale in a logarithmic sequence).

Have at it!

Cheers

Jim

That data is from an instrument running V1 code. I'll have to go back and check it. Something does seem strange. 

For the most common applications, folks ignore the amplitude and look at the spectrum. I suggest to them to "calibrate the axes against local gravity" if amplitude is important. But, I will check it. 

Thanks for catching that.

Jim

jc - so many questions and ideas, all good.

I suspect the software that is optimal for tree sway might not be optimal for monitoring a package shipment, and whether or not UPS drops one's new laptop.

I have little doubt that you are correct. The one thing that this device offers that few others do is long operating time on batteries. I can see it being useful in shipping containers where it might be en-route  for a month or more, maybe between US and Europe or Asia, going by truck and or rail to a port, then via ship, then another port, then more truck or rail.  Lots of opportunities for high impact events that some shippers might be interested in. The data and recording rate requirements are pretty similar for the two applications; the profile of potential trigger events could be quite different. In the transport case, I would expect impact; in the case of tree sway, it will be much "softer" and probably interested in pure amplitude.

How do you go about writing the data to the SD card?

Using the FatFs SD library with a 256 byte application buffer. I write CSV records to the buffer and when the buffer is full, it gets dumped to the SD card. At 10Hz recorded sample rate, that dump happens about once a second, plus or minus. I don't have much control over this.

So why bother measuring and recording the X axis?

That is a very good question. My justification is that it makes the orientation of the device unimportant. But, of course, it comes at a cost. Battery life is a big cost. Recording just two axes would increase the recording time by 1/3 and that is not a small issue. With many of the units now going into "citizen science" projects, I thought that fewer deployment details would be important.

Taking it a step further, when then should the tree sway monitor bother sampling the X axis, and including it in the calculations and the data storage?

The original model allowed the user to select which axes are recorded, with the understanding that fewer axes means more recording time. As far as I can tell, this was never used. So, I left it fixed at recording all 3 axes. 

I suggested triggering on the peaks of the sway, easily detected compared to detecting the onset of sway, and then back recording the data of interest, but that presumes you have enough buffer space, and aren't recording "dead time", with no motion.

Since you have an RTC, one would ask why you bother to record the dead time at all.

A flat line is a flat line is a flat line.

If there are hours of the day, (night time perhaps), or days on end, when there is little motion, or the motion is below the system's noise level, then recording that signal seems to be wasteful or power and memory.

Trees sway when there happens to be wind. Often, there are many hours, even days, with so little wind as to be basically "dead" as you observe. But, we don't know when this will be, and that is the whole point of trying to get triggered operation. Without triggering, recording all that noise is indeed wasteful of both battery life and recording medium. Until I can respond to activity, there is not much else one can do. Then, you have scientists who view lack of data with suspicion - how do you know that something was not missed? I can imagine there being applications where knowing the amount of dead time might be important.

Does the box need to do ANY data analysis at all?

If so, why?

Here, we get to an important question.

Recorded data is processed only to the extent of block averaging to reduce the sample rate and improve resolution. The only real analysis I am proposing is for trigger detection. Also, its not really "analysis" though a decision is being made depending on the output: start (or extend) recording or not? That is the extent of analysis. Some processing needs to be done to get to that decision and that processing is what I am trying to design, right now.

From a data processing and storage perspective, one might also argue that if the tree sways, and doesn't fall over, then it has to "sway back" to its original position.

So in theory one could store half of the sway event and still know the occurrence of the sway and its magnitude, if one had a sway "Peak" detector.

This is analogous to storing 1/4 of a Sin wave instead of recording 1/2 of a sin wave, you already know what the "missing" data looks like.

Interesting observation. So far, none of the instrumented trees have fallen over so there is no experience with that!  There is not much problem distinguishing "big" events but tree sway tends not to have very high accelerations. Since acceleration is the second time derivative of displacement, it is proportional to the square of the sway frequency. Thus, the really tall trees, such as in the Amazon rain forest, sway a long ways, displacement-wise, but the acceleration is very small because the frequency is so low (periods of 5 seconds or more were not uncommon). Thus, there is a need to be able to trigger close to the noise level and that is the challenge.

Can you mention how often the data is retrieved?

That varies with the experiment. Citizen Science projects tend to do weekly. In the Amazon, they tended to do 45 days, and change the batteries at the same time. This was a BIG undertaking because expert tree climbers were needed and each instrument would take several hours. In that experiment, they tended to swap SD cards. Don't know if they tried to do that up in the tree. Imagine dropping an SD card from 150' up in a mahogany tree!  A recent experiment in California Coast Redwoods simply started the unit, installed it, then pulled it off after 45 days and shipped it back to the lead researcher, without even opening. I have a copy of those data files, so have a full record of a FedEx shipment. Oh, the files, themselves, are for 24 hours.

I guess the real question in my mind is why do you need to determine the sway onset in the data logger?

Perhaps I misread or overlooked it, but it sounds like you are continuously data logging at 10 Hz, and not ignoring the no-sway intervals?

Or is the goal to start ignoring the no-sway intervals?

Or is the goal to increase the recording's sampling rate during a sway?

 Goal: start ignoring no sway intervals.

Now that you have real world data, is +/- 1 G full scale still the best choice?

Can you set the X axis for +/- 1/2 G full scale, if you really need to record it?

This ia a limitation of the sensor. I would really love to be able to set the axes independently, but not allowed. With that limitation, the most sensitive scale is +/-2g. There are also (+/-) 4g, 6g, 8g, and 16g scales but none of my users, so far, have used those.

Side story:

I was helping load my son's pickup truck bed with a bunch of furniture, (Ikea), still unbuilt in (Heavy) boxes, for him to take to his new college apartment.

He got me a step ladder to make it easy for me to climb in and out of the back of the truck.

(Ask me if that made me feel old...).

And, while backing out of the almost full truck bed, I wasn't properly aligned with the step ladder, it tipped, and I fell.

My son laughed...

I don't want to know what an accelerometer would have read! Have just had two local friends involved with falls. One had fractured vertebra and cracked ribs. Laid up until September. You got out of that one pretty lightly!

Back on topic:  How does one get the data from the boxes mounted up in the trees?

Does one have to retrieve the box, or does it have a wireless interface?

I'm thinking of minimizing my ladder activities for a while!

Getting the data is a bit of a chore. A common mounting strategy is with bungee cord. 

Basically, you HAVE TO remove a uSD card. Some take the unit down, some do it in place. Commonly, batteries are swapped at the same time. Version 2.0 will have the option for real-time or batch wireless data and a way to greatly extend battery life. Minimizing ladder work is a good strategy. Right now, my brother is helping me design a base that the unit latches into. The base gets secured to the tree. With this base, the user can easily remove the unit, service it, and replace it in very close to the same orientation as it was previously.

Thanks for those GREAT questions. They really help to focus my thinking and planning.

Best wishes

Jim

Very interesting. That IS consistent with spectra that I have generated, though not identical.

I expect the spectrum to be pretty "jumbled". That particular tree (a 25' maple) has a number of sub-branches to the trunk and each is a different length plus each of those has lots of branches, and those have branches, and those have branches (standard fractile style).

The spectrogram is somewhat clearer if you just use an interval with known activity rather than the full 24 hours.

Jim

I had not caught that narrow-band signal because I don't think that I looked at that axis, spectrally. I need to look at current units to see if that is still present. The only thing I can think of near that frequency is uSD writes.

Thanks!

Jim

Could, indeed be a computational defect. Computation is designed to be exactly identical on all axes, but I will look at this possibility in detail. That IS the axis that has the highest gravity component. Maybe there is something with larger numbers?

I had considered power supply sag during SD write, but, as you note, it is not present on the other axes.

Again, thank you VERY much for catching that.

Jim

If you read between the lines, that show series seems to be oriented toward disease control and yield management. I don't think that I have much to contribute there.

Jim

That is a VERY interesting idea. I am working on an external power pack that would allow larger power sources for longer operating life compared to the current 6 weeks with continuous 10Hz sampling. This life IS expected to be significantly longer once triggered mode is working. But, I DO like the idea of having the data accessible from ground level. REALLY like it, actually. This capability would mean a major system redesign, but now working on TreeSway 2.0 so that's not out of line.

Not sure that multiple units in one tree would be of much use but that certainly IS an option once you change the system architecture. Also interesting what you would do for a sensor that is a hundred feet up in a tree, especially where there are varmints around (especially monkeys).

Thanks for the GREAT idea.

Jim

Tree leaves are a major obstacle to use of solar cells in many trees. I had a test installation in Boulder, CO (well, a local researcher did it, and shared the data). It worked great during the winter; nice sun, bare tree, worked great. But, when the tree started leafing out in May, you could see the battery start to go down. It would come up during the day, and down at night, as you would expect. But, as the tree leafed out, each day, less and less of the night-time energy use was recovered the next day. It finally failed in late June.

'Tis a challenge!

I like wireless, but, in this case, its hard. And, not hard because of wireless, specifically, but because of the energy budget.

Jim

curtvm - pretty sure there are solutions. Its a matter of finding them.

joeymorin - the problem was insufficient sizing of the solar cell. Unfortunately, I had no usable data to base any design on. The Boulder test was sort of a best-worst-case scenario. Winter, there is lots of sun. But, elsewhere, its a big problem and especially in realms north of, lets say, 40N, or south of 40S. It would have been a VERY rapid failure at my own house. In a northern hardwood forest, it would have been unworkable, summer or winter; just too much shade and too little sun whole year. That is part of why I've been looking at external power delivery that accommodates more than just solar.

avrcandies - wired would probably be the simplest technically and maybe logistically. Simply not having to climb a tree after installation would be a big plus; many kinds of trees are really hard to climb. The unknown is how well a wire link would stand up. In some places, squirrels are a big problem with scientific gear, especially wires (they chew wires). In other places, its bears, or monkeys or other critters. Basically, there is no free lunch! The "something like a selfie stick" is not a bad idea, but something like that that sticks up high is an ideal perch for many kinds of birds and bird poop is a real killer for photo cells (in addition to just covering them up).

Some great thoughts and ideas here. It is great to have some of these seemingly "off the wall" suggestions. They really can lead to some useful rethinking, some times.

Jim