This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Crash instead of remote control (1.1.7-beta2)
#9
Is this the "only ay" experiment from the other thread (https://phyphox.org/forums/showthread.php?tid=1169)? If so, I think the problem is a slightly different one:

In the configuration you have set the "partialUpdate" to "true", which means that the remote interface does not request the entire plot every few milliseconds but uses the x axis to only request data that corresponds to larger x values than the current maximum on the x axis. As the x axis is time, it means that it only requests the newest values it has not yet received. However, if you stop the measurement it once re-requests the entire data set to be sure that it did not miss anything. That is why the graph becomes nice when you stop.

The reason that it is not nice before is because the data is requested before tha Gauß smooth has all the data. If you request the latest data point, then the Gauß smooth of the last points can only take into account data points to its left as the data points to the right do not yet exist. So, the smooth has a clear weight to the data points to the left and hence these points appear shifted to the left. But because "partialUpdate" is set to true, the web interface does not expect that these points will ever be updated and does not update them while in the app they get updated as new data points come in.

What I do not exactly understand is why it appeared better on a faster Wifi. You can see the effect of the slow wifi in your screenshot as the shifted graph has "steps" and looks a bit "jagged". The reason is that it takes a while to transfer the latest data points (especially on a slower wifi) and so you get the newest points in little block, in which the right-most datapoint is most affected by the problem and the left-most datapoint is almost correct as there are already newer datapoints present. As the next block again starts with an almost correct datapoint, they do not exactly match and you see a little step in your curve. However, I would expect these steps to be less pronounced on a fast Wifi but the shift to be more pronounced as it can always get the latest values which have not yet settled.

In any case, if my hypothesis is correct, there are three solutions:
- The easy one is to disable "partialUpdate". The downside is that the remote interface becomes slower the longer you measure, because it always trasnfers the entire curve for each update. But if it is still fast enough, it is a quick solution.
- The slightly more tedious solution is to only calculate the Gauß smooth for data points that have enough neighbors to their right. To do so, you can use a count module to count the number of data points, subtract 3*sigma (60, I think?) and then use "subrange" to get the data points which you can feed to the Gauß smooth. I would also recommend to use a subrange on the time axis as well, so the smoothed curve does not have the additional time stamps for which it has not been calculated yet and the remote interface can get the newer raw data while keeping track of the smoothed curved independently.
- The most performant option would be to only calculate the Gauß smooth for the newest values to also prevent the phone from slowing down on long measurements. That would involve retaining the already smoothed data, counting those and only subranging the data points that have not yet been smoothed (plus neighboring ones to not introduce the error again). This solution is the fastest, but it is quite a headache to implement because of the overlap of old and new data that you need to get a correct Gaußian.
Reply


Messages In This Thread
RE: Crash instead of remote control (1.1.7-beta2) - by Sebastian Staacks - 11-26-2020, 12:04 PM

Forum Jump: