1. 29 Jan, 2018 1 commit
  2. 17 Oct, 2017 7 commits
  3. 15 Aug, 2017 1 commit
  4. 31 Jul, 2017 1 commit
  5. 01 Feb, 2017 1 commit
  6. 28 Jan, 2017 1 commit
    • moogle's avatar
      Replace hci.Stop() with hci.Close() · 4187da02
      moogle authored
      Stop() and Close() were used for the same thing
      so now the Stop() is gone and Close() will be used
      to stop/close hci.
      4187da02
  7. 14 Jan, 2017 1 commit
  8. 15 Dec, 2016 2 commits
  9. 14 Dec, 2016 1 commit
  10. 26 Sep, 2016 1 commit
    • Tzu-Jung Lee's avatar
      gatt: add ble.Client.Disconnected() <-chan struct{} · 0df5af5e
      Tzu-Jung Lee authored
      Since we've turned most of the GATT level API synchronous, the only
      asynchronous event is disconnected by remote peripheral, or the signal
      breaks up.
      
        // Disconnected returns a channel, which is closed when the client
        // disconnects.
        ble.Client.Disconnected() <-chan struct {}
      
      issue #14
      0df5af5e
  11. 01 Sep, 2016 1 commit
    • Tzu-Jung Lee's avatar
      update a few things · a80141fb
      Tzu-Jung Lee authored
      1. Introduce ble.Device interface, so we can mock it,
         and have other platform independent implmentation such
         as grpc-based one.
      
      2. Promote GATT stuff from ble/examples/lib/gatt to ble/
      
      3. Make API more synchronous:
      
        a. Remove StopAdvertising, StopScanning, ..
        b. Add context.Context in Scanning, AdvertiseXX API.
      
        So,  user can easily have a blocking advertising/scanning with
        optionally set timeout.
      
      4. Update current examples accordingly, and move them to
         lib/examples/basic/
      a80141fb
  12. 16 Aug, 2016 2 commits
  13. 11 Aug, 2016 1 commit
  14. 10 Aug, 2016 2 commits
  15. 22 Jul, 2016 1 commit
    • Tzu-Jung Lee's avatar
      hci: fix Advertising Data and Scan Response handling. · fe701591
      Tzu-Jung Lee authored
      AD and SR,if any, are delivered separately via HCI.
      Upon recieving an AD, we'll create an Advertisement and pass it
      to user's AdvHandler. If it's a scannable AD, which means there
      will be a Scan Response coming, we cache this AD, so when the
      SR is recieved, we associate it to the cached Advertisement,
      and pass it to the user.
      
      Normally, user will recieves Advertisement twice, the first one
      has AD only, and the second one has AD and SR.
      fe701591
  16. 20 Jul, 2016 1 commit
    • Tzu-Jung Lee's avatar
      linux: remove state machine handling out of hci. · c15a5369
      Tzu-Jung Lee authored
      A controller may have more than one instance of state machine to
      handle multiple concurrent connections. It's hard to maintain
      another state machine in the hci package, and try to keep it
      sync'ed with the controller's state.
      
      When a controller accepts a connection, it moves from advertising
      state back to idle/ready state. The host has to explicitly enable
      it to advertise again.
      
      In the 4.0 spec, where there is only ne connection at a time,
      this is plain simple; always re-enable advertising when the
      conecction disconnects.
      
      Things get much more complicated when it comes to supporting
      multiple connections. First of all, there's no way for the host to
      query how many connections the controller support.  What the host
      can do is to re-enable the advertising right after it accepts a
      connection. However, when the number of connecetions reaches to the
      limit of the controller, different controller may have different
      implementation/behaviour.
      
      One controller may return "command success" while it doesn't really
      re-enable advertising on the spot, but waits until the number of
      connections drops. Other controllers may return "command disallowed"
      and expect you to retry later, and the host would need to re-eanable
      advertising when a connection disconects.
      
      Given that we can't
      
        * learn how many connections a controller supports,
        * query if the controller is really advertising or not
        * different controllers may have different implementations
      
      the best we can do in the low-level package is probably to make it
      transparent to the users, passing errors with more context.
      
      Users should learn the capability of the controller from the vendor,
      datasheet, or product description. And figure out which case is the
      controller when it reaches to its maximum concurrent connection, and
      handle it accordingly - retry at the disconnect event or not.
      c15a5369
  17. 07 Jul, 2016 1 commit
    • Tzu-Jung Lee's avatar
      linux: fix l2cap signaling response · 7bd2a69b
      Tzu-Jung Lee authored
      Currently, the SignalCommandReject is responded uncontionally.
      In cases we've already handled and respond the request properly,
      the superfluous SignalCommandReject causes the remote device
      responds SignalCommandReject, and we go into a ping pong loop...
      7bd2a69b
  18. 06 Jul, 2016 3 commits
  19. 05 Jul, 2016 3 commits
  20. 01 Jul, 2016 2 commits
  21. 30 Jun, 2016 2 commits
  22. 28 Jun, 2016 2 commits
  23. 27 Jun, 2016 1 commit
  24. 23 Jun, 2016 1 commit