Flight Core v2 not working with any telemetry radios
-
@lccarter note. in the title i mean that there were not working. Not instead of Now.
-
Please review the following documents:
https://docs.modalai.com/flight-core-v2-rc-options/
https://docs.modalai.com/flight-core-v2-telemetry/Is your radio working without connecting the telemetry signal? (just RC input into flight core V2) ? Have you tried any non-telemetry radios?
Also please keep in mind that telem2 may be reserved for other data, not just RC telemetry, so should check what is being send on that port.. You could be sending too much data to RC receiver.
It could help to use a logic analyzer just to check if there is data flow on the TX and RX wires.
-
I've tested both telemetry ports. I only need it for use with telemetry radios because I'm using sbus hardware configuration for my sbus receiver. I've clarified that it's neither the radios or the wires because each of the telem radio sets work with a different flight controller i have. Is there a parameter that I am missing that should be turned on? ESC Telemetry is turned off, so I can utilize Telem 1 for other purposes, such as a telemetry radio, however no matter what port or configuration I have it in, Flight Core 2 does not recognize it. What steps do you propose I take?
-
@lccarter
Just to clarify I haven't tested with non-telemetry radios. -
I am not an expert in setting up the particular radio with px4. I will ask my colleagues to take a look as well. But here is what my debugging process would be:
- The RC receiver outputs the RC data into flight controller via SBUS at certain baud rate. In PX4, there has to be a driver running that understand the SBUS protocol. That driver needs to connect to correct port on Flight Core 2, bitrate, number of stop bits, and need to check if the polarity of signal needs to be inverted in the Flight Core 2 (SBUS protocol has inverter polarity)
- Once you have identified and set all the correct serial port parameters, if you do not see RC data coming in to Flight Core (no px4 messages with RC data are generated), then you can follow these steps:
- check using a logic analyzer or oscilloscope that the RC receiver is actually sending SBUS data into Flight Core
- enable some sort of debugging in the PX4 RC receiver driver to make sure it is reading at least some data
- if the px4 driver is reading data but does not produce valid packets, then maybe your RC receiver is using some variant of SBUS that the driver does not understand (or wrong driver is used). Also maybe baud rate is wrong (logic analyzer can confirm SBUS baud rate).
Hopefully after debugging those steps, you will have RC data coming into your Flight Core / PX4.
Now, for telemetry... it's kind of a reverse process to go through.
- telemetry packets that go out from Flight Core to the RC receiver needs to have a certain format. is it SBUS?
- is the baud rate for telemetry the same as the data from RC receiver (should be). Does signal also need to be inverted?
- What is the signal level that RC receiver expects telemetry (3.3V or 5.0V)
- what frequency of telemetry packets should be sent out from px4 to the RC receiver
- what data actually has to go out from PX4 to the telemetry port? I am assuming the same PX4 RC driver that receives the RC data, may have an option to send telemetry? If not, what PX4 driver is taking care of sending telemetry data in the correct packet format to the correct serial port? It probably has to subscribe to some PX4 messages, then create a telemetry packet and send it out to the correct serial port
- make sure that no other PX4 driver is sending anything to that serial port, as it can disrupt the communication to your RC receiver's telemetry input
- once you have confirmed that you have a px4 driver that is creating valid telemetry packets for the RC receiver and supposedly sending them out to the serial port, use logic analyzer to confirm that the data is going out from Flight Core uart TX into RC receiver telemetry RX port. Also you can check how often those packets are going out (should be maybe 50hz, depending on how you configured it).
After you confirm that there is data flow from PX4 into your RC receiver's telemetry input port and the data looks reasonable on logic analyzer (correct baud rate, correct voltage, polarity), then i would expect that your RC receiver should be actually receiving the data.
There is a lot of detail here, but i think if you take a step by step approach you can find the point of failure and fix it.
Meanwhile i will check with my colleagues if we have tested a similar telemetry radio and what was the set up.
-
@Alex-Kushleyev
thanks, I'll see what I can do. Basically, the only issue is with the telemetry radio. The Rc receiver works completely fine. They are two separate things and I'm only worried about the telemetry radio. it communicates via Mav-link to the ground station (my laptop running QGC). -
@lccarter , I got it. So you basically have a dedicated telemetry transmitter, which is not related to your RC receiver.
In that case, you can still follow the steps in the second part of my previous post and track it down step by step to make sure the right data goes out the right serial port with correct serial port params and signal levels.
-
@Alex-Kushleyev I was able to figure out the issue. The firmware had the baud rate parameter to the wrong speed. After correcting it and setting it to 56,000 it works. Thanks for the Help!
-
@lccarter From where do you set the Baud Rate for FC firmware?
-
@Alex-Kushleyev Where could we find the documentation for this?
Should we build it with the firmware?
-
@prawinsankar , can you please clarify which firmware you are talking about?
If you are referring to PX4 and drivers for RC, you have to look at the specific driver for the RC and see how the baud rate is passed to the driver, typically as a param or launch argument when the PX4 module is loaded.
Alex
