• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 455 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

RTOS/CC1310: 15.4 pairing mechanism similar to BLE

Darcy Huisman
Intellectual 280 points
Part Number: CC1310
Other Parts Discussed in Thread: CC2640R2F, CC1352R

Tool/software: TI-RTOS

Hi,

We have previously used a CC2640R2F in order to get BLE functionality in our product. Now we are working on a combination of CC1352 and CC1310 in order to pass through all BLE activity over the 15.4 stack.

Everything is working out relatively well, but one major downfall is the method of pairing using the 15.4 stack. It is possible to have multiple distinct pairings of different products within the same vicinity of one another (each cc1310 and cc1352 is only connected to one device at a time).

We use the following projects as a basis for our code, both using versions 3.10 of the stack:

CC1310 - collector

CC1352R - dmm_sensor_remote_display_oad

Ideally we would like the 15.4 connection to behave the same as it would with BLE. I am finding that, due to pan id's being the same, multiple devices are connecting together like a star network. We would like a peripheral/central connection that connects using mac address like BLE. 

Is this possible?

Thanks,

Darcy Huisman

  • 0
    Intellectual 280 points

    Ok, I think I have made progress in accomplishing this but I still have a few questions.

    In my case, the sensor is scanning for available collectors before choosing which one to connect to. When it connects to a collector it saves the collectors short address in NV. Now, whenever it tries to join with a collector it will check the NV for a match before connecting.

    Next comes the issue with the PAN id of the collectors conflicting. I know that it will check for PAN conflicts when the network starts up but it is possible that two devices can be brought into range with one another after that. I set up a periodic event that does an energy detect scan, which makes it recheck for conflicts and change the PAN ID.

    My remaining questions have to do with the short address. The short address is hardcoded but we want to use the same .hex file for all devices we produce.

    1. Is there a way to make the short address unique for each device without modifying the .hex file before programming? If not, can somebody guide me on where I can find the short address stored in the .hex file?

    2. I would actually prefer to use the IEEE extended address instead of the short address. It is already unique per device and it is still possible to get short address conflicts since we may produce more devices than the number of unique short addresses available (this conflict is probably not very likely though). As far as I can tell, the extended address is not exposed to the sensor until it has already associated with the network. Is it possible to get the extended addresses without associating?

    Thanks

  • 0 in reply to Darcy Huisman
    Intellectual 280 points

    I have managed to programmatically set the short address as the first two bytes of the IEEE extended address. Now I can program every device with the same unmodified hex file and get a somewhat unique short address for my collectors.

    In addition to my above questions I would like to ask:

    3. How reliable is it to do this? What are the chances that I will get conflicting short addresses?

    Thanks

  • 0 in reply to Darcy Huisman
    TI__Mastermind 35070 points

    Hi,

    In the end, the short address is a 16-bit value. The chances of conflicting short addresses is the nearly (if not exactly) the same as if you had just used a random short address. This situation, although possible, is fairly slim in application (about 1 in 65000).

    Regards,
    Toby