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.

Bluetooth & 6LowPAN simultaneously on CC2650

Other Parts Discussed in Thread: CC2650, LAUNCHXL-CC2650

Hi,
Is it possible to have CC2650 running both Bluetooth & 6LowPAN at the same time?

Example use case would be having 6LowPAN to create a mesh network and Bluetooth to connect smartphones to it.

Cheers.
Conall

  • Moderator, can you move this to the correct forum? Cheers, Conall
  • Hey Conall,

    Yes. Theoretically (and practically), the CC2650 could run Bluetooth Smart and 6LowPAN at the same time. However, we do not have any sample applications on this yet as the Bluetooth Smart and 6LowPAN are separate software solutions at this point. 

    Best Regards

    Joakim

  • Thanks for getting back to me Joakim. 

  • Hi Conall,

    have you been able to achieve bluetooth and 6lowpan running simultaneously?
  • In CC26XX-web-demo of contiki, it enable BLE beacon. So, you can see BLE beacon and 6LowPAN work at the same time. But for BLE Peripheral or Central to work with Contiki at the same time, I don't see any example.
  • Thanks YK Chen, will launchpad LaunchXL-cc2650 be enough for me to evaluate the chip? Can I reprogram the launchxl an write my code on chip mcu itself?
  • Yes, CC2650 LaunchPad is enough to evaluate the chip itself and Yes, you can program CC2650 Launchpad and write your own code to it.
  • As others replied before me, the cc2650 can run 6lowpan and BLE at the same time. There is no open complete Bluetooth stack available though, and space (flash and RAM) will be a problem. Limiting the BLE use to BLE beacons (and scan response) makes it possible to run a 6lowpan network that uses BLE for eg device discovery.

    We at Thingsquare use BLE for device discovery as can be seen in the following video:

    Instructions here on how you can try this yourself:

    This makes it possible to assure that the user is in physical proximity of the device at a particular point in time, and access to the device is controlled through user management so not just anyone can see the data (unless the customer wants the user to, or just limited to the latest two days worth of data, etc).

  • (necro bump, sorry) I've been playing around with the cc2650 smarttag along with contiki and from what I read in the source code the usage of the 6lowpan stack + BLE beacons is limited to sending the beacons. However you mention scan response which makes me believe that there's also a way to read something back from BLE while still servicing the 6lowpan stack.
    Is this so? Did I misunderstand it? I'm sure it is possible, just like it should, in theory, be possible to run the two full stacks concurrently but my question is if this is already supported with the current code base for contiki.

    Thanks!
  • You would still have problems fitting the stacks in flash, ie the code takes too much space. Scan responses are super simple - after a beacon, the cc2650 keeps the radio on for a short duration and if it gets a Scan Request, it responds with the Scan Response frame. The SR is very similar to the beacon, and does not set up a connection or something like that. If I understand you correctly, you are thinking along the lines of exploiting this mechanism and adding custom data to the request and response in order to transport data, instead of setting up a connection? If so, you will likely have lots of headaches with the BT stacks in phones, the cc2650, and the BT SIG.

    Again, Contiki only allows to send BLE beacons, along with the "normal" operation of the 6lowpan stack. You are free to add data to this beacon though.
  • Yes, well, I didn't even consider the resulting firmware blob size, honestly, and while I have used BLE in a few projects I'm not intimately familiar with the protocol, so what I understood by scan response was an actual optional payload to be sent back to the beacon advertiser, and as such I thought this was part of the protocol.

    I still haven't dug into the protocol, but now I'm reading it as an ack frame, no user data payload.

    I was just entertaining the idea of using BLE beacons to trigger a state change in my devices. In particular, I'm using a private 6lowpan network of devices, i.e. no border router, so I can't just detect a node using its beacon and then initiate a communication with it from, say, a smartphone as I'll only have BT available between the two parties (or 6lowpan, but 802.15.4 is not something I'll be able to use on the phone side). My intended workflow would be to have the phone reply to the beacon and as such trigger a state change on the node device where it would switch to a BT config mode temporarily, but of course as you explained my idea is very much flawed by lack of real estate on chip to carry both 6lowpan and BT stacks and by not being able to reply to a beacon with a user payload while still complying with the standards.

    Seemed like a good idea at the time...

    Thanks!

  • Sorry if I added confusion to the discussion, but yes, you do add user data to the scan response. Since the beacon has a small size and have no way of being larger, BT supports adding more data in a scan response. The scan response though is only sent in response to a scan request. What I meant is that this does not set up a connection between the two devices so you won't be able to use this mechanism to interact with the cc2650, ie command it to do things, or read attributes and so on.
  • Actually, that would be exactly what I had in mind, although the lack of space for running both stacks still precludes this option.
    So using a common BLE stack on my, say, android phone, I could receive a beacon request from the cc2650 and reply to it, stating "hey, I need you to move to a different comms medium / protocol for me". The actual comms channel would therefore be independent of the beacon, that would just be a trigger.

    And thinking about using this for a simple control mechanism, which clearly isn't a good idea but still wouldn't it be possible to use a polling approach to implement an interaction protocol?
    cc2650->beacon("here I am")
    ->android->reply_to_beacon("cool, I want to know the value of X")
    ->cc2650->beacon("X=Y")
    ->android

    obviously all beacons go to everyone, and two concurrent replies to a beacon will likely garble each other, and there is certainly a very strict payload size for the beacon response, but still you just convinced me I need to look into this :)