Sorry I have no examples and I should probably either create some or just stop answering these questions...
There is/was a High Frequency sampling demo app that didn't use the regular TimerM. There is also the TimerJiffy component that runs at 32kHz and I think has a similar Timer functionality. There may be others, but as I said, I haven't used any. If you start a new conversion from the dataReady(), or look into the ADC.getContinuousData() interface, you may be able to get very fast, if slightly irregular samples. Look at ADCControl.setSamplingRate(uint8_t rate) for a way to control the ADC conversion time. MS Omar Bouzid wrote: > Hi Michael, > > You have mentioned below that there are other timing mechanisms in TOS and > the ADC itself can free-run at different rates. Could you please let me know > how can I do that and if you have some examples, could please you show me > some of them. > > My best regards, > OMB > >> -----Original Message----- >> From: Michael Schippling [mailto:[email protected]] >> Sent: 13 August 2009 21:46 >> To: Omar Bouzid >> Cc: Tinyos-Help >> Subject: Re: [Tinyos-help] Units conversion of acoustic data >> >> I'm cc'ing back to the help list to keep a record of my mistakes... >> >> I don't know what the Moteworks app does with displayed data. >> I would expect that the messages it receives contain the raw ADC >> values, so you should be able to access them directly. >> >> Without looking at all the code involved this is speculation: >> Most likely the re-Mote program is sampling its inputs using >> a Timer.fired() trigger. The TimerM module is limited to >> somewhere between 1-3 (binary: 1024 instead of 1000) milli-sec >> per fire minimum. Therefore doing high speed sampling for audio >> or other data is limited. There are other timing mechanisms in >> TOS and the ADC itself can free-run at the rates you show, but >> then what do you do with the data? Mica2's can send something >> like 500 bytes per sec, and micaz's maybe 5000...as long as >> there is only one re-Mote in the system... >> >> Someone asks how to do audio about every 6 months on this list, >> but I've never seen anyone post a working program after I have >> repeatedly tried to help them -- that must say something about >> the quality of my help, eh? But you can try searching the list >> for audio, microphone, and such like to see where we have been. >> >> MS >> >> Omar Bouzid wrote: >>> Hi Michael, >>> >>> It is mentioned in the MoteWork manual that sensor data converted to >>> engineering units. Regarding to the ADC counts, how can I get the raw >>> data which represents my signals? >>> >>> I am also thinking that increasing the sampling rate will improve the >>> quality of acquiring the signals, so I am now trying to implement a >> code >>> that reads only the microphone input rather than the whole other >> inputs >>> which might on the one hand, help to reduce the time needs for getting >>> the microphone input, and on the other, give me the ability to test >> the >>> effect of sampling rate on my acoustic signals which will be done in >>> the next stage. >>> >>> Regarding to the sampling rate, I am a little bit confused because: >>> According to the information that I got from the Crossbow group, >> though >>> that the microphone responds to 4.2 kHz generated by the buzzer and >> that >>> the fastest sampling rate is probably in the order of 5 kHz. However, >> it >>> is also mentioned in the ADCControl.nc code that the sampling rate >> can >>> take different values as illustrated below: /** * Sets the sampling >> rate >>> of the ADC. * These are the lower three bits in the ADCSR register of >>> the * microprocessor. * * The <code>rate</code> parameter may use the >>> following macros or * its own value from the description below. * <p> >> * >>> <pre> * TOS_ADCSample3750ns = 0 * TOS_ADCSample7500ns = 1 * >>> TOS_ADCSample15us = 2 * TOS_ADCSample30us = 3 * >> TOS_ADCSample60us >>> = 4 * TOS_ADCSample120us = 5 * TOS_ADCSample240us = 6 * >>> TOS_ADCSample480us = 7 * </pre> * * @param rate 2^rate is the >> prescaler >>> factor to the ADC. * The rate of the ADC is the crystal frequency >> times >>> the prescaler, * or XTAL * 2^rate = 32kHz * 2^rate. * * @return >> SUCCESS >>> if successful */ command result_t setSamplingRate(uint8_t rate); >>> >>> Does this mean that the used microprocessor is able to achieve these >>> levels of sampling rates, so using a self implemented circuit composed >>> from a high microphone response and the prototype area such as >> MTS101CA >>> and MDA100 might help to increase the sampling rate?. >>> >>> I would be grateful if we could share ideas and information. >>> >>> Cheers, OMB >>> >>> >>>> -----Original Message----- From: Michael Schippling >>>> [mailto:[email protected]] Sent: 13 August 2009 18:17 To: Omar Bouzid >>>> Cc: '[email protected]' Subject: Re: [Tinyos-help] >>>> Units conversion of acoustic data >>>> >>>> I'm not sure what you mean by "engineering units", but if you have >>>> "ADC counts" they are the raw data from the converter. These are >>>> exactly equivalent to voltage, since that is what is being converted: >>>> >>>> volts = count/MAX * Vref >>>> >>>> Where: volts is the signal voltage; count is the "ADC counts" result >>>> you have; MAX is the ADC maximum range (10 bits == 1024 for the >>>> atmega); Vref is the ADC reference voltage (nominally 3.3v for most) >>>> >>>> For acoustic data, from a microphone, what you are getting is the >>>> instantaneous signal voltage when the sample is made. This will vary >>>> over the entire range of the ADC since you are sampling a fast >>>> changing AC signal, usually at a very slow rate. >>>> >>>> MS >>>> >>>> >>>> Omar Bouzid wrote: >>>>> Hi All, >>>>> >>>>> By looking to the displayed data in MoteView most of them are >>>> displayed >>>>> in engineering units which are unlikely to give any sense, in >>>>> particularly the acoustic data that are captured by mts310's >>>> microphone. >>>>> Thus, I would like to know if someone have any experience to convert >>>>> them to voltage units. >>>>> >>>>> Cheers, OMB >>>>> >>>>> >>>>> _______________________________________________ Tinyos-help mailing >>>> list >>>>> [email protected] >>>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos- >>>>> >>>> help _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
