Has anyone looked at this yet? I now noticed that in MicP.nc, in SplitControl.start(), there is a Timer.startOneShot being called with 1200ms. This accounts for the Resource.request()/Resource.granted() delay I wrote about. What the Timer.fired() executes is the same as a commented line right beneath the calling of the Timer, so I commented the "call Timer" and de-commented the "signal SplitControl" and the delay I wrote about is no more. But without this timer readings seem meaningless. In MicDeviceP.nc the name used for that timer is self-explanatory (WarmupTimer), but why is it being always "warmed up" for each reading?
Cheers, Hugo On 4/19/07, Hugo Sousa < [EMAIL PROTECTED] > wrote:
Using: TinyOs 2.x (CVS updated), cygwin, crossbow micaz motes, mts300ca sensorboard The initial problem while using MicC to access the microphone tone detection was that the microphone seemed to be always "detecting" the 4khz tone, even if no tone was present. I tried reading the code "below" (MicP, MicDeviceP, MicReadP, etc) and got to the conclusion that there was no (that I could find) Resource.request() to access the mic tone detection, and that solved part of the tone detection problem. The second issue is that it seems that when a tone is detected, the interrupts aren't disabled like it says in MicSetting, so a "call MicSetting.disable()" is needed inside the "async event error_t MicSetting.toneDetected()" implementation. After solving the tone detection I went to the raw data mode, it seemed to work ok, but a little sluggish. Reading the code "below" ( MicC, MicReadP, ArbitratedReadC), I saw that for each Read.read() a Resource.request() is called, and after Read.readDone() a Resource.release() is also called. In my motes the time from a Resource.request() to a .granted() is very high, 1 second wouldn't be an exageration (I would like to know your experiences on this), so the solution was write my own module and configuration (similiar to MicC, but not using MicReadP), wiring myModule.Read interface directly to AdcReadClientC (check MicC.nc), and do not release() the resource after a readDone(). I hope this helps someone, I've seen many mails with problems with the tone detection, but I have some questions. Am I doing something unadvisable by not using ArbitratedReadC (thus not releasing the resource)? Can the resource be "stolen" by some other piece of code? Should I use MicStreamC (haven't tried it yet) for periodic sound sampling? My interest is not the actual sound it self, but whether or not there is noise.
_______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
