06-24-2024, 09:14 AM
Hello there,
I want to ask about some best practices for shifting buffer content.
My current implementation of such a buffer shift is a combination of append and subrange modules, is a little lengthy, and consumes probably too much power during the experiment.
The append module seems to add buffer values each time it is being executed, which would be more often than the (location) sensor delivers new data (approx. at 1 Hz); interestingly the append module seems to be slower that the linear acceleration sensor (approx. 208.9 Hz on my device).
To avoid an ever growing buffer (due to appending all the time) a subrange module needs to cut off the buffer in the frequency of new sensor data.
Buffer shift could be used for several things:
In the attached example the lat buffer (size 0) is being counted and the third most recent position (size 1) is taken (subtract/subrange modules).
Then there is the append/subrange combination which feeds in their output as input for each other.
From what I understand currently this crossed reverse input would correspond to a sub-cycle resolution in the implementation which does not seem to be supported by the visual editor. This only works when I put these two module manually in the XML file in the correct order (subrange ahead of append). Yep, it might be that this technique will not work on each mobile device, but on mine it does.
The if condition is just to only output data if at least 3 GPS fixes are there and I have a set of 3 points to work on.
The subrange module then is to cut off the first buffer element which is an artifact by the append/subrange combination before.
If I'm not wrong some shift buffer module could do the job more easily. Such a module could have two inputs, the original buffer and the number of positions the original buffer should be shifted (+/-). It just might be like the append buffer with settings in which the position shift could be configured.
Or it might be just some shifting in the function module, where the (1st) input buffer is being refeneces as [1_], isn't it?
Some shifting could be configured as [1_(-1)] when using buffer [1] in the formular.
I outlined this just for giving these example and a better understanding of my intention.
Since I'm a new user of phyphox there is a lot I do not know, of course.
Maybe you already have something I could use for shifting buffers. Any idea welcome.
Thanks and kind regards, Trikes.
I want to ask about some best practices for shifting buffer content.
My current implementation of such a buffer shift is a combination of append and subrange modules, is a little lengthy, and consumes probably too much power during the experiment.
The append module seems to add buffer values each time it is being executed, which would be more often than the (location) sensor delivers new data (approx. at 1 Hz); interestingly the append module seems to be slower that the linear acceleration sensor (approx. 208.9 Hz on my device).
To avoid an ever growing buffer (due to appending all the time) a subrange module needs to cut off the buffer in the frequency of new sensor data.
Buffer shift could be used for several things:
- general usage is to construct buffers based on different sensors and based on own calculations in a way that they fit to each other for being displayed during the experiment and at the same time when exporting them (same buffer length which corresponding data at the same position for later reuse in OpenOffice or QGIS, for example), actually the export is the most important reason for juggling with the data this way
- based on 3 GPS points (6 horizontal coordinates) my experiment calculates UTM coordinates and then the curvature radius for these 3 points and the lateral acceleration, for the overall calculation I use the append/subrange buffer build technique 15 times, yep, the mobile phone is getting warm during the experiment
- to clock data from one sensor with the new data frequency of another sensor (currently I try to synchronize linear acceleration data with location data, which in principle works, but I don't see yet in an easy way some correlation between my additionally calculated data and the measured acceleration data, some puzzle piece still missing)
- minor usage example: on my Android devices the location sensor sensor seems to start right away with a location even when before the firt GPS fix, I cut off this 0th location (this situation has been discussed within this thread)
In the attached example the lat buffer (size 0) is being counted and the third most recent position (size 1) is taken (subtract/subrange modules).
Then there is the append/subrange combination which feeds in their output as input for each other.
From what I understand currently this crossed reverse input would correspond to a sub-cycle resolution in the implementation which does not seem to be supported by the visual editor. This only works when I put these two module manually in the XML file in the correct order (subrange ahead of append). Yep, it might be that this technique will not work on each mobile device, but on mine it does.
The if condition is just to only output data if at least 3 GPS fixes are there and I have a set of 3 points to work on.
The subrange module then is to cut off the first buffer element which is an artifact by the append/subrange combination before.
If I'm not wrong some shift buffer module could do the job more easily. Such a module could have two inputs, the original buffer and the number of positions the original buffer should be shifted (+/-). It just might be like the append buffer with settings in which the position shift could be configured.
Or it might be just some shifting in the function module, where the (1st) input buffer is being refeneces as [1_], isn't it?
Some shifting could be configured as [1_(-1)] when using buffer [1] in the formular.
I outlined this just for giving these example and a better understanding of my intention.
Since I'm a new user of phyphox there is a lot I do not know, of course.
Maybe you already have something I could use for shifting buffers. Any idea welcome.
Thanks and kind regards, Trikes.