openrcforums

I am trying to get Smartport telemetry from my XSR and sparky. I am using a turnigy 9xr . I am also using multiprotocal module with Fryskyx protocol .I have FryskyX with Type CH_16 set in Serial multi . But UsrProto just to be set FRHUB havn't frsky.I've tried it in both FRHUB and WSHhi but still no telemetry.
VERS: V1.642-Mike
DATE: 20.09.2016
SVN: er9x-pr820
MOD: FRSKY NT

Please confirm you have done the telemetry mod to the 9XR.
Is the processor a mega64 or a mega128?

Mike.

Thanks Mike. I have done the telemetry mod to the 9XR,and the processor is a mega128。just Can be brush er9x - frsky.

Does you telemetry mod include an inverter on the telemetry input signal?
What Multiprotocol module are you using, and what firmware do you have flashed to it?
There may be a problem of inverted/non-inverted telemetry signal.

Mike.

Thanks Mike.Just like this，I have installed Banggood multiprotocol module, soldered the tx and rx jumpers,Compiling and Programming both the inverted/non-inverted telemetry two firmware of Multiprotocol v1.1.4 version.and Then I change TX to the er9x-128 version in the er9xProv821g_multiDSM-2.zip, but on the radio option not appear set frsky mod option.so I get aleart thr ali switch warning.Flash the er9x-frsky version of the er9xProv821g_multiDSM-2.zip.UsrProto just set FRHUB still no telemetry even rssi.

The "Frsky Mod Done" setting, on the '128 version, is in the Hardware menu. This menu is disabled unless you power the radio on while holding the left horizontal trim to the left.

As part of the telemetry mod, have you connected the bottom pin of the module connector to the serial input of the processor?

Mike.

Thanks Mike.I've found the "Frsky Mod Done" option, and I haven't put the bottom of the module pin connector to connect to the serial input processors.They are now using TTL - 232 to connect to the fuatba interface.The original method is to use XJT rs232 port by futaba interface telemetry.How do I connect the pin to multi-protocol module?

The serial input is pin 2 of the processor, also used as MOSI to the connector used for flashing.
If just using the MULTI module, then you may connect pin 5 (bottom pin) of the module connector to this pin. I would suggest including a 470 ohm resistor in the connection. The MULTI module then sends the telemetry data on a non-inverted connection.

If you are likely to use a FrSky XJT, then you would need to include and inverter in the connection, and get the MULTI module to send inverted data.

Mike.

MikeB wrote:The serial input is pin 2 of the processor, also used as MOSI to the connector used for flashing.
If just using the MULTI module, then you may connect pin 5 (bottom pin) of the module connector to this pin. I would suggest including a 470 ohm resistor in the connection. The MULTI module then sends the telemetry data on a non-inverted connection.

If you are likely to use a FrSky XJT, then you would need to include and inverter in the connection, and get the MULTI module to send inverted data.

Mike.

Mike: thank you, I finished the modification with your help。Now, I can start testing.
I found that information are digital display when the UsrProto is frsky. attachment=1]9xrattutide.jpg[/attachment] I use a sparky flight control of dronin firmware, itself support frsky s.port.I have set in the flight control instead of frskyacceldata with AttitudeAngles.
Now a lot of flight control system can be directly output frsky s.port data protocol format.For example, the cleanflight naze32/cc3d、dronin sparky2。。。The GUI of UsrProto: ArdunP can only support the mavlink by converter?I tried to use flight control output s.port format and TX using arduP displays, AttitudeAngles Line does not display，HDG direction line is normal.GPS has 3Dfix does not display, ALT and Galt value can be displayed....
https://github.com/d-ronin/dRonin/blob/ ... rtBridge.c

When you select ARDUC (or ARDUP) as the Usr Proto, you get the extra display (with the heading box in the middle) and then specific processing is applied to certain telemetry values, assuming they have been sent by ##a Teensy or Arduino converter.
The number of sats and GPS fix is expected in T2 as 10 times the number of sats plus a code (0-3) for the GPS fix. If your FC is sending T2 with a different coding, then this will display incorrectly.
If you display T2 on a custom display, we may be able to see what they are sending. Eother that, or find what they are sending from their code (or ask them).

Mike.

MikeB wrote:When you select ARDUC (or ARDUP) as the Usr Proto, you get the extra display (with the heading box in the middle) and then specific processing is applied to certain telemetry values, assuming they have been sent by ##a Teensy or Arduino converter.
The number of sats and GPS fix is expected in T2 as 10 times the number of sats plus a code (0-3) for the GPS fix. If your FC is sending T2 with a different coding, then this will display incorrectly.
If you display T2 on a custom display, we may be able to see what they are sending. Eother that, or find what they are sending from their code (or ask them).

Mike.

https://github.com/TauLabs/TauLabs/wiki ... -telemetry

通过我的 Nexus 6 上的 Tapatalk发言

So they are using T1, not T2, and encoding the information differently. It makes it quite difficult when there isn't a common standard.
You could display T1 on a custom telemetry screen to, at least, see the information.

I don't want to add specific code to handle another variation of non-standard use of FrSky telemetry values. What I'm thinking about is adding a method of handling this sort of thing in a general way. This will then allow most such non-standard usage to be handled without firmware changes.
It will take a while to do though.

Mike.

MikeB wrote:So they are using T1, not T2, and encoding the information differently. It makes it quite difficult when there isn't a common standard.
You could display T1 on a custom telemetry screen to, at least, see the information.

I don't want to add specific code to handle another variation of non-standard use of FrSky telemetry values. What I'm thinking about is adding a method of handling this sort of thing in a general way. This will then allow most such non-standard usage to be handled without firmware changes.
It will take a while to do though.

Mike.

Thanks.Really looking forward to your masterpiece,I guess you mean using eepe telemetry interface editor to create a corresponding relation table and then save in the epprom like mixed control Settings?In addition, I didn't find ARDUC in er9x-128，Will there be a horizontal line in ARDUC title box shows the attitude?

I've got some ideas, and something I'm testing using Scalers that update telemetry values.
One significant problem on the '128 is there is very little space left in the RAM and this limits just how much I can add. Flash is not such a problem.
The only real difference between ARDUP and ARDUC is the flight mode names. I'm looking to try to find out automatically which is currently active.
Please explain in detail what you mean by "Will there be a horizontal line in ARDUC title box shows the attitude?".

Mike.

I think he means an "Artificial Horizon" like on real aircraft.

João

jhsa wrote:I think he means an "Artificial Horizon" like on real aircraft.

João

Thanks João,You understand me,The FC has output attitude Angle by setting the FrskyAccelData source，And I found that HDG direction and FrskyAccel-z axis almost the same on the Fixed wing aircraft.if HDG on behalf of the direction of GPS movement，How to display the Head towards when the multicopter and helicopters backward.