-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Esp32 with Bluetooth telemetry #66
Comments
"Selected protocol is F.Port 2" Could you please select CRSF protocol in the config.h. If I remember correctly, it is 9 |
if change to CRSF there it is, only warnings: |
Unfortunately I'm travelling, and working from memory, but I suspect the BT option was only ever added for Frsky and Mavlink, not elrs/crsf. I need to look. Give me a few days and I'll take a look. |
ok, thanks |
I've added a generic BT version for CRSF, v 20.20.05 in the BETA folder, but I'm going to need some help testing it. Here where I am I have absolutely no boards or kit to test with! You must add your information here, in config.h lies 125
Also, when you must select Tools/Partition Scheme: "Minimal SPIFFS (1.9MB APP ...) in the Arduino IDE to make more space for the bluetooth code |
Ofcourse i will test it. So i have module HC-05 with password and im need also make some changes in AntTrack.ino:
and i notice problem when trying to connect with name - not working. I change to mac address:
with FrSky is connecting without problem, but when i change to this version with CRSF i got strange problem:
|
The assert warning is in one of the underlying c libraries. I would ignore it for now. The question is; why is the tracker Bluetooth failing to connect? It's not usually a source of problems. |
I found this link to the earning message. Very interesting. |
Ok i will test it, but need time. Today my son born :) |
Congratulations my friend! |
finally find little free time to test it. After move closer the warning not show. Also i found some bugs:
I get connection but nothing happen after this
|
Hello, I'm still travelling, but get back in about 10 days, and will look at this then. Thanks for the feedback. |
Hi, Now need make some test with GPS lock :) |
Hey, I'm back in the home office, and I can look at this today. Thanks for your work so far. I need to set up a test source of BT elrs/crsf telem. |
Cool :) i stop at this point and dont know whats wrong. |
My Kakute-h7 flight controller has BT, but it's flashed with APM and doesn't know what to do with it. I have an HC-05 somewhere in storage, about 5km away. I'll have to search :) |
I finally got to this. Sorry for the delay. V2.21.00 BETA supports BT, WiFi or UART I/O for all protocols. I've tested CRSF/ELRS with BT, but from another uController, not from HC05. You might need to make your changes to support the MAC rather than slave name. Please could you let me know how you go. I have left these debug macros enabled in crsf.ino. You might want to comment them out later.
|
Cool! Thank you. I test it and let you know :) |
How i can test if got good crsf frame? |
Yeah, it looks like you are not getting recognisable crsf frames, and yes, you can view incoming bytes. First, let me say that I test with a Kakute H7 V2 running Betaflight. Receiver is a CYCLONE Nano 2400RX ExpressLRS, and Transmitter/Controller is a Radiomaster TX16S with a HappyModel ES24TX Pro 2.4GHz 1000mW TX Module. This is successfully paired/(bound) and all works fine. I take the test crsf telemetry signal off the flight controller, not the Transmitter, because the JR Bay is occupied on there, and it is more convenient to use the receiver side. Perhaps this is an issue? Here the ESP32 converts the crsf telemetry to BT. I run the test Tracker firmware on a LILYGO® TTGO T-Display ESP32 1.14". Note that here we expect the CRSF signal to be inverted. config.h line 357
If you are taking the crsf signal through to the transmitter, then into an HC05, perhaps the signal is idle high, or NOT inverted. So maybe try that. If you want to print your incoming byte stream in hex, it's a little trickier. Find terseCRSF.cpp in the libraries, and on line 308 uncomment the line:
|
Update: I added this debug macro into terseCRSF.h v0.0.4
|
Okey i try that :) thanks |
ok i see the messages but something wrong. When i change to invert = false is the same. on ELRS i have selected protocol CRSF (not inverted). When i look the data its looking good.
|
HKR1987: The crsf telemetry from the Betaflight flight controller looks like this: TELEMETRY_BUILD but I'm seeing a pattern. For example, a Betaflight battery frame from the FC looks like this C8 0A 08 00 00 00 00 00 00 00 00 6D where the delimiter is 0xC8, length 0x0A, frame_id 0x08, payload 00 00 00 00 00 00 00 and CRC 0x6D The payload is zeros because I have no motor battery attached. Your similar frame looks like this: EA 0A 08 00 6F 00 01 00 00 00 2E ED where the delimiter appears to be 0xEA, length 0x0A(#10), payload 00 6F 00 01 00 00 00 2E, CRC 0xED and I can see you are showing battery values. So our frame delimiters are different. Can you try this: find terseCRSF.h in your library folder. Go to line 62. It looks like this
now change it to this:
build and flash, and please let me know. If this works we can create an iNav option |
ok, i will try it tommorow when be at home. I think that this is it :) |
only i see the problem with flight mode but i dont know if this ruin something?
now im need test it with servo maybe in weekend i get some free time for it. |
Haha. No need for coffee, but thank you. I'm pleased that it is coming together. You have helped me understand the iNav + Flysky i6x, and also we tested the BT together The "GPS lock good" looks suspect if latitude and longitude == 0, and flight mode should be readable text. You could also check the baud. Sometimes they use 400000 b/s. Let's keep the issue open for now. |
I had a similar problem, the telemetry did not seem to be recognized by the tracker. I was using a wire for the telemetry, latest Inav, latest ELRS and latest Edge-Tx on a tx16s. Using a terminal i could see that the transmitter was outputting telemetry but as i said i could not get it to be recognized by the tracker. I then edited the terseCRSF.h and changed CRSF_TEL_SYNC_BYTE to 0xEA like the example above and got it working! Some info was a bit off, like battery voltage (wrong decimal place) and amp-draw off by a factor of ten. Flightmode was also showing strange info just like above. I have not had time to really test that everyting actually works yet but i will get to that as soon as possible, right now im just happy to get some telemetry to the tracker working after spending too many hours chasing gremlings :) |
Thank you for the feedback. I think I might have fixed the flight mode. Could you ensure you use my latest versions of AntTrack and terseCRSF. They are still under BETA. I would welcome advice on the correct order if magnitude for volts and amps. |
I also notice same. Not get working tracker but i got error FC GPS Timeout. Maybe there is something cut the data and thats why is problem with flight mode, voltage and this timeouts? |
Yes, this is great info, thank you! "Moved the airplane to see if the alt reading was wrong due to it showing minus -0.1" Yeah, what happens here is this: Once we have "home" altitude and the GPS alt drifts a little due to accuracy tolerance, our calc for alt above field can go negative. I should show negative numbers properly there. I will try to look at this today, but wife has things arranged, lol. |
Thanks. Could you please give me details. Versions, log, anything else. |
I was going to edit my original post but you were quick to respond! |
I have posted V 2.21.07 |(under release_candidate) with fixes and some new features. Please could you check it when you get the chance. |
Also check out https://github.com/zs6buj/CRSF_Utlilties where you will find three utilities for CRSF to send telemetry from uart to UDP or BT, and read UDP. The utilities work with AntTrack. |
Cool! i will test when had some free time and let you know |
It compiles without problems but sadly i seem to have fried my t-display unit somewhere along the way so i cant test it on the hardware right now, i ordered some new units and i will get back to testing as soon as they come in. |
Ok, thanks. Did you do this?
This is a requirement if you are using :
Point the 'plane/drone in the default tracking direction, and tracker stores the FC compass reading as "home" direction Not sure why no display tho |
i dont remember if i push the button with this test but if i have this: |
This is something else, to do with when I write info to eeprom. "the display show correct coordinates but sometimes start showing errors like above" This is being caused by the long delay between GPS messages from Edge/TC box. There are many link statistics messages, and the GPS messages time out. You can change
|
volatge, amps and ah_drawn also looking wrong |
Yeah, I see that. Divided V and A by 10, and MhA by 1E3. Please could you try terseCRSF lib v0.0.7 when you get the chance. |
Ofcourse i will test it and back with results |
So...I have it mostly sort of working now, on a newer Lilygo T-display-S3 of all things. Like i said i fried my original T-display and had a s3 laying unused so i gave it a go and with a bit of tinkering i got i working, its right now a bit of a botch job changing the existing parameters for the T2 until i got it working. I could not use the bluetooth connection due to it being only Bluetooth LE but i got the display working and it receiving telemetry thru UART. The only issue i have now is that i cant get my servos working. I had exactly the same problem with my original T-display before i fried it, and any pointers would be very helpful. Edit: Servo write az=90 el=0 |
Thanks for the test. Make sure you power the servos separately from the ESP32. I use a separate 5V regulator. Don't use the 5v pin on the esp32, it burns the voltage reg on the board, or burns off the trace. I'm not sure what the LEDC thing is. I'll try to look later. |
Yes i have a separate bec for the servos.I also measured the output using i Lipo charger i have that can measure PWM signals and it shows nothing. Im pretty sure that it doesnt output any pwm signal. Based on some limited googling and guesses i think the LEDC problem and me not getting any pwm out is related, something with timers used to generate the pwm signal, but all the info i found went way over my knowledge level :) |
@toofen what esp variant you have in config? 5 or 6? |
Right now im using a modified version of 6. I had to modify option 6 to get it working with my Lilygo T-Display-S3 |
The datsheet says you can map any pins for motor control PWM. https://www.espressif.com/sites/default/files/documentation/esp32-s3_datasheet_en.pdf
I used these pin for another project, but no specific PWM signals.
|
You could also search to pdf for "LED PWM" |
after loads of reading and scratching my head i managed to get the LEDC error to go away. It was due to me using ESP version 2.0.14 due to TFT_eSPI not working on any higher version, but i found a work-around for that in Bodmer/TFT_eSPI#3355 (comment) and using that in combination with updating ESP to version 3.0.2 made the LEDC errors go away. I still cant get my servos to work but now i have something to work with at least. Starting antTrack version:2.21.07 |
Good work, and thanks for the feedback! |
ok i make test again with push home button. Version 2.21.07 (terseCRSF v0.0.7)
|
Since we see this:
we should start tracking provided that the 'plane/drone has moved more than minDist, which is presently 4m. I can't see from the logs if latitude or longitude have changed. For debugging I recommend that you activate these macros in debug.h #define DEBUG_AzEl |
ok, i made some test and something is still wrong. Test servo working, after set home location and go further with drone the tracker set in one position only, not moving after drone (16:34:18.417 in log)
|
The serial monitor is very slow and adding to the timeout problem. Could you go to your terseCRSF library, to terseCRSF.h and change these debug settings. We don't need to see the buffers anymore
Change to this:
Also, be aware, that the CRSF telemetry messages emerging from the transmitter box are pretty slow. Nothing we can do about that unfortunately. We need to get a GPS message on a regular basis, otherwise tracking becomes sporadic. |
I have opentx (open i6x) with elrs module. successful send telemetry over bluetooth to android telemetry app (telemetry viewer) but when i send it to anttracker its not working i got this output:
14:12:21.388 -> Starting AntTrack version:2.20.04
14:12:21.388 -> Setting up Wire I2C: SDA:21, SCL:22
14:12:21.495 -> Display support activated: Landscape
14:12:21.495 -> 64x128 text_size=1 char_w_px=6 char_h_px=8 scr_h_ch=8 scr_w_ch=21
14:12:21.495 -> Target Board = 3 ESP32 / Variant is Dev Module
14:12:21.495 -> FrSky Bluetooth In
14:12:21.495 -> Selected protocol is F.Port 2
14:12:21.495 -> headingsource = 2 FC Compass
14:12:21.495 -> Frs bluetooth master mode looking for slave name Frs2BT
14:12:22.630 -> Frs bluetooth connected!
14:12:22.663 -> EA<11<02<1F<05<67<FB<0D<6D<47<7C<00<02<3B<B0<03<E8<07<9E<EA<0C<14<C7<00<61<0A<00<08<02<DA<64<0B<E6<EA<0D<3A<EA<EE<10<00<00<75<4E<00<00<00<64<21<EA<0A<08<00<00<00<00<00<00<04<00<41<EA<0D<3A<EA<EE<10<00<00<75<4E<00<00<00<54<D7<EA<0C<14<C8<00<64<0B<00<08<02<DC<64<0A<62<EA<08<1E<00<7A<01<05<C4<36<3E<EA<0D<3A<EA<EE<10<00<00<75<4E<00<00<00<4B
There is data visble but something wrong...
The text was updated successfully, but these errors were encountered: