I am playing with the network connection and trying to send data to a web page using a custom phyphox experiment. If I understand correctly the wiki (https://phyphox.org/wiki/index.php/Network_Connections), there are only two ways to trigger such a connection:
- using the "interval" property of the <connection> block
- using the "trigger" property of a view button
I would like to send a data only once, after a given amount of time, and I would like to avoid using a button. The way I do it now is that I set the interval property at the proper time:
The experiment is programmed to stopped after 5 seconds (via the "timedRun" and timedRunStopDelay" properties of the analysis block), so the experiment uses the connection twice : one at 0s, one at ~ 4.6 s. The first connection is unwanted, and I plan to disregard it on web side (either via php or python script), but is there a better way of programming the phyphox experiment? Ideally I would like to be able to trigger a connection at a given time, using the <timer> analysis module.
Also, on a side note, each time my phyphox experiment sends a data to my server, the data are received, but a message "Could not parse JSON" appears on my smartphone. I haven't investigate this yet (in fact it helps me by clearly tagging each connection), so it may be a simple problem with my server. I plan to look at it, but if this is a well known problem, I wouldn't mind any pointers.
No, there is no better solution at the moment. I would suggest to use the analysis blocks to add metadata to your data submission so you can easily recognize the submission that should be discarded (you could for example submit the result from the timer-block).
The could not parse JSON probably occurs because phyphox tries to parse the result to be written back to the buffers. You can either set the conversion attribute to conversion="none" to discard any response or let your server give a meaningful response that you can show to the user. For example you can respond with {"result": 1}, write it to a phyphox buffer and map different codes to different messages like "submission received" in a view element using its "map" node.
thank you for your reply, it is quite clear I think. I guess I will send a buffer "discard", which I will put to 0 or 1 depending on the value needs to be kept or not.
OK for the JSON parsing, I haven't looked at what to send back to the smartphone yet, your answer gives me ideas.
I am still working on sending a data only once, after a delay. The solution so far is too ignore empty data on the server side, which allows me to ignore the data sent at the beggining of the program (the buffer that will be sent is init as empty and I wait for some cycles of analysis to be done before calculating its value).
I used the TimeRuned option in the analysis block to stop the experiment after 5s, and the network connection block is configured to send data each 4.9s.
So far so good: it works for the first run. But then I wanted to be able to hit the play button again without clearing the data (the bin icone). I decided to play with the clear="true" attribute from the <send></send> block. My idea was to clear the buffer after the data has been sent to the network, at the end of a 5s run, so that at the beggining of the next 5s run the buffer would be empty, and the connection to the network ignored by the server.
this long introduction to come to this point: when I tried to clear the data (<send id="data" type="buffer" clear="true">time</send>), it seems that the data was cleared before being send to the network: my server only receive empty data, never any actual data.
I was never able to send any data with the attribute clear set to true. Am I missing something?
I post below a minimum example displaying the problem: two data are sent to a network, one with the clear attribute set to true (timer1), the other set to false (timer2). Timer1 always arrives empty on the server, whereas timer2 arrives with a value (in this example, 2 connections are made, one at the beggining of the analyse, the other at the end, both with the same result.) Note that if you want to test this program on your server, you need to enter the correct address.
Thank you in advance for any help,
Cheers,
Fred
PS: I think I could go around this problem by detecting if the pause button has been hit and manually emptying the buffer, but I would like to understand. By the way, is there an easy way to detect if the pause button has been hit ? I can do it by measuring the time elapsed between two analyses cycles, but it is a bit cumbersome ...
The pause button is indeed not represented in the analysis logic. Since the analysis block is not executed while the experiment is paused (not entirely - it is still used to create a preview), it never occured to me that it is relevant, but knowing that it is the first analysis *after* a pause makes a lot of sense.
In any case, without knowing the exact experiment, I would recomment not to use the play/pause button for this, but use a button that triggers the submission. You can use multiple buttons to start/stop the measurement and the timer to control if the data is ready for submission. Then use labels to instruct the user and inform if enought data has been collected. (For example have a look at how the sensor db experiment does this (https://github.com/phyphox/phyphox-exper...db.phyphox)). Unfortunately, this also does not prevent empty submissions, but these only occur if the user presses "submit" too soon and should be easy to filter at the server side. You probably want to filter there anyway, because there could be a whole lot of things that delay measurements (depends on the sensor that is used) and a simple stop delay may not be a "safe" solution.
Another idea (again without knowing the experiment) would be a continuous measurement. The experiment keeps and analyzes the last 5 seconds and immediately submits the result when the user presses a submit button. This of course depends on the experiment.
As to why your version only works once: Not sure, this indeed looks like a bug. I have to test this. Did you try it on Android or iOS?
Ok, I think I found a bug that affects clear for http connections. The buffers are passed by reference and cleared immediately, which usually occurs before the buffers are actually transmitted. A classic. I will fix it for the next version.
Thank you for looking at my problem Jens. It does not answer my questions, unfortunately. If I understand correctly, the blutooth output is executed after each analysis cycle. Dominiks solution is to ensure that the buffer that is supposed to be sent by bluettoth is always empty, except when he wants it to be sent. Hence the play with the button and the flag buffer.
I am playing with the network connexion, and it is executed only at certain moments, based on the time. So Dominik solution would not work as it is.
Just to be clear, I have a program that works (maybe I should have begun with this). My solution to check for the restart cycle is to compare the time between two analysis cylcles, and if the elapsed time is larger than the arbitrary value of 0.5 s, it means that this is the first cycle after a pause (the experiment has been restarted - I am using timed run experiments). When I detect that the experiment is restarted, I just empty the buffer that is sent through the network connexion, and an empty data is sent. On the server side, I just ignore empty data. I find this solution a bit messy, and I was wondering if the clear=true attribute in the <network><connection><send> block could help me to write a better program. When I begun to play with this attribure, I found what I believe is a bug: when the clear=true attribute is added, no data is ever sent (or rather, only empty datas are sent - see the example of my first message).
Actually, I have two questions I guess :
- is the clear=true attribute of the send block in the network connexion working properly? I have the impression that it is not, but I would like a confirmation.
- is there an easy way to detect a restart of an experiment? I am currently comparing the value of the timer between each analysis cycle, and it works, but it is not elegant.
If someone wants to play a bit, I attach to this message a program that sends a single data trough the network after 5s, and that supports a restart of the experiment. The address of the network connexion is blank and should be adapted to your server.
Thank you,
Fred
----
Ah, I did not see that Sebastian jumped in, my reply does not take in account his messages, sorry. I will read them now.
(02-07-2023, 05:34 PM)Sebastian Staacks Wrote: In any case, without knowing the exact experiment, I would recomment not to use the play/pause button for this, but use a button that triggers the submission.
thank you for your answer, Sebastian.
OK, so the clear attribute is indeed not behaving nicely, that is fine, I will wait for the next version. I was just wondering if I was missing something.
Using a button to trigger the submission, and having the network aknowledging the data are things I plan to work on, it seems very promising indeed! However, for this precise usage, I do not want to do so. Some context: I plan to use such experiments in front of an non-scientist audience that will have little knowledge of phyphox. I want to simplify as much as possible the manipulation. This is why I want to use a TimedRun experiment : the users press play, and it runs for 5s, and then it stops. If I want to do another experiment, the users press play again, and that is all. I do have an experiment that does what i need, I was just wondering whether a more elegant solution exists... From what you say, I guess that for the moment, my ugly time calculation is the only way. That is fine, it works!
Thank you again, I may come back with more questions,
10-17-2023, 04:40 PM (This post was last modified: 10-17-2023, 04:45 PM by fbouquet.)
Hello,
I am still playing with the server, and I hit a behavior which I think is not intentional from phyphox....
I used the program that is posted above. This program defines a run time experiment of 5 seconds, starting after a delay of 2 seconds. The web connection is defined with an interval of 4.9 seconds. So a data is sent at t=0 and at t=4.9. The first one is empty and is disregard by the server. So far so good, this is the situation that was discussed above.
I had some strange behaviors when I run twice the experiment consecutively: Instead of 2 data, I had 3! If I wait a bit before starting the experiment again, then I only received the expected 2 data on the server.
The program sends to the server not only the data (which is emptied after being sent) but also the time (which is not). Here are the value of the times for one of my tests:
[ [0], [4.9110000000000005], [0], [1.540000000000001], [4.923]]
The [0] and the [4.9] values are expected, the [1.5] one is surprising. My hypothesis is that this 1.5s data is the third connexion from the first run, happening during the second run. (I guess I needed 1.4 s to hit the run button after the end of the first run, then there was a 2 seconds delay, then the experiment ran for 1.5 second and we are about 4.9 seconds later than the previous connexion from the first run. This extra connexion happening after the end of an experiment, but only if a new experiment is running looks like and unwanted feature...
I think I will be able to get rid of it by adding additional tests, but maybe it could be fixed in phyphox?
If you have some new thoughts on how to send only one data after a given time, I am interested!
Took me a while, but I think I have found the issue in the code: The next scheduled submission is not removed from the queue when the experiment is paused, but scheduling the next submission is suppressed when paused. So, I think that whenever you pause the experiment, one more submission at the next 4.9s interval always happens. If you pause long enough it happens while the experiment is still paused and you won't notice an unexpected value as submissions start again as expected when pressing start, but if you paused short enough, a submission is done immediately on start, a new submission is scheduled for 4.9s and the old scheduled submission (which should have been cancelled) happens somewhere inbetween.
Should be an easy fix which I will put into our upcoming bugfix release (once the chaos of the new semester has calmed down a bit). Do you need a test version of the fix quickly?
