Not bad English, just didn't know to what you were referring... I would place a small wager that you are seeing the MAC protocol backoff, although 20 micro-sec seems a little short... Search this list for MAC related stuff, I think there is an approved way to change the behavior.
MS Carlos Gil Soriano wrote: > Hi Michael, > > > I am sorry because of my bad bad English ;D. What I like to mean it's > that after sending a message, CC2420 automatically goes to a reception > state (according to FSM in data sheet). After this, -in the case that > you sending a message (so you're using continuos sending)- it appears a > variable timing according to oscilloscope readings. > > In the programs that I have made, I have tried to avoid any kind of > access to another devices (for ex. Flash memory). So, in between TX > state and RX, it should be happening that SPI bus is busy (at least for > filling TXFIFO memory), but another strange variable delay appears > (that's what I called it "spare variable timing"). That variable delay > is something unknow for me. > > If you need anykind of further info don't hesitate to mail me. > > > Regards, > Carlos > > > P.S.: in my programs, if I try to send a message in imote2 with a > payload greater than 80 bytes it fails. It is NEVER been send, so I > think that this is a big problem. I don't know why it is happening. If > someone knows why it is happening I would appreciate that they report > its experience by posting it here. > > 2009/6/6 Michael Schippling <[email protected] <mailto:[email protected]>> > > I'm not sure what "spare variable timing" means, but the protocol > does have a random backoff 'feature' for CDMA (or whatever the > correct Multi-Letter-Acronym is). Another delay might be due > to something sampling the SPI bus for other activity. Can you > verify that no other SPI access is being attempted? > > > MS > > Carlos Gil Soriano wrote: > > Hi Michael, > > You're right regarding to SPI problems. I don't expect to find > problems with SPI in micaz. I've been testing continuous sending > in cc2420 in micaz and, after carefully read data sheet and all > code (line by line), there's one spare "variable timing". The > value of this timing moves from 200 us to 2000 us. > > I have requested further information of 2420 to Texas so as to > discern if that timing belongs to radio transceiver or not. I'm > waiting to hear from them. Anyway, I get the impression that > this timing is excessive for 2420, so here it comes SPI bus. > > Another issue comes with CC2420 in imote2. I've found out that > when you try continuous sending in imote2 with a payload greater > than 80 bytes it fails. I do know why but it does so (at least > in a couple of programs that I've made). I feel that the source > of that kind of problem could be SPI bus, too (I haven't check > timings, but I suppose that the "variable timing" should be > considerably higher). > > I'm a newbie in SPI studying. So I would appreciate any kind of > help. > > Regards, > Carlos > > 2009/6/5 Michael Schippling <[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> > > > I think it's one of those little lapses that makes TOS so > intriguing. > Xbow seems to have chosen not to publish a full schematic, > only the > bits that changed from the mica2 when they added the > different radio. > So what's on that 2420 radio page is probably the best you'll > find. > I do remember something about the SPI lines needing to have > pull-ups > added in order to work correctly with external devices... > > I'm just about to embark on my SPI learning curve so I can't > pontificate, > but I'd be surprised if there were timing problems due to > hardware that > behaves according to spec. > > > MS > > > Carlos Gil Soriano wrote: > > Thank you very much Michael, > > what I am looking for it is the way in which all the SPI > modules > are interconnected. I am studying timings in CC2420 > architectures and I have found one timing that should be > caused > by SPI factors. > > Before starting to read carefully all the code which involves > SPI bus I would like to know micaz schematic to clear up my > mind. I would like something similar to the mica schematics > found at http://www.tinyos.net/scoop/special/hardware. > > Thanks for your help, > Carlos > > 2009/6/2 Michael Schippling <[email protected] > <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>>> > > > I thought it was in the User's Manual: > > > http://www.xbow.com/Support/Support_pdf_files/MPR-MIB_Series_Users_Manual.pdf > but you need to piece it together using the mica2 bits as > well. I have a > nice mica2 schematic here: > http://www.etantdonnes.com/Motes/mica2_sch.pdf > which I can't find at: > http://www.tinyos.net/scoop/special/hardware > anymore. Maybe that will help a bit. > > MS > > Carlos Gil Soriano wrote: > > Hi everyone, > > I was looking for the schematics of MICAz but I've > found > nothing. Do you know where I can find them? I've > taken a > look to > xbow site but it only appears a few parts of the > schematic, not > the whole one. > > Regards, > Carlos > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Tinyos-help mailing list > [email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>> > <mailto:[email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[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
