NSLU2-Linux
view · edit · print · history

"Frogloggers" have been successfully used in biological field research:

Bridges, A. S. and M. E. Dorcas. 2000. Temporal variation in anuran calling behavior: implications for surveys and monitoring programs. Copeia 2000: 587-592.
Peterson, C. R., and M. E. Dorcas. 1994. Automated data acquisition. Pp. 47-57. In: Heyer, W. R., M. A. Donnelly, R. W. McDiarmid, L. C. Hayek, and M. S. Foster (eds.). Measuring and monitoring biological diversity: Standard methods for amphibians. Smithsonian Institution Press, Washington, D.C.

Those two efforts were for recording frogs, but other uses have been for recording birds and insects.

The first frogloggers used a custom programmed microcontroller and timer, along with a cassette tape recorder. Newest ones use minidisc and solid state recorders, still controlled by a microcontroller and timer (http://froglogger.coquipr.com/).

Use of an actual computer such as the slug offers the possibility of doing audio recording in a similar timed fashion, but also weather data could be logged, using 1-wire devices for example, and the processor could be used during idle times for processing and filtering the audio (hopefully the slug would be robust enough to do something feasible here), device-to-device communications, device-to-web communications, etc.

Typical field biology studies are done over a period of at least several months, but perhaps for several years, with periodic visits to the field for data collection. For a study of birds, one might visit the field weekly for a period of a year to get a good sample of the species using a particular piece of land (this is called a species inventory study). Other studies, such as the work being done by L. J. Villanueva-Rivera (who runs http://froglogger.coquipr.com/), are focused on particular species; in that case, on a species of endangered frog.

One important concern is getting the cost down as low as possible, to allow deployment of multiple "stations" at once. This crux of the problem is that one researcher can't be at more than one place at a time, but it would be great to be able to collect data from different habitats simultaneously. This would allow more robust comparisons of habitat use by different species. So, if a "station's" cost could be kept down to several hundred dollars, it would be a very workable research strategy for many researchers. Of course, when dealing with audio and huge amounts of data, there must be a feasible processing design -- thus, investigation here is to determine the feasibility and design of the data collection part first, with a kind of parallel and contingent attention on software development.

At first blush, components of a slug-based system might include:


Audio Recording:
USB external sound card
Griffin Technology iMic for about $35
In this review of the iMic they mention that the iMic needs a dedicated USB port -- I wonder if this will be a problem? (not to be able to plug it into a USB hub, if that is the case).
Soundblaster Live 24 bit external for about $50
This one is tad more expensive, and haven't done any comparisons with the Griffin iMic.
external microphone:
a good external mic is the Sony ECM-MS908C for about $80
but, consider DIY for lower cost to allow more stations
Combo sound card/microphone:
Sound Professionals USB mic for $59.
This one is actually a tiny USB microphone -- so the external sound card would not be needed.
From the product sheet, "combines a high quality, high sensitivity, omni-directional microphone with a quality mic preamplifier and built in A/D converter – it is essentially a miniature external soundcard with a built-in microphone." If this microphone performs for the task, it could be the ticket.
I wonder if it would work in a USB hub, instead of in a dedicated USB port, as mentioned above for the iMic)?
Sound Professionals offers up to a 4.5 meter USB cable with this microphone, which gets me to thinking about being able to place the microphone at a specific location in a tree or patch of shrubs -- a specific microhabitat. The specs don't say much, but it does mention a range of 40 to 50 feet. And, in such usage, it would perhaps be better if it isn't the greatest mic in the world (pick-up-wise), because you would want to sample a specific microhabitat location. If this works -- and eventually something like it will, and even cheaper -- researchers will be able to deploy many recording devices, each targeting specific microhabitats, and will be able to design robust sampling strategies. Exciting possibilities!
Sound Professionals IMic/Microphone Combo for $99.
This is effectively the same as the one above, but it includes an actual iMic device, which could offer quality advantages? control advantages?. There would need to be $40 worth of advantages, because that is the difference between the cost of this and the tiny mic/soundcard combo described above.

Storage / Data Handling::
USB Flash stick
- lower power
- lower cost
- but, lower capacity, which would require more frequent field visits to collect data (by actually switching out the sticks?)
USB Hard Disk
- more power consumption (it is assumed)
- higher cost (well, maybe; the optimum price point, on a mb-for-the-buck basis, is somewhere here)
- but, higher capacity, which would require less frequent field visits, and might allow audio processing fu in the idle times
Possibilities:
Use a laptop hard drive in an enclosure. In the list of what people do with their slug, there are several mentions of this use, and that the power consumption is low and the noise is quiet. Need to find out more about this angle.
Got a tip from ByronT to check out the BYTECC ME-930U2 2.5" USB 2.0 External Enclosure and a 2.5" drive. Found a price of $14 for the bytecc, and a price of $66 for a "Western Digital Scorpio WD400UE 40GB 5400 RPM Notebook Hard Drive - OEM" as an example, for a total cost of $80, which seems to offer a good inexpensive solution.
Storage Needed
Lossless (PCM) audio saved to a wav file, at 600 mb / hour, would amount to about 50 mb for each 5 minute sample. Sampling 5 minutes/hour, the samples per day would add up to 2400 mb per day, and for a seven day week the stored wav files would amount to 16800 mb, if my calculations are correct. Taking advantage of the slug's processing power (hopefully) to filter the audio using bird or frog specific processing fu, this would require perhaps double the storage, if the filtered file is the same size as the original.
Leanest recording to a flash disk: Record 1 minute of lossless audio to a wav file every hour. This would amount to 10 mb/hour or 120 mb/day or 840 mb/week, requiring at least a 1 gb stick, and perhaps missing the price point, which looks to be at about 512 mb (but there is a bare minimum size needed for the slug anyway). Hmmm..., well for birds, recording could be concentrated in the morning, especially, starting before sunrise and perhaps also in the late evening before sunset. Maybe something like 1 minute for 4 hours in the morning and 2 in the afternoon, for a total of 60 mb/day, or 420 mb/ week, but this really doesn't seem very attractive.
Compression. FLAC (Free Lossless Audio Codec) seems to get compression ratio of about .5, but I'm not sure about encoding speed on a slug...
Data Handling
Field Collection. In the case of a one-shot deployment, you would simply collect the data logging stations in toto and take them back to the home network for downloading and data archiving. But for deployments where devices are left in the field, there must be a scheme for pulling off the data periodically.
If your budget was rich enough, you could switch out the mass storage device of each unit, either an external hard drive or a flash stick, perhaps -- this might be the most rapid method. For this scheme, you would need two storage devices for each unit.
Or, you could hook up a storage unit that is larger than the stored files and copy off the data. A labtop with an attached large external USB drive for backup could be used. The mass storage device would be unhooked from the slug and plugged into the laptop for copying off the data to the backup drive. This might require an extra laptop battery.

Weather Sensors
1-wire sensors seem to have good support and functionality, but there are more DIY examples that seem less expensive. There is one very good reason to consider 1-wire, as Simon Melhuish is using a slug now for his weather station and One Wire Weather software (oww): http://oww.sourceforge.net/. A good source for 1-wire sensors seems to be maybe 1-wire devices such as those at http://www.hobby-boards.com. As described on the oww hardware page, the 1-wire weather logging devices are connected to the slug by a DS9490R 1-wire adaptor USB connector, so this would require getting this connector and an external sound card working in a USB hub.
Also, there are plenty of DIY weather station descriptions on the Internet that use PIC, AVR, OOPIC, and other microcontrollers, and these could be hung off a serial port following SOP, leaving one USB port for a soundcard/microphone and the other for a hard drive. Lower cost might also might be an advantage here.

Power Possibilities:
Power requirements of the combined slug, hard drive, and other devices would need to be determined by testing, and then several possibilities could be considered:
Perhaps a rechargeable could be changed out weekly; maybe something like a RoadPro (http://www.baproducts.com/rpsl-600.htm). (Maybe wrong voltage though; only 3v; I use one of these to power my Zaurus for field work) This one is not so terribly heavy; several could be collected in one hike and packed out. Something as large as a car battery would, ahem, strain the limits of possibility, given the hope for multiple devices scattered across an area, and including the need for frequent repositioning.
Or a battery and a solar trickling charger (e.g., this one)

Networking/Communications Possibilities:
USB Wireless perhaps; for my project, multiple stations would be deployed across a several hundred acre forested land tract (about 1 x 2 km) -- distances would require station-to-station communications perhaps
If each station device had its own large hard drive, such a networked design would not be necessary, as each station could be visited periodically for servicing batteries and to download data/switch out storage devices. Even in such a design, however, wireless communication between stations could allow real-time adjustment of sampling rates (sample more, when more detections appear, less when species activity slows; careful here, though, regarding proper statistics and robustness), or automated control based on weather conditions and/or other variables. A further benefit of having autonomous stations would be that failure could be limited to one device at a time.
Or, if each audio/weather recording station had limited storage to keep the cost down, perhaps the data sent via wireless communication to a central storage station, which would contain a large hard drive. This design would have the benefit of easing the interaction with only one main device, if the logging stations had low power consumption and long life (the logging stations would write over the storage on perhaps a daily basis, after uploading data to the central repository station).
And, perhaps it would make sense to have some station devices as audio recorders only, some as weather stations only, or some as combination audio/weather loggers. Perhaps weather data needn't be recorded on such a fine scale; perhaps even one weather recording station would do; however, wind and temperature do vary locally, and it would likely be a great thing if weather data logging could be done for each station, since the physical labor of placing them will be substantial anyway.

Study Designs (Has obvious implications for design of each unit; For all designs, assume there are 10 slug data recorder units):
One week deployment, changing batteries, pulling off data each week.
Move each unit each week
Leave units in place
Three days per week deployment, perhaps pulling data off daily, if units are handled during moves; But all units would be taken to home network for processing during the 4 day "off" period, so daily data handling would probably be unnessary.
Move units each day, for three separate 24 hr recording sessions
Leave units in place for 72 hrs.
One day per week deployment, collecting all units at the end of the day for processing at home over the next six days.
Units could be moved between morning and afternoon sessions, if desired.
Leave units in place for 24 hrs.
Longer range deployment, well why not?
Leave units in place
No, mount them on robots that walk around :) (Well, maybe not "walk around," but perhaps climb up and down a pole or walk along a cable, based on some clever sampling scheme, perhaps that listens for "action" and repositions to record).
Saturation Deployment (many slug-based logging "stations"), uh, speaking of pie-in-the-sky
You get to thinking about use of these inexpensive slug-based systems, provided there is a smart overall system and effective species recognition, etc., as an automated "bio-blitz" style of monitoring for conservation assessment and management decision-making. Possibilities include:
Saturation monitoring for habitat edges (to access the so-called edge effect) or even in several places within a single large tree
Evaluating species use of different habitat patches and corridors for conservation design. I saw a recent paper in Science where corridor use was assessed by a combination of seed-trapping and three-person observation teams. Slug-based monitoring could also apply here to augment such work.
A dense pattern of devices deployed across a transition from unpopulated to populated areas to assess human disturbance with a view toward identifing specific causes (e.g., dogs barking, car traffic, industrial noises) and behavior responses (e.g., associated frequency or timing of calling, species movements, ).

Software Development
Research on species recognition by call and by keying on the sound spectrogram for different species (e.g., Bird Sounds, by Gerhard A. Thielcke, 1976, and North American Bird Songs - a World of Music, by Paul Bondeson, 1977, just to name a couple of books found in the library, and that contain species-by-species spectrograms). Research on this (and I'm sure there are many many research papers on the subject) is progressing.
Species recognition needn't be the target for an effective system, however, as an intermediate functionality, viz. the mere recognition that something is calling would allow isolation of samples for by-the-ear checking and identification.

This is at the initial stage of investigation -- thoughts and suggestions are much appreciated.

My preferred software/programming environment is linux and python. Earlier this year I learned how to reflash a Zaurus 5500, so have experience with embedded linux. And, I've written a pyqt/python application for the Zaurus, so appreciate software dev on such devices. I see python in the feeds and am very happy for that. I would prefer to develop the software side of things using python along with any necessary lower level libraries for interfacing with audio recording and weather sensing devices.


I've not been able to work on this project in the last month or so, but will pick it up during the Fall semester. On IRC I did ask about work on audio support, and someone commented that progress has been made on both iMic and external Soundblaster support. It might be necessary to use openslug for this support.


Contact is jeff at geojeff dot org

view · edit · print · history · Last edited by geojeff.
Originally by geojeff.
Page last modified on October 16, 2005, at 03:27 PM