phyphox Forums

Full Version: Crash instead of remote control (1.1.7-beta2)
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Sad This summer I used the phyphox remote control via a web explorer (Firefox). Now when I tries to allow it from any phyphox application the program crashes (see the captured screen attached here). I got it at home and in my office in university where I have a small private Wi-Fi spot. Could it be some new security of Android came with an upgrade of the system?

phyphox version: 1.1.7-beta2
File format: 1.11

Android 8.1.0
Could you check if this also happens on the non-beta version? In this beta I introduced a new method to determine the IP address (and to hide the IP address of mobile data). I am suspecting that there is something in their that is not compatible to your device. (Maybe an Android 8 thing...)
Can I install the non-beta version in parallel to the existing one (beta)? And all my collection of the programmes...

Ooo! I got a star!

I will try to find somebody with Android and non-beta phyphox..
Never mind, I found the problem. Oh, man, such a rookie mistake...

Unfortunately, the only workaround is to have a mobile data connection. It should be enough to have the mobile data enabled while actually using Wifi, but turning off mobile data will definitely trigger my stupid mistake.

Also, no it is not possible to install two versions in parallel, so if you cannot enable mobile data you can only downgrade and possibly lose your collection (not sure, but I would not guarantee that you can keep it) or wait a few days until I have a new beta with a fix ready.
I have just published a new beta version (1.1.7-beta3) with the fix. It may take a moment before Google Servers have distributed it everywhere, but then you should be able to use the remote access again.
Hi,
thank you, beta3 is already installed and the remote control works again!
For the graph with 2 lines I observed an effect of a delay of one curve (gausssmooth - red) relatively to another (original - blue). When the recording is stopped the red curve jumps back to the blue one... (see figures). I will check this with other wi-fi connection.
Is this new in the beta version or was this happening before, too? And I understand correctly that this is only happening on the remote interface, i.e. the graphs are in sync in the app?
Yes, it is with beta3, the new version. Before I did not try. I repeated this in my office with the wi-fi source just near to me and with the faster connection there is no problem. For both cases there is no desynchronization on the smartphone. I think the problem is in the poor wi-fi connection with some pauses. A pause I understand but no desync between curves.
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.
Thank you, Sebastian.

I will try those corrections. My "only ay" from the other tread (you are right) is very fast that is rarely the case. Anyway, this was considered as a test program.

With best (Brest) regards
Mikhail