Hi Selahattin, On Mon, Feb 6, 2012 at 12:36 PM, Selahattin Kosunalp <[email protected]> wrote: > Hi Miklos, > > Sorry again about bothering you, I found all fields below in > Ieee154PacketLayer interface that makes sense, but except preamble and > sync. How can I get more info for preamble and sync like default value, > where they are defined, or are they directly produced in rf230 before a > message ready to be sent, I mean hardware-based they are?
Read the AT86RF230 datasheet, you can find it on the atmel website or use google. That has the preamble and sync byte values, but they are not that important as you cannot change the value of those and it is done completely in hardware. > I am sorry that I may ask some stupid questions as I am new user of > tinyos, is the message frame similar to IEEE 15.4? if so how similar is > it? It is standard 802.15.4 message frame. > Finally, As you said, I used DiagMsag tool and I got some lines on the > screen, one of the lines is shown below, I can identify some bytes ( group > id Am type etc) but not all of them, are the pramble and sync bytes a part > of DiagMsg? Preamble and sync bytes are not part of the message, and you cannot observe it, but we know it is transmitted and received and used to get the bit synchronization right. > Best wishes, > ------------------------------------------------------------------------- > 11:21:40 'r' 77393350 62691 41 [ 0x41 0x88 0xe5 0x1e 0x00 0x00 0x00 0x01 > 0x00 0x3f 0x06 0x80 0x01 0x02 0xd4 ]42 > ------------------------------------------------------------------------- Look at the RF230DriverLayerP.nc file where this line is output. Here it is: 11:21:40 is the PC time when the line was displayed 'r' indicates that this message is a received one. 77393350 is the 32-bit PacketTimeStamp of the message (reception time of the SFD field) 62691 is the 16-bit current time (both times are in TRadio units) 41 is the message length [ 0x41 0x88 ... ] is the first 16 bytes of the message 41 is RSSI or link quality (actually two bytes should be here, one if RSSI the other is LQI) The payload section starts with the FCF field. You can read the format in the RF230 datasheet. Best, Miklos > >> 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] >>> >> > > > 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
