Adds bluetooth and wifi data collection

[matthewfcarlson]

No description provided.

[jonfroehlich]

Wow, looks awesome. Seriously, so cool. Thanks for doing this.

I haven't had a chance to test this but a a few small things based on a skim of the code:

• Do we need common.h or should this just go at the top of the LIS3DHGestureRecorder.ino? Also, if we keep common.h, should we capitalize the 'C'
• Your comment says that we default to Serial in common.h but CURRENT_MODE is actually set to RECORDER_BLUETOOTH
• Do we have any way of knowing or measuring drop out rates with Bluetooth and WiFi? I suppose we can see if the ~90Hz receiving rates are similar across all three transmission approaches
• Finally, there are a lot of lines of code marked as changed in GestureRecorder.pde but aren't actually changed. Would be nice to clean this up so that it's easier to determine the new content... but not sure if this is just a poor GitHub diff engine or what's happening...

[matthewfcarlson]

1. The origional thought was to have the common file shared by processing and arduino but I realized processing is java not cpp.
2. My bad. Left over from testing.
3. I haven't added any sort of mechanism since so far it's been quite fast. In my testing I was seeing about 89HZ so it's possible we're dropping some samples but I don't think so.
4. I think I hit auto-format :/

[matthewfcarlson]

Okay I tried to fix some of the differences on the PDE but it's not quite fixed. There's just a lot of changes :/ What if you hit autoformat on your source and pushed a new change?

[jonfroehlich]

Did this and also made a few slight edits. Haven't had a chance to test yet--and will have to do so on both Windows (which it looks like you did) and Mac.

…

On Sat, May 16, 2020 at 1:28 PM Matthew Carlson ***@***.***> wrote: Okay I tried to fix some of the differences on the PDE but it's not quite fixed. There's just a lot of changes :/ What if you hit autoformat on your source and pushed a new change? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAML55M7BP6RCZMYRNCLNBTRR3ZPNANCNFSM4NCY5KOA> .

-- Jon Froehlich Associate Professor Paul G. Allen School of Computer Science & Engineering University of Washington http://makeabilitylab.io @jonfroehlich <https://twitter.com/jonfroehlich> - Twitter Help make sidewalks more accessible: http://projectsidewalk.io

[jonfroehlich]

Given the code redundancy in LIS3DHGestureRecorder.ino, it would be so much cleaner if we had a pointer (or Interface) that we set to either Serial, ESP_BT, or ESP_WIFI (depending on mode) and then printed out that way. Not sure the best way to do this in C/C++, however. @EdigaHe, any ideas?

Pseudocode.

CommProtocol getCommProtocol(){
  switch (CURRENT_MODE)
  {
    case RECORDER_SERIAL:
      return Serial;
    case RECORDER_BLUETOOTH:
      return ESP_BT;
    case RECORDER_WIFI:
      return ESP_WIFI;
  }
}

loop(){
 commProtocol = getCommProtocol();
 commProtocol .print(lis.x);
 commProtocol .print(", ");
 commProtocol .print(lis.y);
 commProtocol .print(", ");
 commProtocol .print(lis.z);
 commProtocol .print(", ");
 commProtocol .print(!buttonVal); // because pull-up
 commProtocol .println();
}

[matthewfcarlson]

Since they're objects I'm not sure if it would be a virtual method lookup or not. I'll do a quick prototype

[matthewfcarlson]

So a stroke of luck, they all inherit from the Stream baseclass.
https://github.com/espressif/arduino-esp32/blob/master/libraries/BluetoothSerial/src/BluetoothSerial.h
https://github.com/espressif/arduino-esp32/blob/master/cores/esp32/Client.h
https://github.com/espressif/arduino-esp32/blob/master/cores/esp32/HardwareSerial.h

[matthewfcarlson]

Disclaimer, I haven't tested this on hardware yet

[EdigaHe]

@matthewfcarlson I tested your code and the Bluetooth solution works quite well on both Mac and Windows, although I made some changes to the Bluetooth setup because I use a different BluetoothSerial library.

I have trouble getting the WiFi version work. The ESP32 can connect to my host (my laptop) and the Processing program can find the ESP32 (client). I noticed that the data started streaming and being visualized in the Processing program when I moved thread("processServer") in the draw() function. However, the streamed data seems incorrect and varies dramatically.

Can you check if this happens to you as well?