RSSI localization

Hi Necdet,

You can send a broadcast message, without the option of discovering routing, plus

you should be limiting this message to one hope (that is, this message won't be

retransmitted by the routers).

Br,

Igor

Hi Igor,

I've seen this topic and your answer: http://e2e.ti.com/support/low_power_rf/f/158/p/135183/487569.aspx#487569

I tried it but if I write AF_DISCV_ROUTE  | AF_SKIP_ROUTING to options and set the radius to 1, the message was not delivered nearest router/coordinator.

Regards,

Necdet

Hi Necdet,

Can you see the packet transmitted over the air (packet sniffer)?

Br,

Igor

Hi Igor

No, I didn't try using packet sniffer yet. I'm trying now. I will inform you about the results.

Regards,

Necdet

Hi Nected,

I think that the problem is in the code, not in the RADIO (broadcast of the ):

Changing the radios beyond 1 will trigger retransmissions of the packet by each router

(radius=2, the messages will be retransmitted one time end so on...).

AF_DSCV_ROUTE enabled by default (no matter if you set this flag in sending options

or not). You can supress the discovering feature of Z-Stack, by disabling AF_DISC_ROUTE,

that is, by setting/ORing the sending options with AF_SKIP_ROUTING.

Try to troubleshoot the problem by following these steps:

1. If you see (or suspicious) that the message hasn't been transmitted to the air,
   go to your code in the ED where you send the message by using AF_dataRequest,
   ensure that the settings are as described in LPRF's last post (follow this link).
2. If the packet transmitted to the AIR, check whether cluster ID and application end point
   are right one, so the receiving router won't filter the packet upon its recieving. 

Br,

Igor

Hi Igor,

I've tried your suggestions. I can see the message transmitted to the air. So there is no problem in the first part. Transmitter and receiver The Cluster IDs and enpoints match. When I change only the routing option to AF_DISCV_ROUTE the message is received on the other side.(with radius = 1) I'm trying to send an empty message to the nearby routers and then I form a new message on routers to be addressed to coordinator. What might be wrong? Maybe I'm missing some basic steps?

Thanks in advance.

Regards,

Necdet

Hi Necdet,

Can you please post the part of your code where you sending this broadcast message?

This is an example of interesting part:

MyApp_DstAddr.addr.shortAddr = 0xFFFC; // Broadcast to routers (no end device involved);
MyApp_DstAddr.addrMode = (afAddrMode_t)AddrBroadcast;
MyApp_DstAddr.endPoint = MYAPP_ENDPOINT;

AF_DataRequest( &MyApp_DstAddr, &MyApp_epDesc,
  MY_APP_CLUSTERID,
  tmpBuffLength,
  (byte *)tmpBuff,
  &MyApp_TransID,
  AF_DISCV_ROUTE | AF_SKIP_ROUTING,
  1 );

Br,

Igor

Hi Igor,

Here is the codes:

  Seriver_Tag_DstAddr.addrMode = afAddrBroadcast; 
  Seriver_Tag_DstAddr.addr.shortAddr = NWK_BROADCAST_SHORTADDR_DEVZCZR;  //adres to routers
  Seriver_Tag_DstAddr.endPoint = SERIVER_ROUTER_ENDPOINT;

AF_DataRequest( &Seriver_Tag_DstAddr, &Seriver_Tag_epDesc,
                       TAGS_LOC_CLUSTER,
                       SERIVER_TAG_DATA_CNT, // this is 0
                       NULL,
                       &Seriver_Tag_TransID,
                       AF_SKIP_ROUTING , MIN_TAG_RADIUS ); //Min tag radius is 1

I tried ORing with AF_DISCV_ROUTE but no improvement.

Regards,

Necdet

Hi Necdet,

Just to be 100% sure, the NWK_BROADCAST_SHORTADDR_DEVZCZR is

one of the following addresses; 0xFFFF, 0xFFFC, or 0xFFFD?

Br,

Igor

Sorry about that, I forgot to write. its defined in NLMEDE.h as 0xFFFC

regards,

Necdet

Ok...

Well, since I don't see anything wrong here, the next step is to use

the packet sniffer.

You said that you see this packet transmitted over the air, what is the destination

MAC address of this packet, is it 0xFFFC?

Yes,

There is no problem in that part. I think something may be wrong with my router program. It must capture broadcast messages and form a new message to be sent to coordinator. Maybe skip routing is not supported in early verisons of z-stack?

Hi Necdet,

That is a good question and I have no answer for that one.

You can do additional experiments to see whether the problem is only with

a single router or with all the ZigBee devices?

Br,

Igor

Thanks Igor,

I think I'm going to search an alternative way for RSSI localization.

Regards,

Necdet

Hi Necdet,

You are welcome.

It is a little bit hard to achieve RSSI localization once you have no the option of broadcasts.

What about a router broadcasting a message to other routers (short Addr = 0xFFFD), is

this configuration doesn't work for you as well?

Br,

Igor

Hi Igor,

I changed my algorithm and everything is fine now. I can get the RSSI value between each router to nearby end devices.

Thanks for the great help.

Best regards,

Necdet

Hi Necdet,

First of all, i'm glad to hear that all is fine.

Also, it sounds very interesting, do you mind to share and maybe elaborate on the main Idea

of this algorithm?

Br,

Igor

Hi Igor,

At first, I was trying to send periodic messages from end devices to nearby routers. Now, I send periodic RSSI request from routers to nearby end devices. Then the end devices turn an empty data packet to the related router. The router gets the RSSI value and send it to ZC.

At this point, I wonder what will be the difference if I get the RSSI value on the end device and send directly to coordinator. I need to be very careful about the end device battery lifetime. Will it increase the battery drainage?

Regards,

Necdet

Hi Necdet,

Tx/Rx actions draws the highest power from the device, so as long as you reduce

the amount of these actions in the End device you are set.

In the bottom line, sending several bytes message, instead of an empty one, won't

do any harm as long as you'r not increasing the number of these messages.

Also, keep in mind that End devices using different poll rates, thus additional transmissions,

to get different packets from their parents, where routers aren't.

Br,

Igor

Thanks,

I will definetly retry reducing the Rx/tx amount. I also wonder : do addressing modes effect power drainage?

I didn't understand the last sentence, can you explain a little more.

Regards,

Necdet

Hi Necdet,

It's just a piece of information that should be kept in mind when one want to reduce the power consumption

of a sleeping device.

ZigBee End Device using different polls to retrieve different types of data from its parent. These polls are as follows:

• Data Request Polling – periodically sends a data request to the parent device to poll for queued messages.
• Queued Data Polling – polls the parent device for queued messages after receipt of a data indication.
• Response Data Polling – polls the parent device for response messages after receipt of a data confirmation.

These polls are sort of transmissions sent by ZEDs to the AIR. In sleeping devices polls should be maintained in a

manually way in order to reduce the power consumption.

Br,

Ior