link_ID IN Simplicity

Hi Ran,

Have a look in the documentation.    Specifically the SMPL_Ioctl command ... with the object IOCTL_OBJ_ADDR.    This can be used to get/set a device address.

The documenation comes with SimpliciTI and on a typical installation can be found here:

C:\Texas Instruments\SimpliciTI-IAR-1.1.1\Documents

Cheers,
Lisa

Note that the suggested answer by Lisa will only supply the address of the radio the call is made on.  If you are looking for the address of the remote radio (the one at the other end of the LID) then you will need to make some lower level calls to get this information.

This function will return true if the LID is valid and will also populate the addr_t type variable pointed to in the parameter addr.  If the LID does not map to an active connection table entry or the addr parameter is null, false is returned.

// possible required include files
#include <stdbool.h>
#include "nwk.h"

bool GetRemoteAddr( linkID_t* lid, addr_t* addr )
{
  connInfo_t *pCInfo = nwk_getConnInfo(*lid);

  // if a connection object found and address pointer not null
  if( pCInfo && addr )
  { // copy over the address found to the supplied structure
    memcpy( addr->addr, pCInfo->peerAddr, NET_ADDR_SIZE );
    return true; // indicate success
  }

  // no connection found, indicate failure
  return false;
}

Jim Noxon

Note: I have corrected the code in this post so it should compile directly now without needing to go through the following posts which corrected it.

Thank you for your response Lisa and Jim,

I tried your funktion and it looks really prommissing but I get two errors in my build massages and I dont know what I just did wrong.

I copied the function like this:

bool GetRemoteAddr( linkID_t* lid, addr_t* addr )
{
  connInfo_t *pCInfo = nwk_getConnInfo(lid);                                            //Error[Pe167]: argument of type "uint8_t *" is incompatible with parameter of type "uint8_t"

  // if a connection object found and address pointer not null
  if( pCInfo && addr )
  { // copy over the address found to the supplied structure
    memcpy( addr->addr, pCinfo.peerAddr, NET_ADDR_SIZE );            //Error[Pe020]: identifier "pCinfo" is undefined
    return true; // indicate success
  }
  // no connection found, indicate failure
  return false;
}

and made a call of the function in the main like this:

bool check;

linkID_t adress

addr_t adresslong;

check=GetRemoteAddr( &adress, &adresslong );

thanks in advance

Ran

My apologies.  Please change the line

connInfo_t *pCInfo = nwk_getConnInfo(lid);

to

connInfo_t *pCInfo = nwk_getConnInfo(*lid);

and change the line

memcpy( addr->addr, pCinfo.peerAddr, NET_ADDR_SIZE );

to

memcpy( addr->addr, pCInfo.peerAddr, NET_ADDR_SIZE );

Things should work then.

Jim Noxon

Thanks Jim,

the two errors are gone now but I get a new on now.

bool GetRemoteAddr( linkID_t* lid, addr_t* addr )
{
  connInfo_t *pCInfo = nwk_getConnInfo(*lid);

  // if a connection object found and address pointer not null
  if( pCInfo && addr )
  { // copy over the address found to the supplied structure
    memcpy( addr->addr, pCInfo.peerAddr, NET_ADDR_SIZE );     //Error[Pe154]: expression must have struct or union type
    return true; // indicate success
  }
  // no connection found, indicate failure
  return false;
}

If i click the error message the cursor jumps infront of pCInfo.peerAddr.

And thanks for the quick help

Ran

Thanks Jim, 

everything is fine now.

Ran

Jim:

This will come as a stupid question, but please help me out. In which part of the communication does this "sender's address" get transmitted?

For instance, in a peer to peer network, first linking occurs, and then peers can TX and RX data correct?

In which stage of the communication; is it during linking, or is it after linking, does this address get transmitted?

What I am trying to do is, to TX specific data to specific devices. Is that possible? Could you please guide me?

The source and destination radio addresses are passed on every communication including those packets used during linking.  Note that sometimes the destination address may be the broadcast address (as it is when the link request packet is sent).

If you are trying to send data to a specific radio address, I would suggest you try the following

addr_t get_peer_address( linkID_t lid )
{
  addr_t a;
  connInfo_t* p;
  if( p = nwk_getConnInfo( lid ) )
    memcpy( &( a.addr ), p->peerAddr, sizeof( addr_t ) );
  else
    memset( &( a.addr ), 0, sizeof( addr_t ) );
  return a;
}

This should return the address associated with a link ID.  I would suggest you use this function to populate your own table during the link process as searching for a link ID from an address is time consuming.

Hello.

Dominic Pritham said:

What I am trying to do is, to TX specific data to specific devices. Is that possible? Could you please guide me?

I am trying to understand your issue and why you need the a specific device address. What do you mean by "specific devices"? By using a layered design device addresses are purposely decoupled from the application layer. Peers are identified and accessed via the Link Id. I do not see how knowing a device address at the application layer identifies a "specific device".

If the Link ID is too abstract for your purposes why don't you simply include an identifying token in the application messages between peers? You could even use the device address if you wanted. But the application wouldn't need to know that the token is in fact the peer's address. That's irrelevant. If you use a token in the application message to identify "specific devices" you don't need to work around the layered design that purposely encapsulates the lower layer constructs.

You have asked an implementation question but maybe it's really a design issue. If I am misunderstanding what you are trying to do maybe a little more detail such as a Use Case would clarify things for me.

lfriedman

lfriedman :

Work case, there are 6 peers in a network. 5 are wireless devices. The last one is connected to a wall. The peer that is connected to the wall supply, just for terminology sake, let's call it "wall peer" and the remaining 5, let's call them "wireless peers". The "wall peer" sends data wirelessly, of course, to the wireless peers. 

The important thing to note here is; each of the wireless peers do not receive the same data. All of the wireless peers have a different role to play in this network and take completely different actions. For instance, consider the case of a fire alarm, the wall peer "commands" one wireless peer to set the alarm for audio and visual notification. The second wireless peer is commanded to start the water sprinklers, the 3rd wireless peer is commanded to shut down the elevators and so on.

Therefore in order to TX specific data (rather I should have used unique data) to specific wireless peers, I should be able to distinguish between each wireless peer. And my though process was to distinguish them based on their device address. If there is a better and power efficient way to do it, please advice me. 

Thanks for your reply.

OK. Thanks.

I still would suggest including a token in the application message. So, after linking the wireless peer would send a frame to the wall peer and the message would contain the token. The wall peer would then associate the token with the Link ID as Jim Noxon suggested. There is no logical difference between using the (unneeded) probe of the network layer to get the address associated with the Link ID and sending an application message with the same information. The difference is that the latter respects the layered architecture so if you ever port the application you won't need to do anything new from a design perspective.

The token scheme should work based on your scenario. That token could be the address of the peer but I don't think that would be the best token. If the wireless peers have different roles to play then they should tell the wall peer what their function is by some kind of token in an application message. It assumes of course that the wireless peers know who they are, i.e., how to identify themselves and what their specific roles are.  If the individual wireless peers don't know who they are, how will the wall peer know from just the connection establishment transaction (linking)?

Hope this helps.

lfriedman

Hello lfriedman,

Trying to set up End(CC2530) to End(CC2430) Device Wireless Link using  SimpliciTI-IAR-1.1.1 code

I have CC2430 as one End Device and other End Device is CC2530. I am trying to understand how the SimpliciTI  protocol works.

So I have "SMPL_LINK" on talker device (CC2530) and I have "SMPL_LINKLISTEN" on listener side (CC2430). By reading the document I understand that when it tried to set up link at first. Each End device will send each own link ID to each other and they remember and once after the link is set up they try to send and receive packet based on the link Id they received initially during the link setup. (Now I don’t understand here is this Link ID is zig bee address....? ) Also in the manual I saw its recommended to setup "THIS_DEVICE_ADDRESS" what is this used for.....? is it necessary to implement.....???? is this default address at beginning..

Now to my understanding once the link is setup. than both the end device will communicate only to each other and no other wireless device can interfere or nor they will interfere... this case is true until the one of the device is powered down. Once its powered down it will lose its link ID n application has to reinitiate the link... is this case correct... no in this scenario where does "THIS _DEVICE_ADDRESS" fall...?

Any help or suggestion would be appreciated.

Thanks!!!

lfriedman said:

OK. Thanks.

I still would suggest including a token in the application message. So, after linking the wireless peer would send a frame to the wall peer and the message would contain the token. The wall peer would then associate the token with the Link ID as Jim Noxon suggested. There is no logical difference between using the (unneeded) probe of the network layer to get the address associated with the Link ID and sending an application message with the same information. The difference is that the latter respects the layered architecture so if you ever port the application you won't need to do anything new from a design perspective.

The token scheme should work based on your scenario. That token could be the address of the peer but I don't think that would be the best token. If the wireless peers have different roles to play then they should tell the wall peer what their function is by some kind of token in an application message. It assumes of course that the wireless peers know who they are, i.e., how to identify themselves and what their specific roles are.  If the individual wireless peers don't know who they are, how will the wall peer know from just the connection establishment transaction (linking)?

Hope this helps.

lfriedman