How do I get an 802.15.4 module in API mode to queue an indirect message rather than send direct?

Question

I have my coordinator CE set to 1 (Coordinator enable)
I have my coordinator's ST set to 5ms (remote is 10ms)
I have my coordinator's SP set to 30 seconds (remote is 28 seconds - and have tested with 2 seconds on the remote)
I am in API mode.
I am using 64 bit addressing in my transmit packet.
I have mac mode (MM) set to 2 (no MaxStream header, but 802.15.4 acks enabled) - my remote does not support MaxStrem (it could if it were documented somewhere).

I have a packet sniffer - and am able to see traffic both ways.

It starts out fine, requests a beacon, gets one, requests coordination (indicates battery powered, no short address) - gets accepted, sends a "hello" message (custom protocol), followed by a few data requests, the software sends an appropriate response via API, it's transmitted (within 2ms of the last data request) and the remote goes into a sleep mode. Later (about 2 seconds) I send an API transmit request for a message to the remote, and the coordinator simply sends it (and repeats 3 more times since the remote is asleep and doesn't ack).

How do I get the coordinator module to queue this as an indirect message rather than send immediately as a direct message?

The poll request comes 26 seconds later - get's ack'd, but no data (since it was already sent).

Answer 1

Check your A2 parameter on the Coordinator.

Comments

A2 = 0x40 (allows association, which we need, active and energy scans disabled).  Welcome the feedback - but I don't see a relationship to indirect transmit.  We are associating fine, it's after association and after initial data exchange that we have an issue sending indirect to a remote station.

---

Sorry that is the A1 parameter on your End device which allows the End device to Poll its parent Coordinator for data when the end device wakes up..

---

Also confirmed - poling is enabled.

I can watch on a packet sniffer the coordinator simply transmits the data immediately, without waiting for a poll.  Everything I read in the manual says that if I have my ST and SP settings right, the coordinator should know it had not heard from that device in > ST time and hold the message up to 2.5* SP - it's not doing that.  When the next poll does arrive, and it does at the end of the remotes SP time (less than the coordinator's) - there is no data for the remote.

Thanks again - all you out there please keep the suggestions coming, I have to be missing something, or there has to be an incompatible setting that's not documented somewhere.

---

What is the DL and DH set to on the Coordinator?

---

These have not been changed from the defaults, as I'm not using AT mode the destination address is part of the API transmit command (and would vary for each destination device).  Doc says defaults are 0 and 0.  Are these values used in API transmission?  It does not make sense that one would need to set the address in these registers and then repeat that address in the API command (and that adds a LOT of time to the process for serial communications).  It is my understanding (and I cannot remember where I read this) that in API mode the destination address in the API command overrides DH and DL.  Is this incorrect?

The packet (as seen by the sniffer) has the correct destination address (64 bit) for the remote, and is not a broadcast (in fact, now that we're using the frame ID byte, we get a no-ack transmit response).

---

No, when using API mode, the DL and DH address field are not used for UART data.  They are only used for the sending of ADC or DIO line data if enabled.

You gave us the SP and ST  values but not the SM command,  Can you provide what the SM the value is for the SM command?

---

Sleep mode (SM) on the coordinator is 0 as a coordinator can't sleep, and as described in manual page 26 (v1.xEx). The documentation is hard to follow, but SM of 4 appears to be for remote devices only (indeed our Digi remotes are set to SM of 4).  Everything in the manual says that for a coordinator (CM=1, SM=0, SP >= SP of remote, ST <= ST of remote) that SP determines immediate vs indirect transmission.

The module's firmware version is 10EC so SM of 6 is not set, again per same manual page.

---

What firmware version are you working with?
What happens if you use a different MM mode?

---

The firmware version is 10EC.
If we use a different MM mode - we're no longer compatible with our sensor. I could test with a digi remote - but even if I found that worked, it would be of no value; as in production we are not using digi remotes.  (Base station production is holding for this issue)  I personally wrote the firmware on the remote (TI cc2538 based) and could implement the MaxStrem mac mode (MM) if it were documented somewhere - but since it appears to be Digi secret - I can't use it - hence the of no value result.

Let me thank you for all the help.  I'm also working though our sales channel to get some engineering support.  I am, however, running out of time.  If I cannot resolve this by weeks end - we will be launching a new base station design based on the TI chip, instead of the Digi module.  (All the buy vs build makes sens to buy for our base stations, except we can only buy if it works with our application).

In the short term, I'm working around the issue by implementing our own data request packet (we have our own message header, and have created one that means data request - and let our base station application send the data only at that time).  The down side to that is that due to serial transfer speeds, we have to leave the remote on 15ms to reliably get data, and thats 13ms longer than planned and therefor 7.5x the battery consumption on every data pole, which we can't afford.

So - anyway - I still welcome the suggestions, I'd rather not redesign the base station at this point.

---

Then may I suggest you contact Digi Technical Support for help in this area. The area you are in right now is for customer helping customer and is not monitored by Digi representatives.

I would also recommend upgrading your firmware to the most current possible.