4 Replies Latest reply on Sep 18, 2017 10:47 AM by e.pratt_1639216

    Need help with switching BLE roles and a few more things

    virajkhatri_2481501

      I'm implementing the following system-   

      • Chip1(Peripheral) initially advertising data, Chip2(Central) scanning
      • When Chip2 encounters an advertisement, Chip1 sends a scan response packet and Switches to scanning(Central)
      • When Chip2 gets the scan response packet, it switches to advertising(Peripheral)

       

      My difficulties-

           1.I don't know the API's for switching roles or any method followed

           2.How does Chip1 know a scan has taken place?

                    Which even in stack is triggered, or how can I execute some instructions along with sending scan response packet

           3.How does Chip2 understand difference between advertisement packet and scan response packet?

       

      Any help appreciated,

      Regards,

      Viraj

        • 1. Re: Need help with switching BLE roles and a few more things
          virajkhatri_2481501

          Got how to switch states

          • #define CyBle_SetState(state) (cyBle_state = (state))
            • takes input parameters similar to CyBle_GetState() return values

           

          Still need help with recognizing that a scan response packet has been sent(Peripheral side)

          And help at central side recognizing a scan response packet from a advertisement packet

           

          Regards,

          Viraj

          • 2. Re: Need help with switching BLE roles and a few more things
            e.pratt_1639216

            CYBLE_EVT_GAPC_SCAN_PROGRESS_RESULT will occur when the central device receives a scan response packet; You can then proceed to handle the mode switching afterwards.

             

            Unfortunately, I don't see a way to access whether there was a scan response sent out; Cypress handles the advertisements in their binary, and thus it is unlikely there are hooks to handle switching modes after a scan response was sent out.

            Also, why have this odd process of switching which side is scanning and advertising? Chip1 could just be set to always scanning, and then chip2 would be always advertising. Switching the direction of the connection initiation/setup doesn't make alot of sense for applications that I can think of.

             

            Have you tested that the CyBle_SetState(state) define that you wrote works? Afaik, I thought you had to call cyble functions to turn the advertising, and scanning on/off properly otherwise the BLE stack crashes or messes up

            1 of 1 people found this helpful
            • 3. Re: Need help with switching BLE roles and a few more things
              virajkhatri_2481501

              The CyBle_SetState(state) didn't and it's not returning anything too, so I couldn't figure out why. I dropped that API

               

              I want to issue advertisement initially form Chip1 for an Interrupt, and then I want Chip1 to listen for instructions from Chip2, while Chip2 must wait for similar events form other chips too

              So until I command Chip2 it will still scan, and when command is received it switches to Advertisement, advertises the required data, and then goes back to Scanner for monitoring other interrupts from other chips

               

              Regards,

              Viraj

              • 4. Re: Need help with switching BLE roles and a few more things
                e.pratt_1639216

                Hmmmm; I would suggest sending a couple advertisements rather than just one (wireless transmissions are prone to error). Then, when you switch Chip1 to scan, set a timeout in case the Chip2 didn't receive the advertisements and then it can retry the advertisements or handle the issue in your app how you want.

                 

                For a setup like this, I would architect Chip1 to be passively scanning, and when it gets and interrupt to connect to Chip2 (which is setup as advertising), read the data/values you are currently returning in the advertisement packets, and then disconnect to allow other devices to connect and read the data when they need it. The only downside to this is handling the errors/timing for multiple devices trying to connect at the same time, but it simplifies the BLE mode to only one.

                 

                Epratt