Turnigy 9Xtreme, XJT, and Telemetry

Cant get your radio to work? General Hardware issues?
User avatar
jhsa
Posts: 15421
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by jhsa » Mon Sep 26, 2016 9:55 pm

floaledm wrote:Hi,

I'm the dev for the OpenTX Passthrough protocol in ArduPilot. If you have any question about it, I'd be happy to answer them here...

By the way, you should probably use the latest protocol which is found in the official ArduCopter 3.4-rc5 (or same in master branch)...
As far as I know openTX doesn't support the 9xtreme board??

João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW

User avatar
MikeB
9x Developer
Posts: 13553
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by MikeB » Mon Sep 26, 2016 10:08 pm

Which is why I'm adding support for the data from Ardupilot in ersky9x!

Mike.
ersky9x/er9x developer

pmshop
Posts: 90
Joined: Sun Aug 14, 2016 8:10 pm
Country: -

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by pmshop » Mon Sep 26, 2016 11:03 pm

floaledm wrote:Hi,

I'm the dev for the OpenTX Passthrough protocol in ArduPilot. If you have any question about it, I'd be happy to answer them here...

By the way, you should probably use the latest protocol which is found in the official ArduCopter 3.4-rc5 (or same in master branch)...
Hi floaledm,

I appreciate the assistance.
There is a reason why I am mentioning ArduCopter 3.3.3 is because the official 3.4rc5 does not record valid log files for analysis or uploading to dronelogbook.com.
APM 1.JPG
APM 2.JPG
DroneLogBook 1.JPG
DroneLogBook 2.JPG
To be more specific, my configuration requires a custom ArduCopter version provided by a manufacturer Craft & Theory for telemetry to work.
They provide a Sbus telemetry cable between the PixHawk 2.4.8 and FrSky X8R receiver.
Their custom version is based off of the official version.

floaledm
Posts: 8
Joined: Mon Sep 26, 2016 8:02 pm
Country: -

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by floaledm » Tue Sep 27, 2016 8:08 am

My main question is why values are being passed in the 'special' IDs (1000-1007) when, for some values, there is a standard ID for them.
A specific one is GPS altitude, this is 0x0820~0x082f and the value is a signed 32 bit integer in cm. Using the 'special' passthrough value causes a resolution problem. pmshop is at 550m when on the ground so this causes the resolution to be 10m.
OpenTx has worked with FrSky to reserve all IDs in the 5000-50ff for passthrough data, so we pass data in that range in ArduPilot (the 10xx range is found only in our modified firmwares and soon to be deprecated as the 50xx range is used in the official ArduPilot firmwares as of Copter 3.4-rc5). The original pull request is here and provides some insights: https://github.com/ArduPilot/ardupilot/pull/3434

With passthrough, that data is not interpreted by OpenTX (as would Ids for such things as RPM, etc.) but directly passed to lua scripts on the Taranis. So any data can be passed. You may not have the same limitations as OpenTx, though...

Using passthrough instead of standard IDs allows a lot more information to be passed, which is critical considering the limited bandwidth. Some standard IDs have been kept (such as Alt emulating a Variometer) because OpenTX can be configured to use that information, but besides GPS lat/lon, that info passed on std IDs is redundant with what is found in the passthrough data. Think of it as compressed data essentially...

GPS altitude and others therefore don't have a full 32 bit resolution because multiple info are passed on 32 bits. Instead of GPS altitude, why don't you use the altitude relative to home which seems more representative?: https://github.com/ArduPilot/ardupilot/ ... m.cpp#L684
You can also get the rangefinder distance: https://github.com/ArduPilot/ardupilot/ ... m.cpp#L727

pmshop: so is the logging issue with the official 3.4-rc5 firmware? What changed or what is causing it? Which is the latest version that works for the logs? Is there anything preventing it from being fixed (through a pull request or otherwise)?

pmshop
Posts: 90
Joined: Sun Aug 14, 2016 8:10 pm
Country: -

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by pmshop » Tue Sep 27, 2016 10:00 am

floaledm wrote: pmshop: so is the logging issue with the official 3.4-rc5 firmware? What changed or what is causing it? Which is the latest version that works for the logs? Is there anything preventing it from being fixed (through a pull request or otherwise)?
I am the end user reporting.
I will have to get access to the other 3.4rc to see where logging stopped working.
But from what I have seen in the past, it is an issue with all rc firmware.
It is almost like a "final signature" thing where once the firmware is officially released as a version and not rc the software/ uploaders can read it again.

With the log analyzer, there is a specific message "This is release candidate firmware" before trying to analyze.


User avatar
MikeB
9x Developer
Posts: 13553
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by MikeB » Tue Sep 27, 2016 11:13 am

floaledm wrote:OpenTx has worked with FrSky to reserve all IDs in the 5000-50ff for passthrough data, so we pass data in that range in ArduPilot (the 10xx range is found only in our modified firmwares and soon to be deprecated as the 50xx range is used in the official ArduPilot firmwares as of Copter 3.4-rc5).

With passthrough, that data is not interpreted by OpenTX (as would Ids for such things as RPM, etc.) but directly passed to lua scripts on the Taranis.
As I understand it, LUA scripts are only available on the Taranis with openTx, they are not available on other hardware (e.g. 9XR-PRO, 9X, 9XR, 9X upgraded with SKY board or AR9X board or 9Xtreme board), so this limits the use the passthrough data to users of the Taranis running openTx (ersky9x also runs on the Taranis).
All these other hardware platforms handle the standard SPort data, whether using openTx or ersky9x/er9x, so it seems to me that using standard IDs, where possible, is more useful. This is particularly important, in my opinion, for the 9X and 9XR that have AVR processors rather than ARM processors, and in the case of the 9X with an ATMEGA64, with VERY limited flash space to add anything extra.
floaledm wrote:Using passthrough instead of standard IDs allows a lot more information to be passed, which is critical considering the limited bandwidth. Some standard IDs have been kept (such as Alt emulating a Variometer) because OpenTX can be configured to use that information, but besides GPS lat/lon, that info passed on std IDs is redundant with what is found in the passthrough data. Think of it as compressed data essentially...
Er9x/ersky9x already also have processing in place to handle the Teensy/Arduino formatted Sport data, that packs data into some IDs and re-uses some IDs for ARDU data.
Using a single SPort hardware ID, you should get 41 packets per second, using two SPort IDs may well get you 55 packets per second.
The code I've recently written will actually respond to both 100X and 500X in the same way.

Mike.
ersky9x/er9x developer

User avatar
Kilrah
Posts: 8763
Joined: Sat Feb 18, 2012 6:56 pm
Country: United Arab Emirates

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by Kilrah » Tue Sep 27, 2016 12:18 pm

MikeB wrote: As I understand it, LUA scripts are only available on the Taranis with openTx, they are not available on other hardware (e.g. 9XR-PRO, 9X, 9XR, 9X upgraded with SKY board or AR9X board or 9Xtreme board), so this limits the use the passthrough data to users of the Taranis running openTx (ersky9x also runs on the Taranis).
All these other hardware platforms handle the standard SPort data, whether using openTx or ersky9x/er9x, so it seems to me that using standard IDs, where possible, is more useful.
Standard IDs are already implemented in the stock firmware and no special version is needed, anybody can use that already.

This discussion is about an alternative solution that thanks to the capabilities of OpenTX on Taranis optionally allows for a "higher performance" system (faster refresh rates, passing non-standard data, advanced graphics presentation) on that particular, popular setup.

pmshop
Posts: 90
Joined: Sun Aug 14, 2016 8:10 pm
Country: -

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by pmshop » Tue Sep 27, 2016 1:36 pm

I have been looking for the 3.4rc1-4 for a test but cannot find them.
Could someone point me in the right direction?

Thanks

floaledm
Posts: 8
Joined: Mon Sep 26, 2016 8:02 pm
Country: -

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by floaledm » Tue Sep 27, 2016 6:04 pm

Standard IDs are already implemented in the stock firmware and no special version is needed, anybody can use that already.
Absolutely. It's the protocol #4 (SPort) in ArduPilot which has been around for a little while now (as far as I know, at least since Copter 3.2). That protocol uses all standard IDs, but uses some of them in a non-standard way. It responds to polling on multiple hardware IDs, although conceptually I like to think that a given hardware should respond on a single hardware ID (after all, the polling mechanism is there to prevent multiple equipment from talking at the same time on the half duplex line). If there's any improvement you want to suggest on that front, I can help coordinate...
The code I've recently written will actually respond to both 100X and 500X in the same way.
I appreciate your diligent work on this and for your sake just want to be really explicit about the 10xx and 50xx "data ID" ranges: in the passthrough implementation of the official ArduPilot firmware, the autopilot responds to polling on a single hardware ID (i.e., "sensor ID") which is 0x1B https://github.com/ArduPilot/ardupilot/ ... elem.h#L62 with messages in the 50xx data ID range https://github.com/ArduPilot/ardupilot/ ... elem.h#L69. The 10xx range is only in modified firmwares from Craft and Theory which, as soon as the official stable Copter 3.4 comes out, won't be used anymore since the changes will be officially in a stable version of ArduPilot. Anyway, the passthrough protocol in stable Copter 3.4 will remain the same as in 3.4-rc5 (current beta) so any dev/testing should really be based off the protocol found in 3.4-rc5.
I have been looking for the 3.4rc1-4 for a test but cannot find them.
Could someone point me in the right direction?
Don't know where you can find precompiled official beta firmwares that are older than the current beta version. You can definitely use the Copter-3.4 branch, rewind the commits to an older rc version, and compile that.

User avatar
MikeB
9x Developer
Posts: 13553
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by MikeB » Tue Sep 27, 2016 6:11 pm

I don't think responding to a few hardware ID's is either a problem or wrong. Think of it as two hardware units on one board. E.g. one is the vario and another is the voltage/current sensor. Using real FrSky sensors these are different hardware devices, so if you have something that provides all the same information, why not respond to the same hardware IDs for them.

Mike.
ersky9x/er9x developer

User avatar
Kilrah
Posts: 8763
Joined: Sat Feb 18, 2012 6:56 pm
Country: United Arab Emirates

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by Kilrah » Tue Sep 27, 2016 7:06 pm

It's "fine" if the FC is alone, but prevents proper operation if other sensors than the FC are connected to the s-port bus and is thus improper use.

pmshop
Posts: 90
Joined: Sun Aug 14, 2016 8:10 pm
Country: -

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by pmshop » Tue Sep 27, 2016 10:02 pm

floaledm wrote: Don't know where you can find precompiled official beta firmwares that are older than the current beta version. You can definitely use the Copter-3.4 branch, rewind the commits to an older rc version, and compile that.
Oh, a question was asked "which version did the APM log creation stop working correctly?"
So I would need compiled versions.
Just as 3.4-rc5 is now.

I would be more than happy to run those tests for you all - (I used to be a HP Protect Tools software functionality tester a while back).

User avatar
MikeB
9x Developer
Posts: 13553
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by MikeB » Tue Sep 27, 2016 10:20 pm

Kilrah wrote:It's "fine" if the FC is alone, but prevents proper operation if other sensors than the FC are connected to the s-port bus and is thus improper use.
I don't see why you consider this improper use at all. Suppose you make your own sensor that returns the same appID data as the vario. This may surely use the same hardware ID as the 'real' vario. Now you make another sensor that returns the same appID data as the Fas40. This could surely use the same hardware ID as the real Fas40. Clearly they would conflict with a real sensor of the same type, but since you are replacing 'real' sensors with your own this should not be a problem.
So now you could make another sensor that has both vario and FAS40 functions on a single board. This should be able to use BOTH hardware IDs since it is replacing both sensors. The SPort bus will work correctly with this.
So I don't see why the FC, if it returns the same appID data as a real sensor, shouldn't use the corresponding hardware ID(s). It might need some documentation to indicate what hardware ID(s) it is using, so making it clear it is replacing 'real' sensors.
Other sensors, that are not being replaced by the FC, will still work correctly.

Mike.
ersky9x/er9x developer

floaledm
Posts: 8
Joined: Mon Sep 26, 2016 8:02 pm
Country: -

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by floaledm » Wed Sep 28, 2016 1:43 am

pmshop wrote: Oh, a question was asked "which version did the APM log creation stop working correctly?"
So I would need compiled versions.
Just as 3.4-rc5 is now.

I would be more than happy to run those tests for you all - (I used to be a HP Protect Tools software functionality tester a while back).
So, which tests do you want to run? Is it that the logs don't work for rc5 and you want to see if any of rc1-4 still has the logs working correctly?

Building ardupilot is pretty straightforward. On windows, you can use these instructions: http://ardupilot.org/dev/docs/building- ... -make.html (the latest PX4 Toolchain is v15)

Change to the Copter-3.4 branch, then there are multiple methods to reverse commits. The one I use most often is

Code: Select all

git rebase -i HEAD~<number-of-commits-you-want-to-edit>

pmshop
Posts: 90
Joined: Sun Aug 14, 2016 8:10 pm
Country: -

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by pmshop » Wed Sep 28, 2016 2:31 am

Yes, I would like to test and report where the break in the useable APM log files is.

I said I HP software tester, not a compiler :D (just being funny).

I know it is only $7 USD to get access to run the github compiler but I am too cheap to sign up.

Anyway I could ask you to compile the 4 firmware files?

I would appreciate.

floaledm
Posts: 8
Joined: Mon Sep 26, 2016 8:02 pm
Country: -

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by floaledm » Wed Sep 28, 2016 3:29 am

$7 USD/mo is to get private repositories. You can compile for free...

Email info@craftandtheoryllc.com and I'll send you the firmwares... Just so you know, though, the FrSky passthrough protocol is only in rc5.

User avatar
Kilrah
Posts: 8763
Joined: Sat Feb 18, 2012 6:56 pm
Country: United Arab Emirates

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by Kilrah » Wed Sep 28, 2016 6:45 am

MikeB wrote: I don't see why you consider this improper use at all. Suppose you make your own sensor that returns the same appID data as the vario. This may surely use the same hardware ID as the 'real' vario. Now you make another sensor that returns the same appID data as the Fas40. This could surely use the same hardware ID as the real Fas40. Clearly they would conflict with a real sensor of the same type, but since you are replacing 'real' sensors with your own this should not be a problem.
That's the problem, they aren't necessarily replacing the real sensors, the system allows for both (or more) to be present at the same time. Misusing the bus by responding to all IDs prevents that.
Say in the case of a hexacopter with Arducopter, the FC has its own current sensor that can measure total current consumption, and reports as a FAS-40 on the bus. With the system as designed, you could also install 6 FAS40S (or e.g. oXs based equivalents) to additionally measure each motor's current, and simply connect all of that to SPORT along with the FC. Those 6 different physical sensors need 6 IDs, but since the FC trumps on everything there isn't any you can use for them. That is a configuration that is used by some.

User avatar
MikeB
9x Developer
Posts: 13553
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by MikeB » Wed Sep 28, 2016 8:23 am

I'm only suggesting using 2 or 3 hardware IDs for the FC, as opposed to what it seems Eagletree are doing, which is to use 27 of them! If you want to have 6 FAS40s, you would need to change the hardware ID on 5 of them so why not on all 6. There are 28 potentially available so I don't see it as a problem.

Mike.
ersky9x/er9x developer

pmshop
Posts: 90
Joined: Sun Aug 14, 2016 8:10 pm
Country: -

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by pmshop » Wed Sep 28, 2016 9:55 am

floaledm wrote:$7 USD/mo is to get private repositories. You can compile for free...

Email info@craftandtheoryllc.com and I'll send you the firmwares... Just so you know, though, the FrSky passthrough protocol is only in rc5.
Email sent.
I really appreciate your time.

pmshop
Posts: 90
Joined: Sun Aug 14, 2016 8:10 pm
Country: -

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by pmshop » Wed Sep 28, 2016 3:23 pm

@floaledm ,

I received the 4 previous 3.4rc firmware and decided to go straight to number one.
Apparently, when the firmware is compiled with the developer/ release candidate tag, the logging is affected.
See attached log just created with 3.4 - rc1
2016-09-28 09-53-44.log
(3.11 MiB) Downloaded 10 times
The software sees the invalid date values and declares the file invalid for upload or does not populate correct data.

So I can go back to 3.3.3 but not all of the pass-throughs are set as in 3.4-rc5

@MikeB
What I do not get with 3.3.3 is as follows:
FasV
alt
dth

Still with 3.3.3 - gAl is metric when imperial is selected

User avatar
MikeB
9x Developer
Posts: 13553
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by MikeB » Wed Sep 28, 2016 4:54 pm

I must have forgotten to put the conversion in for gAl, I'll add it.

I can only assume that 3.3.3 isn't sending those values using 'normal' ID's.

Mike.
ersky9x/er9x developer

pmshop
Posts: 90
Joined: Sun Aug 14, 2016 8:10 pm
Country: -

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by pmshop » Wed Sep 28, 2016 5:06 pm

MikeB wrote:I must have forgotten to put the conversion in for gAl, I'll add it.

I can only assume that 3.3.3 isn't sending those values using 'normal' ID's.

Mike.
That would be my guess with the normal ID's

Technically & logically, 3.3.3 "had" the normal ID's
They got shifted with the 3.4 - rc's ??

pmshop
Posts: 90
Joined: Sun Aug 14, 2016 8:10 pm
Country: -

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by pmshop » Thu Sep 29, 2016 12:12 pm

*UPDATE*
Still using 3.3.3 with the new 29-Sep-2016 00:42 Ersky9x9XT firmware.
Battery icon and fuel bar now reading full progressing to empty.
gAl is now imperial as selected on the ArduC screen.

Still not reading FasV, alt and dth.

Curious - Directly across from alt on the right, what is the value "max" is representing on the GPS screen?

User avatar
MikeB
9x Developer
Posts: 13553
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by MikeB » Thu Sep 29, 2016 1:08 pm

Max is the maximum value that Alt reached, it will still be in metres.

Mike.
ersky9x/er9x developer

pmshop
Posts: 90
Joined: Sun Aug 14, 2016 8:10 pm
Country: -

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by pmshop » Thu Sep 29, 2016 4:01 pm

Roger that - that is off a bit.
Also, a reading I got just before a crash on my quad (confirmed reading on my hex) - The alt on the GPS screen is actual above ground level in feet until I get a GPS fix

User avatar
MikeB
9x Developer
Posts: 13553
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by MikeB » Thu Sep 29, 2016 4:27 pm

My guess there is the flight controller is sending the barometric altitude until it gets the GPS fix.
The max is the max value received, you should be able to reset it to the current reading by pressing EXIT while viewing the display of it.

I've changed the source code to convert it to feet if imperial is selected.

Mike.
ersky9x/er9x developer

pmshop
Posts: 90
Joined: Sun Aug 14, 2016 8:10 pm
Country: -

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by pmshop » Thu Sep 29, 2016 4:51 pm

That would be my guess too.
But there is a disconnect. GPS screen shows the alt before the lock, but the alt does not display anywhere else.

And from what I have seen, nothing can be reset on the GPS screen.
Short menu press for that reset menu or long exit - nothing changes the GPS screen except incoming telemetry and the left or right selector to next screen.

User avatar
MikeB
9x Developer
Posts: 13553
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by MikeB » Thu Sep 29, 2016 6:23 pm

A short press of EXIT should reset all telemetry items that have a max and or min value.

Mike.
ersky9x/er9x developer

pmshop
Posts: 90
Joined: Sun Aug 14, 2016 8:10 pm
Country: -

Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by pmshop » Thu Sep 29, 2016 8:23 pm

I stand corrected - short press of exit does clear...briefly though.
Happens very fast.
I also noted whatever the number is for max is incorrect.
I have 45 as max right now and the actual alt was 14.9 - looked straight at it.
Absolutely could not be 45 feet because my warehouse peak is only 25 feet.

If this helps, I hit exit and now alt reads 5.2 and max reads 16

User avatar
CobaltEcho
Posts: 19
Joined: Mon Sep 05, 2016 4:06 am
Country: United States
Location: East Coast

Re: RE: Re: Turnigy 9Xtreme, XJT, and Telemetry

Post by CobaltEcho » Thu Sep 29, 2016 8:27 pm

pmshop wrote:I stand corrected - short press of exit does clear...briefly though.
Happens very fast.
I also noted whatever the number is for max is incorrect.
I have 45 as max right now and the actual alt was 14.9 - looked straight at it.
Absolutely could not be 45 feet because my warehouse peak is only 25 feet.

If this helps, I hit exit and now alt reads 5.2 and max reads 16
Could it be 45ft from sea level?

Sent from my SM-G900V using Tapatalk
-Echo

Post Reply

Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 3 guests