This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RandomAddress

Other Parts Discussed in Thread: SIMPLICITI, CC2533, CC2510

Hi

About SimpliciTI, I've been lookin the Sensor Monitor Example included in the developpement kit. I don't know if it could be a problem, but wouldn't be a bit dangerous use a function which generates a random address? What happens if casually the two generated addresses are the same? The system wouldn't link! I know that probably this possibility could be very little, but it exists, and could be a problem in crytical systems.

How could I assure that this two (or more) addresses will be different?

Thanks you. Regards,

Eduardo

  • I also wondered about the random link token generation and the possibility of collisions.  With 2^32 (4 billion) possible values it is very unlikely. Even if two EPs collide one or the other will eventually connect with the AP which will assign it a new link token eliminating the problem for the remaining unit.

    I recently attended a Ti ez430-2500 class where 30+ people were given new ez430-2500 kits and laptops to use.   All of the kits had the same link token, join token and were on the same frequency so the many collisions prevented most from linking to the EP for the sensor demo. They had us change the link address and with 32 bits (2^32) of possibilities no two chose the same Token. If these had been random as well everyone would have linked straight out of the box. If you are Ti, and want someone to have a couple of kits work together right out of the box the rand function is a good idea. I have eliminated the function and use fixed tokens.  It makes them easier to track on the packet sniffer at turn on.

    I would guess if it wasn’t random and had to be set most people (me included) would chose a pattern such as 01020304 or a0a0a0a0 or something similar with a higher probability of a collision due to similar patterns being use by many than a machine generated token.

     

     

  • Agreed on what you have written. Some of the first things i do when i write a new SimpliciTI code is to change the tokes from the default ones, change the channel number and I usually end up doing a random address thing, but that makes it harder to track using the packet sniffer.

    The code is use to generate random address was posted here (for the 8051 devices):
    https://community.ti.com/forums/p/7000/27122.aspx#27122

    Kjetil

  • H Stewart said:
    Even if two EPs collide one or the other will eventually connect with the AP which will assign it a new link token eliminating the problem for the remaining unit.

    So if multiple devices have the same address, a peer-to-peer network won't work, but an AP star network still will work?  Even with 3 End Devices with the same address?

    Is it recommended to use a random number as the address in mass production, or is this just for demos?  Or do they get a unique serial number burned in Flash at the assembly factory?  CC2533 comes with a unique EUI-64 burned in Flash from the chip maker for 802.15.4, does the CC2510 have any unique ID in it?  Is there any mechanism to prevent collisions between devices made by different manufacturers?

  • Hi,

    are you guys talking about the token or the address of the device?

    The address is used to filter echos.

    Basically same address as receiver == echo, therefore no Device can receive anything if all devices in a network got the same address, unless its a broadcast.

    And it doesnt matter if its linked to an AP or not. The only reason why they can talk to the AP is that it got a different address, but the ED arent able to communicate directly with each other(unless broadcast)

     

  • Is it a bad idea to just broadcast everything and let the application layer decide whether to respond?  Would that prevent relaying by repeaters and APs?

  • Broadcasts are resent by AP/RE, the difference is just that the AP/RE can aswell process it as every other (End)device that gets the broadcast one way or another.

    As you said, the application just has to determine itself then if it responds to the broadcast or not.