Making OpenScienceJournal work with our external bluetooth sensor device

[whatsthebeef]

I am a programmer working on the PocketLab project. I am currently trying to make our sensors work with the OpenScienceJournal app and I have the following questions regarding sensor detection.

I'm assuming that Bluetooth device connections can't be managed through the existing aidl interface and I therefore need to implement a new discoverer module with all associated classes or modify the existing NativeBleDiscovererModule module and associated classes. Are these assumptions correct?

If so, would creating a new module in the OpenScienceJournal code base be preferable or modifying the existing NativeBleDiscovererModule?

Shall I create a pull request to the OpenScienceJournal to try get the changes submitted to the main branch or will we just need to work off a PocketLab branch form now on?

[dsaff]

@whatsthebeef, the goal is that you should be able to create your own app that implements the AIDL interface in ISensorDiscoverer. That app can then use your own code to scan for bluetooth devices with a given characteristic. We're hoping that api.scalarinput will allow third parties to input data to Science Journal without a need for branching the core code.

[whatsthebeef]

@dsaff So if I understand correctly the management of our devices (connections, sensor sensor selection etc.) should NOT be performed in the OpenScienceJournel ManageDevicesActivity otherwise we would need to edit OpenScienceJournel code. If it isn't to be performed in ManageDevicesActivity then we need to integrate a separate GUI to manage devices which we need to switch to and from, to select the correct device and sensor. If we don't implement this GUI and there are multiple devices each with sensors generating 11+ different values all being auto-detected then sensor selection in record mode would become very complicated.

Is this understanding correct?

[dsaff]

@whatsthebeef,

Our idea is that your app would implement ISensorDiscoverer, and expose it as a service, allowing it to search for devices, and sensors per device, and advertise them by name and address. ManageDevicesActivity then would present these advertised choices; if the user chooses to connect to one of them, then a call would come back to your service to actually connect to the chosen sensor and begin streaming data from it.

I have a document and diagram that should help, but I need to get it up to date with the current implementation, hopefully by this time tomorrow. Let me know if the above makes sense, however, from a high-level perspective.

https://github.com/google/science-journal/tree/master/SampleGyroProvider has a reference implementation that may help some, although it only advertises one device with multiple sensors.

[whatsthebeef]

@dsaff Yes, the document would be very useful. The problem we will encounter when advertising all sensors is that our devices have 4 different sensors and 3 of the sensors generate x, y and z values. It is also highly likely that there will be 5+ devices in the proximity. This would mean that there may be an unreasonable number of sensors to connect to.

Any thoughts?

[dsaff]

@whatsthebeef,

As a first pass, you can advertise each device your app can see, and then 11 sensors per device (A.X, A.Y, A.Z, B.X, B.Y, B.C, C.X, C.Y, C.Z, D, E). When you're concerned about an unreasonable number of sensors to connect to, is the concern that there will be an overload of bluetooth traffic during the discovery phase, or that users will choose to try to add 55 sensors and stream them all?

[berndporr]

I had a good read of the AllNativeSensorProvider and thanks for providing it. That looks pretty straightforward. It compiles fine by itself and runs. How do I add such a service to the main science-journal project in the correct way so that this service is started alongside the other services such as the BLE service? I'm not very familiar with starting an external service. I've tried adding it to the manifest but I guess I need to also add the source dir so help would be appreciated. Haven't done any external AIDL integration so far. Really appreciate your help here. <service android:name="com.google.android.apps.forscience.samplegyroprovider" android:enabled="true" android:exported="false"/> The 2nd question is regarding the synchronous data: essentially I'm getting an observer for every sensor at the moment the DAQ starts. So I can keep them sitting there in the class waiting for data. The Attys will send then all sensor-readings within one timestamp so I essentially I send that data at this moment to all observers with onNewData() with the identical timestamp. Is that right? 3rd question: I haven't seen that Volt is in the list of dimensions actually. Is that right?

[dsaff]

@berndporr,

You shouldn't have to edit anything to get the app and AllNativeSensorProvider working together. However, you do have to (a) run a debug build of the app, and (b) using the app, go to Testing Options > Enable Third-party Sensor Providers. This requirement will go away before the next public release of the app, but for now, this is to protect the core Science Journal functionality from being affected by API bugs if any exist.

Let me know if that makes sense.

2) Yes, that sounds right, to a first approximation

3) You can return any unit name you like, you shouldn't feel limited by what's already reported in the app.

Good luck, and please let me know if you run into more challenges.

[berndporr]

AttysPatch.zip

thanks for the all the support. I've written a first version of a Service which connects to the Attys. See screenshot attached.

I guess I'm not allowed to commit to the respository so I've sent you a patch (in the zip).

A couple of questions: 1) the scrolling seems to be too slow so that samples are omitted which makes it look quite rough. Would it be possible to guarantee that all samples are plotted at a sampling rate of 250Hz? Or should I just reduce it to 125Hz? For ECG 250Hz would be nice. Here is how it should look like: Both programs use AttysComm to get the data. In Attysplot I don't scroll which is good for realtime plot (using SurfaceView) but of course ScienceJournal looks much, much nicer! 2) How do I add proper dimensions? Just now it reports acceleration and I'm not even sure where I've set it and where to set it properly. 3) How can I configure a sensor? For the analogue ones I'd like to offer DC mode, AC mode, resistance and ECG/bio mode (to show those tiny signals in the right scaling). I think aiming for the educational market these options should be fine not to overload people.

Thanks for your prompt help yesterday. Very much appreciated!

[dsaff]

Bernd,

Looking good!

I don't see a zip attached, but the hope is that you wouldn't need to submit a patch; you can host the service from an app that you publish, and then you can update the service without being linked to our release schedule. Did you find that you needed to make edits to Google-authored files to get things working?

1) We haven't really done any optimization on the throughput yet, but hope to quite soon. There will be a limit on sample rate, but I don't yet know what it will be.

2,3) For customizing the dimension display and settings, I'm rolling out API changes today (or tomorrow at the latest) that will make that possible. Keep an eye out for commits to master, or feel free to ping me back here if you don't see it.

[berndporr]

David, thanks! :) Actually really fun working on it. 0) that makes total sense. I can just absorb it into AttysPlot and add it as a service there. I didn't make any changes except of adjusting the aidl path: main { String osj = '../../OpenScienceJournal' aidl { srcDir osj + '/whistlepunk_library/src/api/scalarinput/aidl' } } ...but that depends really from where you run the project. It's one or two ../ less I think. Haven't changed anything else. So, can do all my coding completely separately.

1) OK. I'll leave it as it is for now and then tweak it once you've decided. 250Hz would be nice (esp for ECG). 2,3) Looking forward to it. In the meantime I move the service to its proper place in AttysPlot and tidy things up. I see that my AttysPlot and the scienceJournal complement each other quite nicely anyway.

[berndporr]

David, I've moved the service over to AttysPlot: https://github.com/glasgowneuro/AttysPlot here is the source: https://github.com/glasgowneuro/AttysPlot/blob/master/app/src/main/java/tech/glasgowneuro/www/attysplot/Attys2ScienceJournal.java

[dsaff]

Fantastic! Stay tuned for more improvements.

[berndporr]

David, I've just pulled the latest version from github and adjusted the code. Just now it's not very elegant but I thought I rather check if it works before I tidy things up. Plotting of the Attys data works: However the problem is that the device dialoge for the external dev won't show any sensors: but I can still select a sensor and I'm able to pair it. It's the same issue with ScalarApiSampleApp. I only see empty rows but I can pair them. Apart from that -- great that I can select now the icon and the dimension. That all shows up in the plotwindow and looking good.

[dsaff]

FYI, for people following along, the problem with the dialog was that the text was white-on-white due to a theming bug. This should now be fixed on the master branch.

[whatsthebeef]

David,

I still see this problem even after doing a pull form the OpenScienceJournal on the master branch and rebuilding.

What might I be doing wrong?

On Wed, Sep 28, 2016 at 10:10 PM, David Saff notifications@github.com wrote:

FYI, for people following along, the problem with the dialog was that the text was white-on-white due to a theming bug. This should now be fixed on the master branch.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/google/science-journal/issues/1#issuecomment-250268756, or mute the thread https://github.com/notifications/unsubscribe-auth/AARGY2EglgvR8cjPL5BRuS_TUOB2CZW9ks5qurulgaJpZM4J3aVu .

[dsaff]

@whatsthebeef, sorry! Can you pull master again (just so we're in sync), and post a screenshot? Thanks.

[whatsthebeef]

Okay, done the sync, screenshot is below

https://www.dropbox.com/s/ovudfsqajztg3b2/2016-10-05%2007.05.27.png?dl=0

On Tue, Oct 4, 2016 at 10:49 PM, David Saff notifications@github.com wrote:

@whatsthebeef https://github.com/whatsthebeef, sorry! Can you pull master again (just so we're in sync), and post a screenshot? Thanks.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/google/science-journal/issues/1#issuecomment-251493237, or mute the thread https://github.com/notifications/unsubscribe-auth/AARGY1kRZQMtl-AOdbSdHOy4roBsWpDtks5qwq3cgaJpZM4J3aVu .

[berndporr]

In order to get that black/white design I've added colours to the styles of the spinners. Background grey essentially to make the text visible: https://github.com/glasgowneuro/AttysPlot/blob/master/app/src/main/res/layout/adc_settings.xml Otherwise the dev sub config is indeed white on white.

[dsaff]

@whatsthebeef, aha, thanks, I thought you were talking about the sensor list. This is the dialog that pops up after the connection? I will take a look.

[dsaff]

@whatsthebeef, I'm very sorry that I didn't respond when I thought I had. I just pushed a new set of commits, including a new theme in the example ScalarApiSample app for dialogs. Can you see if following that example resolves your problem, or @berndporr's suggestion? Thanks!

[berndporr]

@dsaff , just out of interest where is that theme located for the dialogs? I had a quick look, found your commits but I'm still puzzled how you got that applied to the dev config. It certainly is looking good!

[dsaff]

@berndporr, I was referring to

https://github.com/google/science-journal/blob/master/ScalarApiSampleApp/app/src/main/AndroidManifest.xml#L35

But maybe I'm missing the problem?

[berndporr]

Ahhh. Thanks! I was the problem. I've completely overseen that fix. Added it and now it's looking good!

[dsaff]

Excellent!

[berndporr]

I thought you might be interested how the new devices list looks like. It's a good idea to have sub-menus per device (actually the sub menu just now has the device as a heading but the 1st senser of that dev but I guess that's just work in progress). However the sensor list when it's expanded is pretty tiny. At least with my finger I've got trouble tapping on it. OR; if you keep it that small then it would be good to have the name of the sensor in the config window so that one knows if he/she has tapped on the wrong sensor. Might be work in progress but just thought I give you quick feedback.

[dsaff]

It's definitely work in progress. I'll update here when we're close to visual spec!

[berndporr]

That's looking now really good. I've sneaked in an "OK" button in my context menu which finishes the sensor config activity.

[dsaff]

Great, glad it's working better!