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.

Real time data download
#6
(11-11-2018, 03:03 AM)jbshute Wrote: Here is another question though.... Using your specified method, what would you expect the amount of dropped data to be? I am looking for high frequency data transmission upwards of 100 hz on as many sensors as possible. Would I expect to have a perfect sampling rate if I query it as you suggested?

No, not with the method in the example, which just requests the latest value. But if you have a look at the documentation, you can add parameters to specify which part of the buffer you need:

Code:
/get?abc

Just returns the latest value of the buffer "abc".

Code:
/get?abc=full
Returns the whole buffer "abc" (similar to your export method).

Code:
/get?abc=42
Returns all values of the buffer "abc" starting from the first one that is larger than 42.

Code:
/get?abc=42|def
Returns all values of the buffer "abc" starting from the first value that is larger than 42 in the buffer "def".
The latter two only make sense if you have two buffers that represent value pairs and if one of them is monotonous. The typical example would be a buffer "time" for time data (which would be the monotonous one) and "value" with some random sensor data. If you already have the first 30 seconds of your measurement (or don't care about the older data), you could do the following request:

Code:
/get?time=30&value=30|time
This returns two arrays with all time entries larger than 30 (in this example in seconds) and all value entries at indices that match time values after 30s.
The reason that we do not directly request a specific index is that phyphox can also handle finite buffers (i.e. a queue) that only contain the last n values. New values push older ones to lower indices, so a client can not reliably keep track of these indices if finite buffers are used.
You might also want to have a look at our file format for the experiments in the app. This is how we (as well as teachers) deploy new experiments without updating the app. A good example of what our file format can achieve is our old christmas experiment: https://phyphox.org/xmas. With the upcoming version 1.1.0, new experiments can also simply be added with QR codes.
Reply


Messages In This Thread
Real time data download - by jbshute - 11-10-2018, 12:50 PM
RE: Real time data download - by jbshute - 11-10-2018, 02:08 PM
RE: Real time data download - by jbshute - 11-11-2018, 03:03 AM
RE: Real time data download - by jbshute - 11-11-2018, 01:25 AM
RE: Real time data download - by Sebastian Staacks - 11-11-2018, 10:45 AM
RE: Real time data download - by Romaxx - 10-28-2021, 09:40 AM
RE: Real time data download - by Romaxx - 10-28-2021, 01:11 PM
RE: Real time data download - by Romaxx - 11-04-2021, 05:40 PM
RE: Real time data download - by Romaxx - 11-06-2021, 08:40 PM
RE: Real time data download - by Romaxx - 03-26-2022, 11:37 PM
RE: Real time data download - by Romaxx - 11-08-2021, 08:57 PM
RE: Real time data download - by Romaxx - 03-19-2022, 09:23 PM
RE: Real time data download - by Romaxx - 03-22-2022, 08:15 PM
RE: Real time data download - by Romaxx - 03-29-2022, 09:13 PM

Forum Jump: