There is a possible mistake in dw user manual v2.12 (which is latest version I believe).
If the frame is a beacon frame then the Source PAN ID must match the PAN_ID programmed in Register file: 0x03 – PAN Identifier and Short Address, (or be 0xFFFF)
On receiver I do:
dwt_setpanid((uint16_t) 0xBEEF );
When on transmitter I set source PAN ID inside the beacon standard 802_15_4 frame as 0xBEEF - everything works fine and I could get through filtering and receive frames. But when I set it as 0xFFFF, I could receive nothing.
Is it mistake in docs or I’m just reading it all wrong?
Which one do you set to 0xFFFF? I believe you need to set it in the message you send.
The PAN id in the decawave must be the same. I’ve not tried it myself with beacon frames, but i did with data frames and i haven’t discovered a problem so far.
At the end I could solve this problem.
0xFFFF must be set on receiving side, in this case beacon frames with any panid will pass through filtering. If another panid (not 0xFFFF) is programmed on receiver side, then only frames with this specefis panid will get through.
I still think there is some portion of ambiguity in user manual chapter describing filtering rules.
And did you test if you send 0xFFFF as pan id? To my understanding it was in this way it was intended. So you could send broadcast messages to other networks.
I’ve tried sending with 0xffff pan id initially as I thought this is how I could send broadcast messages irrespective what pan id is set on receiver end.
But this is not how it works in real life.
In order to receive messages from another networks 0xffff must be set as pan id on receiver not on transmitter. In this case any pan id in incoming messages will be accepted and pass filtering.
If any other pan id is set on receiver (not 0xffff) then only messages with this pan id will be accepted and all other will be rejected by filtering mechanism.
In that case you’re right. There is [color=#333333]ambiguity on this in the datasheet.[/color]