Hello, General question: do you base on rf212 or rf212B chips (there is an app note on Atmel's site describing differences between those chips). It is ok to target only one version of the chip, provided you put a notice in the source file.
On Tue, Jan 28, 2014 at 3:59 PM, Phoebe Buckheister <phoebe.buckheis...@itwm.fraunhofer.de> wrote: > On Tue, 28 Jan 2014 00:52:26 +0400 > Dmitry Eremin-Solenikov <dbarysh...@gmail.com> wrote: >> I have a question regarding LBT. Isn't it just another clear channel >> assessment mode? Not from the terms in the standard maybe, but from >> the logical point of view. Another type would be ALOHA (IIRC), maybe >> some other types. What about adding single generic interface that >> will select between those channel availability check methods? Thus >> you would merge together patches #4 and #5 and replace them with a >> single generic API (I'm not so sure about patch #6 - set_cca_ed). > > No, it's an alternative to CSMA. Usually, you will use CSMA with > exponential backoffs to determine whether the channel is free for you > to use, or wait until it is. LBT replaces this with a predetermined > (long) wait before you may send at all, and more (long) waits between > transmission attempts. Both CSMA and LBT use CCA to determine whether > the channel is free or not though, so i don't think it's i a good idea > to merge the two features into one. Ok. You actually forced me to open the -2011 standard. Now I have the impression that LBT is a property of the channel band (let's call it subpage - several channels in the same page, spanning sequential frequencies). Am I right, or it is actually a property of the channel band in some countries (e.g. you may use 950Mhz with CSMA in countries A and B and with LBT in C). What is more correct? >> Patch #7 is another topic. It is about MAC acceleration features. The >> problem is that this (potentially) clashes with >> multiple-interface-per-mac support. I will think later how to fit that >> in, ok? > > Actually, it is a bit more, on RF2xy at least. First some things I > found while digging a bit deeper in the linux stack: > > * dgram sockets have sockopts to send packets with the REQ_ACK flag > * 6lowpan sends all packets except broadcasts with that flag Strange. I thought that rf230 did not support AACK. However judging from datasheets, rf230 does support it. > It makes sense to send ACKs to a sender that requests them, which is > what the RX_AACK modes usually do. In RF2xy, this mode also has some > other features, but the driver disables or ignores them, so we might as > well switch to RX_AACK by default. AACK requires that HW/PAN/short address is set in the registers. This can be problematic if there are no hw-addressable interfaces (several monitors, SMAC, etc - but no full 802.15.4). Another and more important use case is having several 802.15.4 interfaces on a single phy. I had an idea of requesting capabilities through add_iface (so one can create one 'accelerated' iface and several 'unaccelerated' ones), however nobody ever implemented this. Maybe this part needs to be redesigned. > Further, TX_ARET modes in RF2xy enable CSMA (and LBT), automatic > handling of ACKs, failure after a number of retries and such things. We > might use TX_ARET if a xmit skb has the REQ_ACK flag set, but to use > CSMA/LBT (which we must, to stay withing regulations), we must use > TX_ARET in RF2xy either way. Is it possible to use ARET without waiting for an ACK frame? > I propose to drop patch #7 entirely and use RX_AACK and TX_ARET modes > by default in RF2xy for exactly this reason. Fine with me provided you can fit it in. -- With best wishes Dmitry ------------------------------------------------------------------------------ WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
