I've got a strange problem which I think has only shown up with the latest update last week. It's intermittent. I've just managed to catch it.
This is the data I'm sending through via onNewData(Math.round(timestamp),v); here plotted against the timestamp so that you see that there aren't any time-reversals or timestamp issues:

I've literally had a Log.d directly next to the onNewData with the pairs to be sure I have the exact data:
log.zip
Now what I see in ScienceJournal are these samples:

Any idea from where that might come from? It doesn't matter if I have one or two channels running. It's also intermittent that sometimes it's really bad and sometimes it looks perfect for the whole recording:

The timestamp is kept pretty close to the system clock (certainly not creating time reversals etc). I do a bit of timestamp correction so that the Attys clock and the system clock are always in sync. I take the Attys sampling interval of 8ms and then do a small correction of the timestamp to stay in sync with the system clock. Of course not going back in time to correct it. The Attys is very precise with its internal clock:
` double timeNow = System.currentTimeMillis();
// let see if we drift apart which happens because
// the clock in the Attys might be slightly
// faster or slower
// so if the timestamp is lagging behind the
// system time we speed up our timestamp a bit
double timeDiff = timeNow - timestamp;

                // let's gently stay in sync with the system
                // time but let the ADC clock dominate the
                // timing because we know that they arrive at
                // the sampling rate (+/- a small drift)
                double offset = 0.1 * timeDiff / ((double) attysComm.getSamplingRateInHz());

                Log.d(TAG, String.format("offset=%f,timeDiff=%f", offset, timeDiff));

                timestamp = timestamp + samplingInterval + offset;`

Happy to do some debugging if you point me to the bit where it's processed.

I'd like to remove some temporary journals I made to explore the feature of this app. The option seems available but grayed out. Can the option be added to remove journals?

I've recorded a short video (admittedly at a too low bitrate!) but you get the idea:
https://www.youtube.com/watch?v=09uzuLuCyRE&feature=youtu.be
I get the circular spinner when I start the program but if I for example go into the external dev config and back it reports briefly Failed to load sensor data but that then goes away once my service reports the successful connection and everything is fine. I cannot really tell science journal that I'm waiting for a connection explicitly so it seems so that it defaults to the error message or can I use the listener to tell sciencejournal I'm waiting? How can I prevent the error icon and have the spinner back up running?
Please ignore that with two cards I need to restart the program (I'm fixing that at the moment).

Trying the new Android release, and notice a severe yellow tint and blurriness when using the camera in GSJ. Compare screenshots of these scene in my office from within GSJ and from my phone's native camera app (HTC One M8 running Android 6.0):

The two ADC channels can be configured to measure V, mV (multiplied by 1000 for mV signals) and Ohm. For channel one I have: V and mV depending on the application. For biosignals (or small differential one) I set the PGA of the ADC to a higher value (x6) and I multiply the result by 1000 (see also my ECG).

For channel 2 I have Volt or Ohm (essentially I switch on a 22uA bias current via the config menu and then one can measure resistance):

I've got the impression that the dimensions are only read once and then stored in sciencejournal. Would it be possible to have these checked dynamically or perhaps move these to the observer and/or able to modify them after an config intent has happened?

It would be really cool to be able to store data and notebook(s) in a Git repository with CSV (or CSVW with units) and an .ipynb notebook.

If smartphones were rotated, Accelerometer X and Y pointed wrong value. e.g.on portrate device and device is landscape mode, my back tilt isn't rewarded by displayed accelerometer value.

1. Enable Font and Screen Zoom as large as possible
2. Open the app
3. Tap GET STARTED
4. Observe the screen

SIGN IN button is hardly seen in the bottom of the page, CONTINUE WITHOUT SIGNING IN option is overlapped by another text, LEARN MORE option is not seen at all.

Language (Hindi)

Action Performed

1. Launch Science Journal
2. Record a trial.
3. Tap on the overflow button and select "Share".
4. Check on Relative time option and tap on "Share".
5. Select "Save to drive"/"Gmail"/etc and observe the filename.

Expected Result
Filename should be named as the "Experiment name" followed by the word recording and the record number.

Actual Result
Filename is named as "________1.csv"

COMMENTS:
This isn't just a Hindi issue. It seems to occur with any language that doesn't use the alphabet it seems. Repros if you set your language to Japanese for instance.

Would be great, especially for sound but also for other inputs, to be able to add filters: high pass, low pass, band pass band stop

@dektar , @precision , @scrubskip
https://www.youtube.com/watch?v=M-l7K_AMr-Q
@dsaff I thought that the sine becomes rough because there is not enough time between scrolls to plot the data. So I had a look at this.
I'm inputting is a sinewave which is first plotted perfectly. However then it looks that a couple of subsequent samples stay constant. I had a look at the code where that might happen but it looks as if all samples end up in ChartView. That's the way the data comes in as far as I see:
The scalarInputSensor gets a onNewData, that then goes into ScalarSensor with then does an addPoint at the ChartController and from there it goes into the ChartView via addPointtoEndOfPath. I'm puzzled where the samples are set to equal as soon as the path becomes longer.

To see what arrives at Chartview/addPointToEndOfPath I've added a Log statement here:

           } else if ((mChartOptions.isPinnedToNow()) ||
                    mChartOptions.getRenderedXMax() >= point.getX() || mLeadingEdgeIsDrawn) {
                // Add the point to the end only if the end is being rendered.
                // The path is in the previous coordinates, so we can add a point using those
                // mins/maxes.
                mPath.lineTo(getPathX(point.getX()), getPathY(point.getY()));
                Log.d("addPointToEdmdOfPath",""+point.getY());
                mXMaxInPath = point.getX();
                transformPath();
            }
![steps](https://cloud.githubusercontent.com/assets/1679394/19799484/d86b6b6e-9cee-11e6-8556-fb476ec41c07.png)
[sine2steps.zip](https://github.com/google/science-journal/files/557876/sine2steps.zip)

You see the data is already corrupted when it arrives at charview. I would have suspected it would have happened there.
The chart view actually already gets this step-wise data from the earlier classes and has no problem plotting it. Where could have that happened? Looks like pretty simple thing to fix but cannot find the exact place.

Action Performed
1.Go to system settings and set display settings to large font(Maximum size)
2. Open science journal app
3.open any experiment and click on any trial to view trial review screen
4.Observe the content of the trial review

Expected Result
Text seem visibly clear

Actual Result
Text overlapped in trial review when display settings are set to large font

I have an experiment in the library that doesn't have any cover photos selected, and as a result show the generic SJ image for blank experiments.

However, after sycning finishes in the library, this experiment suddenly takes on the cover photo of the experiment below it. Sometimes this happens with other experiments in the library as well.

My idea is to use realtime data sensors as input to neural network. To train o can use recorded data, but later will be nice to use realtime data. Maybe You can add aditional functionality as a data server over Wifi.

I work for a K-12 STEM education nonprofit (www.sciencebuddies.org) that is incorporating the Science Journal app into a bunch of our projects. Many kids use our resources for science fairs which means at the end of an experiment they will want to print out a graph to mount on their display board. I've noticed two things that might make this easier:

• An option to export an image of a graph directly from the app. Right now (to the best of my knowledge) you have to take a screenshot with your phone and then crop the image with third party software. This would make things easier for younger kids who don't want to deal with Excel or another spreadsheet program.
• A couple improvements to the export feature for kids who do wind up exporting the data:
• A time column that starts at 0 and is in seconds - this would make it consistent with the x-axis you see in the app, and spare kids from doing the conversion from Unix time. Keeping the Unix time option may be useful for projects where the date matters (e.g. weather observations on different days), but for most basic experiments kids would just be using a stopwatch and counting up from zero.
• Column header for the sensor (acceleration, light, etc) - right now it just says "value"
• Appropriate units in the column headers (seconds, m/s^2, etc)

Hi!

I recently discovered science-journal and seems pretty fun. I would like to know more how it works to make an individual contribution to the project, and if there is a planned development cycle. I'm interested in contributions regarding features that can turn it suit to be used as a geology/geophysics digital field book. An example of what it is a geology field book can be found here.

Regards,
Ricardo

The icon for no-wifi is visible. The sync progress bar (at the top) keeps going forever.

I am getting issue while importing project in Android Studio.

Caused by: org.gradle.internal.metaobject.AbstractDynamicObject$CustomMessageMissingMethodException: Could not find method leftShift() for arguments [android_release_aar_8aaffqenud6qsg8w8hrovmfvc$
_run_closure7@5f35a04c] on task ':scalarinputapi:generateRelease' of type org.gradle.api.DefaultTask.
        at org.gradle.internal.metaobject.AbstractDynamicObject.methodMissingException(AbstractDynamicObject.java:179)
        at org.gradle.internal.metaobject.AbstractDynamicObject.invokeMethod(AbstractDynamicObject.java:164)
        at org.gradle.api.DefaultTask_Decorated.invokeMethod(Unknown Source)
        at android_release_aar_8aaffqenud6qsg8w8hrovmfvc.run(https://raw.githubusercontent.com/ArthurHub/release-android-library/master/android-release-aar.gradle:62)
        at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:90)

I can see there is << available in "https://raw.githubusercontent.com/ArthurHub/release-android-library/master/android-release-aar.gradle" and this is deprecated android not allowed this.

I have research on this issue but not getting the solution.

Please help me..

Thank you

It would be great if this app could also record temperature (with a legal disclaimer to refrain from using your phone as an oven thermometer).

I'm using Android Studio 3.0.1 and all necessary plugins have been installed but i get this error every time i try to run it on an AVD or my phone using USB debugging.

Error:(62, 1) A problem occurred evaluating project ':scalarinputapi'.

Could not read script 'https://raw.githubusercontent.com/ArthurHub/release-android-library/master/android-release-aar.gradle'.
raw.githubusercontent.com

Even after clean building and including necessary packages, the problem persists.

Basically, it appears that sometimes unregisterClient doesn't always actually unregister, and then when trying to connect again to the same address, service tries to deliver the callbacks to the old client rather than the new one.

01-19 14:44:20.156 D/BluetoothGatt: connect() - device: E0:75:43:BD:63:51, auto: false
01-19 14:44:20.156 D/BluetoothGatt: registerApp()
01-19 14:44:20.157 D/BluetoothGatt: registerApp() - UUID=9a7e9dec-4acb-401f-8383-fed60a45792c
01-19 14:44:20.158 D/BtGatt.GattService: registerClient() - UUID=9a7e9dec-4acb-401f-8383-fed60a45792c
01-19 14:44:20.158 D/BtGatt.GattService: onClientRegistered() - UUID=9a7e9dec-4acb-401f-8383-fed60a45792c, clientIf=2
01-19 14:44:20.159 D/BluetoothGatt: onClientRegistered() - status=0 clientIf=2
01-19 14:44:20.159 D/BtGatt.GattService: clientConnect() - address=E0:75:43:BD:63:51, isDirect=true
01-19 14:44:20.159 I/SynthesisEngine: JSyn already stopped.
01-19 14:44:20.160 D/BtGatt.GattService: onConnected() - clientIf=1, connId=1, address=E0:75:43:BD:63:51
01-19 14:44:20.160 E/BtGatt.ContextMap: Context not found for ID 1

i want to log my life and, later on, analyze it against reality around me. so i was quickly very interested in this app capabilities as there's really nothing like it in the market! but unfortunately, there are still too many missing essential features to be useful for me right now. i believe they wouldn't be too hard to implement since just 2 of them might be enough:

• log all sensor at once
• automatic backup! sync with docs, spreadsheet, keep, ifttt, add an api or something (even if this is or will be on google takeout, i still can't risk the lack of a true automatic backup)
• search (although this might be mitigated by backup, to docs)
• plot graphs (although this also might be mitigated by backup, to spreadsheets)

and then, given i'm doing so many requests in a single issue already, here are a couple more that would be really helpful, even if not essential:

• let us feely set date and time of observation, to log past experiments
• much quicker and practical way to add observations/logs - for instance: through persistent notification or app shortcut a single press will do a pre-configured action to log all sensors and then record audio and/or transcribe it into a text comment

hopefully you can merge a few or all of those features into 1 issue! :D

1.Open Science Journal app.
2.Create any experiment with all sensors.
3.Now change device language into Hindi from device settings.
4.Navigate to Trial Review page for the recording.
5.Open all trial recordings and observe the same sensor titles

Expected Result
1.Sensor name in trial recording should be reflected in Hindi or should be localized

Actual Result

1. All the sensor names in graph are still displayed in English even after changing the device language to Hindi.

Comment:
When the device language is changed to hindi, after experiments are created, experiment trial review relaunch displays the sensor names in English. This is not reproducible in experiment feeds page where sensor names are displayed in Hindi. Reproducible in Pixel/OS 9

The "external devices" view looks like this:

I've paired three sensors and all the others are also there. I can go back to the main UI and do my experiments with them. There everything works as it should.
In order to get to the bottom of it I've added to ConnectableSensorRegistry:

   public void setPairedSensors(PreferenceCategory availableDevices,
            PreferenceCategory pairedDevices, Map<String, ExternalSensorSpec> sensors) {
        for (Map.Entry<String, ExternalSensorSpec> entry : sensors.entrySet()) {
            ExternalSensorSpec sensor = entry.getValue();
            removeSensorWithSpec(availableDevices, sensor);

            ConnectableSensor newSensor = ConnectableSensor.connected(sensor, entry.getKey());
            Preference pref = buildPreference(newSensor, null);
            pref.setWidgetLayoutResource(R.layout.preference_external_device);
            pref.setSummary(sensor.getSensorAppearance().getName(pref.getContext()));
            // bbb
            pref.setTitle("setPairedSensors");
            pref.setSummary("setPairedSensors");
            pairedDevices.addPreference(pref);
        }

and

    @NonNull
    private Preference makePreference(ConnectableSensor sensor, String key,
            PendingIntent settingsIntent) {
        Preference pref = new Preference(mContext);
        pref.setTitle(sensor.getName());
        pref.setKey(key);
        pref.setSummary("makePreference");
        pref.setTitle("makePreference");
        Log.d(TAG,String.format("make Preference: Title = %s, name = %s",sensor.getName(),key));
        mSettingsIntents.put(key, settingsIntent);
        return pref;
    }

still the Preferences are empty. All the calls seem to contain the right Strings and are not empty. I've also followed it through to ManageDevicesFragment but couldn't find any place where Title/Summary might got lost. I'd be happy to continue getting to the bottom of it but would really appreciate your help. I'm puzzled.

Sometimes, when you start recording data and later return to the app to stop recording, you cannot press the “stop” button to any effect.

Steps to reproduce (flaky):

1. Start recording any experiment. (Light sensor works well because it’s cheap.)
2. ??? (For me, this usually involves letting the device sit for a while, it going to sleep, and waking it back up after several minutes.)
3. Reopen Science Journal and switch back to the observation tab.
4. Tap the stop button.

Expected result: Tapping the stop button stops recording and saves your data.

Actual result: When you tap the stop button, nothing happens—data recording continues and cannot be stopped except by force-stopping the application.

I’ve had this happen multiple times (including just earlier today) but haven’t been able to work out a consistent way to repro it.

Sorry for the long title... couldn't think of anything more succinct. On multiple android phones whenever I close science journal the service that I use to scan devices, sensors, update science journal with new sensor data etc through the whistlepunk.api.scalarinput AIDL gets an onDestroy() call. I'm currently relying on that call to let the rest of my code that handles bluetooth connections etc know it is ok to shutdown, close my gatt connections, stop scanning, etc.

On chromeos when the google science journal app is closed this onDestroy() call never happens.

Is this a bug? Or am I relying on undefined behavior?

If you think it is a bug just point me in the general direction I should be looking in the science journal code and I'll be happy to try and fix it. If it isn't a bug I would appreciate some advice on how I should tell whether science-journal is still running/cares about what I am doing from my end. Thank you.

Mentioned in

#4 (comment)

Hi,
When there are variations in reading is there possibility to get that exact time when there is drastic change in sensor value ?
Currently you have to drag spot of time scale to find what time sensor value has been changed ?

I like that I can use this tool to collect and annotate data. But if I want to export the information I gathered to publish in my science project page for others to analyze, then I'm not able to it.
It's a requirement for a project I'm advising on and this tool was rejected because of that unmet requirement.
Do you think it's something you might add?
Just a CSV of the data for each observation, and the notes as an additional column would work, or maybe something more complex but still using open standards.

1. At least 1 experiment with trial recording having recording time more than 1 minute.
2. Set font size large (or) largest from device settings.

Steps to reproduce the issue:

1.Launch Science Journal App.
2.Open already created experiment.
3.Select any trial recording which shows recording time more then 1 minute, select 3 dot menu & select archive
4.From experiment 3 dot menu, select show archived recordings.

Expected Result
1.Recording time of archived trials should be able to see properly from experiments page after enabling show archived recordings.

Actual Result
1.Archived tag of recording trial overlapping with trial recording time from experiments page.

Thank you for this great tool! We are using the Science Journal to collect meta data during data collection using tablets. The meta data will answer questions on the environment the data was collected in, dark/light, loud/quiet etc.

The data collections that we will record meta data during are sometimes hours long so we are looking into ways to somehow generate summary stats of the data recorded over a time period of one or a few seconds and save that to file. But in order to decide how to do this best, we frst wanted to understand the nature of the sensor data better so we ran a pilot.

We piloted this using the Science Journal app, and it looks promising but when exploring our pilot data we saw both a pattern and randomness in the duration between each recording, and we would like to know if anyone in this forum that can shed some light on why it both has a pattern and is random. See the two graphs below of one very clear example. The left is a histogram of the duration between each recording of pitch, and the right is a scatter plot with the duration since previous recording on the y-scale and time into the recording on the x-scale. In the histogram it is clear that the duration of multiplies of 40ms is important. But there is also an non-negligible amount of recordings that does not follow that pattern. We do not want to disregard them, because what if those are correlated with something we want to measure in our environment meta data.

Is this something that depends on the device? We have tried with a couple of devices and whle some details are different, we get the same big picture results. In the example I used for the graph above the differences is quite uniform throughout the recording as can be seen in the scatter plot. But I have other graphs where the scatter plot shows that different parts of the recording have different patterns, or more/less distinct patterns.

We have also been thinking if this is due to a delivery rate setting in the sensor capturing in the implementation of the science journal app. But that would not explain where the random duration recordings are coming from. Or where the value 40ms comes from. In the light variable a similar value is about 100ms and in the accelerometer it is about 60ms.

Any advice on this would be highly appreciated. I am happy to provide more information if needed, but this post is already very long. Sorry if it is too long.

Once we know what we want to do we will include the open source code into our own app, but until then we are running the science journal app separately.

Suggestions of completely different but better ways to reduce the size of the data is much welcomed. We need the data to be smaller than the raw data in the science app and we need the unit of observation to be time uniform somehow.

Action Performed
Perquisites :
Microphone permission is not granted

Steps to reproduce:
1- Open the app
2- Tap the + button to create a new experiment
3- Tap on trial tab
4- Tap plus button at the bottom to add decibel sensor
5- Do not give permission to the app to use microphone

Expected Result
Second part of the error should be translated to the device language.

Actual Result
The second part of the error is in English with all device languages:
"Could not connect to microphone"

Only the phrase "Error occurred when connecting to this source" is localized.

Language /Locale Reproducibility: Reproducible Across any language. (Tested in Turkish, Hindi, Hebrew, Spanish, German)

1. Open a experiment having a image associated with it.
2. Update the Experiment name and Experiment image.
3. Tap on 'X' to not save the changes.
4. Observe that Experiment name is not changed but Experiment image gets updated.

Expected Result
Both Experiment name and Experiment image should not get updated.

Actual Result
Experiment image is getting updated though cancel is tapped.

https://github.com/google/science-journal/blob/5207658364671a5666b79107b322cfed586d02a2/OpenScienceJournal/whistlepunk_library/src/main/java/com/google/android/apps/forscience/whistlepunk/metadata/CropHelper.java#L100

This field is never used.

I'm developing a small data acquisition device specifically for education/science which is called "Attys" (see www.attys.tech) which will be released later in the year. I've started writing my own standalone app for it (https://github.com/berndporr/AttysPlot) but I'm really thrilled that the Science Journal is now open source and that ties in perfectly with my aim to have a mobile DAQ box for science experiments.

I've written a class which talks to the Attys (AttysComm), establishes the connection, reads data into a ring buffer and then it expects another thread to read from it. My background is comedi.org (see the usbdux* devices) so I've pretty much written it in a similar way. That might not be exactly the way it should be written for science-journal though.
I've read the thread started by @whatsthebeef and I've got also a couple of custom options which mainly relate to biomedical data acquisition (special signal routing, DC filter, 50/60Hz mains filter) but also the option to measure resistance instead of voltage and the ADC has different sensitivities.
I guess I'd implement a service which has the class AttysComm inside as you've suggested to @whatsthebeef.
I agree that it makes sense to contact you early so I've just done that!

Hi!

We are working on connecting a bluetooth classic sensor hub to SJ.

the issue we encounter is that the SJ sensor LE scan runs when the Sensor Settings activity starts, which blocks results from the bluetooth classic scan.

we can workaround by manually refreshing our BT classic scan after the SJ LE scan finishes.

the issue is exacerbated by the fact that we must connect to the hub to know what sensors are attached, so the process is quite painful already,

not the official docs, but this gives some context: https://stackoverflow.com/questions/25065810/android-bluetooth-scan-for-classic-and-btle-devices

hope all is well!

Action Performed
1.Open Science Journal app.
2.Set font size to extra large from device settings.
3.From science journal app open already recorded trial recordings.
4.From trial recording graph X coordinates showing overlapping..

Expected Result
1.Graph X-Coordinates should show properly from trial recording on setting font size extra large.

Actual Result
1.X-Coordinates overlapping from graph from trail recording on setting device font size to extra large.

At some point after flashing a custom ROM and kernel science journal allowed me to access the experimental developer settings. This allowed me to use sensors on my phone not otherwise available. At some point I restored to stock and lost these options. I have root and Xposed, is there any way I can activate the developer options again? Is there a flag in the build.prop I can edit? The Moto phones you had at maker faire had access to the experimental sensors so I was hoping you guys could help me out. Thanks.

Action Performed
Month/Year value are displayed as coded or displayed as "month/year" ("महीना/ साल") instead of actual value for experiments created from previous year.

experiments created in current and previous years.
Device Settings>Language & Input>Language-English.

Steps to reproduce the issue:

1. Launch Science Journal App and run setup.
2. In home page, observe the month/year category for experiments in both current and previous years.
3. Close or background the app.
4. From Device Settings>Language & Input>Language-Set to Hindi.
5. Relaunch Science Journal app home page.
6. Observe the localized value for month/year category for all experiments
   (both current and previous years)

Note: Remove English from language settings.

Expected Result
Month and year value for any experiment should display actual value [Ex: December 2018] and should not be "month/year"
("महीना/ साल")

Actual Result
In Hindi, Experiments created in previous year have"महीना/ साल" ("month/year") as category value instead of actual month/year value.
[Ex: Experiments in month/year -December 2018 are displayed as "महीना/ साल" ("month/year" in English) when device language is Hindi]

Such a generic library will be useful for creating graphs and recording data .

I work for a K-12 STEM education nonprofit (www.sciencebuddies.org) that is incorporating the Science Journal app into a bunch of our projects. I've noticed two things that I think would make the acceleration feature more accessible for younger kids:

• An option to measure linear acceleration instead of proper acceleration (i.e. the gravity vector is automatically subtracted out, so the phone will read 0m/s^2 in the vertical direction when it is at rest instead of during free fall). This makes it consistent with how kids learn about acceleration at the K-12 level (rate of change of velocity) and spares us from explaining anything about relativity.
• Automatically calculate and display the magnitude of the acceleration vector, not just the individual components. This lets you monitor it in real time instead of needing to export to Excel and do the calculation yourself.

Combined, both these features would make it much easier to do projects where you can't easily control the orientation of the phone (for example, attaching the phone to your body as you walk around).

I have noticed on several occasions when recording data for a long period of time (a few minutes) that there are gaps in the data. It initially seems to correlate to my screen's timeout but the recording will flicker on and off after that, without me touching the phone at all. Here are a couple screenshots from the X-accelerometer when the phone is just sitting on my desk for a few minutes

It records for about 1 minute (the noisy part of the graph) until the screen times out, but then it flickers on intermittently after that (the graphs show the gap in data points between 2:15.5 and 3:14.6).

Is the intention that the app will only record while the screen is on? Or is it always supposed to keep recording until you hit stop?

Hello there! Small issue here. Unable to build and run the project as it is.
Nothing else to add here. It is probably low priority but still an issue.

screencapture.zip

Would it be possible to add different autoscale options? Here is a simple example (as you know I'm heavily into bio): imagine you want to record the tremor on somebody's hand which are tiny changes of the acceleration. Then suddenly the person moves the hand a bit then the signal goes through the roof (see video above where I held the Attys first still and then shook it violently and then kept it still again). The same problem is with ECG or other biosignals which are tiny. A fridge next door might cause a massive spike so that the ECG trace would vanish for the remainder of the experiment. It would be great if you could add a "reset" button for the autoscaling or perhaps a gentle re-scaling towards the initial scales at a timescale of a couple of seconds and/or the width of the plotwindow. I guess you'd want to have such functionality at a minimum and transparent to the user.
As a more local fix (and leave it to the external developers) I'd be happy if just the observer class had an optional argument where the scaling could be controlled and then the external device could either leave it to ScienceJournal or could take care of the scaling by itself. For example an ECG will always be about 1mV so no need to scale or an EEG at 100uV.

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?

Seems so that start observers is called at the very start when ScienceJournal starts and then only later the scan Sensors.
The way I do it that ScanSensors first checks if the bluetooth dev is paired, then populates behaviour etc.
The in startObserving I use the bluetooth dev which I've found in ScanSensors. That fails because scanSensors hasn't been called.
When I press "retry" then that works because then the ScanSensors has been executed.
I can avoid this by moving the bluetooth detection also in the observer and do it at least once but that feels not right. What's the best approach of doing it? I'm pretty sure that before the update last week that order was the other way around.

From line 210:
https://github.com/glasgowneuro/AttysPlot/blob/master/app/src/main/java/tech/glasgowneuro/www/attysplot/Attys2ScienceJournal.java

Log (starting program, then fails, then I press retry and then it works):
`10-18 00:42:10.008 565-841/tech.glasgowneuro.www.attysplot D/Attys2ScienceJournal: Start observing on sensorID:7
10-18 00:42:10.008 565-841/tech.glasgowneuro.www.attysplot D/Attys2ScienceJournal: Finding paired attys
10-18 00:42:10.010 565-613/tech.glasgowneuro.www.attysplot D/Attys2ScienceJournal: Start observing on sensorID:6
10-18 00:42:10.010 565-613/tech.glasgowneuro.www.attysplot D/Attys2ScienceJournal: Finding paired attys
10-18 00:42:10.012 565-841/tech.glasgowneuro.www.attysplot D/Attys2ScienceJournal: Found an Attys as a paired device
10-18 00:42:10.013 565-613/tech.glasgowneuro.www.attysplot D/Attys2ScienceJournal: Found an Attys as a paired device
10-18 00:42:10.015 565-4265/tech.glasgowneuro.www.attysplot V/AttysComm: Got rfComm socket!
10-18 00:42:10.114 565-4264/tech.glasgowneuro.www.attysplot W/BluetoothAdapter: getBluetoothService() called with no BluetoothManagerCallback
10-18 00:42:10.115 565-4265/tech.glasgowneuro.www.attysplot W/BluetoothAdapter: getBluetoothService() called with no BluetoothManagerCallback
10-18 00:42:10.387 565-4264/tech.glasgowneuro.www.attysplot W/BluetoothAdapter: getBluetoothService() called with no BluetoothManagerCallback
10-18 00:42:10.455 565-4265/tech.glasgowneuro.www.attysplot D/Attys2ScienceJournal: Retrying to connect
10-18 00:42:10.555 565-4265/tech.glasgowneuro.www.attysplot W/BluetoothAdapter: getBluetoothService() called with no BluetoothManagerCallback
10-18 00:42:10.828 565-4264/tech.glasgowneuro.www.attysplot W/BluetoothAdapter: getBluetoothService() called with no BluetoothManagerCallback
10-18 00:42:10.830 565-4264/tech.glasgowneuro.www.attysplot D/AttysComm: Could not establish connection to Attys: read failed, socket might closed or timeout, read ret: -1
10-18 00:42:10.833 565-4264/tech.glasgowneuro.www.attysplot E/AttysComm: Could not get streams
                                                                         java.io.IOException: java.io.IOException: read failed, socket might closed or timeout, read ret: -1
                                                                             at tech.glasgowneuro.www.attysplot.AttysComm.connectToAttys(AttysComm.java:577)
                                                                             at tech.glasgowneuro.www.attysplot.AttysComm.run(AttysComm.java:803)
                                                                          Caused by: java.io.IOException: read failed, socket might closed or timeout, read ret: -1
                                                                             at android.bluetooth.BluetoothSocket.readAll(BluetoothSocket.java:684)
                                                                             at android.bluetooth.BluetoothSocket.waitSocketSignal(BluetoothSocket.java:643)
                                                                             at android.bluetooth.BluetoothSocket.connect(BluetoothSocket.java:377)
                                                                             at tech.glasgowneuro.www.attysplot.AttysComm.connectToAttys(AttysComm.java:559)
                                                                             at tech.glasgowneuro.www.attysplot.AttysComm.run(AttysComm.java:803) 
10-18 00:42:10.889 565-4265/tech.glasgowneuro.www.attysplot D/AttysComm: Last resort: we try the hidden API
10-18 00:42:10.990 565-4265/tech.glasgowneuro.www.attysplot W/BluetoothAdapter: getBluetoothService() called with no BluetoothManagerCallback
10-18 00:42:10.993 565-4265/tech.glasgowneuro.www.attysplot D/AttysComm: Could not establish connection to Attys: read failed, socket might closed or timeout, read ret: -1
10-18 00:42:10.993 565-4265/tech.glasgowneuro.www.attysplot E/AttysComm: Could not get streams
                                                                         java.io.IOException: java.io.IOException: read failed, socket might closed or timeout, read ret: -1
                                                                             at tech.glasgowneuro.www.attysplot.AttysComm.connectToAttys(AttysComm.java:577)
                                                                             at tech.glasgowneuro.www.attysplot.AttysComm.run(AttysComm.java:803)
                                                                          Caused by: java.io.IOException: read failed, socket might closed or timeout, read ret: -1
                                                                             at android.bluetooth.BluetoothSocket.readAll(BluetoothSocket.java:684)
                                                                             at android.bluetooth.BluetoothSocket.waitSocketSignal(BluetoothSocket.java:643)
                                                                             at android.bluetooth.BluetoothSocket.connect(BluetoothSocket.java:377)
                                                                             at tech.glasgowneuro.www.attysplot.AttysComm.connectToAttys(AttysComm.java:559)
                                                                             at tech.glasgowneuro.www.attysplot.AttysComm.run(AttysComm.java:803) 
10-18 00:42:17.564 565-612/tech.glasgowneuro.www.attysplot D/Attys2ScienceJournal: Keep connection alive.
10-18 00:42:17.584 565-841/tech.glasgowneuro.www.attysplot D/Attys2ScienceJournal: Start observing on sensorID:6
10-18 00:42:19.569 565-613/tech.glasgowneuro.www.attysplot D/Attys2ScienceJournal: shutting down sensor 7.
10-18 00:42:19.569 565-613/tech.glasgowneuro.www.attysplot D/Attys2ScienceJournal: Keep connection alive.
10-18 00:42:19.590 565-661/tech.glasgowneuro.www.attysplot D/Attys2ScienceJournal: Start observing on sensorID:7
`

As mentioned in #4, being able to crop a run would be very useful when the data of interest actually happens after the recording starts or before it ends. This is on the team's roadmap.