This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Multiple connections

Im making a project were i have two robots each one with a device connected with a mobile phone. But at same time i want that, when they are near each other they exchange a unique id (so that can know the identity of the other). The best way to connect the chip to a mobile would be a peripheral-central connection right? What about the "handshaking" between the chips? Inicially i thought it would be that each one would send a beacon but now im a bit confused since they would have to send a beacon and scan for beacons... Any ideias of the best way of doing this? Thanks in advance

  • Hi,

    I see 2 questions:

    1. Connection between robot and mobile device (phone): yes, with current state of BLE support on Android and iOS you can only use GAP&GATT layers so one side must be GAP Peripheral and second GAP Central. Many new phones support both GAP roles as well as GATT (Server/Client) so you can choose freely. If your concern is maximum support base among already deployed devices then mobile acting as GAP Central + GATT Client is the most natural and supported combination. It also helps to save power on the other side (assuming your robot is battery powered) because BLE roles are asymmetric and GAP Peripheral should consume less power then Central (of course how must depends on the implementation).
    2. How to use BLE to detect proximity of another object: indeed you need to listen (= scan) if you want to detect some broadcaster, there is no way around (at least not with 2.4GHz technology like BLE). But specific implementation method depends on your expectations in terms of proximity (how far/near) and timing (how quickly they should detect any change of position/velocity/direction) resolution. If you want to detect devices with the resolution of several meters and effective "sampling" frequency ~1s then you can implement it easily with broadcaster (can be non connectable with interval 100~400ms) and scanner (can be low duty cycle like ~30%) which must be running in parallel + the connection to mobile device on top of it. All Nordic BLE stacks can do this today (1 Peripheral connection + 1 Scanner + 1 non-connectable Broadcaster) but the power consumption will go notably high. If your expectation is to detect devices with <1m accuracy (and in wide range like 0-10m or even more) and/or higher "sampling" frequency (to be able to track any velocity/position/direction change with <100ms accuracy) then you will have big problems due to limitations of BLE technology as such.

    Cheers Jan

  • If the goal is only to detect if the 2 robots are "near each other", then maybe lowering the tx-power to a minimum would be an idea(-30/-40 dbm), so that the robots only are able to scan and find each other when they are close enough to pick up the weak RF signal? Not sure what -30/-40 dbm would corresponding to in meters with the nRFs, would need to be tested.

  • I'm afraid that won't work much (you can compute what it means to lower Tx Power by ~30dBm if visibility on free air and 0dBm can be hundreds of meters...). Anyway unless we know what "near to each other" means it's just academic debate;)

  • Hi, Thanks for the help, by near i mean just a like 5 meters or so. So for location i should use a beacon. Would it be a problem if they send the beacon at the same time? Thanks in advance

  • Yes, for proximity detection you can use advertising (sometimes called "beacon") and (passive) scanning on the other side. Choice of adv. interval, power level and scanning duty cycle should be then fine tuned for your specific application (if you have ultimate control over BLE hardware on both sides - if not then you need to test it and fine tune within limits of API you got).

    No, collisions are very rare in BLE (unless you have >500 advertisers with short interval or in opposite case few advertisers and lot more very active scanners). Advertising has mandatory jitter in adv. period (required by BT SIG Core spec) so even if you get one collision on some adv. channel and devices would pick the same adv. interval they should be out of sync for next event.

Related