Boot probleem r1331

[Peter]

Today I couldn't get the transmitter on. It was stuck on the boot animation. Some dots on the screen.. I had to remove the battery. Open9x revision 1331. Boot logo was disabled.

And I had a momentary custom switch > 100m with a play value ALT. And it kept playing. But I am using my own sensonhub and recently changed the code, so that could be the problem. I will look into that. Does anyone know what the bit layout of a negative value of altitude is in the Frsky protocol?

[bertrand35]

I have fixed the bug with Orphee. It was the SD Initialization which I have changed to be quicker, and with some SD cards it's not ok.
I will commit as soon as all tests are Ok.
Bertrand.

EDIT: Orphee just confirmed it's ok on his board. I release in a few minutes.

[bertrand35]

r1336 released

[bertrand35]

Today I couldn't get the transmitter on. It was stuck on the boot animation. Some dots on the screen.. I had to remove the battery. Open9x revision 1331. Boot logo was disabled.

And I had a momentary custom switch > 100m with a play value ALT. And it kept playing. But I am using my own sensonhub and recently changed the code, so that could be the problem. I will look into that. Does anyone know what the bit layout of a negative value of altitude is in the Frsky protocol?

If my memory is right, there is no negative altitudes in FrSky protocol. But all altitudes do have an offset. The first altitude which is received is considered as the 0-reference. So if you fly below pilot altitude, open9x will report it as a negative altitude.

Last revision should be ok, you will have the possibility to use the |d| > ofs function to play the altitude only when it increases / decreases by X meters.

Bertrand.

[Peter]

I couldn't find any negative altitude info either. But the problem is that I fly under sea level. We have dikes here in holland!
So the start level is negative. I could keep an offset in the sensorhub to correct it.
But can someone acknowledge that the Frsky sensorhub and field display don't report negative height?

If it is not there, maybe it is an idea to add it. I doubt that anyone flies above 32000 meters. So the most significant bit is never used.

[bertrand35]

But even at a negative absolute altitude, the FrSky "baro" sensor will report a positive altitude. We keep it as the 0-reference and use an int16_t to store it!
Bertrand.

[Rob Thomson]

Correct. All these barometers seem to auto calibrate 0 at the height the system is powered on.

Sent from my Nexus 7 using Tapatalk 2

[bertrand35]

Correct. All these barometers seem to auto calibrate 0 at the height the system is powered on.

Sent from my Nexus 7 using Tapatalk 2

Not exactly! You are using the Thermal Scout, which auto calibrates to 0 - it would be interesting to try it in Holland
But the FrSky doesn't auto calibrate, it's the FW on the Tx which does it: the 1st altitude received is considered as the offset, and therefore negative altitudes should be correctly displayed.

Bertrand.

[Rob Thomson]

Oh.... so they must use an internal reference to what they believe sea level is?

I cant imaging this would be very accurate?

Rob

[Kilrah]

Yeah the frsky baro and such seem to have a fixed QNH... when I power up mine it will show "more or less" my place's altitude.

So if the protocol can't send negative numbers, then there's no way to get a display below sea level, even if open9x stores the zero itself - the frsky baro will just be sending 0 all the time.

[bertrand35]

... or garbage, it would be interesting to know ...
Bertrand.

[Kilrah]

Yep, can't exclude that possibility indeed!

[Peter]

I have looking through Frsky.cpp and I can't find a reason why negative wouldn't work. The important variables are all int16_t. Maybe I was fooled by the automatic offset.
I will test it further, but first a Leffe beer and watching Snow White and the Huntsman with my wife..

[bertrand35]

I have looking through Frsky.cpp and I can't find a reason why negative wouldn't work. The important variables are all int16_t. Maybe I was fooled by the automatic offset.
I will test it further, but first a Leffe beer and watching Snow White and the Huntsman with my wife..

In my opinion, the problem is not in frsky.cpp, but in the sensor (or the Hub). It would be interesting to know what it returns in this case. I will ask to Eva.
Bertrand.

[Kilrah]

Just put it in your mouth and add some pressure, you'll see soon enough

[Peter]

That might actually work! To bad it is build into a plane. I have a big mouth, but a whole plane...

[Peter]

I just tested the negative altitude with some test code in an arduino connected to the serial of the receiver.
It just works!
My sensor code already had automatic offset code. When I disabled that, I expected to see a negative value, but I kept seeing 0 at the transmitter.
But I didn't know the transmitter also has automatic offset code.

Bottomline: open9x is awsome!

[Kilrah]

OK, so now you know that negative numbers can go through the telemetry link - now to see if the sensor actually sends some