On 08/02/2012 03:53 PM, Mariano Alvira wrote: > On Thu, Aug 2, 2012 at 3:22 PM, Alan Ott <a...@signal11.us> wrote: >> I'm currently able to talk between two systems, one system with the >> Econotag and serial.c, and the other system with an MRF24J40 and a >> driver I wrote[3] and am trying to test. I can ping6 between the two >> systems with high reliability, but there seems to be trouble when >> packets are sent too quickly from the Econotag. For example, if I change >> the ping interval (-i) to 0.1, most of the packets get lost. > You might check that the MRF24J40 can keep up; the mc13224v uses DMA > to transmit and can easily swamp most (if not all) > 802.15.4 radios.
Hi Mar, Ok, that's good to hear, and it stands to reason since the MC13224 has 802.15.4 as an integrated peripheral. Assuming the Econotag is much faster than the mrf24j40 then, what's the right way to do this? I suppose for now I could artificially slow down the serial.c as a testing hack. Shouldn't the 802.15.4 frames be acked and then retransmitted by the MAC layer if there's no ack? I have Auto-ack turned on in the mrf24j40, and was relying on that functionality for just this kind of thing, since the receiver on the mrf24j40 is effectively disabled while the data is being read from the device by the CPU over the SPI interface (that procedure is per the datasheet (box at the end of 3.11.4)). There's still some issue with that procedure in my mind though, since the mrf24j40's MAC will ACK the packet when it is received (concurrent with giving the CPU an rx interrupt), before I've read the packet through the SPI. It would seem like this would cause the sender to send the next packet while I have rx disabled, only to have it NAK'd (or ignored). It should still work, because the sender should retransmit, but it seems highly inefficient. Maybe I need to ask someone at Microchip about this. > It looks like the MRF24 has a 144 byte TX fifo; a little more than 1 > packet. The default maca.c parameters can keep 32 full packets > buffered. maca.c flushes the TX queue as fast as possible and the duty > ratio is very close to 100% (I don't remember exactly what the turn > around time is for back to back packets, but its very fast). Under > that condition you'd have to make sure you are reading out the data as > fast as it's coming in. Yeah, so for the 10 or so packets I see going out at once at ~100% duty rate, I'd have absolutely no chance of keeping up with that with my SPI 802.15.4 device. Reiterating my above question, how is a "slow" device like mine supposed to inter-operate with fast devices on 802.15.4? My understanding was that the ACK/retransmit was supposed to handle this kind of thing. > The tests I typically do are with modified versions of rftest-tx and > rx. You can do things like keep the TX queue full of random packets > which will cause them to be transmitted as fast as possible ( > guaranteed to take down any 802.15.4 network within 200 ft :) ). Or > send out bursts when you press spacebar, or whatever you want to test. > You can verify the reception with another econotag. Then try the same > tests with the MRF24 and see how things go. I'll give this a try. > As for the state of the linux serial driver, there was a patch > recently committed that fixed a bug. It's probably not using the most > recent version of libmc1322x as I have been away from the linux802154 > dev for a while now. It shouldn't be too hard to up date the submodule > and test against the latest libmc1322x. The serial link ends up as a > bottle neck unless you set the baudrate to 921600. I saw that change last night actually but haven't tried it yet. Thanks for your detailed response and for responding so quickly. I'll let you know how it goes. Alan. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
