Replies: 4 comments 9 replies
-
|
Inav is getting all telemetry sent by the Crsf protocol plus single cell batt level was added to 3.0. |
Beta Was this translation helpful? Give feedback.
-
|
CRSFv3 is coming out soon. I see room for expansion there. I would suggest looking into implementing that first and look at what it can offer before messing with a proven/working protocol. I looked at the Ardupilot work. Looks like it was done by Yaapu to support crsf for the Yaapu script... Interesting concept but a big change for a small user base |
Beta Was this translation helpful? Give feedback.
-
|
Good point - I could spend some time on CRSFv3 if there is need, however I do not have any relevant documentation or pointers. |
Beta Was this translation helpful? Give feedback.
-
|
Nothing out yet except what was recently merged to Betaflight. Still a bit "raw" |
Beta Was this translation helpful? Give feedback.
-
|
I will have look. As a software engineer it trickles me a bit the wrong way that the features of telemetry is dependent on the radio link (which sensors are supported, naming etc.) |
Beta Was this translation helpful? Give feedback.
-
That's why there's Mavlink and other telemetry options. Look into OpenTx/Mavlink... it's a whole new world!🎵🎵and crsf supported. There's no need to break or play with the protocol for a small user base. There's limited bandwidth as it is and it's like trying to thread an elephant through the eye of a needle. |
Beta Was this translation helpful? Give feedback.
-
|
with the mavlink stuff , could we just not add it to that i fthe pilot (like me and others) have mavlink going over the second serial port of the receiver. IE, crsf is on the main, but mavlink is on another uart which also goes back to the transmitter but can be passed through to a ground station computer or other mavlink enabled device. |
Beta Was this translation helpful? Give feedback.
-
|
I would prefer something simpler and generic - something that only addresses the telemetry use case and provides a standardized features for communicating sensor and FC values back to the ground. I think I will give LTM over crsf a shot, it does not necessarily have to be that complex to get it working. |
Beta Was this translation helpful? Give feedback.
-
|
the problem you're going to have is that anything over the second serial port such as LTM using bridge mode WILL stop when it goes into RFMD 1 (50hz) that is by design (as per trappy and the tbs dev team) and has been a bain of mine for a number of years, but they aren't going to change it, they say use mavlink. having the bluetooth and now the wifi module enabled in the crossfire modules, then mavlink is going to be the way to go if we cannot get it over CRSF. My thoughts were, and forgive me if this is not how it works, we already get inav sensors via CRSF can we not "add" another one to the stream of sensors? |
Beta Was this translation helpful? Give feedback.
-
|
Sure, I have added a "distance to home" sensor to a nav build, but the numerical IDs of such sensors would have to be aligned between inav and OpenTx. Thus the idea of a more generic transport, that is not dependent on radio link make and model. Actually, what I am planning to try is to use the LTM encapsulation of telemetry data, but transported in a crsf telemetry frame. So I am actually not planning using a secondary serial port. |
Beta Was this translation helpful? Give feedback.
-
|
I hear you. But this is still another channel from FC to TX through the RX, right?
As for bandwidth LTM is lean, and doing generic telemetry that way could lead to the “old style” crsf sensors to be disabled.
What I was considering was simply to send a LTM frame as the data of an unused crsf sensor. Those frames are not that big, so impact and/or breakage would not be a concern IMHO.
Anyhow - I will try to get a Mavlink/CRSF setup running.
Sendt fra min iPhone
… Den 27. maj 2021 kl. 15.40 skrev OptimusTi ***@***.***>:
I will have look. As a software engineer it trickles me a bit the wrong way that the features of telemetry is dependent on the radio link (which sensors are supported, naming etc.)
That's why there's Mavlink and other telemetry options. Look into OpenTx/Mavlink... it's a whole new world!🎵🎵and crsf supported.
There's no need to break or play with the protocol for a small user base. There's limited bandwidth as it is and it's like trying to thread an elephant through the eye of a needle.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Beta Was this translation helpful? Give feedback.
-
|
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Segoe UI Emoji";
panose-1:2 11 5 2 4 2 4 2 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
-->I’m not sure this is the correct way to go. Besides, seems like TBS would have to allow for it Paweł Spychalski https://fpv-shopping-list.com/ Od: Stephen Mose AaskovWysłano: czwartek, 27 maja 2021 16:42Do: iNavFlight/inavDW: SubscribedTemat: Re: [iNavFlight/inav] Passthrough/custom/generic telemetry for crsf (#7007) I hear you. But this is still another channel from FC to TX through the RX, right? As for bandwidth LTM is lean, and doing generic telemetry that way could lead to the “old style” crsf sensors to be disabled. What I was considering was simply to send a LTM frame as the data of an unused crsf sensor. Those frames are not that big, so impact and/or breakage would not be a concern IMHO. Anyhow - I will try to get a Mavlink/CRSF setup running. Sendt fra min iPhone> Den 27. maj 2021 kl. 15.40 skrev OptimusTi ***@***.***>:> > > I will have look. As a software engineer it trickles me a bit the wrong way that the features of telemetry is dependent on the radio link (which sensors are supported, naming etc.)> > That's why there's Mavlink and other telemetry options. Look into OpenTx/Mavlink... it's a whole new world!🎵🎵and crsf supported.> > There's no need to break or play with the protocol for a small user base. There's limited bandwidth as it is and it's like trying to thread an elephant through the eye of a needle.> > —> You are receiving this because you authored the thread.> Reply to this email directly, view it on GitHub, or unsubscribe.—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or unsubscribe.
|
Beta Was this translation helpful? Give feedback.
-
Has anyone looked at getting more telemetry through Crossfire? The Ardupilot project has had some work at it, but I am not sure about the status.
With more functionality on the FC I think there is a need for a more capable return path for telemetry.
Beta Was this translation helpful? Give feedback.
All reactions