search

googlearchive / science-journal

Use the sensors in your mobile devices to perform science experiments. Science doesn’t just happen in the classroom or lab—tools like Science Journal let you see how the world works with just your phone.
https://sciencejournal.withgoogle.com/
Apache License 2.0
509 stars 131 forks source link

Delivered samples are constant in subsequent datapoints in ChartView #11

Open berndporr opened 8 years ago

berndporr commented 8 years ago

@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. sine 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.

dsaff commented 8 years ago

There's code in place to create repeat values if a sensor's refresh rate is too low; I'm concerned that that's somehow getting applied in the wrong place. Will take a look.

berndporr commented 8 years ago

Thanks! Sampling rate is 125Hz as before.

dsaff commented 8 years ago

Bernd,

I just pushed some code to the master branch that should help some. It looks like we may need some additional engineering before we can handle data at that rate.

berndporr commented 8 years ago

Thanks! I've seen you've made the path creation a bit less frequent. Still quite choppy at 125Hz. Would be great if you could make it work at that sampling rate. Happy to help/debug from here.

dsaff commented 7 years ago

[Note to self: internal bug b/33239073]

berndporr commented 6 years ago

sj Not sure if you guys have worked on it but I've bought yesterday a tablet running Nougat 7.1.1 (Lenovo TB-850F) and that plots the data super smoothly at Atty's 125Hz sampling rate. See screenshot.

dsaff commented 6 years ago

We have been making small improvements where we can, but I still think we can do even better. Great to hear that the progress we have made is showing up!