06-30-2024, 02:55 PM
The new editor should not limit you. In fact, the goal was to actually represent the phyphox file format as it is to avoid having limitations that we got when designing the old editor.
The underlying XML format is definitely linear, with just a sequence of "analysis modules" in the "analysis" tag that are executed in sequence. If no delay is set, the entire sequence is executed as fast as the phone can handle, but limited to a maximum of 100 times per second. So, when handling different data sources at different rates (even more so for sensor with arbitrary intervals like many light sensors or GPS with bad reception), you have to decide on a strategy to handle this. For slow data, retaining the latest state in a buffer might be a good option, while in other cases interpolation might be required. For fast data, the analysis sequence needs to be able to handle multiple values per "loop".
The approach of the old editor was that by default all data just accumulates in the first buffers and is recalculated for each analysis sequence. Not very efficient, but it would spare beginners the need to think about managing new and old data. But, yes, it is not really a good solution.
About the state of the new editor:
We are currently giving students the task to test it almost weekly and are still finding some issues. But it will be in public beta soon.
The new editor omits all attributes that match the default values in phyphox. "size" should default to 1, so your lat_count should be fine. Is there any other difference that might be the reason for the problem?
The underlying XML format is definitely linear, with just a sequence of "analysis modules" in the "analysis" tag that are executed in sequence. If no delay is set, the entire sequence is executed as fast as the phone can handle, but limited to a maximum of 100 times per second. So, when handling different data sources at different rates (even more so for sensor with arbitrary intervals like many light sensors or GPS with bad reception), you have to decide on a strategy to handle this. For slow data, retaining the latest state in a buffer might be a good option, while in other cases interpolation might be required. For fast data, the analysis sequence needs to be able to handle multiple values per "loop".
The approach of the old editor was that by default all data just accumulates in the first buffers and is recalculated for each analysis sequence. Not very efficient, but it would spare beginners the need to think about managing new and old data. But, yes, it is not really a good solution.
About the state of the new editor:
We are currently giving students the task to test it almost weekly and are still finding some issues. But it will be in public beta soon.
The new editor omits all attributes that match the default values in phyphox. "size" should default to 1, so your lat_count should be fine. Is there any other difference that might be the reason for the problem?