i tried to upload the basic example "Create Experiment.ino" inot ESP32-C3-MINI-1
when i try to connect to the device i receive this error message:
Bluetooth experiment error
The transmitted experiment data is
corrupted ( could not write descriptor)
with other version of ESP32 ( e.g. S3) everithing works fine.
any idea ?
When does the error message show up: on loading the experiment or after starting it, while receiving data?
What specific board are you using?
Ok, the error message should only show up on loading an experiment (and on Android)…
Have you tried connecting the experiment loaded from an S3 to the C3, i.e. load the experiment from the S3 and store it in the menu, then reopen it, however, select the C3 in the list? If any, what error message do you receive?
(04-08-2025, 02:37 PM)Jens Noriʇzsɔɥ Wrote: [ -> ]Ok, the error message should only show up on loading an experiment (and on Android)…
Have you tried connecting the experiment loaded from an S3 to the C3, i.e. load the experiment from the S3 and store it in the menu, then reopen it, however, select the C3 in the list? If any, what error message do you receive?
If i load the experiment from S3 and save in the menu, then i can connect C3 without problems, but we are working on boards based on C3 and i wanted to figure out why it is not possible to download directly from C3. We are building some physycs equipments that can be connected to phyphox out of the box. C3 version of board is more compact.
Weird. This error message is only triggered if the BLE module on the microcontroller is not running smoothly or if the connection is lost at a very specific moment. I wonder if the load while transferring the file is higher than sending data…
- Is there any chance that you could try an iDevice or a Mac with Apple Silicon in order to check if these also fail?
- Could you test it with more than one C3-MINI? We once had a DevKit shipment that got broken BLE modules…
- Do you observe data loss compared to the S3 if you use the S3 experiment? (Also try to increase the rate and check if this also leads to problems with the C3.)
I check back with our hardware expert if he has any additional idea what could go wrong or how you could “optimise” BLE reception. Unfortunately, we do not have any of these here to test ourselves.
(05-20-2025, 06:32 PM)Jens Noriʇzsɔɥ Wrote: [ -> ]Weird. This error message is only triggered if the BLE module on the microcontroller is not running smoothly or if the connection is lost at a very specific moment. I wonder if the load while transferring the file is higher than sending data…
- Is there any chance that you could try an iDevice or a Mac with Apple Silicon in order to check if these also fail?
- Could you test it with more than one C3-MINI? We once had a DevKit shipment that got broken BLE modules…
- Do you observe data loss compared to the S3 if you use the S3 experiment? (Also try to increase the rate and check if this also leads to problems with the C3.)
I check back with our hardware expert if he has any additional idea what could go wrong or how you could “optimise” BLE reception. Unfortunately, we do not have any of these he
I tried with iPad, now i ask my collegue to try with iphone. I have 5 custom devices and 2 dev kits i'll try to repeat test with all of them.
( we are a small company in Italy and we produce physics experiments, we made a smart Wilberforce Pendulum, actually it interacts with other software smoothly but the idea that everyone could make a basic data acquisiton with Phyphox it looked interesting for us)
At moment we have a S3 controlled IMU and a C3 controlled IMU. The only difference was related to board size because with C3 we can fit everithing in a smaller area.
I'll try to check the 3 points you suggested and eventually come back. Thanks for your support.
Brief update from our side: comparing the specs of ESP32-C3-MINI-1 vs. ESP32-S3-MINI-1, the single-core processor, the lower clock, and less SRAM might be issues. The BLE server typically runs on the second core and transferring the experiment might be too demanding.
Our library code certainly has some space for improvements, particularly for the ESP32, however we currently lack the resources for such a refactoring. There could be some quick fix though, so let's wait for you coming back…
At moment i not a big issue for us, we will use the S3 version.
A similar issue has been raised on GitHub,
https://github.com/phyphox/phyphox-arduino/issues/8, and you could find a proposed fix there. Could you verify if it also works in your case? We need to investigate a bit if it might break something else before we can release it…