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.

LAUNCHXL-CC1310: RSSI distance measurements with multiple transmiters and one receiver

Part Number: LAUNCHXL-CC1310
Other Parts Discussed in Thread: CC2340R5, SYSCONFIG

Hi,

I'm developing a network that would consist of one receiver and multiple transmiters in order to measure distances at line receiver-transmiter. I'd like to try the RSSI method with power level measuring, but don't know if i should work on TI 15.4 stack or build up the examples such as rfPacketErrorRate, which works "fine" in this scenario , but it only shows simple comunication with usage of one receiver and one transmiter. Could you provide me some advices what should i work with? I've got 4 launchpads already so I'd like to try a network with one receiver and three transmiters.

Regards,
Adrian

  • Hi Adrian,

    If you want TI 15.4-Stack features such as over the air download (OAD) and security already implemented, then you should go with this one. But it sounds like you can make either technology work.

    When you say one receiver and multiple transmitters I'm curious if you have thought about how the four transmitters should be coordinated. Do they have a timing window? Does the receiver poll the transmitters one after another?

    Cheers,

    Marie H

  • Hi again,

    Probably I've described my thoughts a bit wrongly, so I'll try to rewrite it. I wanted to make a pseudo localization system that would indicate if there is another radio device (in this case launchpads) in the near area, let's say to 20m. Moreover, I need to know how many of these devices are in range and where is the closest one. I assumed that it would be better to have one receiver and few transmitters, which simultanously transmits short message with its IDs (maybe i should add info about transmitting power and exit time) - receiver would get only signal from the near devices and depending on RSSI idicate which one is the nearest. Coordination would be assured by the receiver which would queue incoming data, but now if I look closely on that one I think there might be a problem with overlapping.

  • Hi Adrian,

    (Side note, if your distances are on the scale of 20 m, you could also go for 2.4 GHz solution such as Bluetooth low energy. E.g. use a CC2340R5.)

    If you use the TI 15.4-Stack in non-beacon mode, the collector is "always" in receive mode and sensor nodes can send a message at any time (using clear channel assessment or listen before talk to avoid collisions). Only caveat is that you would need to start the communication by going through the connection process, exchanging information between the collector and the sensor node.

    If you don't case about encryption or authentication it may be easier to just implement a proprietary network. Or use Bluetooth low energy advertisements/beacon packets.

    Hopefully my answers conveys that your use-case sounds like it can be implemented in various ways and should not be too complicated to get it to run!

    Cheers,

    Marie H

  • Hi Marie,

    I've got another question being connected to the topic, but now about rfEchoRx/Tx examples - can we use multiple devices, that are going to make a smth like a mesh? Let's say that i want to make now few Masters and lot of Slaves that going to broadcast their presence and if they would be near to the Master they would start talking about distance between them. Moreover i want the feature that Masters would talk also with other Masters. 
    For measuring distances i would try to merge rfPacketErrorRate example into described rfEchoXX. 

  • Hi Adrian,

    This sounds a little bit like a flooding mesh network. (Or if you want to use a well-know technology, you could use Bluetooth mesh.)

    If you make a proprietary network you can make it any way you want, but on the other hand you have to do the work of implementing it.

    BTW are your nodes battery driven?

    Cheers,

    Marie H

  • Hi Marie,

    Main nodes are supplied from accumulators of the moving vehicles and other nodes/node subscribers are battery driven.
    BTW, I have to use 433/868MHz frequencies because bluetooths 2.4GHz is being used in a different system in the same localization and i think it could lead to problems with overlapping transmissions from two different systems. Second reason of using 433/868MHz frequencies is a better ability to penetrate walls and obstacles.

    Regards, 
    Adrian

  • Hi Adrian,

    That's fair.

    Ok so it seems like a good idea for the main nodes to be always listening, while the node subscribers should be sleeping most of the time.

    If you have enough range to cover all your devices in a star network, I would recommend going for this topology. Mesh usually adds a lot of data overhead and latency, which again impacts your power consumption.

    Cheers,

    Marie H

  • Hi Marie,

    I tried to make a proper star network, but tutorials on resource explorer don't go with actual example projects. As I deduced, examples for CC13x0 are slightly different than examples for CC13x2 & CC26x2 and that's a shame that tutorials from SimpleLink academy, even though marked as compatible with both SDKs, they really aren't, because informations are shown for the CC13x2 & CC26x2 examples, that as i said are different than CC13x0. I managed to search for setting files like "config.h" manually, but at some point the discrepancies between these SDKs become so great, that I can't use these tutorials anymore, so I have to make it all on my own :<

    Regards,
    Adrian

  • Hi Adrian,

    We have a dedicated SimpleLink Academy portal for CC13x0 devices here:

    https://dev.ti.com/tirex/explore/node?node=A__AA78LmvkwjuaUT184Nz.jg__com.ti.SIMPLELINK_ACADEMY_CC13X0SDK__1FaRUBA__LATEST&placeholder=true

    Please let me know if you find an outdated instruction.

    Cheers,

    Marie H

  • Hi Marie,

    Yeah, problems are with i think not outdated instructions, but with non-compatible instructions, because some of them, although described as compatible with CC13x0, they are not. For example: 
    https://dev.ti.com/tirex/explore/node?node=A__AIxCz.M9qvop..3ndx0rEQ__com.ti.SIMPLELINK_ACADEMY_CC13X0SDK__1FaRUBA__LATEST&placeholder=true
    This one covers explanation for example dedicated for CC13x2 not CC13x0 and they are not the same. At first i don't have a file called "collector.syscfg" when i import collector example from CC13x0 SDK.

    Regards,
    Adrian

  • Hi Adrian,

    I see.

    You can try and go back to an old package to find the instructions without SysConfig, or read the collector project readme file.

    I'll put in an internal ticket to update this description.

    Cheers,

    Marie H