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
#21
(03-21-2022, 09:25 PM)Jens Noritzsch Wrote: There are two threads on MatLab in this forum: https://phyphox.org/forums/showthread.php?tid=716 and https://phyphox.org/forums/showthread.php?tid=796 – and a search text field at the top… Wink

You could also find some examples on the net, for instance, at https://uk.mathworks.com/matlabcentral/f...?q=phyphox

Thanks for your answer.
Reply
#22
(11-06-2021, 08:40 PM)Romaxx Wrote:
(11-05-2021, 01:59 AM)Sebastian Staacks Wrote: I have tracked the problem down to an unexpected (if not buggy) behavior of requests: It form-encodes the pipe "|" no matter how you pass it to get(). The docs (https://docs.python-requests.org/en/mast...t-requests) specifically say that it should not encode it if you pass the url or the parameters as a string, but it still does so and phyphox at the other end does not decode the form encoding (why should it - it's not an endpoint for a HTML form and it still is a valid HTTP request).

So, after searching for ways to circumvent this problem, I ended up using urllib3 instead and this seems to work:
Code:
#MIDI configuration
M_OUTPUT = "Midi Through:Midi Through Port-0 14:0"
M_CHANNEL = 0
M_CONTROLS = [1, 2, 3, 4] #You can send on different CC channels
# M_CONTROLS = [70]

#phyphox configuration
PP_ADDRESS = "http://192.168.2.194:8080"
PP_CHANNELS = ["accX", "accY", "accZ", "acc_time"] #If using different CC channels, define multiple phyphox buffers
# PP_CHANNELS = ["accY"]

from urllib.request import urlopen
import json
import time
import numpy

value_temp = 0

time_update = 0
count = 0
while True:
    if count == 0:
        PP_CHANNELS_def = ["acc_time=full","accX=full","accY=full","accZ=full"]
    else:
        PP_CHANNELS_def = ["acc_time=" + str(time_update), "accX=" + str(time_update) + "|acc_time","accY=" + str(time_update) + "|acc_time","accZ=" + str(time_update) + "|acc_time"] #If using different CC channels, define multiple phyphox buffers

    url = PP_ADDRESS + "/get?" + "&".join(PP_CHANNELS_def)

    response = urlopen(url).read()
    data = json.loads(response)

    time.sleep(0.04)
    count = count + 1
    time_update = count * 0.04;

    # Uncomment to send pitch bend
    time_value = numpy.array(data["buffer"]["acc_time"]["buffer"])
    value_x = numpy.array(data["buffer"]["accX"]["buffer"])
    value_y = numpy.array(data["buffer"]["accY"]["buffer"])
    value_z = numpy.array(data["buffer"]["accZ"]["buffer"])

However, there is one other thing you probably want to change: You should not use "time_update" in your request, but the latest value you received in data["buffer"]["acc_time"]["buffer"] in your previous request (so, the last value in "time_value"). Otherwise, your time_update will eventually get out of sync with phyphox (well, it will probably start out of sync as you cannot start the script and the measurement at exactly the same time) and you will either get duplicates (imagine your time_update is 10 seconds behind and phyphox will send you everything from the last 10 seconds every time) or miss values (imagine it is a few milliseconds ahead and requests before a data point with that timestamp exists). The whole point of this function is to tell phyphox which is the last value you received, so it can send you anything after that.

Thanks for your answer.

I did not try it so far, but I will (probably tomorrow).

Edit: I now tested your code and it works as expected. Thanks for this!!!

But, can you tell me what you think about my first Question in my last post, the one with the link?

Thanks again!

I tried to get access to the Audio Data via the Audio Scope Experiment.

I identified the variable name for the buffer "Rate". (https://github.com/phyphox/phyphox-exper...pe.phyphox)

But I failed to adapt the code for this case because there is no "Rate_Time" to access the data like before.

I only found some output called "subtime0", but this variable I can not access or find in the buffer.

How can I access the audio data in a similar manner as above (streaming).

Thanks.
Reply
#23
Code:
<audio>
  <output>recording</output>
  <output component="rate">rate</output>
</audio>

The audio data is in the buffer “recording”. In contrast to other sensors, audio data has no time stamp associated to it. That's why phyphox goes to some length in the analysis block to create some time buffer.

Code:
<graph label="Audio Data" labelX="Time" unitX="[[unit_short_milli_second]]" labelY="Amplitude" unitY="[[unit_short_arbitrary_unit]]" scaleMinY="extend" scaleMaxY="extend">
  <input axis="x">subtime0</input>
  <input axis="y">subdata</input>
</graph>

Hm… our remote access indeed plots “subdata” against “subtime0”.
Reply
#24
(03-29-2022, 05:36 PM)Jens Noritzsch Wrote:
Code:
<audio>
  <output>recording</output>
  <output component="rate">rate</output>
</audio>

The audio data is in the buffer “recording”. In contrast to other sensors, audio data has no time stamp associated to it. That's why phyphox goes to some length in the analysis block to create some time buffer.

Code:
<graph label="Audio Data" labelX="Time" unitX="[[unit_short_milli_second]]" labelY="Amplitude" unitY="[[unit_short_arbitrary_unit]]" scaleMinY="extend" scaleMaxY="extend">
  <input axis="x">subtime0</input>
  <input axis="y">subdata</input>
</graph>

Hm… our remote access indeed plots “subdata” against “subtime0”.

The python code depends on some time buffer, so that I know, which data points I already "downloaded".

How is the buffer "recording" accessable in a real-time sense then?
Reply
#25
There is (perhaps) no way for this experiment. You need to setup your own if you would like to have a continuous audio stream – and create your own time stamps then. Note, however, that this easily gets out of hand at 48kHz…
Reply


Forum Jump: