Two device ble

[bvanommen]

First prototype for connecting two qbeads together. I also refactored blochVector into a separate file to reduce some of the code repetition. But, it's still pretty bad and ideally the host and client qbeads inherit some functions from a more general qbead class that takes care of lighting LEDs etc..

The host sketch lights an LED according to the orientation of the client qbead.

ATM the host connects to the first client qbead it detects. We could try to do something with MAC address.

The default settings result in a range of ~3.5m (~12 feet for americans). It's possible to adjust transmission power to increase this, I suppose.

[bvanommen]

MAC could be retreived in the scann callback from the report:

  // MAC is in little endian --> print reverse
  Serial.printBufferReverse(report->peer_addr.addr, 6, ':');
  Serial.print(" ");

  Serial.print(report->rssi);
  Serial.print("  ");

from the source: https://github.com/adafruit/Adafruit_nRF52_Arduino/blob/master/libraries/Bluefruit52Lib/examples/Central/central_scan/central_scan.ino

Also the default power seems to be 0dBm, can be raised to 8dBm max I think, but not good for battery life I guess.

[Krastanov]

suggested class structure:

• qbead class without BLE capabilities
  • some of its methods will need to call into callbacks that are to be overwritten by subclasses
• one subclass with peripheral capabilities (to be factored out from the current qbead class)
  • characteristics are meant to be a 1-to-1 interface to hardware (IMU or LEDs), this should already be the case
• one subclass with central capabilities (new features added here)
  • no characteristics, but an API to enumerate connected devices and a C++ API to interact with the characteristics of connected devices

[Krastanov]

Maybe one PR that makes the split into hardware class + BLE peripherals class (no new features, just a split). And a separate PR that implements the BLE central class.

For each hardware function like do_something_with_LEDs, the BLE central class can have a function do_something_with_LEDs_remote which updates the corresponding characteristic of the remote device (and an extra argument picking which remote device to touch)