edgetx
edgetx copied to clipboard
EdgeTX
Feeding telemetry via AUX1/AUX2 (TX16S) does not work anymore
Is there an existing issue for this problem?
- [X] I have searched the existing issues
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 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:
https://github.com/EdgeTX/edgetx/commit/ff2b3ac22ab3756204066153cd5fc2ac08212026#diff-c4a06aa2127e48201e600ecfb1fd4805378bc8b6d532adc93244f54a26589f48
This enables telemetry-in only when external module is ppm. That doesn't make sense to me.
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. :shrug:
That change you reference was part of https://github.com/EdgeTX/edgetx/pull/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 g_model.telemetryProtocol can't be set to PROTOCOL_TELEMETRY_FRSKY_D_SECONDARY via the UI... I don't think it was present on colorlcd UI at all for us, and this PR removed it from B&W and Companion for consistency... with the plan going forward mentioned there https://github.com/EdgeTX/edgetx/pull/3782#issuecomment-1676028946 ... meaning you might be the one to make that happen :grin:
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?
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 https://github.com/EdgeTX/edgetx/issues/4633#issuecomment-2044599005, 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 https://github.com/EdgeTX/edgetx/issues/4633#issuecomment-2044599005, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJ66KNMEAUE2GN3JFY5MM3Y4O2QZAVCNFSM6AAAAABDGQCIDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBUGU4TSMBQGU . You are receiving this because you commented.Message ID: @.***>
what is the purpose of
PROTOCOL_TELEMETRY_FRSKY_D_SECONDARY? And what isPROTOCOL_TELEMETRY_FRSKY_Dinstead?
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
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.
Ok, sounds really that I just picked something that wasn't really in use ;-)
There is still https://github.com/EdgeTX/edgetx/pull/4102
Unfortunately I still had not the time to finalize this, but maybe we can include FrSky-D there. But on the other hand, since at present it seems that I am the only one who used that, it could be fully dropped.
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?
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.
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.
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. SumDV3 can transport only binary switches. CRSF could / must be extended, e.g. https://github.com/crsf-wg/crsf/issues/12
Do you have something special in mind?
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.
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.
Do you mean also another physical layer, e.g. I2C? But that isn't availabe at AUX1/2 I think.
Injecting values via trainer protocol is a bit cumbersome to integrate.
Why? Which obstacles do you see?
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.
What I meant was
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).
Do you mean also another physical layer, e.g. I2C? But that isn't available at AUX1/2 I think.
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).
Why? Which obstacles do you see?
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: https://github.com/EdgeTX/edgetx/pull/617
Well, I don't think I2C would be a good idea here, because
- if the handset is the master, it requires drives for all possible I2C slaves
- if the handset is the slave, if places the burden on the almost DIY master
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"? The channel data could be transmitted with https://mavlink.io/en/messages/common.html#RC_CHANNELS and an aux of https://mavlink.io/en/messages/common.html#MANUAL_CONTROL could be mapped to various switches.
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.
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. Thanks.
BTW: what about olliw's work integration into edgetx?
Here the "latest" state for EdgeTX: https://github.com/EdgeTX/edgetx/pull/150/files For truly latest state, see Olli's own repo (committs on top of OpenTX): https://github.com/olliw42/mTX
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.
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:
- obviously MAVLink and its microservices aim at a higher level of communication, and
- is designed for inter-node (Handset, GCS (PC), UAV, drone, ...) and inter-device (s.a. tunneling) communication
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
<start> <len> <type> <payload> <crc>
where <type> could be
-
0x01: proportional values [16] -
0x02: binary switches [64] -
0x03: 4-ary switches (include 3pos) [64] -
0x04: 8-ary switches (include 6pos) [32] -
0x05: index and state of one binary-switch (as one byte) -
0x06: index and state of one 4-ary-switch (as one byte) -
0x07: index and state of one 8-ary-switch (as one byte) - ...
where <payload> is the data according to <type>.
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).