Hi Dmitry, all, As you said you will work in serial ZB protocol evolutions to allow better management of hardware capabilities of transceiver, would it be possible to add these kind of 'ops' in serial driver (hence protocol) and link them to specific 'ops' in the corresponding kernel device:
==> For global ACK capabilities (as you discussed with Andrew) .set_auto_ack_(on/off) .set_auto_crc_(on/off) .set_mac_address (u64) .set_short_address (u16) .set_panid (u16) ==> For 802.15.4 CSMA/CA tx capabilities: .set_auto_retry (on/off) .set_nb_csma_retries(u8) .set_nb_retries(u8) .set_min_backoff_exponent (u8) Maybe all this and existing '.set' would also necessitate a 'get' capability also ? I think these kind of ops are quite common to many hardware transceiver implementing time constrained services of Mac (802.15.4) layer. So the ability to configure all these across serial driver would be very useful. Best regards, Pierre-emmanuel PS: I would be very happy to contribute but i'm not really aware about the way to do it, and i don't think i've enough knowledge in Linux Kernel programming, but do not hesitate to tell me the way i could ... Dmitry Eremin-Solenikov a écrit : > Andrew Webster wrote: > > >> I've been trying to see if I can set up a 802.15.4 network and have >> other 802.15.4 compliant devices join the network. I however am >> noticing that when the other device expects to get an ACK, it only waits >> 50ms before retransmitting. Now I don't have the ACK working yet, but >> in my system, due to scheduling and so on with the serial port data, I >> don't even start processing the incoming message until 30-40 ms after it >> has arrived. By the time the CCA, TX, and DATA messages have been sent >> I'm up to about 120ms. At this rate, my system gets tied up processing >> the message and the retransmits so it won't be able to send out an ACK >> before the other side gives up entirely. >> >> Does this sound right compared to what others are seeing on PCs? >> > > Yes. That's why I'd dropped all software ACK generation and moved CCA calls > to tx driver callback: they should be done either by HW or by firmware running > on the dongle. Otherwise we won't get timing accurately. > > >> I was thinking of trying to eliminate some of the waiting between PHY >> messages by combining them into one message so it only has to be acked >> once. This would at least eliminate the 20-30ms of waiting for the >> response to each message. >> > > > Moreover It seems that to support necessary timing the packet should be > received in stream mode (to be analyzed in the same time, as it's received). > > I have an implementation of working STREAM mode of MC13192, however no > work to completely debug things was done. > > I hope to get at least few days during two next weeks to write a draft > of the next generation of serial protocol and to dump the code I have > here into usable external project repo. > > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
