openrcforums

Kilrah wrote:It will discover things as soon as everything is powered up.

Great, that's what I thought. I need to do the same for my Hubsan X4 so that I can get RxBatt back.

I got the telemetry working in Taulabs but unfortunately it flooded all of the slots and now I just get the dreaded error. Is there an easy way to delete all of the telemetry entries under the model?

Not at this point. If you're on 2.1.1 you can check the "ignore instance" checkbox on the telemetry page until Taulabs fix their code (you'll still have to clean up the items manually first though).

Thanks. The Taulabs folks have a fix that will be rolled into the next stable release. I tested the latest "next" version last night and it looked good. For now I'll just turn off the S.Port telemetry from the FC. I might give the "ignore instance" a try just to see what happens.

Deleted

What would a use case for the 0-F range (last four bits of the data IDs) be?
I see that F101 - F105 is used for completely different things, measured in different places.

A given sensor on the bus that sends multiple values of the same type, for example 4 RPMs. That's the only scenario that would make sense, but I doubt that's what FrSky intended. Don't really know why they did that really, they call the last nibble a "group number" and say it's for "distinguishing the same sensor".
IMO they thought they needed that to allow multiple identical physical sensors, and didn't realize that the physical ID was enough of a differentiation (what we use in 2.1). If they had thought of multiple values of the same type by a single sensor they'd have used it for TEMP instead of using 2 separate IDs.

Thanks, that's a good one. Would avoid using several physical IDs.
Would the current 2.1 version see 0x0400-0x0403 as four separate RPMs?

Yes.

Any idea why the telemetry page in Companion (I'm using 2.1.3 just now) has some of the sensor lines which don't display all the fields - on mine the 12th sensor definition line down (if selected as 'Custom') has the 2nd field (the one where 'Custom' appears) much longer than the same field on all other lines, and also the 'Instance' field is really long, and as a result of both of these, 7 other fields are missing from that line. Line 27 is the same. I don't see any purpose to it. Is this a bug perhaps?

You got that backwards. Depending on the chosen type/formula/etc some parameters are not applicable or available and are hidden. As the remaining elements autoresize to use the entire width they become stretched.

Maybe I'm not explaining myself clearly - apologies. This is what I am seeing (even if no data is entered on line 12 in the sensors table): Regardless of the settings assigned to that row, it remains like this (as long as its set to 'Custom'). As I suggested, line 27 appears the same. Its not just me seeing this either. I refer to a github wiki page describing how to setup telemetry for a mavlink convertor I use:
https://github.com/Clooney82/MavLink_Fr ... -Telemetry

You can see on this person's Companion Telemetry screen (also appears to be mac version) that lines 9 and 12 display in the way I describe.

On mine if I enter GPS on that line, then upload the config to my Taranis Plus, in the telem screen on the Taranis, it assumes Voltage for that telemetry sensor rather than Raw as is desired for GPS (as I was not able to select raw due to that field being omitted from the line in Companion.

Hopefully this explains the issue a little better.

Hmm if that line previously had a GPS sensor that wasn't deleted on the radio it's possible it still has its unit set to GPS, which hides the fields you don't see.
Setting type to something else than custom should reset the other parameters and/or allow you to change them.

Kilrah wrote:Hmm if that line previously had a GPS sensor that wasn't deleted on the radio it's possible it still has its unit set to GPS, which hides the fields you don't see.
Setting type to something else than custom should reset the other parameters and/or allow you to change them.

If I set this line to Calculated, then back to Custom, I get the same long fields return. I think perhaps some work needs to be done on this form to improve the field handling. As I mentioned, using this field for GPS doesn't even work as it renders the units incorrectly.

Are you suggesting that you don't see long fields like this on your system?

This may also depend on the OS you are running. I've noticed that QtCreator screens display slight differently on windows and Linux, so it is possible some of these things don't appear on another's PC.

Mike.

athertop wrote:Are you suggesting that you don't see long fields like this on your system?

No, but as I said they are likely due to a persisting "under the hood" setting you have, which you somehow got in your setup and that I won't have on mine. If you posted your EEPROM file so I could reproduce I could have a look.

That's a great idea! Many thanks for checking this for me. eepe file attached.

On a separate note - is there a way to easily copy telemetry settings to another existing model?

Best regards, Paul

OK so it's as I thought, if you set to Calculated and change the unit back to something in the list it (i.e. not a virtual unit anymore) it's good again once you switch back to Custom.

There is no copy method at this point.

I see what you mean - I tried this workaround also and it does as you suggested. Nice work! To be honest though, this is a bug as the form shouldn't allow itself to get caught up this way, requiring the workaround to get the sensor row usable again. Do you concur?

Should I make a feature request for the copy/paste functionality for the sensors? I know this feature is available for other screens - even drag/drop is an option I think on some screens between models. I have several models which use the same telemetry so not having to configure all the required sensors by copy/paste would be beneficial.

athertop wrote:To be honest though, this is a bug as the form shouldn't allow itself to get caught up this way, requiring the workaround to get the sensor row usable again. Do you concur?

Well not really, because you wouldn't really want the virtual units (that you cannot select manually again) to be wiped my a single action you might do by mistake on one of the dropdowns either.

athertop wrote: Should I make a feature request for the copy/paste functionality for the sensors? I know this feature is available for other screens - even drag/drop is an option I think on some screens between models. I have several models which use the same telemetry so not having to configure all the required sensors by copy/paste would be beneficial.

Yeah a copy/paste/clear could be good.

I purchase a 9x radio and burn on it the last Open TX 2.1.3 firmware. I works great. I already fly my MINIMOA with it and it was great. I change the original RF module with the XJT of FRSKY with the Smart Port. Also I have some smart port sensors as variometer and voltage measure and the smart port receiver X8R. I understand that last version of Open TX can receive the smart port data messages. My question is where I have to connect the tx and rx of the serial communication ( after I separate and invert them from the smart port signal line). On ATMEGA64 of the 9X radio are 2 UART ports. So I have to connect the tx/rx signals to UART0 or UART1 in order to get the telemetry directly on radio display and by able to set alarms an so on ?

Hello,

I’ve just completed modifying my Turnigy 9x for telemetry using FrSky DJT transmitter module and DFR-II receiver.
I also connected an external battery monitor to the analog side connector and flashed the radio with the latest v2.1.3 FW with the telemetry support.

So far most of my tests passed except one, the alarm. I read the right voltage monitor from the receiver but when the voltage reaches the set points for alarms nothing happen. I expected a loud buzzer worming.
In Bar mode, when the voltage reaches the first set point it turns from solid to chess pattern.

Am I missing something is my settings?

Thanks.

ramdg wrote: Am I missing something is my settings?

How should we guess if you don't post them?

Kilrah wrote:

ramdg wrote: Am I missing something is my settings?

How should we guess if you don't post them?

Kilrah, please find attached the 9x configuration file that can be loaded into the OpenTX Companion 2.1.3.
The model is Quad 330 #5.

Thanks.

With your setup the alarms would come out of the DJT's internal beeper. Did you do a version of the telemetry mod that has both serial lines connected to the DJT?

Kilrah wrote:With your setup the alarms would come out of the DJT's internal beeper. Did you do a version of the telemetry mod that has both serial lines connected to the DJT?

Yes, I did the telemetry mod. I do get the voltage reading in the Tx LCD and the bars are updated. The only issue is that neither the Tx buzzer nor the DJT buzzer beep when the threshold is reached.

Please re-read my question and answer it... there are several published telemetry mods, and some do not connect the line that allows the radio to send alarms levels to the module. If that's what you did, then the alarms on the telemetry page won't work and you have to use a logical switch and special function instead. Or wire the 2nd line.

Kilrah wrote:Please re-read my question and answer it... there are several published telemetry mods, and some do not connect the line that allows the radio to send alarms levels to the module. If that's what you did, then the alarms on the telemetry page won't work and you have to use a logical switch and special function instead. Or wire the 2nd line.

Kilrah, I have performed the following two mods:
9x Transmitter : 9x Full Mod Telemetry
FrSky DJT module : 9x Full Mod FrSky

My understanding is that the Tx module communicates with the Tx box via RS232 and the box FW (OpenTX) compares the monitors Rx voltage to the set thresholds and alarms (Yellow, Orange, Red). Should a threshold is met the internal box buzzer should beep.

Does it work other way?

ramdg wrote:

Kilrah wrote:Please re-read my question and answer it... there are several published telemetry mods, and some do not connect the line that allows the radio to send alarms levels to the module. If that's what you did, then the alarms on the telemetry page won't work and you have to use a logical switch and special function instead. Or wire the 2nd line.

Kilrah, I have performed the following two mods:
9x Transmitter : 9x Full Mod Telemetry
FrSky DJT module : 9x Full Mod FrSky

My understanding is that the Tx module communicates with the Tx box via RS232 and the box FW (OpenTX) compares the monitors Rx voltage to the set thresholds and alarms (Yellow, Orange, Red). Should a threshold is met the internal box buzzer should beep.

Does it work other way?

Solved:
in order to get the alarm in the radio two things should be done:
1. Define a new Logical Switch e.g. L1 a<x A2 11.2v
2. Define a new Special Function e.g. L1 Play Sound Sirn 10