Look at the apps/tests/rfxlink/RadioSniffer application. In particular, if you define the RADIO_DEBUG_MESSAGES define in your makefile, then it will print out messages with the DiagMsg framework. You can display these using the java net.tinyos.tools.DiagMsg application. Miklos
On Thu, Feb 2, 2012 at 1:05 PM, Selahattin Kosunalp <[email protected]> wrote: > Hi Miklos, > > That is fairly clear, thanks a lot for your lovely knowledge. The only > thing, Can we display all the fields on a PC when a packet is received? > because I am using java serial application to display the messages > received, I only see "destination, Source, Length, Group id, Message > type". >> Hi Selahattin, >> >> Ok, here are the fields: >> >> 4 bytes preamble >> 1 byte sync >> 1 byte length >> 2 bytes FCF (frame type) >> 1 byte DSN (sequence number) >> 1 byte dest PAN (group id) >> 2 bytes dest addr >> 2 bytes source addr >> 1 byte network type for 6lowpan >> 1 byte AM message type >> 28 bytes payload >> 2 bytes crc >> >> this is 46 bytes. The speed of the radio is 250 kbps, which is 31250 >> bytes per sec. So you should be able to transmit 679 messages per >> second. Everything else is overhead (downloaded/uploaded messages via >> the SPI, processing, tasks, etc). You can calculate the overhead in >> bytes from the observed 500 messages per second: 31250 / 500 = 62.5 >> bytes, so the MCU processing time overhead is around 16.5 bytes which >> is around 0.528 millisecond per message. >> >> Best, >> Miklos >> >> >> On Thu, Feb 2, 2012 at 12:32 PM, Selahattin Kosunalp >> <[email protected]> wrote: >>> I employed 28-bytes data payload, I think the header is 8-bytes >>> long(destination, Source, Length, Group id, Message type), As far as I >>> know, the header is automatically added by tinyos, I did not do anything >>> for header. When a packet arrives, I display it on a PC using serial >>> java >>> app. Then I can see the header fields. Again, I did not include CRC, >>> preamle and sync bytes, I just defined a meessage_t variable and send >>> it, >>> Can we work out the processing time? >>> I define a task to send messages using Amsend interface, at first my >>> code >>> transmits a message when sendDone is signaled, I call post the the task >>> and send next message, kind of continues transmission. I observe that >>> how >>> many times sendDone is signaled in a second, then I got around 500 >>> times. >>>> Hi Selahattin! >>>> >>>> How did you get the 36 byte value? Did you include all headers and the >>>> CRC? Did you include the 4-byte preamble and the sync byte? Also, >>>> there is a significant amount of processing involved. How did you send >>>> this many messages? Did you use ActiveMessageC? If so, then packets >>>> travel through the whole stack and that also takes some time to >>>> process. >>>> >>>> Best, >>>> Miklos >>>> >>>> On Thu, Feb 2, 2012 at 12:03 PM, Selahattin Kosunalp >>>> <[email protected]> wrote: >>>>> Hi Miklos, >>>>> >>>>> Thanks for your answer, I am trying to determine the limitations that >>>>> how >>>>> many packets can be transmitted in a second with iris nodes. >>>>> Basically, >>>>> the packet size is 36-bytes and transmission rate is 250 kbit. The >>>>> time >>>>> taken to transmit a packet is (36*8) / 250 =1.15 ms. So, I expect to >>>>> transmit and receive 1000 / 1.15 = 870 packets/second. I turned >>>>> Backoff, >>>>> CCA and Software-ACK off, nonetheless around 500 packets are >>>>> transmitted >>>>> and received in a second, so the question is why?. Is it due to the >>>>> processing time or is the transmission rate really equal to 250 kbit?. >>>>> Am >>>>> I missing something different at this point? >>>>> >>>>> Best Wishes, >>>>>> Hi! >>>>>> >>>>>> I do not really understand your problem. The radio can either >>>>>> transmit >>>>>> or receive a message, not both at the same time (half duplex). If you >>>>>> want to transmit a message while the radio is currently receiving >>>>>> one, >>>>>> then the SOFWTARE (the driver running on the microcontroller) will >>>>>> wait till the reception completes, and only then uploads the outgoing >>>>>> message to the radio chip and transmits it. Hope this helps. >>>>>> >>>>>> Best, >>>>>> Miklos >>>>>> >>>>>> On Thu, Jan 19, 2012 at 5:42 PM, Selahattin Kosunalp >>>>>> <[email protected]> wrote: >>>>>>> Hi Miklà à ³s, >>>>>>> >>>>>>> I am currently working in tinyos and struggling a problem, I have >>>>>>> seen >>>>>>> some of your comments about the problem. The problem is that packet >>>>>>> reception simultaneously. As I read your comment, during a >>>>>>> transmission >>>>>>> if >>>>>>> another packet arrives, radio stack buffers up coming signals and >>>>>>> result >>>>>>> in the first Receive interface. This is known Overlapping problem in >>>>>>> literature and most mac protocols assume that if overlapping >>>>>>> happens, >>>>>>> collided packets are discarded. From this perspective, I would like >>>>>>> receiver to not buffer up new packet after a reception is done. >>>>>>> >>>>>>> Would you recommend any interesting idea to do so?, >>>>>>> >>>>>>> Best wishes, >>>>>>> >>>>>>> >>>>>>> Selahattin Kosunalp >>>>>>> PhD Research Student >>>>>>> Communications Research Group, >>>>>>> Department of Electronics, >>>>>>> University of York, >>>>>>> Heslington, York, YO10 5DD >>>>>>> Email: [email protected] >>>>>>> >>>>>> >>>>> >>>>> >>>>> Selahattin Kosunalp >>>>> PhD Research Student >>>>> Communications Research Group, >>>>> Department of Electronics, >>>>> University of York, >>>>> Heslington, York, YO10 5DD >>>>> Email: [email protected] >>>>> >>>> >>> >>> >>> Selahattin Kosunalp >>> PhD Research Student >>> Communications Research Group, >>> Department of Electronics, >>> University of York, >>> Heslington, York, YO10 5DD >>> Email: [email protected] >>> >> > > > Selahattin Kosunalp > PhD Research Student > Communications Research Group, > Department of Electronics, > University of York, > Heslington, York, YO10 5DD > Email: [email protected] > _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
