Bluetooth ESP32 Dev board and TBS Crossfire

[Pascal-m]

Hello, I can not operate the internal Bluetooth connection of the ESP32 Dev board with TBS crossfire. It seems to me that a little bit of code is missing to support the internal Bluetooth of the ESP32 Dev board. Thank you

[zs6buj]

Hi Pascal

I have a friend who is using Mav2PT bluetoorh successfully with TBS Crossfire. I will put him in touch with you.

[zs6buj]

Oops, I was thinking about a different project.

Ok, I can include the code for you.

[Pascal-m]

Great, thank you I am not a good coder but I managed to advance by adding it's a few lines : (I do not know if all are good but it gives a start of result ;-))

in AntTrack_v2.12.ino file

...

...

in Mavlink.ino file I corrected &F2Rmsg by &msg

Thanks

[zs6buj]

Pascal, you have identified many of the changes. Well done my friend.

I started doing the upgrade myself, and should finish tomorrow, but please go ahead and try it.

[Pascal-m]

ok, no worries, as you made the update I put them in place to try them. Thks

[zs6buj]

Pascal, could you try v2.13 please.

[Pascal-m]

Hello, 2.13 does not work with the blueetooth of the crossfire. you miss things in the AntTrack_v2.13.ino file to line 415 "Bluetooth Setup" it should look like that I think:

// ************************ Setup Bluetooth ***************************  
  #if (Target_Board ==  3) 
    #if (Telemetry_In == 1) // Bluetooth / Mavlink
      SerialBT.begin("AntTrack", true);
      bool bt_connected; //PM

      bt_connected = SerialBT.connect(BT_Slave_Name); 
      if(bt_connected) {
        Debug.println("Bluetooth connected!");
        OledPrintln("Bluetooth connected!");
    }

    #endif  
  #endif

There must be something else in the mavlink.ino file because I do not get mavlink frames :-( thks

_

For information I tried Mav2PT and the link works perfectly between the crossfire and the ESP32 Dev board, the decoding of mavlink frames are perfectly transcribed ;-)

_

[zs6buj]

Thanks for the feedback Pascal. I made a lot of changes and could not test Bluetooth at the time. I might have missed something. I'll check tomorrow morning.

[Pascal-m]

Yes i saw :-)

I think it misses the test of "Telemetry_In == 1" in "main_loop ()" ;-)

Thanks

[zs6buj]

Ok, done. Thank you Pascal, you are very helpful indeed!

I just updated 2.13 again to keep is simple.

You are far better at C++ than you implied, mon ami. :<)

[Pascal-m]

Ok I will test tonight. I think there is still a small error in the Mavlink.ino file in the void Mavlink_Receive () procedure there is a test "FC_Mavlink_IO == 1" instead of "Telemetry_In == 0" ;-) Thks

[zs6buj]

You mean (Telemetry_In == 1) :)

Ok, I did Find this time and I hope I have them all.

Thanks again.

[Pascal-m]

Exactly I made a mistake it's fine "Telemetry_In == 1" ;-)

[Pascal-m]

Good news :) Bluetooth is working now :) the crossfire communicates well I get the GPS position of my drone!

Now I have another problem the servo does not move :-( I uncommented the TestServos () procedure to test them but nothing happens. The signals are connected to"vn" and "vp" of the dev board and they are well fed in 5v by an external power supply. The mass is common with the dev board.

It's getting late I would look for a tomorrow night where the problem comes from. Thks

[macfly1202]

Congrats ! I will test this in next few days. thanks

[zs6buj]

Pascal, I'm travelling during the next two days. If you can get hold of an oscilloscope look at the pins. I'm not sure if those pins will work. It might be worth trying other pins. Look on the diagram for pwm pins.

[Pascal-m]

Eric, yes I have an oscilloscope, I'm going to watch that. thks

[Pascal-m]

Eric, Pin 36, 39 is input only. I made you a request github (this is my first contribution via github ;-) to replace them in 32, 33 I continue my tests ... Thks

[zs6buj]

Congratulations on first successfully merged PR. Thank you

[Pascal-m]

Hi Eric, I reworked on the project and it goes slowly :) The receipt of gps position with the bluetoopt is OK :) The status led (StatusLed) does not work and the tracking either. While searching I saw that the status update of the led was driven by ServiceTheStatusLed () which is called by CheckForTimeouts (). CheckForTimeouts () is not called! CheckForTimeouts () is commented in gps.ino I tried to de-comment but it does not change anything. Thanks

[zs6buj]

If I remember correctly, ServiceTheStatusLed() should be in the main loop also.

[zs6buj]

Pascal, I was thinking about this. Remember the tracking only starts when craft is more than minDist (4m) from home

[Pascal-m]

hi Eric, I keep on the project and I go step by step. I'm using a compass now (Heading_Source = 3) I think I found a little bug on the variable homSaved was never set to true. I reactivated it in the void AutoStoreHome () procedure. Now I have a persistent bug: my variable "ap_hdg" is always at 655.3 so I get a systematic error "Bad hdg! Cur.hdg = 655 hom.hdg = 68 Packet ignored". This variable should be between 0 and 359.99 ° this is never the case at home :-( I want help on this bug :) Thank you

[zs6buj]

Thank you once again Pascal! Your help has been invaluable.

Yep, I checked and it vanished between v2.08 and v2.09. Technology devil again :(

void AutoStoreHome() {
  homSaved = true;
  #ifdef Debug_Status
    Debug.println("homSaved=true");  
  #endif
  hom.lat = cur.lat;
  hom.lon = cur.lon;
  hom.alt = cur.alt;

Ok, when Heading_Source == 3, ap_hdg becomes redundant. We only need to use ap_heading when Heading_Source == 2, i.e, when the FC provides initial heading to orientate the tracker box. So I patched this for you in v2.14. :>)

655.3 looks like 0xFFFF = 65535 in a single byte, but I don't get why ap_hdg is corrupt. Maybe you are not using Mavlink and that is just random un-initialised junk in ram. I looked back on this issue thread and can't see the answer. We don't need ap_hdg anyway, but I would like to understand why.

Let me know. I appreciate your feedback.

[Pascal-m]

Hi Eric are ready for the goal but there are still things to fix. I join you my log in Debug All. log_20191211_2218.txt You can see that "ap_hdg" remains at 655.3 For the test as I have small garden I put minDist = 2 instead of 4 It is strange when I am connected to the pc with the serial monitor open I quickly get to catch "GPS lock good! Push set-home button anytime to start tracking." on the other hand disconnect from the PC it often blocks Heartbeat good. I said that I did not do extensive testing 2~3 with 2.14

Thank you

[zs6buj]

Hi Pascal

It is strange when I am connected to the pc with the serial monitor open I quickly get to catch "GPS lock good! Push set-home button anytime to start tracking." on the other hand disconnect from the PC it often blocks Heartbeat good.

So when your 'craft is outdoors, and your TBS and tracker indoors by the PC heartbeat is good and regular. When you take the TBS and tracker away from the PC to outdoors, then heartbeat falters sometimes? Do I understand correctly?

Remind me how you are powering the ESP32 in the tracker? How far away is the TBS from the tracker? Remember, BT uses the same 2.4GHz band as WiFi. Not sure if that matters here. Is your power regulator for the ESP32 switch mode? Some of the cheap ones emit a lot of RF noise.

ap_hdg" remains at 655.3

I wonder if TBS is truncating the Mavlink record. Or we are in the ESP32. hdg is the last field in the message.

[zs6buj]

It is interesting that cog (course over ground, which is the same as heading for a plane if there is no cross-wind) shows the same corruption.

Could you possibly post the TLog out of Mission Planner?

[zs6buj]

Stale