following video, not working

[mburnskaurin]

I am following the video, but only doing v calculation in m/s for simplicity.  When I spin the phone, graph basically is nothing.

   

---

phone is moto g6 play, running android 8.0.0

[Jens Noriʇzsɔɥ]

(Now I am unsure if my recommendation on keep="true" fell onto my feet… )

The mix of keep="true" and append="true" does not work here. If you keep the entire data for the gyroscope y axis, you should overwrite the velocity container on each analysis run, i.e. append="false" (it's the default). If the data gets appended, you simply will not see it in the graphs as there are far less time stamps for the quadratically growing velocity container. By the way, you could observe in the graph how often the analysis block is run from the –sort of– “periodicity”.

This approach (the same as in the standard “roll” experiment) is repeating quite some multiplication work, however, the amount of data is low so you should not ever observe an effect.

[Jens Noriʇzsɔɥ]

The reason that it works in the video is that the gyroscope y axis buffer is cleared in the second operation. So, you could alternatively use keep="false" on the y container in your reduced example.

[Jens Noriʇzsɔɥ]

JFYI, the example in the tutorial happens to trigger an exotic bug in the iOS version of phyphox, causing problems for the v_kmh graph. Simply swap the last two factors for its calulation (y and 3.6) to work around the problem. This will be fixed in the next iOS release. (Sebastian added this information to the editor “welcome page”.)

[mburnskaurin]

(Now I am unsure if my recommendation on keep="true" fell onto my feet… )

The mix of keep="true" and append="true" does not work here. If you keep the entire data for the gyroscope y axis, you should overwrite the velocity container on each analysis run, i.e. append="false" (it's the default). If the data gets appended, you simply will not see it in the graphs as there are far less time stamps for the quadratically growing velocity container. By the way, you could observe in the graph how often the analysis block is run from the –sort of– “periodicity”.

This approach (the same as in the standard “roll” experiment) is repeating quite some multiplication work, however, the amount of data is low so you should not ever observe an effect.

Okay, I thought that I was following the video.  To be blunt, the usage of "keep" and "append" does not make sense to me--is there a document that describes how these things work in practice?

So, I should use keep true, append false for the calculated linear velocity?

[Jens Noriʇzsɔɥ]

You have been correctly following the video, however, leaving out a part that –unfortunately– is required to make it work.  (there are pros and cons for covering keep and append in a introductory video and we keep an eye on it how “well” it works in its current form)

The full technical details on the phyphox file format are in our wiki, https://phyphox.org/wiki/index.php/Phyphox_file_format, and Analysis modules in general covers the attributes “keep” and “append”.

The concept of containers in phyphox differs from classic variables in programming languages. They are closer to a pipe system, i.e., by default the data flows as input into a module and the container is empty afterwards. There are circumstances that it is convenient that the data is retained for later modules. That‘s what the keep attribute is for.

If we keep the picture of pipes, then data flowing as output out of a module comprises just this data, i.e., the (empty) container is freshly filled. Again, there are circumstances that is is convenient to add the data to that of previous modules or analysis block runs. That‘s what the append attribute is for.

I hope that this clears it up a bit. Making this easier to understand is on our list for quite a while and we hoped that the different names for the attributes helped. There used to be a clear attribute for data in and out flows, however, that proved even more confusing…

[Jens Noriʇzsɔɥ]

… and to answer your last question: keep/true on all input and append/false on output works, however, it is a bit of waste of resources.

An alternative for your reduced example would be to use keep/false on gyro input and append/true on output.

Computing v_kmh is still possible then: just multiply v_ms (you need keep/true here ) with 3.6 and append it to v_kmh.

[mburnskaurin]

Thank you for the response, I will try it out both ways.

tbh, it is confusing that you suggest two completely opposite alternatives.

[Jens Noriʇzsɔɥ]

Yeah, I perhaps should not have done that. It's my original suggestion (taken from the standard roll experiment) opposing the video – I can't get out of the story now (hm, does this phrase make sense in English?)…

Particularly in such a simple example you have the options. If you extend it, you will quickly learn when an approach has unintended (side) effects.

[mburnskaurin]

… and to answer your last question: keep/true on all input and append/false on output works, however, it is a bit of waste of resources.

An alternative for your reduced example would be to use keep/false on gyro input and append/true on output.

Computing v_kmh is still possible then: just multiply v_ms (you need keep/true here ) with 3.6 and append it to v_kmh.

Success with keep/false for gryro input, append/true for the calculated quantity, *and* keep/true for radius.