When using the I2C function with an address on the 0x50~0x57 range for thr Robotics TXT, RoboPro complains.
This message was intended at the RoboTX. However, it still appears on the Robotics TXT.
Is the message relevant for the Robotics TXT or should RoboPro be modified?
Robotics TXT - I²C Device Address Alert
Moderator: fischertechnik Mitarbeiter
Forumsregeln
Bitte beachte die Forumsregeln!
In dieser Unterkategorie können nur fischertechnik-Mitarbeiter und Moderatoren antworten!
Bitte beachte die Forumsregeln!
In dieser Unterkategorie können nur fischertechnik-Mitarbeiter und Moderatoren antworten!
-
- Beiträge: 171
- Registriert: 12 Jan 2016, 09:13
Re: Robotics TXT - I²C Device Address Alert
Dear Rei Vilo,
thanks for pointing out this issue in this forum. This issue is already known, and I am pretty sure that it was reported by you.
Best regards
Markus
thanks for pointing out this issue in this forum. This issue is already known, and I am pretty sure that it was reported by you.
Best regards
Markus
Re: Robotics TXT - I²C Device Address Alert
Indeed, but the message for 0x50 and 0x54 addresses is new!
-
- Beiträge: 171
- Registriert: 12 Jan 2016, 09:13
Re: Robotics TXT - I²C Device Address Alert
Dear Rei Vilo,
for the TX controller, these addresses have to be handled with care and the message is required. But I am not sure if these messages have to be shown for the TXT controller. I have to check that.
Best regards,
Markus
for the TX controller, these addresses have to be handled with care and the message is required. But I am not sure if these messages have to be shown for the TXT controller. I have to check that.
Best regards,
Markus
Re: Robotics TXT - I²C Device Address Alert
Dear Rei and Markus,
it is just a side issue:
There is still within RoboPro Bibliothek a I2C driver "I2C/Accelerometer-ADXL345" which used the forbidden Address 0x53. Rei you know the file very well.
I would propose either to remove the file or to change the Sensor address to the alternative one "0x1d" and to add a description "A resistor between VCC and SDO of ie. 1,5kOhm might be necessary for the alternative address".
My recommendation is to remove the file "Accelerometer-ADXL345" from RoboPro update, since the driver results are not really stable and the unit of the measurement data is not clear at least for me. So the file was misleading for me, I bought first this sensor since a driver from fischertechnik was available. I thought that this is running well since verifed by fischertechnik.
Finally I spend last year some time for improvement, i.e. a calibration sequence, change to +-2g / 4g / 8g and 16g etc. however the results are still behind the sensors on the market i.e. MPU6050 or BNO055, with the conclusion that I switched to other acceleration and gyro sensor with my own driver.
Regards
Christian
it is just a side issue:
There is still within RoboPro Bibliothek a I2C driver "I2C/Accelerometer-ADXL345" which used the forbidden Address 0x53. Rei you know the file very well.
I would propose either to remove the file or to change the Sensor address to the alternative one "0x1d" and to add a description "A resistor between VCC and SDO of ie. 1,5kOhm might be necessary for the alternative address".
My recommendation is to remove the file "Accelerometer-ADXL345" from RoboPro update, since the driver results are not really stable and the unit of the measurement data is not clear at least for me. So the file was misleading for me, I bought first this sensor since a driver from fischertechnik was available. I thought that this is running well since verifed by fischertechnik.
Finally I spend last year some time for improvement, i.e. a calibration sequence, change to +-2g / 4g / 8g and 16g etc. however the results are still behind the sensors on the market i.e. MPU6050 or BNO055, with the conclusion that I switched to other acceleration and gyro sensor with my own driver.
Regards
Christian
Re: Robotics TXT - I²C Device Address Alert
On the RoboTX controller, the 0x53 address was forbidden but actually usable for reading the values. I'm still waiting for an answer about the Robotics TXT.
As you rightly point out, the ADXL345 accelerometer is superseded by much better solutions.
For example, the MPU9250 and BNO055 pack three sensors, accelerometer + gyroscope + magnetometer, and a controller to calculate the quaternion and Euler angles. The MPU9250 needs to be programmed while the BNO055 is ready out of the box.
About adresses, a better solution would consist on an I²C address translator, like the LTC4317 from Linear Technology, the PCA9545A from Texas Instruments or the MAX7357 from Maxim, to name a few of the many available solutions.
As you rightly point out, the ADXL345 accelerometer is superseded by much better solutions.
For example, the MPU9250 and BNO055 pack three sensors, accelerometer + gyroscope + magnetometer, and a controller to calculate the quaternion and Euler angles. The MPU9250 needs to be programmed while the BNO055 is ready out of the box.
About adresses, a better solution would consist on an I²C address translator, like the LTC4317 from Linear Technology, the PCA9545A from Texas Instruments or the MAX7357 from Maxim, to name a few of the many available solutions.