Hi all, 
 
Let me go through my scheme again, to avoid misunderstandings:
 
I have one acc/gyro hooked up on a Mica2Dot, that's transmitting this 
20byte-packet to a TOSBase station programmed on a Mica2.
I've decreased my fire events to 3ms, but the bottleneck was around 33ms 
anyway, which lead to 30packts/s. I intend to do one hop only with just one 
Mica2dot. 
 
To exactly avoid the frequency sweeping that you mentioned (because I intend 
that my BaseStation listens to just ONE channel), I intended  to fix the freq 
and avoid that loop. This is why I was wondering that that loop took the 
aforementioned 33ms. 
 
About the Manchester Coding is Ok. I knew that it halved the bandwidth. But 
still with 38.4kbps I imagined it would be fine.
 
Anyway, I got to the CC1000ControlM.nc (which seems is the one that implements 
the receivemsg command after going really really deep) and I got this table, 
where the IF is 150Khz and there are some constants defined, so as the osc 
core. Is this where the channels are defined ? (there are some other "for" 
loops that really use this array, but I wasn't sure about this strange numbers) 
It seems they redefine frequecies, based on their desired ones.
 
Anyway, thanks guys.
Edgar
 
***************************************************************************************************
 
  const uint32_t FRefTbl[9] = {2457600,          2106514,          1843200,     
     1638400,          1474560,          1340509,          1228800,          
1134277,          1053257};    const uint16_t CorTbl[9] = {1213,         1416,  
       1618,         1820,         2022,         2224,         2427,         
2629,         2831};    const uint16_t FSepTbl[9] = {0x1AA,          0x1F1,     
     0x238,          0x280,          0x2C7,          0x30E,          0x355,     
     0x39C,          0x3E3};
 
 
 
 
> From: [EMAIL PROTECTED]> To: [EMAIL PROTECTED]> CC: [EMAIL PROTECTED]; [EMAIL 
> PROTECTED]; tinyos-help@millennium.berkeley.edu> Subject: RE: [Tinyos-help] 
> Pumping up bandwidth - Mica2Dot/Mica2> Date: Mon, 14 Apr 2008 22:20:22 -0700> 
> > I'm not sure if this applies to all mica2's, or just some older versions.> 
> I'm also not sure about OEM's. You'll have to screen yours nodes yourself> to 
> see if this applies. > > Our experience (and we're not alone) has been that 
> there was not a good> 50-ohm impedance match on the passive network 
> connecting the radio chip with> the antenna. Where there should be 50-ohm 
> traces on the PCB, there is not.> This steals a few dB of output power, and 
> significantly decreases range (you> double the range for every 3 dB, so even 
> 3 dB less is half the range). > > Mica2Dot's are even worse: in an attempt to 
> meet size specifications, the> matching network is split across two sides of 
> a PCB. This is never a good> idea, because you may not be able to guarantee 
> the reliability of the> radio's matching network. With the matching network 
> separated, small> manufacturing differences of the PCB can cause significant 
> differences in RF> response from module to module. And, mica2dot's don't have 
> a sufficient> ground plane.> > Finally, the curly-q loop thing added to the 
> end of the wire antennas that> come with the mica2dot's are a bad idea. This 
> adds some unnecessary> horizontal polarization to the wave. A vertically 
> polarized wave is much> better. Horizontal polarization gets eaten quickly by 
> the ground. Straighten> out those wire antennas, and add a ground plane.> > 
> -David> > > -----Original Message-----> From: Michael Schippling 
> [mailto:[EMAIL PROTECTED] > Sent: Monday, April 14, 2008 8:05 PM> To: David 
> Moss> Cc: 'Edgar Charry'; 'Eric Keller'; tinyos-help@millennium.berkeley.edu> 
> Subject: Re: [Tinyos-help] Pumping up bandwidth - Mica2Dot/Mica2> > YOW!!! 
> Another information packed post (IPP).> Maybe we could start a radio theory 
> page on our new improved doc site?> But what's "that broken matching network" 
> mean?> MS> > > David Moss wrote:> > Manchester encoding. And CSMA.> > > > > > 
> > > Manchester halves the throughput. Instead of 76.8 kbps, Manchester will > 
> > force your radio to transmit at 38.4 kbps. Getting rid of Manchester > > 
> may not be a simple task: it's there to zero out the energy seen by a > > 
> receiver, so it can easily know that it's receiving valid data.> > > > CSMA 
> causes your transmitter to share the channel with other > > transmitters, and 
> the channel checks may be spaced relatively far apart > > which dramatically 
> decreases throughput.> > > > > > > > The CC1000 radio could be a really 
> kick-ass radio if it were implemented > > properly. The ability to easily 
> enable/disable Manchester, CSMA, etc. > > (among other things) would really 
> improve its situation. The CC1000 > > radio is much more energy efficient 
> than the CC2420 radio, and can > > transmit a lot farther than the CC2420 
> radio (but that broken matching > > network on mica2's and especially 
> mica2dot's really cause everyone > > problems). It's unfortunate so many 
> people dismiss the CC1000 radio as > > obsolete, when it could really 
> outperform their radios in terms of > > efficiency and range (not 
> throughput).> > > > > > > > 29 bytes is only a software (and RAM) limitation. 
> Increase it by doing > > a CFLAGS+=-DTOSH_DATA_LENGTH=50 or something in your 
> Makefile. Removing > > unnecessary fields from the CC1000 header will 
> decrease the > > header:payload ratio and increase payload throughput.> > > > 
> > > > > If you're thinking about rolling your own hardware, you should really 
> be > > using CC1100 or CC2500 radios for any wireless application that 
> doesn't > > require 802.15.4 compatibility: > > 
> http://docs.tinyos.net/index.php/CC1100/CC2500> > > > > > > > -David> > > > > 
> > > > > > > > > > > > > > > > > > > > 
> ------------------------------------------------------------------------> > > 
> > *From:* [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] *On Behalf Of > > 
> *Edgar Charry> > *Sent:* Monday, April 14, 2008 3:57 PM> > *To:* [EMAIL 
> PROTECTED]; Eric Keller> > *Cc:* tinyos-help@millennium.berkeley.edu> > 
> *Subject:* Re: [Tinyos-help] Pumping up bandwidth - Mica2Dot/Mica2> > > > > > 
> > > Hi all,> > > > Thanks for your prompt replies. Unfortunately I that link 
> didn't let me > > through.> > > > In fact I am still trying to undestand 
> them, as I wasn't aware of that > > limitation of 33-50ms of the Mica2's! You 
> are saying that the maximum > > bandwidth my app should require is 0-25Hz so 
> that I have a nice > > reconstruction of my wave, due to HW limitations?> > I 
> knew that the CC1000 has a maximum bandwidth of 76.8kbps and of course > > 
> due to EEPROM readings/writings, CPU instructions, ADC's > > measurements 
> etc. this number should decrease. But I wasn't expecting a > > final 
> bandwidth of 30pckts/s!!! In fact, I thought there were problems > > related 
> to the TOSBase.> > My app requirement need at least 100Hz (Mica2's 
> transmission needed thus > > 200 pckts/s), which is necessary to track a 
> complete gait cycle using > > acc and gyros with good definition.> > > > What 
> is the most critical factor in the Mica2's that blow the > > transmission 
> rate so bad? Does this happen with the Mica2Dot too? Data > > compression 
> (sample with a higher freq, store in the RAM and then send > > the whole 
> bunch of bytes) has a limitation of 29 bytes due to TinyOS, > > correct?> > > 
> > Thanks guys for the good info.> > Cheers,> > Edgar Charry> > > >> Date: 
> Mon, 14 Apr 2008 12:20:38 -0600> >> From: [EMAIL PROTECTED]> >> To: [EMAIL 
> PROTECTED]> >> CC: tinyos-help@millennium.berkeley.edu> >> Subject: Re: 
> [Tinyos-help] Pumping up bandwidth - Mica2Dot/Mica2> >>> >> Well, since 
> people are quoting my second source messages, have a look> at:> >> 
> http://www.etantdonnes.com/Motes/report_mica2/> >> (which seems to be down 
> right now but will hopefully be back soon...).> >>> >> However my message 
> speed/reliability measurements use only the standard> >> GenericComm and TOS1 
> code. I think the OP was trying to fiddle timeouts> >> and backoffs to speed 
> things up further. Data mining of the help list> >> should turn up some more 
> useful advice in this respect.> >>> >> MS> >>> >> Eric Keller wrote:> >> > 
> There is a limit to how many packets you can send with a mica2 which > > you 
> are> >> > at or above. You probably want to lower your bandwidth requirements 
> > > somehow.> >> > See this message:> >> > > >> 
> https://www.millennium.berkeley.edu/pipermail/tinyos-help/2008-April/032464.> 
> html> >> >> >> > Eric> >> >> >> >> >> > On Mon, Apr 14, 2008 at 4:59 AM, 
> Edgar Charry <[EMAIL PROTECTED]> > > wrote:> >> >> Hi all,> >> >>> >> >> I am 
> trying to pump my packet transmission up between a Mica2Dot and> a> >> >> 
> Mica2 to at least 200Hz [pckts/s].> >> >>> >> >> I've decreased the timer 
> constant to a bottleneck of 33ms (30 > > pckts/s) that> >> >> pratically 
> executes a round of ADC measurements and send the packet.> >> >> Decreasing 
> from this point doesn't give me more bandwidth. However,> my> >> >> packet is 
> 14bytes long (the TinyOS header + just a couple of adc> >> >> measurements + 
> CRC).> >> >>> >> >> I suspect that this 33ms (parsed time stamps from 
> XSniffer) are > > limited to> >> >> the TOSBase.nc on the Mica2. I suspect 
> that the PLL of the Mica2 is> >> >> listening through channels and is not 
> locked to the transmitter's > > one. Every> >> >> loop thus should take 
> 33ms.> >> >>> >> >> Actually, I haven't been through the CC1000 conf/mod 
> components > > though, but> >> >> I reckon with your experience this can be 
> solved easily.> >> >> Cheers,> >> >> Edgar Charry> >> >>> >> >> 
> ________________________________> >> >> Explore the seven wonders of the 
> world Learn more!> >> >> _______________________________________________> >> 
> >> Tinyos-help mailing list> >> >> Tinyos-help@millennium.berkeley.edu> >> >> 
> > > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help> 
> >> >>> >> > _______________________________________________> >> > Tinyos-help 
> mailing list> >> > Tinyos-help@millennium.berkeley.edu> >> >> 
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help> >>> 
> >> --> >> Platform: WinXP/Cygwin> >> TinyOS version: 1.x, Boomerang> >> 
> Programmer: MIB510> >> Device(s): Mica2, MicaZ, Tmote> >> Sensor board: 
> homebrew> >>> >> _______________________________________________> >> 
> Tinyos-help mailing list> >> Tinyos-help@millennium.berkeley.edu> >> 
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help> > > 
> > ------------------------------------------------------------------------> > 
> > > Explore the seven wonders of the world Learn more! > > 
> <http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE>> > 
> > > -- > Platform: WinXP/Cygwin> TinyOS version: 1.x, Boomerang> Programmer: 
> MIB510> Device(s): Mica2, MicaZ, Tmote> Sensor board: homebrew> > > 
_________________________________________________________________
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to