Feeding telemetry via AUX1/AUX2 (TX16S) does not work anymore #4633
Comments
wimalopaan
added
bug 🪲
|
The firmware on my external µC was working I think at least until 2.8.x and remains unchanged, but the radio stops recognizing the telemetry data the µC sends now. Maybe the FrSkyD-packets it sends were wrong from the beginning ... to help check this out, I append a serial packet view form the LA.
Maybe #4632 has some influence on this. hth |
|
Ok, the first question is, what the motivation was to introduce this check: ff2b3ac#diff-c4a06aa2127e48201e600ecfb1fd4805378bc8b6d532adc93244f54a26589f48 This enables telemetry-in only when external module is ppm. That doesn't make sense to me. |
Does it though (not make sense)? i.e. the only times I have ever used FrskyD (or at least I think it was FrskyD) telemetry in were in my 9XR days, to feed in telemetry from the XJT module. What are normal use cases are there? From my quick refresher of that block of code - and it's predecessors - this is not particularly new... it seems to have always been linked to the module being of PPM and a telemetry UART being available in some way or another, probably since this was the intended use case. 🤷 That change you reference was part of #3822, so only affects 2.10, so if 2.9 is affected also that isn't the issue. I have this feeling your other problem here (also 2.10 specific) is that |
|
Thank you for your explanation! The first question is: If I grep the sources, I get: And here all seems to be disabled: Lines 225 to 231 in fb45009 Maybe you can guide me into the right direction? |
|
You need to be looking at older code to find more references, say 2.9
branch, since the aforementioned PRs effectively removed any remaining
traces of it but those.
Not as yet, it is still very much at formulation/discussion level.
…On Tue, 9 Apr 2024, 7:49 pm Wilhelm, ***@***.***> wrote:
Thank you for your explanation!
The first question is:
what is the purpose of PROTOCOL_TELEMETRY_FRSKY_D_SECONDARY ?
And what is PROTOCOL_TELEMETRY_FRSKY_D instead?
If I grep the sources, I get:
$ grep -R PROTOCOL_TELEMETRY_FRSKY_D_SECONDARY * 2>/dev/null
radio/src/serial.cpp: g_model.telemetryProtocol == PROTOCOL_TELEMETRY_FRSKY_D_SECONDARY) {
radio/src/dataconstants.h: PROTOCOL_TELEMETRY_FRSKY_D_SECONDARY,
And here all seems to be disabled:
https://github.com/EdgeTX/edgetx/blob/fb45009fd430a2fa83bcf35b9a2c412730ead589/radio/src/serial.cpp#L225-L231
Maybe you can guide me into the right direction?
Is there kind of blueprint to implement a new serial telemetry stream?
—
Reply to this email directly, view it on GitHub
<#4633 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABJ66KNMEAUE2GN3JFY5MM3Y4O2QZAVCNFSM6AAAAABDGQCIDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBUGU4TSMBQGU>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Actually, sorry, yes, check the linked comment from before, Michael did say
his PR (think it was #3352?) could be used à a template?
…On Wed, 10 Apr 2024, 6:27 am Peter Feerick, ***@***.***> wrote:
You need to be looking at older code to find more references, say 2.9
branch, since the aforementioned PRs effectively removed any remaining
traces of it but those.
Not as yet, it is still very much at formulation/discussion level.
On Tue, 9 Apr 2024, 7:49 pm Wilhelm, ***@***.***> wrote:
> Thank you for your explanation!
>
> The first question is:
> what is the purpose of PROTOCOL_TELEMETRY_FRSKY_D_SECONDARY ?
> And what is PROTOCOL_TELEMETRY_FRSKY_D instead?
>
> If I grep the sources, I get:
>
> $ grep -R PROTOCOL_TELEMETRY_FRSKY_D_SECONDARY * 2>/dev/null
> radio/src/serial.cpp: g_model.telemetryProtocol == PROTOCOL_TELEMETRY_FRSKY_D_SECONDARY) {
> radio/src/dataconstants.h: PROTOCOL_TELEMETRY_FRSKY_D_SECONDARY,
>
> And here all seems to be disabled:
>
> https://github.com/EdgeTX/edgetx/blob/fb45009fd430a2fa83bcf35b9a2c412730ead589/radio/src/serial.cpp#L225-L231
>
> Maybe you can guide me into the right direction?
> Is there kind of blueprint to implement a new serial telemetry stream?
>
> —
> Reply to this email directly, view it on GitHub
> <#4633 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABJ66KNMEAUE2GN3JFY5MM3Y4O2QZAVCNFSM6AAAAABDGQCIDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBUGU4TSMBQGU>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
|
AFAIK, it was to be able to support some DIY Multiplex module which was outputting its telemetry into the S.PORT pin in this format. @3djc what does your memory tell you? |
|
Yeah, some DIY stuff where you would out PPM and get back D telem, but this was way back then, unsure about brand tho |
Ok, sounds really that I just picked something that wasn't really in use ;-) There is still #4102 Unfortunately I still had not the time to finalize this, but maybe we can include FrSky-D there. My use case was connecting a small attiny1614 based board, that encodes 4 stick-switches into some telemetry-value and this was read via AUX2. The attiny gets its supply also from AUX2, so turning of the supply of AUX2 turns off the attiny and frees AUX2 for other usages. The same can be achieved via CRSF or SumdV3. Comments? |
Wouldn't it make way more sense to have you board using some "real" input extension protocol? Having a way to add inputs to the radio seems like a desirable feature, which could be done properly instead of using some hacky way via telemetry. |
Do you have special in mind? |
|
Wouldn’t trainer be a better fit than telemetry to get extra input in? |
It would be cool to have proportional external input as well as binary / ternary (or arbitrary N-ary) "switch"-values (with the possibility to handle them in EdgeTx). SBus (as well as may IBus) serves as trainer input but lacks the "switch" values. |
Well, something that would be closer to the hardware, and thus allowing us to integrate at lower level, and thus be usable in many flexible ways. Injecting values via trainer protocol is a bit cumbersome to integrate. I'm thinking about something that would allow a more "built-in" feeling, more like some extension that would allow custom input types, as if they were built-in into the radio. Think additional switches, pots, gimbals, etc. |
Do you mean also another physical layer, e.g. I2C? But that isn't availabe at AUX1/2 I think.
Why? Which obstacles do you see?
What I meant was
|
Well, something similar, where the device would send the values/positions of it's different hardware inputs. And yes, that would require some more integration. And by the way, I2C can be used on AUX1 instead of USART, at least on the TX16S (done this before).
Instead of just settings up switches and using them wherever you like, you end up settings up a bunch of logical switches first that all depend on trainer channel values. Also, what if you want to actually use a real trainer input (from another radio), but still use your additional inputs? |
|
For reference, here the original IMU PR that turned TX16S AUX1 from serial into I2C: #617 |
|
Well, I don't think I2C would be a good idea here, because
For me it would be more practical to stick to UART and define some protocol that fullfills the requirements (as I stated above). In EdgeTx the trainer proportional channels can act as normal inputs (TR1-TR16) For the switches we then must extend the datastructure of switches (binary, ternary, ..., 6pos) in EdgeTx to those that come via the new protocol from extern. |
|
How about MAVLink as the "UART protocol"? |
Would be an option, but MAVLink is huge |
|
Yes, but the code is there: https://mavlink.io/en/getting_started/use_libraries.html (here especially https://github.com/olliw42/fastmavlink would likely be the one to go with). Especially the integrated MAVLink router in fastmavlink lib could be IMO of great interest here for you in regards to expandability. |
Ok, need to have a closer look at that. BTW: what about olliw's work integration into edgetx? |
|
Here the "latest" state for EdgeTX: https://github.com/EdgeTX/edgetx/pull/150/files |
|
Olli is not interested in working with us. He did not like something that happened a while ago. I made an offer work together, but I did not get any answer. |
|
What about MultiWii (MSP). Maybe a bit more widespread? |
|
Thinking a bit more about this topic I got the impression, that MAVLink is not the right protocol for extending the built-in pots/switches/... of a handset. There are two reasons:
Extending the handset with external interface-elements (pots, switches) is far more low-level. But - as I said - should not be so low-level as I2C (register level). Therefore I would like to propose a serial handset-extension-protocol. This should be as easy as SBus, IBus, SUmDV3, CRSF (only rc-channels), and it should transport the (normalized) values of external pots, incrementals, ADC-channels, switches (N-ary), buttons, etc. I think a uni-directional protocol would suffice. I could be as simple as
where
where Maybe we could finalize the work on #4102 and add a parser for this. Additionally, to be of full use, it requires to extend the list of sources(the 16 external proportional) and switches (64). For the sources we could reuse the trainer-channel values: But it would be a bit more clearer to introduce new data-structures for these external sources and switches. If the values of these external interface-elements are not used in inputs/mixer-lines they should be queryable via LUA. Then a LUA skript can forward them (crsftelemetrypush()) to a remote device (the FC or something behind the FC). |
Is there an existing issue for this problem?
What part of EdgeTX is the focus of this bug?
Transmitter firmware
Current Behavior
Setting AUX1 to "telemetry-in" and sending serial telemetry-data does not provide new sensors in sensor search.
Expected Behavior
Sending FrSky-D telemetry-data via AUX1@9600Bd should produce new sensors in telemetry.
Steps To Reproduce
Set AUX1 to telemetry-in.
Send FrSky-D telemetry-data 9600Bd to AUX1 RX.
Search for new Sensors.
Version
Nightly (Please give date/commit below)
Transmitter
RadioMaster TX16S / TX16SMK2
Operating System (OS)
No response
OS Version
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: