Connection indication on no connection

The RL78 sends out a connection event to an advertising device which is seen on an over-the-air sniff. However, the device does not respond (it keeps advertising and does not move onto the connection channels). However, the RL78 signals a connection complete event to the application. In response to the event the application starts service discovery which, of course, fails. Why does the RL78 send a connection complete indication on no complete connection? What is the RL78 looking for in order to send a connection complete indication?

  • For central device, the RL78 uses API  (RBLE_GAP_Create_Connection) for connecting to peripheral device and gets response event (RBLE_GAP_EVENT_CONNECTION_COMP).The API and its EVENT are described in page 49 and  62 document R01UW0088EJ0118. The message sequence charts are also shown in page 156.

    For peripheral device,  the RL78 uses API (RBLE_GAP_Broadcast_Enable) for advertising, and it has four advertising types. Those are explained in page 41 document R01UW0088EJ0118 and page 69 document R01UW0095EJ0120.

    Check advertising type to establish connection between central and peripheral role devices.  

  • In reply to Thein Oo:

    This I already know. However, what I am seeing is that as a central after invoking the RBLE_GAP_Create_Connection I get an RBLE_GAP_EVENT_CONNECTION_COMP when I should not. On the wire I see the connection request go out but the device does not respond. It continues to advertise and does not move onto the connection channels. Given that, I would not expect to get an RBLE_GAP_EVENT_CONNECTION_COMP.

  • In reply to Brian:

    The RL78 uses API (RBLE_GAP_Device_Search) and gets the events (RBLE_GAP_EVENT_DEVICE_SEARCH_RESULT_IND) and  (RBLE_GAP_EVENT_DEVICE_SEARCH_COMP). Those are described in page 47, 60, and 61 document R01UW0088EJ0118. Refer to message sequence chart in page 154.

    After calling API (RBLE_GAP_Device_Search), wait until receive the EVENT (RBLE_GAP_EVENT_DEVICE_SEARCH_COMP).

    Then, uses API (RBLE_GAP_Create_Connection) for connecting to the correct peripheral device.

    Make sure that the central device has to connect right peripheral device. Before connecting, check the Bluetooth Device address (BD address) in the list or check the local name in received advertising data. Refer to page 78 document R01UW0095EJ0120.

  • In reply to Brian:

    The RL78 uses API (RBLE_GAP_Device_Search) and gets the events (RBLE_GAP_EVENT_DEVICE_SEARCH_RESULT_IND) and  (RBLE_GAP_EVENT_DEVICE_SEARCH_COMP). Those are described in page 47, 60, and 61 document R01UW0088EJ0118. Refer to message sequence chart in page 154.

    After calling API (RBLE_GAP_Device_Search), wait until receive the EVENT (RBLE_GAP_EVENT_DEVICE_SEARCH_COMP).

    Then, uses API (RBLE_GAP_Create_Connection) for connecting to the correct peripheral device.

    Make sure that the central device has to connect right peripheral device. Before connecting, check the Bluetooth Device address (BD address) in the list or check the local name in received advertising data. Refer to page 78 document R01UW0095EJ0120.

  • In reply to Thein Oo:

    I do not think you understand the original question. All of the items you mention have been done and not relevant to the original question. They HAVE to be done, in fact, before one can invoke the RBLE_GAP_Create_Connection. One can see using a sniff that the connection request generated by the RL78/G1D is correct. The problem is that the peripheral (for some reason that I do not understand) does not receive it or, more likely, does not respond to it. In spite of that fact, the RL78 gives the application an RBLE_GAP_EVENT_CONNECTION_COMP event.

    This question has nothing to do with a device search. That has been done and turned off before the connection was created.

    So I am asking why did I get this connection complete event? That should NOT have happened.

  • In reply to Brian:

    The central device might not connect to intended peripheral device, which is continue advertising. Check the central device can really be in idle state before creating connection to intended device. Check the BD address of peer device in RBLE_GAP_EVENT_CONNECTION_COMP is correct peripheral device.

  • In reply to Thein Oo:

    Check the peripheral device whether non connectable or not. If the peripheral is non connectable, the central will get RBLE_GAP_EVENT_CONNECTION_COMP in status error.

  • In reply to Thein Oo:

    As stated, the connection request generated on the wire is correct, address, parameters, etc. In addition, after the connection disconnects because the peripheral does not move onto the connection channels and the service discovery request fails, the attempt to connect is retried (since the peripheral is still advertising). I have written the code to automatically retry on recognized connectable advertisements. The same thing happens. However, after a few attempts, the connection succeeds. The peripheral moves onto the connection channels. The central continues on with service discovery.

    What seems to be happening is that as soon as a connection request goes out on the wire, the RL78 signals the application with the event whether or not the peripheral responds to the connection event. That is what I am seeing. I would expect the event to be signaled only if the peripheral moves onto the connection channels.

  • In reply to Brian:

    It seems that there is not enough delay between event (RBLE_GAP_EVENT_DEVICE_SEARCH_COMP) and API call (RBLE_GAP_Create_Connection) for central device at Standby state.

  • In reply to Thein Oo:

    Standby state? What is that? The only states I know about (especially at this time) is that it is in RBLE_ACTIVE. It doesn't make sense anyways. Why would the application be signaled that the search is done if it is not? An application has to rely on the fact that when it receives an event stating that a procedure is done that the procedure is, in fact, done and one is ready to take the next legal BTLE action (which in this case is to initiate a connection procedure). At least the connection request sent over the airwaves makes sense. What is wrong is what occurs AFTER the connection request is issued.

  • In reply to Brian:

    Refer to Bluetooth Core 4.2 document page 2573 for Link Layer State that explains on Standby state.

  • In reply to Brian:

    Refer to Bluetooth Core 4.2 document page 2573 for Link Layer State that explains on Standby state.

  • In reply to Thein Oo:

    That doesn't really help. I know what the BT spec does. I need RL78 APIs to access that kind of information and that is NOT available. Please look at the APIs the application has available to it (r01uw0088ej0118-g1drm-main.pdf). This is what I have to work with and I need to work within the context of these methods.  I have GAP, GATT, and SM level methods. I have no control over or information about the link layer...well, at least not that I have seen.