The SimpliciTI Link Problem

The SMPL_Link/SMPL_LinkListen function calls are not transferring addresses, they are creating a communications link between the two peers.

The addresses must be known before this step.  You manage the addresses at compile time in the configuration files with the THIS_DEVICE_ADDRESS macro.  Note that you must change the address for the second ED before you compile and I would suggest you do a rebuild all as the configuration files don't seem to get properly handled in the dependencies of the project make file.

The address you provide in the configuration file will be downloaded to flash when you program the part.

Jim Noxon

Hi Jim

But I Find The variable "sPersistInfo" Can Appearance the other

EnddDevice Address after SMPL_Link??

(Peer to Peer Sample.)

And if I Change The sPersistInfo ID Address to 0x00,0x00,0x00,0x00.

Then The link will be fail???

Thank you.

Hi,

I have no Packet Sniffer but the Link and Listen calls send the address of the device to the other device according to the code.

Anyways back to your question. If you change the address for this connection in the pPersistInfo struct after a link was established then all packets of the other device will be discarded unless it sends a broadcast by using the broadcast address and the default(broadcast) link id. This happens because SimpliciTI uses the address to determine if the device that sent the message is really part of this link, so if you change the address then the device regards it as a new unlinked device and the old link is not useable anymore.

Hi Mart

Thank for your Reply.

I Just want to say. if I change the pPersistInfo struct ID Number then

The Peer to Peer Commucation will be fail.

So. I can back the pPersistInfo struct to Flash.

When next time power on, I can readload the pPersistInfo struct to RAM.

Then I can pass the Linkto/LinkListen process.

Because In product. I can't ask user every time all need Linkto/LinkListen process.

If there was another couple（the same peer to peer） near ??

So I think in product, Device Should be remember another device ID.

Hi Mark

Another Question.

SMPL_SendOpt(sLinkID1, msg, sizeof(msg), SMPL_TXOPTION_ACKREQ)
is Need Receiver Return a Ack, Rhgit.

But When I Apply in Peer to Peer, Why It alway return the SMPL_BAD_PARAM???

Thank's

Hi,

as I said, SimpliciTI saves the address of the other device to determine if a device belongs to this established peer to peer network or not.

Beside that saving the whole spersistInfo structure might actually work, just make sure that you overwrite the default struct with your backup after the RF communication was initialized(smpl_init) because it resets the whole struct.

The TI code is pretty well commented, therefore according to the comment:

SMPL_BAD_PARAM    No valid Connection Table entry for Link ID
 *                               Data in Connection Table entry bad
 *                               No message or message too long

Hi Mark

Thank for your Reply.

It's no any problem in ID back issue.

But The

if (SMPL_SUCCESS == (rc=SMPL_SendOpt(sLinkID1, msg, sizeof(msg), SMPL_TXOPTION_ACKREQ)))

I saw it in AP_as_Data_Hub sampleCode. Seem like EndDevice Send the message need Ack back.

So, This way only Use in EndDevice send meassage to AP??

Because AP can take this message and send ack back to EndDevice??

But EndDevice can't take this message and send ack back to another EndDevice2??

The ACK feature has to be enabled by the macro APP_AUTO_ACK in smpl_nwk_config.dat config, if you dont define this macro then smpl_sendopt always returns SMPL_BAD_PARAM if you use the SMPL_TXOPTION_ACKREQ option.

It seems like you also have to define the EXTENDED_API macro then according to the comment in this file, however I dont see why this would be necessary for ack.

Hi Quote

Thank for your help.

We just make sure let the Receiver can receive the Data indeed.

-Hunter

Jim Noxon said:

The SMPL_Link/SMPL_LinkListen function calls are not transferring addresses, they are creating a communications link between the two peers.

The addresses must be known before this step.  You manage the addresses at compile time in the configuration files with the THIS_DEVICE_ADDRESS macro.

This doesn't make sense to me.  How could the devices communicate if they don't exchange addresses?  In the packet sniffer, the LinkListen device sends a frame from its own address to FFFFFFFF, the broadcast address.  Then the LinkTo device sends a frame directly to the other device.  So it has to know the other device's address, and this works even if the other device's address is random, so it can't be known at compile time.  It's only known after the link process exchanges addresses.  Do you mean "the link token must be known before this step"?

My apologies for the poor wording.  The intent is to explain that the purpose of the linking process is to create the link MORE THAN to simply swap addresses/port numbers.  Although the process does include the transfer of addresses and ports for the purposes of routing future communications, the purpose of the main purpose of the link is to generate and abstract the connection.  If you need to access the address/port associations of the link after the fact, use the ioctrl function call to access the communications structures referenced by the Link ID returned from the linking process.

Jim Noxon

Ok, thanks.  Is it possible to check if a broadcast was sent from a device with a known address / Link ID?  Or would that have to be done by including the sender's address in the application payload?  http://e2e.ti.com/support/low_power_rf/f/156/t/17084.aspx#585090

A broadcast message is sent to address FFFFFFFF (assuming default).  Since this is a connection setup during the call to SMPL_Init, all devices see it as also coming from address FFFFFFFF.  Thus if you need to disclose the address of either device, it must be included in the users payload by your code.

WIth reference to the other post "http://e2e.ti.com/support/low_power_rf/f/156/t/17084.aspx#585090", It may be possible to modify the link structures to create a multicast-ish style of message.  If it were me, I would create a static link which is very much like the broadcast address.  I would attempt this as follows

Create the individual links to each pair of devices as you normally would.  Then, using the broadcast link, associate the nodes which should all be included in the multicast messages with a specific address:port from the multicast purveyor.  In effect you would be duplicating the same link information on each receiving node of the multicast message using the static linking process using the address:port passed in the broadcast association process.  This way, you should be able to send a message to the multicast link id for a given set of nodes and all of those nodes should be able to receive the message.  Note you should not use auto-ack protocols for such a mechanism.

For all of this to work, you will need to make sure you provide the necessary changes in the config files to enable the number of static user nodes necessary for supporting your network structure.  You should also familiarize yourself fully with the code that does the linking so you fully understand the process as static linking bypasses all safeguards imposed by the normal linking process.

Jim Noxon

Another thing you will need to do is to modify the address filtering code.  Currently it filters out the actual device address and the broad cast address.  You will need to add in a filter one or more multicast addresses and a mechanism to set it (them).

Jim Noxon