Strange problem with decimal places

[amindervirdee]

Hello,

I am using this example code with my Revolution board, and I have verified that all my sensors and outputs work.

However, I have a very strange problem that occurs where the data randomly changes between int and float, which is making doing anything else with the data quite difficult.

This is what I mean:

[[1.400e+01 1.000e+00 1.000e+00 1.000e+00 0.000e+00 0.000e+00 0.000e+00 0.000e+00 0.000e+00 0.000e+00 2.900e+01] [1.500e+01 1.000e+00 1.000e+00 1.000e+00 0.000e+00 0.000e+00 0.000e+00 0.000e+00 0.000e+00 0.000e+00 2.900e+01] [0.000e+00 1.000e+00 1.000e+00 1.000e+00 0.000e+00 0.000e+00 1.600e+02 0.000e+00 0.000e+00 0.000e+00 2.900e+01] [1.000e+00 1.000e+00 1.000e+00 1.000e+00 0.000e+00 0.000e+00 1.022e+03 0.000e+00 0.000e+00 0.000e+00 2.900e+01] [2.000e+00 1.000e+00 1.000e+00 1.000e+00 0.000e+00 0.000e+00 1.022e+03 0.000e+00 0.000e+00 0.000e+00 2.900e+01] [3.000e+00 1.000e+00 1.000e+00 1.000e+00 0.000e+00 0.000e+00 0.000e+00 0.000e+00 0.000e+00 0.000e+00 2.900e+01] [4.000e+00 1.000e+00 1.000e+00 1.000e+00 0.000e+00 0.000e+00 4.710e+02 0.000e+00 0.000e+00 0.000e+00 2.800e+01] [5.000e+00 1.000e+00 1.000e+00 1.000e+00 0.000e+00 0.000e+00 6.880e+02 0.000e+00 0.000e+00 0.000e+00 2.800e+01] [6.000e+00 1.000e+00 1.000e+00 1.000e+00 0.000e+00 0.000e+00 3.870e+02 0.000e+00 0.000e+00 0.000e+00 2.800e+01] [7.000e+00 1.000e+00 1.000e+00 1.000e+00 0.000e+00 0.000e+00 8.420e+02 0.000e+00 0.000e+00 0.000e+00 2.800e+01]] [[ 8. 1. 1. 1. 0. 0. 908. 0. 0. 0. 28.] [ 9. 1. 1. 1. 0. 0. 0. 0. 0. 0. 28.] [ 10. 1. 1. 1. 0. 0. 75. 0. 0. 0. 28.] [ 11. 1. 1. 1. 0. 0. 551. 0. 0. 0. 28.] [ 12. 1. 1. 1. 0. 0. 519. 0. 0. 0. 28.] [ 13. 1. 1. 1. 0. 0. 504. 0. 0. 0. 28.] [ 14. 1. 1. 1. 0. 0. 617. 0. 0. 0. 28.] [ 15. 1. 1. 1. 0. 0. 499. 0. 0. 0. 28.] [ 0. 1. 1. 1. 0. 0. 388. 0. 0. 0. 28.] [ 1. 1. 1. 1. 0. 0. 601. 0. 0. 0. 28.]] [[ 2. 1. 1. 1. 0. 0. 554. 0. 0. 0. 28.] [ 3. 1. 1. 1. 0. 0. 500. 0. 0. 0. 28.] [ 4. 1. 1. 1. 0. 0. 639. 0. 0. 0. 28.] [ 5. 1. 1. 1. 0. 0. 442. 0. 0. 0. 28.] [ 6. 1. 1. 1. 0. 0. 462. 0. 0. 0. 28.] [ 7. 1. 1. 1. 0. 0. 431. 0. 0. 0. 28.] [ 8. 1. 1. 1. 0. 0. 470. 0. 0. 0. 28.] [ 9. 1. 1. 1. 0. 0. 363. 0. 0. 0. 28.] [ 10. 1. 1. 1. 0. 0. 630. 0. 0. 0. 28.] [ 11. 1. 1. 1. 0. 238. 493. 0. 0. 0. 28.]] [[ 12. 1. 1. 1. 0. 461. 428. 0. 0. 0. 29.] [ 13. 1. 1. 1. 0. 583. 358. 0. 0. 0. 29.] [ 14. 1. 1. 1. 0. 761. 262. 0. 0. 0. 29.] [ 15. 1. 1. 1. 0. 797. 226. 0. 0. 0. 29.] [ 0. 1. 1. 1. 0. 686. 199. 0. 0. 0. 29.] [ 1. 1. 1. 1. 0. 800. 142. 0. 0. 0. 29.] [ 2. 1. 1. 1. 0. 872. 175. 0. 0. 0. 29.] [ 3. 1. 1. 1. 0. 872. 243. 0. 0. 0. 29.] [ 4. 1. 1. 1. 0. 846. 248. 0. 0. 0. 29.] [ 5. 1. 1. 1. 0. 792. 228. 0. 0. 0. 29.]]

[GRamosPlux]

Dear @amindervirdee,

Thank you very much for creating this thread and for the presented detailed example regarding the identified issue. We did a small update in the code, in order to ensure that the values read from the device will be automatically converted to integers.

This should ensure the uniformity of the output data format.

However, I will carefully wait for your feedback to understand if you are still facing problems!

[amindervirdee]

Hi Again

I updated the library but still having the same issue.

Additionally, some of the sensors are picking up quite erratic and non-realistic measurements? especially ECG and EDA - Is this an issue with the sensors provided or something within the code?

Thanks!

[GRamosPlux]

Dear @amindervirdee,

Thank you very much for your most recent comment/feedback! I am sad for understanding that the previous correction was not effective in solving the identified problem.

This is a quite strange behaviour, but, we are always ready to face a tricky challenge :-)

In order to fully replicate the problem, I will kindly request you some further information's:

1. Which is the Python version that you are currently using?
2. Will it be possible for you to share the script where the problem is happening?

Regarding the erratic values, the API returns RAW data values (integers generated by the Analog to Digital Converter | ADC), so, for BITalino typically we will obtain values between 0 and 1023 (2^resolution - 1 = 2^10 - 1 = 1023).

However, taking into consideration that these values don't present a direct physical meaning, while analysing the results it is advisable to convert them through the available transfer function for the sensor being used.

Each sensor has a datasheet with the correspondent transfer function, which you will be able to access at https://bitalino.com/en/learn/documentation

For the particular cases of EDA and ECG: https://bitalino.com/datasheets/REVOLUTION_EDA_Sensor_Datasheet.pdf#page=2 | https://bitalino.com/datasheets/REVOLUTION_ECG_Sensor_Datasheet.pdf#page=2

Are you obtaining values outside the normal range?

I will carefully wait for your kind feedback ;-)

[amindervirdee]

Hello. I am using Python 3.7.6, and the script am using is the Python example code on this page.

As far as utilising these transfer functions, is there any example of them being applied in code, Python or otherwise?

It's not that I am receiving values outside the normal range, it's just that the sensor data presents erratically - fluctuating randomly between the high and low parts of the range.

[GRamosPlux]

Dear @amindervirdee,

I am grateful for this clarification, it will be helpful in our try to fully replicate all experimental conditions. I suppose that you are using a classic Bluetooth board, am I right?

Regarding the transfer functions, in fact there are some examples of application in Python:

• EDA | https://biosignalsplux.com/notebooks/Categories/Pre-Process/unit_conversion_eda_rev.php
• ECG | https://biosignalsplux.com/notebooks/Categories/Pre-Process/unit_conversion_ecg_rev.php

The previous links are dedicated to apply the transfer functions of biosignalsplux ECG and EDA sensors (which are not exactly identical to BITalino), however, the steps that should be followed in Python are exactly the same.

Saturation is an undesirable situation, which could be caused by a malfunctioning of the sensor or by a problem in the reference/ground definition.

Despite not impossible, the first option seems less probable, considering that both sensors are presenting the same behaviour. So, following the "reference/ground" clue, for the specific case of ECG, are you using a 3-lead cable (https://plux.info/cables/226-3-lead-electrode-cable.html)?

Meanwhile, I will start the procedures to replicate the identified error in your experimental conditions!

[GRamosPlux]

Dear @amindervirdee,

Since our last communication I have positive news regarding the original question!

I was able to replicate the problem, it is probably related with the import statement. Unfortunately I forgot to mention an important point when I wrote the first reply, reason why I need to apologize about the additional time that you spent trying to solve the problem.

In the README.md of the GitHub repository, the 2nd Installation step request the installation of BITalino API through pip

However, the last update (https://github.com/BITalinoWorld/revolution-python-api/commit/4e67908be73497e589b0a7d92d421213e5a75c34) was only applied to the GitHub repository, so, you should locate the site-packages folder of your Python installation (as demonstrated on the followin animation) and replace the bitalino.py file for the one available in the GitHub repository (https://github.com/BITalinoWorld/revolution-python-api/blob/master/bitalino.py).

Locating site-packages

I believe that this will solve the problem :-D