openrcforums

I'll need to look through to see what might be happening. There is code in ersky9x to handle the barometric altitude in particular. This takes the first received value(s) as ground level and uses that as an offset to give relative height. This may be affecting the max value you are seeing.

Mike.

CobaltEcho wrote:

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

Great guess but we are in what is called the Hill Country.
Known mean Sea Level (MSL) is 1720 feet.
That is reflected perfectly once I get a GPS lock.

pmshop wrote:

CobaltEcho wrote:

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

Great guess but we are in what is called the Hill Country.
Known mean Sea Level (MSL) is 1720 feet.
That is reflected perfectly once I get a GPS lock.

Haha, had to try! I'm only 4ft above sea level, so it seemed practical to me, lol

Sent from my SM-G900V using Tapatalk

Awesome!
I could have saved $38USD by building my own RS232 to TTL Converter for FrSky Telemetry from a Pixhawk:
http://www.ebay.com/itm/142076966567?_t ... EBIDX%3AIT
with a 1n4007 diode: Diode band is at the top - away from the board.

There bust be a big difference how the data is handled between 3.3.3 and 3.4rc5.
Running 3.3.3 with the new shutdown sound firmware, FasV and altitude do not display.
I also noticed on the GPS screen, alt max needs a decimal just like alt did.
Temp2 on the RPM screen shows a balmy 199F
This morning it shows 32F but after GPS lock, it shows a sweltering 289F.
I will mention this GPS fix is at a different location - since it seems they are related.

Temp2 is used to send "number of sats" and GPS fix (0-3). It is coded as 10 times "number of sats" + GPS fix (in degrees C).
So 199F comes from 93C, 9 sats and GPS fix of 3.
289F comes from 143C, 14 sats and GPS fix of 3.

If I don't receive FasV and Alt, I can't display them!
I'll put the decimal place in the Alt max.

Mike.

Neat about the sats and temp relation.

That's the thing about FasV and Alt, they are received & displayed with 3.4rc5 firmware.
But I need to stick to 3.3.3 due to logging - Logs for developer and rc firmware editions are not interpreted correctly.

I may be able to do something about the FasV value, the voltage is sent in the passthrough data so I'll see if I can use that when there is no FasV value being received. There does not seem to be an alternative source for the Alt value.

Mike.

I appreciate Mike. Hope they release 3.4 soon

@MikeB ,
FasV up and running with 05 Oct 2016 firmware with 3.3.3 - thank you very much!

I know we discussed it a little earlier, and I know you are the developer and understand more....
...but I still don't understand why Alt on the ArduC, RPM and Custom screens can be seen with 3.4r5 custom but not 3.3.3 custom.
I mean that would be complete functionality...unless the square in the middle of the ArduC screen is an artificial horizon?
*note - older picture just to show the square:

The square has to do with the direction the FC is pointing (heading), and possibly switches to home direction when the home information is available.
It seems only 3.4r5 sends the Alt value (barometric) as a specific SPort value, using the Alt ID.

Mike.

Understood.
I will check and see if Craft and Theory can change that in their custom 3.3.3

Both our modified 3.3.3 and the official rc5 sends (when using passthrough - SERIAL#_PROTOCOL = 10):

- GPS MSL altitude in decimeters on ID 0x1002 for our modified 3.3.3 and ID 0x5002 for official rc5: https://github.com/craftandtheory/APM_F ... 66a8e8R454

- altitude relative to home (using inav) in decimeters on ID 0x1004 for our modified 3.3.3 and ID 0x5002 for official rc5: https://github.com/craftandtheory/APM_F ... 66a8e8R519

The protocol that will end up in (hopefully soon) the stable version of Copter is the one found in the official rc5 (Copter-3.4 branch): https://github.com/ArduPilot/ardupilot/ ... rsky_Telem

The protocol found in the offical rc5 has some differences and is updated compared to C&T's modified 3.3.3.

As you were discussing, the rc5 protocol sends the following standard sensor values:
- Alt (altitude in cm above home position) on ID 0x0100
- Vario (vertical velocity in cm/s, +ve up) on ID 0x0110
- VFAS (battery pack voltage in volts) on ID 0x0210
- GPS (gps latitude or longitude, alternates) on ID 0x0800

Only GPS (gps latitude or longitude, alternates) on ID 0x0800 is sent in 3.3.3. The reason there's more raw (not using passthrough) values in the rc5 protocol is that users requested to be able to use them directly in OpenTX (without having to use scripts required by passthrough on the Taranis).

@MikeB

Did something change in the firmware affecting PWM limits?
When I would calibrate my radio by Mission Planner, my lower limits for sticks/ POTs and switches would be 1000
All are now 980-982 except throttle which is unchanged.

I'm not aware of any chnages that would affect that.
You may check the actual outputs in the Limits menu. The currently highlighted channel output value, in uS, is shown on the top line.
The default range is 988 to 2012 uS.

Mike.

Most excellent!
Craft and Theory made the Alt possible with an alternate 3.3.3custom just emailed to me.
All good now until the official 3.4 is released...

...unless someone wants to work on the direction square

But seriously - thank you all!

Ardupilot 3.4 is released.
Checking with Craft and Theory if they have released their custom and I will report back.

Well, not what I really wanted to hear but @MikeB , you might want to see this:
From Florent Martel at craft & Theory...

I looked at your forum post, and it made me think that really soon we're transitioning to not supplying modified firmwares. The main difference with the official ArduPilot firmware compared to the modified one is that we'll use passthrough addresses in the 50xx range for the FrSky packets, instead of the 10xx range. There are other minor protocol changes, so that's an important consideration for the 9Xtreme.

So, if it's a modified firmware, it will work on the 9Xtreme as is. But if you use the official firmware (and ultimately that will be the only one available - no modified version), there's fairly straightforward protocol changes that need to be made to the 9Xtreme code...

As a side note, the protocol needed to evolve because of changes agreed to between FrSky and OpenTX (on the passthrough protocol addresses) but I don't anticipate that will happen again anytime soon.

Best,
Florent

Florent Martel

[email protected]

Both addresses 50xx and 10xx are accepted by ersky9x. I think I'm supporting the "official" protocol, so I would expect 3.4 to work OK.

Mike.

Checking what I have so far, the flight mode labels are mismatched for 3.4.
Everything else looks great!!!!!!

Do you need to select ARDUC instead of ARDUP?

Mike.

ARDUC is what I am using

In that case, do you need ARDUP?
Please detail what the labels are, and what they should be.

Mike.

ARDUP - Not that I know of.
What is the difference?
And actually, what is the difference between all?

Modes seen in ARDUC:

Actual Displayed
Stabelize ACRO
PosHold BRAKE
Auto GUIDED
Land UNKNOWN
RTL CIRCLE
AltHold AUTO
Guided LOITER
Loiter RTL
Circle UNKNOWN
Drift UNKNOWN
Sport FLIP
Flip cannot get it to enter mode obviously
AutoTune same
Brake UNKNOWN

Modes seen in ARDUP:

Actual Displayed
Stabelize CIRCLE
PosHold UNKNOWN
Auto ACRO
Land AUTO
RTL CRUISE
AltHold TRAIN
Guided FBWA
Loiter FBWB
Circle A-TUNE
Drift LOITER
Sport UNKNOWN
Flip cannot get it to enter mode obviously
AutoTune same
Brake UNKNOWN

Let me know if you need anything else.
**Column formatting did not stay as I wanted it to

From Mavlink documents I found, I'm using the following:
Arduplane flight mode numbers (ARDUP):
0 Manual
1 CIRCLE
2 STABILIZE
3 TRAINING
4 ACRO
5 FBWA
6 FBWB
7 CRUISE
8 AUTOTUNE
10 Auto
11 RTL
12 Loiter
15 Guided

Arducopter flight mode numbers (ARDUC):
0 Stabilize
1 Acro
2 AltHold
3 Auto
4 Guided
5 Loiter
6 RTL
7 Circle
9 Land
11 Drift
13 Sport
14 Flip
15 AutoTune
16 PosHold
17 Brake

It seems something may have been changed.

Just to be clear, that is just the order I tested in...my custom 6 programmable flight modes.
Then, what was missed, I went in Mission Planner order.

Here ya go MikeB
From Florent Martel at Craft & Theory:

I looked at the forum and mikeB did things very nicely by providing support for both protocols (older and newer), so you shouldn't even need the modified firmware anymore, albeit this minor difference:

Re. the flight modes, there's a protocol change there whereas +1 has been added to the flight mode number compared to mavlink (so as to avoid sending all zeroes). So stabilize is actually flight mode 1 instead of 0, land is 10, poshold is 17 ...

Did you see the previous MikeB ?

I've done a change to the source files for this, I just haven't had much time so far this week to do much, I was away on Monday and I'm still catching up.

Mike.

I understand.
Getting behind at the warehouse here too.
Just thinking, if the modes are 1 off, why would the name display UNKNOWN if it should simply display the next mode in the list?