Update 2011 Oct 6 See Christopher’s comments below! Specifically, line 172 might need to be removed, if you’re using this with a pure mrf24j40 network, or a network that doesn’t contain xbee series 1 devices!
Update 2011 May 29 The sample code and library have been substantially upgraded. See my newer post for the details
And now I have TX working too. The microchip datasheet is _reallly_ sparse on details, and you have to go and get a copy of the actual IEEE 802.15.4 spec (either 2003, or 2006, we’re only concerned with the specification of the MAC header)
I had some problems trying to reconcile bit ordering between the IEEE spec (MSB rightmost, most of the time) and the Microhip docs (MSB leftmost, most of the time) but from there it pretty much just worked. I have yet to try out acknowledgements, I was trying to keep it pretty simple, but working code is working code.
Except… The microchip docs say that you write out one byte with the header length, one byte with the frame length, (header plus packet body) then the header, then the packet body. No gaps anywhere. Try as I might, I had to leave a two byte gap after the header, and before the packet data, when writing to the MRF24J40’s tx normal fifo. (And allow for this in the “length” fields)
I thought I had the addressing modes wrong, and my first two bytes of packet data were being used as some sort of header field I didn’t understand, but I tried out 4 different addressing modes, and in all cases, the data on the received side passed all checksums, and was only consistent with there being a _gap_ in the fifo.
Strange, but workable, as long as you know it’s there. It still makes me feel uncomfortable though.
For reference, I’m using 16 bit (short) addressing for both source and destination, PAN ID header compression (only destination PAN ID is sent) with no security.
The library code is over at github and allows sending packets to existing series one xbee listeners just like this…
mrf_reset();
mrf_init();
// set our PAN ID
mrf_pan_write(0xcafe);
// set our local source address
mrf_address16_write(0x6001);
// send something to a given node
mrf_send16(0x4202, 4, "abcd");
I read your message here a while ago, but only just recently did I actually look at your code and notice that there’s a mention of XBees. I think I can explain your apparent need to include two ignored bytes: XBees by default include proprietary stuff of some sort on top of the 802.15.4 specification! For details, assuming you’re using the original XBee/XBeePro modules, see the ATMM command on page 48 of the datasheet. Note that I once tried to get two XBees to talk to each other in strict 802.15.4 mode and had no luck (it seemed like they were happy to transmit data without the custom header, but would sometimes still try to interpret received packets which of course failed miserably if my application data happened to contain “interesting” values in the first few bytes), so YMMV if you go this route. However, if you never tried to get two MRF24J40s to talk directly to each other, and only ever tried to get communication between an MRF and an XBee, this would be the reason for the two extra bytes.
(reposted on both posts, for maximum visibility)
Interesting! That’s very likely. I have three xbee series 1 modules, and 2 mrf24jf0 modules, but for various convenience factors, (the existing network was all xbee series 1) I was probably mostly testing with an xbee on one side, and an mrf24j40 on the other. I had well established debug code for talking to the xbee on one side. I was never very happy with the two byte jump, but I never found anything that would explain it. Of course, now that I’ve seen the MM command, I can see the reason quite clearly.
Thank you very much! I’ll try and update the library and comments to mention this, but it won’t happen anytime soon. :( For better or worse, all my 802.15.4 devices are working and communicating, and I currently have nothing new planned for the network. Perhaps when it gets quiet at work…. HAHAHAH Actually, I’ll probably make it my mission to make an mrf34j40 library for the stm32L parts…