Reusing connection in AP, ED addresses and bidirectional linking

Stefano Bettega

Other Parts Discussed in Thread: SIMPLICITI

Hi, I have some question about usage of SimpliciTI for a star network topology, in which the AP is always on and the ED are battery powered, so they turn on only sometimes to transmit a small packet of data and get back another packet of data.

In this link is stated that in SimpliciTI V1.1 and V1.2 is not possible to get remote remote peer address, but I found the nwk_getConnInfo function that, given a linkID_t, returns a connInfo_t structure, which in turn contain a peerAddr field. Function prototype is contained into nwk.h (implementation in nwk.c) and file has following header:
Filename:       nwk.h
Revised:        $Date: 2008-05-06 16:48:33 -0700 (Tue, 06 May 2008) $
Revision:       $Revision: 17025 $
It should be part of SimpliciTI V1.1.0. Does this fuction work correcly as expected? Or do we have to use the implementation suggested in the FAQ?
AP code in SEH Sensor Monitor example use a vector of linkID_t to store linked device descriptor. Sample implementation will use a new vector element for each connection request. If an ED connects and then reboots, without saving connection information to be used on subsequent power up, the AP will allocate a new element, even if the ED should be conisdered an "already linked device". Is there a way to obtain a peer address before allocating a linkID_t? This way we can lookup if a device is already linked and reuse the same linkID_t of the previous connection. Should this lookup be part of SimpliciTI stack? Or is this an application feature to be implemented in AP code?
Radio message exchange request the AP to invoke SMPL_LinkListen to create a linkID_t, then call SMPL_Receive given the linkID_t of the peer to check for a message. The ED sends a message by SMPL_Send (to AP given the linkID_t obtained from SMPL_Link), which is in turn read from AP. Now AP should reply with a response packet. To do so, does AP need to call SMPL_Send and the ED should be blocked onto a SMPL_Receive? linkID_t used for each device is the same obtained from the LinkListen (in AP) o Link (in ED)? Or do we have to exchange roles and perform a LinkListen in the ED and a Link in AP?

Thanks in advance,

Stefano

over 13 years ago

0 Leo Hendrawan over 13 years ago

TI__Guru 56650 points

Hi Stefano,

Stefano Bettega said:

1. In this link is stated that in SimpliciTI V1.1 and V1.2 is not possible to get remote remote peer address, but I found the nwk_getConnInfo function that, given a linkID_t, returns a connInfo_t structure, which in turn contain a peerAddr field. Function prototype is contained into nwk.h (implementation in nwk.c) and file has following header:

Filename:       nwk.h

Revised:        $Date: 2008-05-06 16:48:33 -0700 (Tue, 06 May 2008) $

Revision:       $Revision: 17025 $,

It should be part of SimpliciTI V1.1.0. Does this fuction work correcly as expected? Or do we have to use the implementation suggested in the FAQ?

Do you mean this FAQ? http://processors.wiki.ti.com/index.php/SimpliciTI_FAQ#How_to_obtain_the_remote_peer_address_in_SimpliciTI.3F, Well i think basically will work

Stefano Bettega said:

2. AP code in SEH Sensor Monitor example use a vector of linkID_t to store linked device descriptor. Sample implementation will use a new vector element for each connection request. If an ED connects and then reboots, without saving connection information to be used on subsequent power up, the AP will allocate a new element, even if the ED should be conisdered an "already linked device". Is there a way to obtain a peer address before allocating a linkID_t? This way we can lookup if a device is already linked and reuse the same linkID_t of the previous connection. Should this lookup be part of SimpliciTI stack? Or is this an application feature to be implemented in AP code?

Do you want to restore the connection after power cycle? There is also an example for this in the FAQ wiki: http://processors.wiki.ti.com/index.php/SimpliciTI_FAQ#Restoring_connection_after_power_cycle

Stefano Bettega said:

3. Radio message exchange request the AP to invoke SMPL_LinkListen to create a linkID_t, then call SMPL_Receive given the linkID_t of the peer to check for a message. The ED sends a message by SMPL_Send (to AP given the linkID_t obtained from SMPL_Link), which is in turn read from AP. Now AP should reply with a response packet. To do so, does AP need to call SMPL_Send and the ED should be blocked onto a SMPL_Receive? linkID_t used for each device is the same obtained from the LinkListen (in AP) o Link (in ED)? Or do we have to exchange roles and perform a LinkListen in the ED and a Link in AP?

The SMPL_Link() and SMPL_LinkListen() shall only be executed once in the beginning of the communication. The returned LinkID can be used for both SMPL_Send() and SMPL_Receive().

Hope this helps you.

0 Stefano Bettega over 13 years ago in reply to Leo Hendrawan

Intellectual 345 points

lhend said:

Hi Stefano,

1. In this link is stated that in SimpliciTI V1.1 and V1.2 is not possible to get remote remote peer address, but I found the nwk_getConnInfo function that, given a linkID_t, returns a connInfo_t structure, which in turn contain a peerAddr field. Function prototype is contained into nwk.h (implementation in nwk.c) and file has following header:

Filename:       nwk.h

Revised:        $Date: 2008-05-06 16:48:33 -0700 (Tue, 06 May 2008) $

Revision:       $Revision: 17025 $,

It should be part of SimpliciTI V1.1.0. Does this fuction work correcly as expected? Or do we have to use the implementation suggested in the FAQ?

Do you mean this FAQ? http://processors.wiki.ti.com/index.php/SimpliciTI_FAQ#How_to_obtain_the_remote_peer_address_in_SimpliciTI.3F, Well i think basically will work

[/quote]

Yes, that's the FAQ I intended. nwk_getConnInfo function seems to use an equivalent code of the patch described in the FAQ, with the exception of the name of the structure involved: for the FAQ is sPersistInfo.connStruct, while actual code uses sConTable.connStruct. In fact no sPersistInfo.connStruct does exist in the code. BTW I must assume my SimpliciTI version is 1.0.6 and not 1.1.0 as I supposed it to be, as in nwk_globals.c sVersionInfo contains
                                                0x02, /* protocol version */
                                                0x01, /* major revision number */
                                                0x00, /* minor revision number */
                                                0x06, /* maintenance release number */
                                                0x00   /* special release */
                                               };

lhend said:

2. AP code in SEH Sensor Monitor example use a vector of linkID_t to store linked device descriptor. Sample implementation will use a new vector element for each connection request. If an ED connects and then reboots, without saving connection information to be used on subsequent power up, the AP will allocate a new element, even if the ED should be conisdered an "already linked device". Is there a way to obtain a peer address before allocating a linkID_t? This way we can lookup if a device is already linked and reuse the same linkID_t of the previous connection. Should this lookup be part of SimpliciTI stack? Or is this an application feature to be implemented in AP code?

[/quote]

Basically I would like to implement a network that works this way: AP is always on, while EDs turn on, link and then fall to sleep mode. Each ED can transmit data with 1s interval, waiting for a reply for each message. When an ED has no more data, it can fall back into sleep mode. As EDs are battery powerd, maybe they will loose power, so that they could start from beginning when battery has been replaced. If an ED never looses power, we can assume that AP has a correct linkID_t mapping for each device. But when an ED restarts (even for an hardware reset), if we do not provide a way to restore the original linkID_t, the AP manages it as a new device, loosing the previously allocated linkID_t. Now, if there isn't a way for the AP to obtain information about the device is trying to join the network, we cannot avoid the AP to register it as a new device. I would like to avoid to store connection information on the ED if it is possible.

Another way to avoid this problem could be a totally connectionless network, in which each ED which awakes from its sleeping mode, performs a join&link procedure, transmit all the packets it needs and closes the connection before getting back to sleep. This will require the AP to serve only one connection at a time, delaying others EDs join request. This solutions requires each ED to wait too much time, as join&link procedure seems to be time consuming, and EDs should behave reactive in human time.

So if the only way to act as needed is to store connection information, I'll do it.

lhend said:

3. Radio message exchange request the AP to invoke SMPL_LinkListen to create a linkID_t, then call SMPL_Receive given the linkID_t of the peer to check for a message. The ED sends a message by SMPL_Send (to AP given the linkID_t obtained from SMPL_Link), which is in turn read from AP. Now AP should reply with a response packet. To do so, does AP need to call SMPL_Send and the ED should be blocked onto a SMPL_Receive? linkID_t used for each device is the same obtained from the LinkListen (in AP) o Link (in ED)? Or do we have to exchange roles and perform a LinkListen in the ED and a Link in AP?

The SMPL_Link() and SMPL_LinkListen() shall only be executed once in the beginning of the communication. The returned LinkID can be used for both SMPL_Send() and SMPL_Receive().

Hope this helps you.

[/quote]

I just asked to be sure, that's was also my idea.

Thanks for your support Leo.

Cheers

Stefano

0 Leo Hendrawan over 13 years ago in reply to Stefano Bettega

TI__Guru 56650 points

Ciao Stefano,

Stefano Bettega said:

Yes, that's the FAQ I intended. nwk_getConnInfo function seems to use an equivalent code of the patch described in the FAQ, with the exception of the name of the structure involved: for the FAQ is sPersistInfo.connStruct, while actual code uses sConTable.connStruct. In fact no sPersistInfo.connStruct does exist in the code. BTW I must assume my SimpliciTI version is 1.0.6 and not 1.1.0 as I supposed it to be, as in nwk_globals.c sVersionInfo contains

                                                0x02, /* protocol version */
                                                0x01, /* major revision number */
                                                0x00, /* minor revision number */
                                                0x06, /* maintenance release number */
                                                0x00   /* special release */
                                               };

Yes, i think the difference is that the code in the FAQ is written for SimpliciTI v1.1.1 / 1.2.0.

Stefano Bettega said:

Basically I would like to implement a network that works this way: AP is always on, while EDs turn on, link and then fall to sleep mode. Each ED can transmit data with 1s interval, waiting for a reply for each message. When an ED has no more data, it can fall back into sleep mode. As EDs are battery powerd, maybe they will loose power, so that they could start from beginning when battery has been replaced. If an ED never looses power, we can assume that AP has a correct linkID_t mapping for each device. But when an ED restarts (even for an hardware reset), if we do not provide a way to restore the original linkID_t, the AP manages it as a new device, loosing the previously allocated linkID_t. Now, if there isn't a way for the AP to obtain information about the device is trying to join the network, we cannot avoid the AP to register it as a new device. I would like to avoid to store connection information on the ED if it is possible.

Maybe you could try to use static linking? http://processors.wiki.ti.com/index.php/SimpliciTI_FAQ#Is_it_possible_to_create_static_linking_between_two_SimpliciTI_nodes.3F

0 Stefano Bettega over 13 years ago in reply to Leo Hendrawan

Intellectual 345 points

lhend said:
Maybe you could try to use static linking? http://processors.wiki.ti.com/index.php/SimpliciTI_FAQ#Is_it_possible_to_create_static_linking_between_two_SimpliciTI_nodes.3F

Hi Leo,

I spent some time reading code and description of static linking, but unfortunately I don't think it meets our needs.

If I well understood, static linking requires each device to know the remote party address to link to. Furthermore, a static link does not involve an acccess point, but this is required for our needs, as the access point is in turn connected to a processing unit that takes care of incoming messages. In such a configuration the access point could know all addresses of every end device, as in the processing unit there must be an association between each end device address to an internal logical configuration. But we cannot associate each end device to an access point, with exception of the join and link tokens. It would require too much effort to configure each one of end device also with its related access point address. We simply could start with a statically defined link and join tokens, and then we could change them only if required by the environment.

So I think I'd better to find a way to store connection information as you suggested in your previous post, and as FAQ explains.

Just another question: if power is lost on the access point, each end device is required to perform the join and link procedure from the beginning. How can an end device know the access point link has broken, if the failure happend when the end device was in sleep mode? Is there a well defined error code (i.e. SMPL_BAD_PARAM) that can be used to detect this failure upon trying to send a message, thus leading to perform the reconnection procedure?

Thanks again for your support

Cheers

Stefano

0 Leo Hendrawan over 13 years ago in reply to Stefano Bettega

TI__Guru 56650 points

Hi Stefano,

I have never personally tested this scenario, but i think in this case it is should be possible for you if you try to save the network configuration of the AP,and if it gets power cycled, the network configuration can be restored since it is already stored in the NV memory.

Stefano Bettega said:

[Just another question: if power is lost on the access point, each end device is required to perform the join and link procedure from the beginning. How can an end device know the access point link has broken, if the failure happend when the end device was in sleep mode? Is there a well defined error code (i.e. SMPL_BAD_PARAM) that can be used to detect this failure upon trying to send a message, thus leading to perform the reconnection procedure?

Maybe this can answer your last question:

http://processors.wiki.ti.com/index.php/SimpliciTI_FAQ#Does_SimpliciTI_support_message_acknowledgement.3F

0 Stefano Bettega over 13 years ago in reply to Leo Hendrawan

Intellectual 345 points

Hi Leo,

sorry for this late answer. I was involved on another project, so I didn't have so much time to spend on this one.

I think that message aknowledgement could satisfy our need to know if access point reboots. I don't think it could be necessary to store connection information into the access point, as long as the end devices are able to perform join and link procedure again.

About end device connection reusage into the access point, I think the only way to solve this without storing connection information in each of the end devices, could be performing join and link as usual, then search for a previous connection to the same physical address and release it into the access point table. This will require a little bit of coding on the access point, but will leave end devices clean about connection data storage.

An off-topic question for you: I'm evaluating CCS5 to develop our application on end devices, while actually CCE provided with ez430RF-2500 is sufficient for access point development. End device application was developed with CCE, then migrated to CCS5. Actually ported application is no longer working on the target device, in particular it seems that radio protocol is not working. I'm wondering if CCS5 does support SimplciTI version 1.0.6 or if there is any issue that must be taken into account.

0 Leo Hendrawan over 13 years ago in reply to Stefano Bettega

TI__Guru 56650 points

Hi Stefano,

Stefano Bettega said:

About end device connection reusage into the access point, I think the only way to solve this without storing connection information in each of the end devices, could be performing join and link as usual, then search for a previous connection to the same physical address and release it into the access point table. This will require a little bit of coding on the access point, but will leave end devices clean about connection data storage.

When you trying to relink the connection, don't forget to do unlink. we are having a discussion in another thread about this: http://e2e.ti.com/support/low_power_rf/f/156/t/202137.aspx. I might try to make a small example code for this

Stefano Bettega said:

An off-topic question for you: I'm evaluating CCS5 to develop our application on end devices, while actually CCE provided with ez430RF-2500 is sufficient for access point development. End device application was developed with CCE, then migrated to CCS5. Actually ported application is no longer working on the target device, in particular it seems that radio protocol is not working. I'm wondering if CCS5 does support SimplciTI version 1.0.6 or if there is any issue that must be taken into account.

Technically, i think there should be no problem using CCS. I am actually quite "new" with SimpliciTI, and has no knowledge about the stack prior v1.1.1 version.

Maybe this wiki page can also help you: http://processors.wiki.ti.com/index.php/Creating_CCS_Project_using_SimpliciTI#Including_the_SimpliciTI_source_code_files_directly_inside_a_new_CCS_Project

0 Stefano Bettega over 13 years ago in reply to Leo Hendrawan

Intellectual 345 points

lhend said:

Hi Stefano,

About end device connection reusage into the access point, I think the only way to solve this without storing connection information in each of the end devices, could be performing join and link as usual, then search for a previous connection to the same physical address and release it into the access point table. This will require a little bit of coding on the access point, but will leave end devices clean about connection data storage.

[/quote]

Hi Leo, that's a good idea :) Also using Ping feature to test if AP is still alive can be a simple way to detect problems.

lhend said:

An off-topic question for you: I'm evaluating CCS5 to develop our application on end devices, while actually CCE provided with ez430RF-2500 is sufficient for access point development. End device application was developed with CCE, then migrated to CCS5. Actually ported application is no longer working on the target device, in particular it seems that radio protocol is not working. I'm wondering if CCS5 does support SimplciTI version 1.0.6 or if there is any issue that must be taken into account.

Technically, i think there should be no problem using CCS. I am actually quite "new" with SimpliciTI, and has no knowledge about the stack prior v1.1.1 version.

Maybe this wiki page can also help you: http://processors.wiki.ti.com/index.php/Creating_CCS_Project_using_SimpliciTI#Including_the_SimpliciTI_source_code_files_directly_inside_a_new_CCS_Project

[/quote]

I'll try to upgrade SimpliciTI to the latest version, to check if problem still persist.

Cheers

Stefano

0 Stefano Bettega over 13 years ago in reply to Stefano Bettega

Intellectual 345 points

Small update: finally I upgraded SimpliciTI to version 1.1.1 (I'm sure, nwk_globals.c contains 1.1.1) and my project started to work also with CCS5.

Now I'm going to have the first debug pass of the final application, then I will think about how to solve disconnection and reconnection issues.

Thanks for all of your support Leo

Bye

Stefano

Sub-1 GHz

Sub-1 GHz forum

Reusing connection in AP, ED addresses and bidirectional linking