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.

Device for experimental physics teachers
I am currently working on a device meant for teachers who would like to use Phyphox to teach experimental physics. Currently, the main difficulties in using Phyphox for physics teachers are the availability of all sensors in their students’ smartphones and the need not to endanger them (for instance with a free fal experiment). For this purpose, TI’s SensorTag was quite efficient but it was impossible to add new sensors and it was discontinued. Thanks to the new Arduino library, I am trying to create a robust, open-source, low-cost and out-of-the-box SensorTag-like device. The main goal is to make it very easy to use for teachers who cannot program. To do so, I am using the Arduino nano sense 33 BLE and the new phyphox Bluetooth low energy library. I am new to BLE, so I may need some help…
My first step is to create an Arduino program which allows the Phyphox app to choose which sensors of the microcontroller should be used, so that students can switch between several experiments without having to upload a new program to the Arduino card. You can find it attached, but I am not fully satisfied as I would have preferred to use the <config> part of the phyphox file, instead of the <output> part, but I could not make it work on the Arduino side. Do you think it is possible?
In addition, it seems that I cannot receive data at a frequency higher than 50Hz, which is a problem for some experiments, such as a free fall measurement. Is it a physical limitation due to the BLE, or do you think this frequency could be improved?

Thank you!

Attached Files
.phyphox   accelerometer_plot.phyphox (Size: 3.83 KB / Downloads: 524)
.phyphox   pressure_plot.phyphox (Size: 2.55 KB / Downloads: 496)
.txt   test_choice.txt (Size: 728 bytes / Downloads: 466)
Hey Gautier,

your code looks quite good so far. To write your configuration data once after a connection is established you just have to replace the "input" tag on the bluetooth output to "config".
Furthermore you should add an "id" to both bluetooth blocks. If the bluetooth in- and output have the same id phyphox knows that they belong to one device.
Unfortunately I cannot test my changes until tomorrow. So if its not working out of the box I might messed something up here.

EDIT: Well I messed something up and figured out that something is not working as intended. Right now it looks like phyphox is not writing the container value to the caracteristic... In the version below i did not write the value of the container "choice" but wrote a value directly to the arduino. This should fulfill your desired purpose and adds another point on my todo-list Sad . 

The data transmision rate is little complex topic. If you are interested in some of the details I can recommend this article:

My practical experience: I was able to get up to 100Hz with a pixel 2 and Arduino Nano 33 BLE (my Smartphone was closeley to the Arduino). This rate is also not very reliable due to package loss etc. A rate of 50Hz is much more stable and thus usable for experiments. I have to admit my data rate test was without our library some months ago. I should test this again with our library, there might be some room for improvement on the library side.

You should also consider the data rate of the pressure sensor. The pressure sensor for example is one of the "slower" sensor with a maximum rate of 75Hz

Some currently possible workaraounds are:
- buffer your data with timestamps on the arduino and send them afterwards
- get up to 5 float values and send them at ones, you have to rearrange them with phyphox before visualization


Attached Files
.phyphox   pressure_plot_Dominik.phyphox (Size: 2.5 KB / Downloads: 482)
Hello Dominik,

Thank you for the example, it is now working as I expected!
The article was also very interesting. My goal is to reach a better frequency for the accelerometer and the gyroscope. 50Hz is clearly enough for the barometer. I am working on your workarounds and I will let you know when my program is giving satisfying results.

Trying to follow Dominik's idea of sending multiple data at a time, I would need to check the exact action of phyphox "first" instruction.

the Arduino nano is sending 5 consecutive data in the same BLE message, the phyphox experiment stores them in 5 different output buffers (containers) CH1, CH2, CH3, CH4, CH5.

I now need to fill a new data container buffer "acc" with the data in order from CH1, CH2, .... Here is what I think should work if I understood correctly the wiki:

<input clear="true">CH1</input>
<output clear="false">acc</output>

<input clear="true">CH2</input>
<output clear="false">acc</output>

<input clear="true">CH3</input>
<output clear="false">acc</output>

<input clear="true">CH4</input>
<output clear="false">acc</output>

<input clear="true">CH5</input>
<output clear="false">acc</output>


I supposed that the instruction "first" takes the first data of the container, clears it (creating a shift in the following data of the container), and add it to the output buffer. Is this correct?

Dealing with the time is going to take a few tinkering, we are thinking of using one or two of the five slots to add timestamps to the data.

Thank you for your help (files are attached for your curiosity),



Attached Files
.phyphox   accelerometer_fast_plot_v01.phyphox (Size: 4.95 KB / Downloads: 496)
.txt   test_choice_acceleration.programme-Arduino.txt (Size: 3.31 KB / Downloads: 497)
OK, we made some tests, and we would welcome some inputs since the BLE is a strange beast… To recap, our goal is to make the arduino nano 33 sense BLE a standalone sensor platform, equivalent to the TI SensorTag. We want to be able to send the data of the accelerometer as fast as possible.

Following Domink’s advices, we tested two solutions:
- A nano program that sends to phyphox via BLE the accelerometer data ax, ay, az and a time-stamps each time a data is available (“one-data packets”) ;
- A nano program that measures the acceleration amplitude four times, and then send these four data plus a time-stamps to phyphox via BLE (“four-data packets”).
For these two tests, the data were also sent to the PC via USB serial.

The following graphs show the results. On the first graph we plot the number of data sent (written on the BLE server), the number of data received when using the one-data packets program and the four-data packets program. The second graph is a zoom of the same graph. The third graph represents de difference of time between two consecutive data packets, for both programs.

We can see that:
- The data sent through the serial port follow the speed of the sensor installed on the nano, 116 Hz, in both programs. All the available accelerometer data are written on the BLE server.
- When working with the one-data packets program, the rate of data reaching phyphox is about 58Hz instead of 116Hz. When working with the four-data packets program, the rate is 82 Hz. In both cases some data are lost.
- Not directly relevant but intriguing, when one zoom on the one-data packets program, one can see that the data are grouped by four. We have no explanation for this…
- Looking at the time difference between two consecutive packets in the one-data packets program,  a strange behavior appears: it favors 8-9 ms delays (corresponding to 116HZ, no loss of packets), 26ms delays (about 38Hz, two packets containing each one data have been lost) and 69 ms delays (about 14Hz, eight packets containing each one data have been lost). We cannot explain why these values are favored.
- Looking at the time difference between two consecutive packets in the four-data packets program,  a more understandable behavior is observed: either the delay is 34 ms (29Hz = 116/4, each packets containing four data, no data lost), or the double 69ms delay (14Hz, one packet of data containing four data has been lost). When one data packet is lost, the next one is caught.

Not being expert on BLE, we wonder whether these behaviors are normal and to be expected? If some Bluetooth experts have some insights on what is going on and how to improve the situation, they would be very welcomed!

Our personal conclusion is that it is important that the nano adds a time-stamps with the data it sends, and that reaching the 116Hz is not going to be possible as it stands. The choice between one-data and four-data packets will depend on whether you want to favor speed (four-data packets) or having the direction of the acceleration (one-data packets).


Fred and Gautier

Attached Files Thumbnail(s)
Hey everyone,

thanks for sharing this observations!

Your "first"-approach could work but i see there some problems which might cause the data loss. Im not sure but i think the analysis loop is running independent from the incomming bluetooth data. This means it could be possible that you get 2 new values into CH1 container while your analysis is currently running. At the beginning of the next analysis run phyphox will take the first value and clear the second one.
You could proof this with sending continuous data, so first value = 1 second value = 2 and so on. If for example value 3 & 4 will be received at roughly the same time during a analysis loop your routine  should take value = 3 and clear value = 4.

Another approach would be using the append function. With this you could append multiple values to your "allData" container.

The 4-data-package observation looks like you are using an iPhone ;-) Bluetooth Low Energy is able to send more than 1 data packet per connection interval. The number of packages is limited to 4 by iOS and to 6 by Android. Since your already at the maximum of packages per connection interval I assume that you are limited due to the connection interval. (This is just a rough summary, more details can be found in the already mentioned article : )

To play around with the connection parameters I implemented a feature to set these values within the phyphox library. You can find this version here:

You might should uninstall the official version of the phyphox library first! Afterwards you can download my version as zip and add it via "sketch" - "add library" - "add Zip Library". I also added the example "connectionParameter" where i decreased the connection interval.
In general you have to set a min and max connection interval value. For me it looks like phyphox always choses the max value (right now i dont know if its possible to change this behaviour). 
You can check the actualy used connection interval with the android app "nrf connect". For me it looks like the iOS version does not have this feautre.. but maybe i just couldnt find it.

Hello Dominik !

Frédéric will check later that the "first" approach is working well, but we are fairly confident.
However, we were not using an iPhone to make these measurements. All of them were made on Fred's Android phone.

Thank you for the new feature! It was very helpful and everything is now working perfectly. By lowering the maxConInterval to 6 and using our 4-data-package, we managed to reach 115Hz, which is the Nano Sense's accelerometer frequency! Do you think it will soon be released in a stable version of the library?
We will share our programs after we finish cleaning them up.

Quote:However, we were not using an iPhone to make these measurements. All of them were made on Fred's Android phone.

mh ok, I though the limitation of packets per event was due to iOS, now I wonder why Android is not using 6 packages per event. 

Quote:we managed to reach 115Hz, which is the Nano Sense's accelerometer frequency!

115Hz is the default sample rate. The IMU is able to go up to 952Hz ;-) It looks like all configuration are more or less hardcoded in the official Arduino Library for the LSM9DS1. See here in line 72-76:

Might be worth it to add some more features to this library to adjust the rate/accuracy to the specific experiment!

Quote:Do you think it will soon be released in a stable version of the library?

The "problem" is that we would like to provide a library which works the same (as far as possible)  on different platforms. This means i have to add this feature first to the ESP32 / Arduino IoT. I dont know yet if this is easy to add there aswell. On the otherside I dont think it is bad at all if we release such small features one after another. Anyway I will discuss this with Sebastian!

Thank you, we didn't know that the IMU could work so quickly. 115Hz is enough for the moment, but we'll think about it later if needed.

We hope that you will be able to add this feature to the library! In case it isn't possible, do you think this feature could be directly implemented in our program ? So any user would be able to use the official version of your library.

We are now trying to make the builtin LED display a different pattern when a smartphone is connected to the Arduino board and when nothing is connected, but I have not found a way to get this information. Is it currently possible with the phyphoxBLE library ?

Thank you!

Forum Jump: