You don't specify what hardware you are using. But it is clear from your context below that you are using the cc2420 so I'm assuming a telosb. But the pertinent part is the 2420 anyway.
It is my understanding of the cc2420 h/w at least in normal mode, that there is a maximum packet size of 128 bytes. I don't beleive you can hog the media longer than 128 byte times. Regardless you are doing something odd with the h/w and are certainly using out of the typical scenerio. So I would recommend that you start by very closely studing the cc2420 manual. If you find a way of tweaking the h/w to get it to do what you want you will then have to figure out how to get the underlying code to accompish the task. The best way of doing this is to write a special purpose piece of code that basically takes over the cc2420 h/w and makes it happen. If you are trying to maintain the existing stack while making the underlying h/w do something very different than what the stack is written to do is asking for trouble. I'm not saying you are doing that, it isn't clear from your snippet. more below. On Tue, Aug 14, 2012 at 5:38 PM, Adeel Javed <[email protected]> wrote: > Hi there, > > I am working on situation where there are two sensor nodes (sender and > receiver). when a receiver receive a particular msg from sender, it should > transmit it for particular time (say 2 mins) > That is rather long. Why 2 mins? What are you trying to accomplish? What problem are you trying to solve exactly? > and should not release the medium before finishing its task. Now problem > arises that receiver successfully receives packet but i shows message that > it has send the packet but actually it is not doing so. As i turn off the > actual sender, receiver also goes to off state (LPL-after checking no > energy). > > I have loaded transmit TXFIFO buffer with the received packet, > > void loadTXFIFO() { cc2420_header_t* header = call > CC2420PacketBody.getHeader(&(m_msg->packet)); uint8_t tx_power = (call > CC2420PacketBody.getMetadata(&(m_msg->packet)))->tx_power; if ( !tx_power > ) { tx_power = CC2420_DEF_RFPOWER; } call CSN.clr(); if ( m_tx_power != > tx_power ) { call TXCTRL.write( ( 2 << CC2420_TXCTRL_TXMIXBUF_CUR ) | ( 3 > << CC2420_TXCTRL_PA_CURRENT ) | ( 1 << CC2420_TXCTRL_RESERVED ) | ( > (tx_power & 0x1F) << CC2420_TXCTRL_PA_LEVEL ) ); } m_tx_power = tx_power;call > TXFIFO.write((uint8_t*)header, header->length-1); > > > > } > > I am sending packet by using strobes as described by CC2420TransmitP.nc > call CSN.clr(); status = m_cca ? call STXONCCA.strobe() : call > STXON.strobe(); if ( !( status & CC2420_STATUS_TX_ACTIVE ) ) { status = > call SNOP.strobe(); if ( status & CC2420_STATUS_TX_ACTIVE ) { congestion > = FALSE; } } call CSN.set(); > > > The change i did is , > > 1- CSN bit is cleared, > 2- transmit packet for specified time period > How on earth do you do that while using the existing default stack? > 3- CSN bit set to high > 4- release resource. > > Now if i am not wrong, it should capture the medium and transmit packet > and shouldn't release before the timer expires > Why do you think it will transmit until the timer expires? The underlying h/w doesn't give a rat's ass about the timer, it only cares about the length it has been told to transmit. And unless it is put into the special long packet format it is my understanding that it is limited to 128 bytes. Timers are a upstairs construct. > but it is not doing so. Even i have tried to capture medium (to transmit > last received packet) without CCA (only call STXON.strobe()) > Get low on the h/w and see if you can get the underlying h/w to do what you are trying to do... trying to tweak the existing driver to somehow make it happen is in my opinion asking for wheel spinning. > > Can anyone guide me with any idea? > > Looking forward for any sort of tips. > > Thanks. > AJ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > -- Eric B. Decker Senior (over 50 :-) Researcher
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
