Hi Miklos, We are both using RF212. And as I understand it there is no HARDWARE_ACK option for the RF212. I used the old blip stack with RF230 and the RF230_HARDWARE_ACK option, which worked nicely, and looked for the same option for RF212. As I understand it hardware acks are supported in the hardware by the RF212 chip also but not implemented? Due to the similarities between RF230 and RF212 I guess it shouldn't be much work to get hardware acks working with RF212 also?
I don't know how much the two chips differ so this is maybe a stupid question but shouldn't it be possible to merge the two drivers and maybe choose which one to compile by ifdefs or modules that implement the Hpl code that differ? /Henrik 2011/9/2 Miklos Maroti <[email protected]> > Hi Guys! > > If there are problems with the ACKs, then try these steps": > > 1) Increase the software ack timeout in > platform/iris/chips/rf230/RadioConfig.h > 2) You can also enable hardware acks by defining RF230_HARDWARE_ACK > (see README in chips/rf230) > 3) If neither of these work, then you should call Packet.clear() > before assembling any new packets (and before the > PacketAcknowledgement interface is used to request acks) > > Let me know what happend. Best, > Miklos > > 2011/9/2 Henrik Mäkitaavola <[email protected]>: > > Its not a problem with timing as I first expected. Instead is seems to be > a > > problem with acknowledgements. By listening to the channel I saw 3 > > retransmissions of all the ping packages. Strange because the smaller > once > > seem to be received by both ends. But looking in "event void > > BareSend.sendDone(message_t *msg, error_t error)" in IPDispatchP and > > checking if the packages where acked or not none of them were. Resulting > in > > 3 retransmissions. The packages that were not fragmented were received > ok, > > even tho multiple copies were sent and received. But the once that needed > > fragmentation were not sent completely because after the first > fragmentation > > the PacketLink layer indicated that the first fragment was not received > and > > the complete packet was dropped. By removing the PacketLink.wasDelivered > if > > statement fragmentation started to work and by only trying to send one > copy > > speeded up transmissions. > > > > So one question is; Do you use any define for the RF212 chip that made > > fragmentation work for you? Because if Im using the same code as you > > fragmentation should work for me to without changes. > > > > But now I'm atleast on the same level as you. I can ping OK up to around > 400 > > bytes after that I'm experiencing the same behaviour as you are. > > > > Hopefully Ill have some time over for this next week, but for now I will > > atleast manage to send packages that I need. > > > > /Henrik > > > > 2011/9/2 Henrik Mäkitaavola <[email protected]> > >> > >> Ok, now I have a few hours over for this. My first thought is some kind > of > >> timing issue. And this is maybe true considering that you are > experiencing > >> the same problem but with larger packages. Maybe your mote is faster to > >> handle incoming packages but cant keep up when they get bigger than a > >> certain size. Because your mote seems to be able to reassemble smaller > >> packages so the code should atleast work with packages up to the same > size > >> as you. If the problem doesn't lie with memory handling or something > like > >> that. Ill do some test now and inform you with the results. > >> > >> /Henrik > >> > >> 2011/9/2 Johny Mattsson <[email protected]> > >>> > >>> Hello Henrik, > >>> > >>> I hadn't noticed any issues with our systems here, but we try to keep > the > >>> packet sizes down. I've run a few ping tests here, and there is > definitely > >>> something odd happening. If I for example ping with 400 bytes of data, > I > >>> reliably only get four (4) replies before it stops. However, if I then > send > >>> a small(ish) ping it responds again, and it's once again possible to > ping > >>> with 400 bytes. It doesn't seem deterministic whether I get another > four > >>> 400-byte pings after that or not though. So to answer your question: > yes, > >>> but apparently nowhere near as bad as you're seeing! > >>> > >>> It would be great if someone with a non-rf2xx radio could check if they > >>> too see this behavior. Anyone? :) > >>> > >>> Cheers, > >>> /Johny > >>> > >>> > >>> 2011/9/2 Henrik Mäkitaavola <[email protected]> > >>>> > >>>> Hi again Johny, > >>>> > >>>> Do you have any problems with reassembling of fragmented packages? > >>>> When I try to ping a mote with a packet size bigger than 75 the mote > >>>> stops responding. I assume this is due to fragmentation. > >>>> Will investigate this more tomorrow. > >>>> > >>>> /Henrik > >>>> > >>> > >>> > >>> -- > >>> Johny Mattsson > >>> Senior Software Engineer > >>> > >>> DiUS Computing Pty. Ltd. > >>> where ideas are engineered > >>> > >> > > > > > > _______________________________________________ > > Tinyos-help mailing list > > [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
