No data via XBUS on AR8020T about msrc

[dgatf]

Check that SDA(A4) and SCL(A5) are at correct pins (eg. not twisted)

Disable SIM_SENSORS. At least you should see 0 values in the transmitter
Disable I2C_T3_TEENSY, that's only for arm cortex boards

If still doesn't work, enable DEBUG and with a monitor at 19200bps, post the output

[dgatf]

Also check that you are connecting to XBUS port at the AR8020 and not to SRXL2

[LuHaGH]

All connections are OK, not twisted, the ports are right.
For debugging I have to disconnect the VCC from the TTL Porgrammer and the Serial RX Port from the ESC?
Then the only output in the /dev/ttyUSB0 window is "V800"

[dgatf]

Yes, but you can keep the ESC at RX. Only TX is needed for debug

Please download the latest code as I fixed some issues related to the esc and xbus

[LuHaGH]

Debugging is working. If I only connect the ESC and "#define SIM_RX" I got some usefull logs:
ESC-Log.txt

But at the XBus the only debug log entry is "V800".

I also tried another Arduino and the XBus at an AR6610T.

Maybe I have a misconfiguration in my config.h (.txt only for upload)
config.h.txt
or my Hardware.

The "first try" is laying at he desk with the soldered pins for debugging an cable to the ESC. The second one is connected to the AR8020T XBus Port without getting ESC telemetry configured in my DX9 (FW 2.08).

[LuHaGH]

I also tested with twisted white and yellow cable without success.

[dgatf]

The esc is being read correctly, but there is no signal from the receiver. Your config.h is ok. The wiring of the connected arduino is also ok
There is one think I don't understand. You shouldn't see V800 in debug unless you start at 115200 and change to 19200 bps
You could also post the issue at helifreak forum. User Oki188 has been testing over different receivers and sensors with success.

Just to confirm. With enabled DEBUG and disabled SIM_RX, do you see any 20 0 2 DE 9 20 0 E0 0 0 0 E7 0 0 0 0 ?

You can also try activating other sensores in config.h even if not connected and see iif it shows on the transmitter

[dgatf]

Check the telemetry config in the transmitter. You need to select ESC and not RPM or voltage separately. You can try with the auto config

Also you can flash the following sketch to check if the receiver is sending and telemetry request through the xbus port:

#include <Wire.h>

void i2c_request_handler()
{
  Serial.println(TWDR >> 1);
}

void setup() {
  Serial.begin(115200);
  Wire.begin(0xFF);
  Wire.onRequest(i2c_request_handler);
  TWAMR = 0xFF;
}

void loop() {
  // put your main code here, to run repeatedly:

}

[LuHaGH]

Just to confirm. With enabled DEBUG and disabled SIM_RX, do you see any 20 0 2 DE 9 20 0 E0 0 0 0 E7 0 0 0 0 ?

No, if I not enable SIM_RX I don't see anything in the log. And you are right, I only get the "V800" when I switch the Baud Rate.

I've flashed your testing sketch but I don't have any log entries after that, too.

Maybe the integrated barometer to provide altitude and vario telemetry of the AR8020T is the problem. The receivers Oki188 tested, are without internal sensors.

[dgatf]

The integrated barometer shouldn't be an issue, but not sure

For some reason the receiver is not sending any telemetry request or the arduino is not receiving those requests. Try adding pull up resistors (2k to 10k) to sda and scl lines (one for each line). Sometimes built in pull ups are not enough.

Which sensors have you enabled in the telemetry screen on the transmitter?

[dgatf]

Disconnect 3.3v líne from the receiver and feed the Arduino with 5v from any servo connector

[LuHaGH]

For some reason the receiver is not sending any telemetry request or the arduino is not receiving those requests. Try adding pull up resistors (2k to 10k) to sda and scl lines (one for each line). Sometimes built in pull ups are not enough.

I will try this on Sunday.

Which sensors have you enabled in the telemetry screen on the transmitter?

Up to now altitude, BEC Voltage and Flight Log. I've tried the autodetection, it found nothing new, so I enabled ESC, flight battery voltage and current manually.

Disconnect 3.3v líne from the receiver and feed the Arduino with 5v from any servo connector

There is no regulated 3.3V line at the XBus port. Only the sda and scl lines are pulled to 3.3V. The VCC line is at the same voltage as the servos, in my case 6.0V.

[LuHaGH]

I have a little success. If I power up the Arduino first with a dedicated LiPo and a few seconds later the AR8020T then the communication is starting.
But in "production use" I have no possibility to start the Arduino first and the AR8020T later.

Is there a possibility to speed up the booting of the Arduino?

[LuHaGH]

I used an old Arduino UNO as ISP (of course with loaded ArduinoISP) and flashed the Arduino Pro Mini without bootloader. So it is booting up fast enough to answer the sensor request form the AR8020T.

Is it normal, that I get the voltage from the main battery only after the first start of the motor and the RPM is not getting back to "0" after stopping it?

[dgatf]

You're right. Arduino was too slow answering the initial poll.

I've done the following modifications to improve this:

• Move i2c sensors to higher addresses (>0x70) as we're free to choose that. That's about 22ms*80 = 1.8 seconds. This alone should be enough
• Add a i2c clock stretch at the begining, so i2c stops until arduino is ready (hoping this happens before the first poll, but depends on the bootloader delay)

[dgatf]

Is it normal, that I get the voltage from the main battery only after the first start of the motor and the RPM is not getting back to "0" after stopping it?

No, voltage and rpm should be correct all the time. This may be related to the esc firmware, which is not updating those values all the time. Please post the DEBUG and DEBUG_HW4 together to verify

[LuHaGH]

Both ideas are not working.
First I restored the bootloader and flashed with TTL programmer. No ESC sensors found and no delay in the receiver.
Second I used the ISP again. With that installation the whole receiver is blocked about 5 seconds, even the ESC is giving a warning for "no signal" and I got no telemetry data too.

Maybe there is a reason for the forbidden clock stretching in the XBus documentation ;-)

I will restore the previous xbus.h and xbus.cpp and try to debug the HW4 tomorrow.

[dgatf]

I've removed the clock stretching... not sure if that was an issue. But indeed is recommended in the Xbus specs:

If your device will be slow to start, it is recommended that you first
select a higher address, and second that you use the stretched clock.

I keep the higher i2c addresses. That has to work. Could you please test it. You may need to run autdetection again

[KHeintz]

Do not use a bootloader together with XBUS. Otherwise the Arduino will not boot fast enough and will not be recognized by the XBUS.

[KHeintz]

A pitfall with Teensy can be in Arduion hardware/ teensy/avr/cores/ teensy3 / pins_teenys.c the anlog init need following change. AR8010T may otherwise have problems with the XBUS.

analog_init();
delay(5);
usb_init();
delay(5);

[LuHaGH]

I keep the higher i2c addresses. That has to work. Could you please test it. You may need to run autdetection again

Neither with autodetection nor with manual enabling ESC I got telemetry in my transmitter with the higher i2c addresses.

Why do you left the "delay(5000)" in the xbus.cpp line 102. I think you have removed the clock stretching?

This may be related to the esc firmware, which is not updating those values all the time. Please post the DEBUG and DEBUG_HW4 together to verify

You are right, only when the motor is is running the ESC is transferring data.
ESC-XBus.txt

I think we can close this issue, cause the solution is to program the arduino without bootloader.

[dgatf]

Damn, the delay is the mistake. Could you comment the delay and flash again. It really has to work with any I2C address

[LuHaGH]

Sorry, it's not working with commented "delay(5000)". You will have to revert to the previous state.

[dgatf]

Reverted to previous I2C addresses. Fixed