High Pass DSP?

Go To Last Post
68 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Greetings -

 

This is really a general question, not specific to AVR except for integer constraints.

 

As some of you know, I manufacture accelerometers that are used mostly for scientific research, especially tree sway. These accelerometers are three axis, 14 bit data in 16 bit words and are set for a fixed 100Hz sample rate. Lower sample rates are created by averaging N samples to produce an effective sample frequency at 100Hz/N in 32 bit integer data. 

 

I am trying to add a trigger capability. To that, I need to look at small changes in the sensor output. Typically, one axis is nearly aligned with the gravity vector while others are approximately normal to that vector. All three axis have a potential zero offset that can be as large as 10mg. One bit is 0.6mg.

 

To do that, I have been trying to use a high-pass digital filter to remove the static background "DC" signals (offset and gravity). I then determine the magnitude of the effective result vector which should be very close to zero without any dynamic acceleration. Here is where I get into problems. I am trying to generate the trigger from the raw 100Hz sensor output. I am hard pressed to get a filter zero much below 0.5Hz due to integer limitations (Yes, I have been playing games, with fixed point multiplications to get even where it is now). I would LIKE to be able to trigger on signals as low as 0.1Hz while removing temperature variations in the DC offset (typically below .001Hz).

 

Moving average filters WOULD work except that a really long shift register (or ring buffer) is needed to get a low enough frequency, and I don't have that much RAM space left. Any of the standard recursive filters require coefficients of finer resolution for such low frequencies) than what I can get with 8-bit fractional part fixed point numbers.

 

So.... I wonder if anyone here has experience with unusually low frequency filters compared to the sample frequency and might be able to share hints, possible solutions, etc, that might help me move on from this current impasse. 

 

Many thanks

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Fri. Jul 5, 2019 - 01:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One trick might be to multiply the signal with a higher frequency (ie a mixer) and perform filtering at the higher frequency. This might be too much work for the AVR.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Fri. Jul 5, 2019 - 01:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't know if I understand the question correctly, but...

 

Could you maybe use this procedure:

 

1) sample the current value of a sensor (call it zero)

2) add and subtract from this value a small number

    which determines trigger level

3) sample the sensor every 100Hz, if its value is

    beyond either limit you have a trigger event

4) periodically go back to step 1 to calculate a new

    "zero" and upper/lower trigger limits

 

--Mike

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Fri. Jul 5, 2019 - 01:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
... and I don't have that much RAM space left.
Would a mega4808 (6KB) have enough RAM?

XMEGA384C3 (32KB)?

ka7ehk wrote:
... with 8-bit fractional part fixed point numbers.
Normalize to obtain more fractional (acceleration has a physical limit, g converted into fractions of a circle)

https://gcc.gnu.org/wiki/avr-gcc#Fixed-Point_Support

...

signed _Fract

...

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Fri. Jul 5, 2019 - 02:27 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I assume you have the issue: you want a sharp/fast trigger on real event spikes, except you may also have some almost-as-fast background noise & drift.

Maybe a frequency filter per-se isn't the best solution...i'm thinking

 

1) A routine that count numbers of crossings (or other statistics) above some threshold, that itself is changing...sort like the opposite of contact debounce..I need to jell my thoughts here.

2) Take a look at airbag Walsh functions...they are very low computation load & used to obviously trigger at impact, even in presence of the car rocking around (bad struts) , or going through a pothole.  Instead of frequency, they speak of sequency. My friend worked on the modules & they needed to use the cheapest possible micros to keep the electronics bom at $5 (???)

 

https://www.researchgate.net/publication/265150269_An_automatic_seismic_signal_detection_algorithm_based_on_the_Walsh_transform

An automatic seismic signal detection algorithm based on the Walsh transform has been developed for short-period data sampled at 20 samples/sec. Since the amplitude of a Walsh function is either + 1 or -1, the Walsh transform can be accomplished in a computer with a series of shifts and fixed-point additions. The savings in computation time makes it possible to compute the Walsh transform and to perform prewhitening and band-pass filtering in the Walsh domain with a microcomputer for use ,n real-time signal detection. The algorithm was initially programmed in FORTRAN on a Raytheon Data Systems 500 minicomputer. Tests utilizing seismic data recorded in Dallas, Albuquerque, and Norway indicate that the algorithm has a detection capability comparable to a human analyst. Programming of the detection algorithm in machine language on a Z80 microprocessor-based computer has been accom-plishe

 

 

This is a rather interesting read...using walsh to detect first arrival 

 

https://apps.dtic.mil/dtic/tr/fulltext/u2/a196796.pdf

a few excerpts:

a)The advantage of the fast Walsh transform is that it can be computed much faster than the Fourier transform because It involves only integer addition and shifting. The macro subroutine for the fast Walsh transform used in the real time event detector is listed in appendix C.

b) Methods Used to Detect and Record Events in the Event Files. The fast Walsh transform detection window is 6.4 seconds long with a 50% overlap. (see figure 1) When the i spectra of the detection window exceeds the background noise threshold the detection is triggered.

c)see fig 12

 

I could be steering you in the wrong direction, but maybe it's a fun trip

 

 

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Fri. Jul 5, 2019 - 05:01 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm curious the purpose of the device. To detect

wind/weather? Animals in the trees? Chainsaw?

 

--Mike

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies: Thank you very much for the Walsh function hint. Off to search, right now.

 

avr-mike: The purpose for this triggering is to allow recording when things (typically wind) actually happen, to reduce power consumption. The power drops to 25% or less when it does not have to  write to  the uSD card memory. Also, it simplifies analysis (if the triggering is good) as there are not long stretches of data that are just noise. So, it is just a convenience factor. But, then, consider it in a shipping container or a vehicle. You MIGHT want it to record just data that results from a "violent" event. But, again, the motive would be power reduction for longer operating life.

 

When used for tree sway monitoring, it is used for several different purposes. With changing climate, researchers want to know when trees leaf out or loose their leaves, as a climate indicator. Its nice not have to go and physically observe every day. Sway changes with the mass of the tree. But, you can also use it to try to measure how much rainfall is captured on the tree leaves. This is what they are used for in Amazonia. Very hard to measure the rainfall, there, because so much of the rain gets intercepted by the leaves and evaporates back into the atmosphere before hitting the ground.

 

Thanks, to both of you!

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

on a different front (or perhaps it is related, since walsh led me here...)

 

http://gfzpublic.gfz-potsdam.de/pubman/item/escidoc:4097:3/component/escidoc:4098/IS_8.1_rev1.pdf

excerpts:

Today, the ‘short-time-average through long-time-average trigger' (STA/LTA) is the most broadly used algorithm in weak-motion seismology. It continuously calculates the average values of the absolute amplitude of a seismic signal in two consecutive moving-time windows. The short time window (STA) is sensitive to seismic events while the long time window (LTA) provides information about the temporal amplitude of seismic noise at the site. When the ratio of both exceeds a pre-set value, an event is 'declared' and data starts being recorded in a file.

-------------

The STA/LTA algorithm continuously keeps track of the always-present changes in the seismic noise amplitude at the station site and automatically adjusts the seismic station's sensitivity to the actual seismic noise level. As a result, a significantly higher sensitivity of the system during seismically quiet periods is achieved and an excessive number of falsely triggered records is prevented,

------------

The (STA/LTA) trigger significantly improves the recording of weak earthquakes in comparison with amplitude threshold trigger algorithms. At the same time it decreases the number of false records triggered by natural and man-made seismic noise.

------------

 

you could search for:  walsh sta/lta

 

again , this could be a road to nowhere........

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In post #3 you are close. Use variance, sum of squares minus square of sums. That is a trick for RMS on the fly, without individual x-xbar, on ac coupled system. Subtracks dc offset of unipolar adc measures.

It all starts with a mental vision.

Last Edited: Fri. Jul 5, 2019 - 11:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps:

 

The RMS is the DC sensor offset and the non-orthogonal baseline vector offset, with your sway signal riding upon the RMS value.

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps:

 

Another approach might be somewhat analogous to a digital storage scope signal display where the user can move through the recorded signal and look at any part of it.

 

You could record all of the sequential data into a big ring buffer.

 

Your current trigger is looking for a very small vector signal shift against a relatively large background noise level.

 

I would guess (???) that if a tree swats, then over the next 10 seconds from your desired trigger point in time, the signal will undergo a significantly larger shift in the vector with respect to the baseline.

 

So, one could watch for that significantly larger change in vector, essentially detecting the peak of the signal change, or at least detecting well above the very small threshold level, to determine that an event has taken place.

 

Then go back and store the preceding 5 - 10 seconds of data, which will thereby capture the entire sway event, including its onset.

 

With an SD card hopefully data storage isn't a limiting factor, and one will likely be post-processing the data on a PC, where a little more refined data analysis can be performed. 

 

In essence, you look for the big signal change, and knowing the nature of the physical system you go back in time and store (for keeps) the data leading up to and including the event.

 

JC

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe, at this point, it would be good to rephrase the challenge:

 

1) I sell a 3-axis accelerometer. It is widely used in outdoor situations where it is subject to a wide range of conditions, most notably wide temperature changes (think boreal forests, night and day through winter and summer).  All three axes have an offset that is temperature dependent.

 

2) Depending on the orientation of the device, one or more axes will have some gravity component. This component can be up to 1g if an axis is perfectly vertical. 

 

3) I want to add to this existing product (Mega328P) the capability to start recording on the detection of a "trigger event". It will run for a user-set time, then shut off. This mode is intended to reduce power (writing to the uSD card is a big power user) and save uSD memory space (which, in turn, simplifies later analysis by omitting long stretches of "just noise"). The user will be able to select a trigger level, from a few mg to 1g.

 

4) The expectation (hope) is that this "trigger" will denote small changes relative to the semi-static "status quo". The status quo includes offset (with its temperature dependence), gravity, and perhaps normal vehicle motion (the device CAN be used in shipping containers, vehicles, and such). My expectation is that for in-motion applications, the threshold will have to be set higher so that it does not trigger under normal conditions. I use "semi-static" because of the offset variation with temperature and because of the changes in the orientation with respect to the gravity vector in a moving installation.

 

5) What I have been trying to do, up to this point, is high-pass filter each axis to remove or reduce the offsets and gravity, then construct a "transient acceleration vector" from the three high-pass filtered components. Then, determine the magnitude of this vector and compare that magnitude against the user-set trigger level. 

 

6) The trouble I am having is to make the corner of the high pass filter low enough in frequency compared to the sample rate (would like corner of 0.01Hz at a sample rate of 100Hz). For moving average filters, a VERY long shift register would be needed. For recursive filters, "reasonable" fixed-point arithmetic (have been using 8-bit fractional part) runs into resolution problems.

 

7) avrcandies has referenced Walsh functions, which he says are used for seismic detection and vehicle air bag triggering. Following up on that now. KitCarson has referenced something else (I think for transient vector magnitude computation) but I am still a bit confused about what it is supposed to do.

 

8) I am going to explore filtering of the vector magnitude (actually, the magnitude-squared to avoid a square root) rather than filtering of the individual components. This may be computationally simpler, allowing a more complex filter process.

 

So, I am open to other suggestions, comments, clarifications, and such. The comments, so far, have ALL been very helpful. For example, gchapman suggested a different filtering process, which might not be directly useful, but which triggered some other ideas.

 

Keep the comments coming!

 

Thanks

Jim

 

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It would be helpful if you posted some waveforms showing waves you'd like to trigger on, vs the run of the mill backgound  (non trigger) waves.

============

How about this idea...(presented here for only one axis...but the 3 axes could be done separately, or perhaps combined as "one"):

 

Monitor both the signal max and min---when they differ by more than XX counts, for more than YY times, declare that as an event.  Collect & update the max and min every zz milliseconds (say every 40).

NOW, how about drift & what level do we trip at???!!!?? 

     Well the exact level is not needed per se, since we are triggering when they differ by XX

Now, how do you get this max & min?  

     Take it as you'd normally would (every ZZ sec read & compare & set as needed).

But wait, what if the max was set 3 days ago? We need "this hour's max" ...a more timely max  & min.

     In addition to finding the max & min, very sloooowly (every QQ seconds) simply lower the max by 1 count (to no lower than the min) & raise the min by 1 count (to no higher than the max).  

     This produces a very slow, creeepy, "nulling time constant", easily changed by you.  

     Note that concurrently (every ZZ)  the min & max will be re-establishing themselves, fighting your +/-1 up/down nulling

 

If not much is happening, the min & max will converge together at some value corresponding to the current "situation"...since they are "together" their difference is small & no trigger event is generated.

When swaying begins to happen (faster effect than the up/down nulling), the min & max will diverge from each other & after enough times (YY), you declare that something is happening.

 

Note that this uses no "math" at all, it's sort of an inverse debouncing activity...instead of eliminating bounce, we are trying to create it. 

  

 

 

 

      

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Fri. Jul 5, 2019 - 07:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll try to extract some graphs to show the situation.

 

Thanks

Jim

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
It would be helpful if you posted some waveforms showing waves you'd like to trigger on, vs the run of the mill backgound  (non trigger) waves.
Could push that data through a PC or Mac via DSP algorithms to try ideas.

Such tools can be shared such that Jim and his customer can try (two paths, two minds, multiple ideas)

Feasible implementations can then be ported and re-tried.

 

GNU Octave – a Great Time Saver | EE Times

Octave Forge - The 'signal' package

edit : follow 'function reference' to see the forward and reverse Walsh functions

 

edit2 : Ch compares well versus MATLAB and would be easier to port.

Ch for Scientific Numerical Computing and Visualization

...

Advanced numerical analysis functions

...

 

edit3 : Ch's DSP add-on is value-added at a price that seems reasonable.

http://www.softintegration.com/products/thirdparty/#dsp

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Fri. Jul 5, 2019 - 09:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have been doing process simulations and have rejected a few for a variety of reasons. The others at this point are "almost there" but have problems with integer/fixed-point implementations, mostly. 

 

I will post some displays in a few hours.

 

Jim

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

 

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Sat. Jul 6, 2019 - 06:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you able to attach a raw data file to this thread?  Might be interesting to noodle around with it...

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

 

Attachment(s): 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Sun. Jul 7, 2019 - 04:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

I'm confused.  If the samples are 14 bit signed, then that's a range of -8192/+8191.  10 samples will have a range of -81920/+81910, and dividing by 8 gets -10240/+10238.

 

How come the data shows a range of:

x: -127633 to -125842

y: +5468 to +12160

z: -22346 to -12964

 

I'm missing something...

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Sun. Jul 7, 2019 - 06:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Something(s) on the spec sheet do not add up. They say "14 bit" but they also have a table that says that +1g on +/-2g scale (finest scale) is 0x4000 (nominal).

 

0x4000 is 16384 by the reckoning of my hex->decimal calculator. Summing 10 (+1g readings) would make 163840. Dividing by 8 would make 20480.

 

That still does not square with the data. More digging is needed. This may be a challenge because the data was gathered with a preproduction prototype and I do not have a traceable copy of the software that was in that unit.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Don't sweat it too much.  I was more curious than needy.  I'll just normalise the data and move on.

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That is what I would suggest.

 

BUT, I do need to resolve this "issue". Thanks for pointing it out.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Any of the standard recursive filters require coefficients of finer resolution for such low frequencies) than what I can get with 8-bit fractional part fixed point numbers.

So... I'm guessing you can't use wider coefficients (16- or 24-bit) and get finer granularity at the low frequency end?  I recall seeing dot plots of the possible poles for different filter topologies, but can't remember where I saw it.

 

EDIT: ah, nevermind ... here's one place:  https://dsp-nbsphinx.readthedocs...
 

It also shows how a different structure can give you better pole location coverage.  Maybe you're already doing that.  

Mike

Last Edited: Sun. Jul 7, 2019 - 01:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Earthquake detection on a chip...

 

https://hackaday.com/2019/07/06/...

 

 

...may or may not work for detecting tree wobble.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jim,
Sorry for long delay. Hint I gave for multiple samples, and it works for bipolar data aquired unipolarly. It was was for 3phase voltage and power measurements, 25 years ago. Signal was periodic -60Hz, and sampling synchronous. V,I,LLVs,Power from point v,I can be derived from sum of cross products, minus product of i,v sums. In the linear algebra some terms zero, so trick works. Suppreses undesired DC in process. It saves text book, accumulating, dividing by #pts, then subtracting each point, something that hogs memory, to save points, and all individual subtractions. Perhaps the only thing to take away from this, is computer solutions in some cases have simple solutions. Idea of using data in spreadsheet, and play, often results in solution.

I haven't touched embedded for 2yrs. Found vintage Singer sewing machine as a hobby. Might get back someday, if grandson has interest.

It all starts with a mental vision.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian - this is an attempt to retrofit an existing product with event trigger capability. So, I am not looking for new hardware. But, that is interesting.

 

KitCarson - thanks, that clarifies things. I dont think that the necessary conditions for that are met here. 

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, might as well ask some more questions..., or make an observation or two.

 

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.

 

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

Presumably, for power savings, the buffer size matches the SD card's sector size?

It has been a while since I worked with SD cards, but IIRC internally the card reads a sector, updates it, then writes it back.

If one was to write 512 bytes one byte at a time one would actually be reading and writing a full sector 512 times.

So one would minimize the card's energy usage by writing exactly one sector at a time, and making sure that the data was sector aligned.

But you likely already new that, and are doing that.

 

Remember holding one's fingers out, orthogonally,  and studying E & M fields?

I had to hold my fingers out to see how the different axes (Had to Google the plural of axis!), to see how a tree sway would effect them.

As the graph shows, Trees don't hop up and down, so the X, (downward, gravity axis), shows very little change as the tree bends.

The "big" change is in the lateral motion, (acceleration), of the trunk when the tree bends.

That is clearly shown by the example data plots.

 

So, I'll as the question:

What does the X axis data even add to the project?

It would appear that the Y and Z axes demonstrate the sway.

So why bother measuring and recording the X axis?

If you only record the overall vector then it doesn't save you much in memory or SD card energy consumption, but it does save processing time.

 

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?

That might free up some time/memory for more involved data calculations on the other axes.

 

Looking at the data one has to ask how is the data used?

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.

One can easily "inject" the dead time, flat line, on the PC if one was plotting the events graphically for viewing, etc.

 

If the project users are looking at the frequency domain of the Y and Z axes for their sway detection, and a measure of the sway amplitude, then clearly one is doing some significant post data collection signal processing.

That then raises the question:

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

If so, why?

Perhaps it just needs to be a dumb box data collector, as all of the real processing will be done after the fact.

That then clearly changes one's design criteria, and buffer size and battery size become far more important that processing horsepower.

(Something to consider for Version II, obviously not relevant to the boxes already out in the wild, (no pun intended).)

 

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.

 

Can you mention how often the data is retrieved?

 

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?

 

Final thought to ponder.

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?

 

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...

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!

 

Cool project!

 

JC

 

Edit: Typo

 

Last Edited: Mon. Jul 8, 2019 - 04:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm gonna try my proposal later, just to see what happens.   Maybe write a python script.  It keeps track of the local min & max separation (each slightly smoothed), using a time-forced closing rate between the two.  When the separation is above a certain amount for enough cycles, the alarm is sounded.  

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Mon. Jul 8, 2019 - 06:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I converted your data file in #23 to three separate .WAV files, with the correct sample rate of 10 Hz (thank you Cool Edit Pro! [now Adobe Audition]).

 

Attached are spectral views of each (horizontal axis is time [entire 24h file], vertical axis is frequency):

 

X:

 

 

Y:

 

 

Z:

 

 

Note the scale on the right.  That is in Hz.

 

The X has a peculiarly sharp and flat artefact at about 0.5 Hz, and the 1st harmonic at about 1.0 Hz.  This would not appear to be data, but narrow-band noise.  Might be interesting to track that down.

 

That narrow-band noise appears to be absent in the Y and Z, although there does appear to be a signal present at the same point.

 

 

Here's a spectral (not temporal) zoom near the fundamental:

 

 

Note the very narrow peak at 0.532 Hz (although for the first several hours it appears to be at 0.512 Hz, and at 0.492 Hz for the first several minutes, a step of 0.02 Hz each time... stranger and stranger...).

 

Here's the Y zoomed near the same frequency:

 

 

Appears to be centred slightly higher near 0.57 Hz, but with a much broader band as I might expect from a real signal.

 

None of this helps solve your initial question, of course.  I'm just poking it with a stick for now.  Maybe these images will give others an idea.  I'll poke it again later as time permits...

 

EDIT:  attached the .WAV files themselves.

 

Attachment(s): 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
As the graph shows, Trees don't hop up and down, so the X, (downward, gravity axis), shows very little change as the tree bends.
One may want to know when a tree fell (one of the disadvantages for a tree being at a forest's edge)

A tree can hop though that's typical only in a few or several rain forests (tropical, temperate) near or in earthquake and volcanic zones.

DocJC wrote:
If you only record the overall vector then it doesn't save you much in memory or SD card energy consumption, but it does save processing time.
Compression is another way though might not be a fit in the current mega328 application.

Lossless compression might be enough; lossy compression could be evaluated.

DocJC wrote:
I'm thinking of minimizing my ladder activities for a while!
Don't, simply be careful; may you heal well.

Summer can be the best time to work on BASE (Buildings, Antennas, Structures, Earth)

DocJC wrote:
Cool project!
yes

 


https://octave.sourceforge.io/list_functions.php?q=compres&sort=package (GNU Octave)

 

Might consider :

  • Variable rate sampling (re-sample the no-sway periods)
  • ADPCM (max of 4:1 lossy compression)

though the following is from AVR32 UC3L ASF3 :

 

ADPCM Overview - Windows applications | Microsoft Docs

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here's another view of the X and Y, as spectral plots of the average of the entire 24h file:

 

 

 

 

This view is somewhat more sensitive than the previous views, although they are averaged over the entire file.  Note how narrow the peaks are in the X, and how multiple harmonics (and possibly other sources of narrow-band noise) are visible.  These peaks are absent from the Y, but the wide-band signals are clearly visible.

Attachment(s): 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

 

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

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

Yes I played around quite a bit, looking at various time/frequency zoom levels.

 

What struck me was the apparent narrow band noise on the X, akin to the 15kHz noise often found on audio recordings, usually caused by a CRT in the studio during one of the sessions.

 

In your case, the signal seems so narrow and exact that it seems to me it can't possibly from the tree or the environment, but a consequence of the device or capture somehow.

 

Again, irrelevant to your original quest.

 

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Mon. Jul 8, 2019 - 08:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

The only thing I can think of near that frequency is uSD writes.

Might be coinciding with the X axis sampling.  If power is sagging a bit due to uSD load, could have an effect.  Doesn't explain why it's not there on Y and Z though, especially since all three are actually sampled at 100 Hz.

 

Could it be evidence of a computational defect in your code?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Strange ...Got an email about this tree analytics show in CA locations...not sure if any interest

 

https://about.aerobotics.io/

 

Google probably saw me searching for tree monitoring/swaying...but can they then send me an email?

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the problem and the data.  I did locate a fixed-point package for Octave, but that is out of date (i.e., assumes sizeof(int) = 32).  I want to try to update and see if analysis of fixed-point is doable in Octave.

 

Ref: fixed-point package for Octave

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I added the actual .WAV files to #36, for anyone interested...

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

>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.

 

Mount the sensor in the tree, have the base unit at ground level. Now the battery change and data retrieval becomes quite simple (bigger batteries also then become an option I assume, as hauling a car battery up a tree is probably not that easy).

(you could also have a number of sensors in the tree all connected- TLAN)

 

Just a thought.

Ok, I'll switch from commenting back to reading/learning mode :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Wed. Jul 10, 2019 - 06:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

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).

Low power sensor node wirelessly linked to the base below.  Would have to do a power budget analysis, but possibly a small PV array and lipo battery would be enough to run an mcu+accel+radio 24/7, with capacity to handle cloudy days.  Could put the trigger smarts into the sensor mcu, to minimise radio use and allow a lower power budget.

 

The base below could house another mcu and the uSD card.  That could also be PV, but likely much less usable light energy down there.

 

Either way, would have to do a worst case analysis (clouds, dirt/debris, age, tree leaves blocking sunlight) to determine how large a PV cell would be needed, and whether or not that is feasible/economical.

 

No wires for varmints to chew ;-)

 

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Pages