03-05-2020, 12:04 PM
(This post was last modified: 03-05-2020, 12:07 PM by Sebastian Staacks.)
Nice work. I am always happy to see when users successfully use our editor as it is not always that easy.
I would say that smoothing is quite the opposite of a higher data rate. Well, this may depend on what data you are getting and what you want to achieve. My first thought about smoothing was getting rid of noise in the recorded data, which could be achieved by using the "gausssmooth" module (make sure that it does not change any absolute values that you might need) or by implementing an actual low pass using two Fourier transforms. But it seems like you have the problem of getting to few data points and therefore only having a rather "rough" approximation of the sine function? If so, you want some interpolation. Not sure if this really would help because when recording sine functions at too low sampling rates, you get a tendency to "miss" the maxima and interpolation cannot easily reconstruct these.
The best thing of course would be if you can increase the data rate of the Calliope, but that is something at the Calliope-end of the problem.
In any case, an interpolation module would be nice in phyphox and I have added it to my todo list.
Your setup of the buffers and clearing is a bit unusual. In the XML file you can see the buffer sizes in the "data-containers" block and the clear-attributes for each module in the analysis-block. In the editor you can see these options when clicking on a connecting line (which you have probably noticed as you seem to have changed these settings). What is happening at the moment is the following:
The entire analysis section is run periodically as fast as possible. Every time a new value from the Calliope arrives, it is written to the buffers "Ax_mg", "Ay_mg" and "Az_mg" and the time is written to "t". Then in each analysis run, the value from "Ax_mg" etc. is used by the formula modules you have set up and then appended to the buffers "Ax", "Ay", "Az" and "A_abs". Those have a size of 1000, so after 1000 values, the oldest values are dropped and the data starts shifting to the left. However, your "t" buffer has the size 0, which means that it is infinite. It receives new values and grows ever larger. But as it is plotted against "Ax" etc. you will only see its first 1000 (old) data points as it only has 1000 matching points in the other buffer.
Unfortunately, you can not simply set the size of "t" to 1000 because of another problem. In fact, I think that you might notice that the behavior of the time axis is a bit off anyways. The problem is that the last value from the Calliope stays in the "Ax_mg" buffer for several runs of the analysis modules because you are not clearing anything. The Calliope delivers values at a much smaller rate than the rate of the analysis, so I would expect (again, not tested) that each value from the Calliope is fed multiple times through the formula modules and you will see something like a stair-case plot in your measurements. Even worse, I would expect that it does not really align with your time axis, because the "t" buffer only receives a new value when the Calliope sends one, so there should be fewer values in "t" than in "Ax" (until Ax is filled any you only see the latest values anyways).
This approach of using buffers of size 1 only works if the analysis process is slowed to run at a lower rate than the data input and only if you are ok with losing some data points.
Instead, I would recommend to set all buffers with direct input to a size of 0 (Ax_mg, Ay_mg and Az_mg) and let the formula modules delete the data every time it has been processed (set "clear at the input" for the connection from the Bluetooth input to the formula nodes). For the time buffer, you can either create a similar construction or directly set its size to 1000 to match the processed data.
Let me know if this works or if you need some more help on this.
If you are sure that your Calliope will not rotate during the measurement, simply subtract Earth's acceleration or the first value recorded if you are sure that the experiment starts without any acceleration. If your Calliope might rotate, however, it is much more complicated. Phyphox does not derive the linear acceleration itself but uses the linear acceleration directly provided by Android and iOS as it is optimized for each sensor. You will need to combine the data from the accelerometer and the gyroscope for this. The term you want to search for is "sensor fusion", but it will be tough to implement just in our editor.
Here are some notes from my site:
Yes, that is a bit of a problem there. An alternative might be looking for a specific service that is advertised by both of them, but I do not know if there is any.
Cannot say much about this. We mostly test the Micro:Bit, but we checked if the Calliope worked the same way a while ago. At that time I do not remember this problem, but that does not say much.
(03-03-2020, 10:23 PM)Jonathan Haug Wrote: Is it possible to "smooth" the graph, i.e. to set a higher rate of given datapoints?
I would say that smoothing is quite the opposite of a higher data rate. Well, this may depend on what data you are getting and what you want to achieve. My first thought about smoothing was getting rid of noise in the recorded data, which could be achieved by using the "gausssmooth" module (make sure that it does not change any absolute values that you might need) or by implementing an actual low pass using two Fourier transforms. But it seems like you have the problem of getting to few data points and therefore only having a rather "rough" approximation of the sine function? If so, you want some interpolation. Not sure if this really would help because when recording sine functions at too low sampling rates, you get a tendency to "miss" the maxima and interpolation cannot easily reconstruct these.
The best thing of course would be if you can increase the data rate of the Calliope, but that is something at the Calliope-end of the problem.
In any case, an interpolation module would be nice in phyphox and I have added it to my todo list.
(03-03-2020, 10:23 PM)Jonathan Haug Wrote: After filing the buffer, old data points are deleted (as expected) but the time line (x-Axis) does not keep in sync, it keeps staying static. Any ideas?
Your setup of the buffers and clearing is a bit unusual. In the XML file you can see the buffer sizes in the "data-containers" block and the clear-attributes for each module in the analysis-block. In the editor you can see these options when clicking on a connecting line (which you have probably noticed as you seem to have changed these settings). What is happening at the moment is the following:
The entire analysis section is run periodically as fast as possible. Every time a new value from the Calliope arrives, it is written to the buffers "Ax_mg", "Ay_mg" and "Az_mg" and the time is written to "t". Then in each analysis run, the value from "Ax_mg" etc. is used by the formula modules you have set up and then appended to the buffers "Ax", "Ay", "Az" and "A_abs". Those have a size of 1000, so after 1000 values, the oldest values are dropped and the data starts shifting to the left. However, your "t" buffer has the size 0, which means that it is infinite. It receives new values and grows ever larger. But as it is plotted against "Ax" etc. you will only see its first 1000 (old) data points as it only has 1000 matching points in the other buffer.
Unfortunately, you can not simply set the size of "t" to 1000 because of another problem. In fact, I think that you might notice that the behavior of the time axis is a bit off anyways. The problem is that the last value from the Calliope stays in the "Ax_mg" buffer for several runs of the analysis modules because you are not clearing anything. The Calliope delivers values at a much smaller rate than the rate of the analysis, so I would expect (again, not tested) that each value from the Calliope is fed multiple times through the formula modules and you will see something like a stair-case plot in your measurements. Even worse, I would expect that it does not really align with your time axis, because the "t" buffer only receives a new value when the Calliope sends one, so there should be fewer values in "t" than in "Ax" (until Ax is filled any you only see the latest values anyways).
This approach of using buffers of size 1 only works if the analysis process is slowed to run at a lower rate than the data input and only if you are ok with losing some data points.
Instead, I would recommend to set all buffers with direct input to a size of 0 (Ax_mg, Ay_mg and Az_mg) and let the formula modules delete the data every time it has been processed (set "clear at the input" for the connection from the Bluetooth input to the formula nodes). For the time buffer, you can either create a similar construction or directly set its size to 1000 to match the processed data.
Let me know if this works or if you need some more help on this.
(03-03-2020, 10:23 PM)Jonathan Haug Wrote: How would it be possible to get linear acceleration from a Calliope?
If you are sure that your Calliope will not rotate during the measurement, simply subtract Earth's acceleration or the first value recorded if you are sure that the experiment starts without any acceleration. If your Calliope might rotate, however, it is much more complicated. Phyphox does not derive the linear acceleration itself but uses the linear acceleration directly provided by Android and iOS as it is optimized for each sensor. You will need to combine the data from the accelerometer and the gyroscope for this. The term you want to search for is "sensor fusion", but it will be tough to implement just in our editor.
Here are some notes from my site:
(03-03-2020, 10:23 PM)Jonathan Haug Wrote: I gave the bluetooth input the somewhat weird name "mi" to let it find the Calliope MIni as well as the MIcro:bit.
Yes, that is a bit of a problem there. An alternative might be looking for a specific service that is advertised by both of them, but I do not know if there is any.
(03-03-2020, 10:23 PM)Jonathan Haug Wrote: I was only able to get results within phyphox after using the beta editor makecode.calliope.cc/beta for starting the bluetooth service on the Calliope. As I'm using phyphox on iPads in the class it would be easier to use the Calliope Mini App, which is currently (to my understanding) not possible. I will discuss this in the Calliope forum later.
Cannot say much about this. We mostly test the Micro:Bit, but we checked if the Calliope worked the same way a while ago. At that time I do not remember this problem, but that does not say much.