Hi Christoph,
Thanks for the information. Finally, I established communication with CRSF as setting below:
FC firmware : Matek F405 wing
5v ->5V
GND->GND
CRSF TX -> FC T2 RX
CRSF RX -> FC T2 TX
Serial2_protocol=23
BRD_ALT_Config=1
The reason why I can’t connect with CRSF at the very first is that I didn’t set BRD_ALT_Config=1.
Besides, I am very interesting to establish wifi connection between Transmitter and laptop. But I tried setting as below, still didn’t work.
Transmitter: TBS Crossfire TX lite
Firmware version : 4.0.5
Wifi activation version:1.17
RC by MAVLINK : tried both on and off
MAVLINK TX -> FC T2 RX
MAVLINK RX -> FC T2 TX
Serial2_protocol=23
UDP port : both wifi module and qground control are 8888(default port number as TBS manual said)
Could you help me to figure out what’s wrong with my setting ?
Besides, during the Wifi connection, is the TBS wifi module or laptop the Wifi host (hotspot server)???
I am encountering the same problem as Alan’s.
Following the TBS manuals to setup my Kakute F4 and Omnibus F4, still can’t get my CRSF TX talking to mission planner or Qground through UDP.
Sensors’ readings for roll, pitch yaw are even available on the TX, so I assume it receives Mavlink telemetry packet from the quad, just that it does not re-broadcast to GCS.
update:
My CRSF TX is a full version. Using Bluetooth “MAVLINK EMU”, connection was established. However, using Bluetooth “MAVLINK”, missionplanner got frozen. Could be a sign that no Mavlink signal being sent from FC to TX? Need to find a way to check. [22/OCT]
iirc that‘s the message subset generated on the transmitter side, mocking a radio modem. check what you get when uncollapsing vehicle 1 comp1, that‘s where the vehicle‘s messages are.
If my interpretation is correct, mavlink telemetry data is generated by Ardupilot just fine but still unsure whether the data is passed to crsf nano RX via FC Uart6.
After almost a month of trials-n-errors, the problem is solved finally. I was just a step away from showing white flag, i.e. bringing my questions to TBS.
To make it short, I always attempted to establish GCS connection through the TX access point directly. But there is a bug with crossfire TX that one MUST first put the TX & GCS talking successfully via an external wifi (wifi created by a router,etc), before MAVLINK signal can be broadcasted from TX access point.
Of course, this is assuming configurations in Ardu, crsf TX, GCS are completed in advance.
Observation and solution confirmed with both my Crsf TX Full & CRSF TX Lite.
Hello!
I was success to setup a communication between fc and qgroundcontrol on mobile via micro tx v2 but faced a problem:
When setting a point go to I always had an error message like vehicle didn’t respond. It make me disappointed because having two way telemetry was a reason for me to switch onto crossfire. At the same time the vehicle was displayed successfully and telemetry data was ok.
Can you please advise anything?
Regards
I can connect missionplanner to micro vx2 through udp with wifi router. But gcs still cannot connect via direct connect to acess point or my mobile hotspot. How can you connect to direct access point mode?
Hi @lawrence, I’m extremely thankful for your advice about connecting first to a WiFi hub and only then to the TX’s Access Point. In this way I’ve wasted only an hour and not a month. There remains only a minor problem: every time I switch on the radio, I need to click in the CrossFire TX and change the WiFi’s module “UDP -> Mavlink” setting from Off to On. Is there any way to save it permanently? I run the 0.17 firmware version on the WiFi module and V4.08 (the newest beta) on the CrossFire TX.
@mavic MissionPlanner doesn’t ask about the host address, only the UDP port (8888). There is a MP android version, and it works very well with Crossfire WiFi.
You are welcome. Exactly why I chose to document the problem&solution here. I knew someone would run into same problem, and we have only 12 months a year…
As for: “I need to click in the CrossFire TX and change the WiFi’s module “UDP -> Mavlink” setting from Off to On. Is there any way to save it permanently?”, I am afraid not yet. TBS is aware of this issue and next firmware release will fix supposedly. You may try rolling back to 1 version older, in which option for ON/OFF UDP does not exist.
Btw, please be reminded that even though a connection is established directly thru TX’s access point, the presence of external WIFI is a must to maintain that connection. This is weird I know. TBS said in email that they knew this and would fix eventually but god knows when.
Oh no, I haven’t checked this without being in my WiFi network. Good to know, it would fail when trying to fly. Maybe a WiFi hotspot from the phone does the job? Another problem is that I couldn’t type the WiFi login from the CrossFire Agent, and doing this using the joystick was rather clumsy. On the phone, I would setup a short password (or no password - will it work? I need to check)
I am SO relieved to find an active thread about MAVLink over WiFi!!!
I have had it working for a little while now, but it is very unreliable for me. My GCS gets live telemetry data (I can see GPS location, craft attitude, etc.), but I am unable to send changes to the MAV. If I try to change a parameter, or upload a new mission, it errors and does not send. If I try over and over again sometimes I can get it to go through. Does anybody else have this issues?
In Mission Planner under the “Link Stats” I have between 2% and 5% download link quality. Is this normal for you all?
Also, thank you @lawrence for pointing out how to connect directly to the CRSF access point by first connecting to a hotspot. I thought the accesspoint was completely non-functional, I had previously been using my phone hotspot as a middle man. Was hoping it would improve the MP MAVLink link quality by cutting out the extra step, but no. It still drops like 95% of packets.
I also experienced packet loss. Then I experimented a little: in mode 150hz, packets received >85%; in mode 50Hz, packets received ~5% (barely functional); in mode dynamic, although packets received only ~8%, I found it performs very close to mode 150hz.
None of them is responsive enough, however.
@lawrence I am having really weird issues. While I have MAVLink Tx and Rx wired to my FC from my Crossfire receiver I get issues with telemetry. If I lock it to 150hz mode it almost immediately drops telemetry. If I disconnect mavlink and instead run only SBUS, the crossfire telemetry works fine. Of course this means I can’t use MAVLink; so I tried running SBUS in addition to MAVLink RX and TX (instead of rc over MAVLink) and that seemed to help as well.
Would you mind sharing the firmware versions you’re running for OpenTX, your Crossfire Micro TX V2, and Crossfire WiFi?
I have a support ticket with TBS and am in contact with them about the weird behavior I am experiencing. The customer service rep I’m speaking with is trying to determine if my issues are related to MAVLink, or if they are unrelated. He also said a new firmware will be released in the coming days to fix some MAVLink issues.
