ArduP screen displaying/processing of GPS status & other Telem data (from Arduino/APMmavlink2Frsky)

er9x is the best known firmware. It has a superb range of features and is well supported by the community. Well worth trying out.
Post Reply
nvd07
Posts: 63
Joined: Sat Aug 15, 2020 8:45 am
Country: France

ArduP screen displaying/processing of GPS status & other Telem data (from Arduino/APMmavlink2Frsky)

Post by nvd07 »

I am playing with an Arduino Pro Mini running Mike's APM_Mavlink_2_Frsky translator

My Matek F405-CTR flight controller running Arduplane was previously connected to a bluetooth stick ; I disconnected this and connected the FC to TXO and RXI of the Arduino Pro Mini ( I left same settings 57600 for the serial1 port in Mission Planner )

By grounding D2 of the Pro Mini I set the output of the translator to be Sport rather than SBUS

And finally I connected the output pin of the translator , D5 , firstly to a Frsky Receiver's Sport with not much success, and then to directly to the back of my 9x radio, to the lowest pin of the module bay, with good success.
So, no module and no Rx involved , no 2.4GHz frsky link , as user LTMNO explained here.

In er9x I switched my Protocol from MPM to XJT , even though none of them are in, so that the expected Baud rate would be 57600

In telemetry I was able to successfully select ArduP (or Frsky as well ).

With this ArduP I get the extra graphical screen as expected.
The status 'No Data' went away and gets replaced with 'Disarmed' which is a good sign.
I am seeing the magnetic bearing react accordingly whenever I move the flight controller on the table.
The altitude and GPS coords seem OK.

About GPS info on the left, I do not understand why my ArduP screen says 'No GPS' at the same time as sat 3 and hdop 11.1
Before and after, the Mission Planner on the laptop was showing '3D fix' and no red warning about 'No GPS'.

I learned about this :
MikeB wrote: Thu Feb 18, 2016 5:24 pm Regarding GPS, this is a bit tricky but is possible. The information is sent as temperature2, coded as 10 times the number of sats + the type of fix:
0 "No GPS"
1 "No Fix"
2 "2D Fix"
3 "3D Fix"
so a value of 52 is 5 satellites and a 2D fix.
....
Mike.
I did not see many people reporting about ArduP with a 9x + er9x;
Fardenco on his 9x with er9x was using HubRaw , so he was not using/seeing this extra screen.
Other people where showing '3D fix' on their 9XRPro screens and ersky9x ; I suspect that for this portion, the code is common to er9x /ersky9x.

I did not see anyone really mention 'NoGPS' , so I must be doing something wrong...
Any Idea ?


I have since toasted my Arduino in the subsequent connexions :mrgreen: but no big deal, I am going to order a few more replacements, as this APM Mavlink2Frsky is great :D Thank you Mike, for making it available to the community!

IMG_20210617_223316.jpg
IMG_20210617_223316.jpg (90.71 KiB) Viewed 9312 times
Last edited by nvd07 on Sun Jul 04, 2021 1:51 pm, edited 1 time in total.

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

Re: ArduP screen displaying/processing of GPS status (from Arduino/APMmavlink2Frsky)

Post by MikeB »

Have a look on another telemetry screen for the value of T2 (temperature 2), it is on one of them at the bottom right (or add it to a custom screen).
It is coded as in the quote above.

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
nvd07
Posts: 63
Joined: Sat Aug 15, 2020 8:45 am
Country: France

Re: ArduP screen displaying/processing of GPS status (from Arduino/APMmavlink2Frsky)

Post by nvd07 »

Mike , as I have toasted/exhausted my inventory of Arduinos yesterday night I cannot have a look at another telemetry screen until next week.
Which also means I do not need any answer/solution right now...

As the weather is too hot and the wind is howling I ventured into your Github ( In the long run you win , as I will be able to find answers and therefore I will ask you less questions ! ;) )

I found the above formula in the APM_mavlink2frsky code which means I downloaded and compiled the correct version of it.


But I think the er9X code differs from ersky9x in just these two lines highlighted below - I cannot see why this would be intentional - could you have a look at the variable names at the left of the assignment operators (sorry I cannot do a proper diff to show it here): gps_sat and gps_fix are swapped

https://github.com/MikeBland/mbtx/blob/ ... 115-L21116

https://github.com/MikeBland/mbtx/blob/ ... 8048-L8049
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ArduP screen displaying/processing of GPS status (from Arduino/APMmavlink2Frsky)

Post by MikeB »

Good spot! I've fixed that, committed the change to Github and built a test version, which I have posted (er9xProv822z).

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
nvd07
Posts: 63
Joined: Sat Aug 15, 2020 8:45 am
Country: France

Re: ArduP screen displaying/processing of GPS status (from Arduino/APMmavlink2Frsky)

Post by nvd07 »

Ok Mike thank you for the fix !

Z already - you are going to run out of letters !

I downloaded it and flashed it today.

nvd07
Posts: 63
Joined: Sat Aug 15, 2020 8:45 am
Country: France

Re: ArduP screen displaying/processing of GPS status (from Arduino/APMmavlink2Frsky)

Post by nvd07 »

so I received more Arduinos and I made a correct connection this time:

This allows me to connect my F405/Arduplane to Mission Planner in a Bluetooth link full Mavlink, ie the F405's Tx/Rx are connected to the Bluetooth stick, while I also put a single of these wires to the APM_Mavlink_2frsky Arduino's Rx pin, which then does the translation into Sport for the lower pins of the 9x module bay. so er9x can listen to the translation of the Mavlink data being sent by the F405-CTR's Tx pin, at the same time as Mission Planner gets the native mavlink. :P
OK_NoFix_with_0_sats.jpg
OK_NoFix_with_0_sats.jpg (68.67 KiB) Viewed 9235 times

Below are my findings with er9x firmware 822z, and ... my questions as a first time ArduP telemetry user. :?
I have looked at some other alt/gAlt discussions on this forum, from one year ago, but they were about ersky9x and Pixhawk. From them I could not come to any conclusion for the present er9x/Mavlink/ArduPlane case.

The data seen on ArduP screen:

arming status : ok

GPS sat : ok now, the GPS satellite numbers match between Mission Planner and er9x


GPS fix : not OK yet in 822z (when sats are >0) because I was not clear in my previous posts - sorry. My sentence implied that the right hand part was correct, while in fact the variables were swapped everywhere. So, on the second line, the right hand still needs: - gps_fix * 10 ; to be replaced by - gps_sat * 10 ;
https://github.com/MikeBland/mbtx/blob/ ... .cpp#L8049
so that it will match:
https://github.com/MikeBland/mbtx/blob/ ... cpp#L21116
NOGPS_with_10_sats_3Dfix.jpg
NOGPS_with_10_sats_3Dfix.jpg (69.03 KiB) Viewed 9235 times


gAlt : nok, solid 3 right now... but as I was able to see more digits before the GPS fix (when the figure was way off) , the GPS alt was alive, 13885-ish on Mission Planner and 138 on er9x, so this probably comes through and needs a factor of 100


hdop : there is a extra factor 10 involved (so this time, it needs to be slashed) : 1.01 in mission planner while 10.1 in er9x


dth : OK: starts working as soon as I ARM the arduplane, and units/factors look they match well between Misson Planner and er9x


alt (baro alt): difficult to say, I am confused :

- It seems to fluctuate more in my er9x than in Mission Plannner. but the delay makes it difficult to compare.
At some point in the initial fix or initial arming, the alt's initial offset is suddenly reset to zero, without me doing anything to it, so that's probably part of the intialization sequence...
- next, mission planner has a toggle button (in 'Actions'), which seems to make 'baro alt' change back and forth from ASL to AGL. And er9x has an alt offset nulling too... So i tried to set Mission Planner at zero first, and soon afterwards I nulled alt in er9x... then looked at both. I saw that fluctuations were bigger in er9x.
Could it be that the scaling factor 100 was put on this baro alt, rather than on the gAlt?


(I could not test the other items of the screen as there was just 'copper wires' in my setup rather than a radio link)


At this stage I could not say if all the scaling factors I mentionned in this post are required because of :

- differences between how the developpers implemented the main existing solutions : I mean teensy vs ArduProMini (APM_Mavlink_2frsky) ? different conventions ?

or

- er9x remained behind ersky9x in terms of bug fixes for the ArduP portion of the code, as there does not seem to be many er9x users of ArduP.


I mean, if people are asking different factor values, each one his own, then there never could be an er9x firmware that will make eveybody happy. So instead we could put the required scaling factors in each people's APMmavlink2frsky ino sketches/code instead ...
:?:

( note all this was with ArduPlane 4.1.0beta1 , Mission Planner 1.3.74, APM_Mavlink_2frsky from Mike's github dated 28 sept 2016. )
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ArduP screen displaying/processing of GPS status (from Arduino/APMmavlink2Frsky)

Post by MikeB »

I'll sort the GPS fix.
Galt on er9x should be in metres. What units is mission planner using? 13885, if in metres, is 13 km high! On er9x, when less than 100m, it should change the display to have 1 decimal place.
I'll investigate hdop and Balt.

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
nvd07
Posts: 63
Joined: Sat Aug 15, 2020 8:45 am
Country: France

Re: ArduP screen displaying/processing of GPS status (from Arduino/APMmavlink2Frsky)

Post by nvd07 »

MikeB wrote: Wed Jun 23, 2021 10:43 am Galt on er9x should be in metres. What units is mission planner using?
My Mission Planner came in meters all across (and a mix of English+French). I also experimented by changing this to feet (in Config/Planner/DistUnits) and subsequently all the displays/tabs got refreshed correctly (even the ones where the units are not mentionned), so it looks like there is no problem there.
MikeB wrote: Wed Jun 23, 2021 10:43 am 13885, if in metres, is 13 km high!
This was before acquiring satellites. I was in the middle of the south altantic too. It looks like the init procedures do not rule out being onboard a Concorde flight to Rio for some glamourous holidays... :D

What convinced me is that the house I am in, is sitting on a rock 360-370m above sea level, and gAlt shows a solid 3, which would be consistent with:
ArduP's gAlt = truncation of (370/100)

( the factor 100 and 'no decimal place' hide the usual drift/wandering of GPS calcs , this is why I am saying 'solid 3' )

hopefully this pic will make it understandable:
gAlt_house360mASL-.jpg
gAlt_house360mASL-.jpg (59.9 KiB) Viewed 9211 times
MikeB wrote: Wed Jun 23, 2021 10:43 am On er9x, when less than 100m, it should change the display to have 1 decimal place.
right now on er9x, I confirm that alt can show one decimal place, but not gAlt:
gAlt_digits.jpg
gAlt_digits.jpg (66.92 KiB) Viewed 9211 times
MikeB wrote: Wed Jun 23, 2021 10:43 am I'll investigate hdop and Balt.

Mike
Thank you Mike as always. no pressure whatsoever from my end - right now I cannot fly, this is a pizza box for now !

I may add that in case no one has ever sent any feedback about the arduP screens on er9x , it might be worth waiting until when I will receive my orangeRx 433mhz modules (about 10 days from now), I could give you some feedback as well about the lower portion of the ArduP screen (RSSI-SWR/RCQ... areas).
You could then bundle the changes, if any, together in a single commit/build/publication of the ZIP. ( I am slow in putting these components together and I feel embarrassed about repeatedly triggering all these multiple releases of test versions from you! )
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ArduP screen displaying/processing of GPS status (from Arduino/APMmavlink2Frsky)

Post by MikeB »

hdop in er9x is set as 1 decimal place, in erskyTx it is 2dp, I'll change er9x to match.
GPS_alt looks to be handled the same in erskyTx and er9x. I note that in the Arduino code, there is a /1000 on the Mavlink data before it is passed on as SPort data.
Perhaps you could try changing the /1000 to /100 and see if the Galt value changes to 37 (around line 163 in Mavlink.cpp "return gps_alt/1000;").

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
nvd07
Posts: 63
Joined: Sat Aug 15, 2020 8:45 am
Country: France

Re: ArduP screen displaying/processing of GPS status (from Arduino/APMmavlink2Frsky)

Post by nvd07 »

Ok so in APM_MAvlink_2_Frsky I found
in Mavlink.cpp "return gps_alt/1000; as you mentionned, Mike

and I changed this scaling factor and re-flashed the arduino. it immediately did the expected effects onto the er9x ArduP display

( I would say that the original 2014-ish code was tailored to accomodate a flight controller (+ firmware) were the Mavlink output had different units on Baro alt and GPS alt ... a good recipe for mission disaster, I would say... )


From there I chose
return gps_alt/10; instead of return gps_alt/1000; ( based on my conclusions from the previous day. )

Next, as soon as enough satellites got acquired after power up, ArduP immediately displayed the correct altitude for my house.

I refrained from touching the scaling factor for Baro alt (return altitude; now) , at the same time (although I do not get why they require different scaling factors)

so right now my APM_Mavlink2Frsky has been modified to :

const float Mavlink::getGpsAltitude()
{
setHomeVars();
return gps_alt/10;
}

and a bit further, there is the untouched :

const float Mavlink::getAltitude()
{
return altitude;
}
(so , no scaling factor at all here ...)


With this, I took my gear (except the laptop / Mission Planner ) on a car trip to the supermarket at the bottom of the valley as it is a significant altitude drop, easy to draw conclusions from.

I switched on the whole setup down by the river, and as soon as the GPS had acquired the right amount of sats, the GPS alt was correct : 136m (ASL).
Startup_down_the_valley.JPG
Startup_down_the_valley.JPG (76.32 KiB) Viewed 9181 times
Similar to what I saw yesterday, the initial Baro alt was pretty much lined up with the GPS alt (ASL) and i suspect ArduPlane does this as soon as the GPS fix is good, but it does it only once (not a constant chase/update until you arm/fly the plane), as you will see in the end. Probably, at startup, er9x does not apply any offset at all to the received MAvlink figures (until the user starts to use the Zeroing menu).

Next, in er9x, I zeroed the altitude (baro) before the drive back to my home (uphill).
Zeroing_down_the_valley.JPG
Zeroing_down_the_valley.JPG (73.95 KiB) Viewed 9181 times
After the drive and when arrived at home the Galt was 355 m again, so it was good, and the (baro) alt was 219m (ie +219m compared to when I zeroed it), which was consistent with the uphill climb I just did (355-136). Which means the scaling for baro is right at the moment, and also ArduPlane did not make any change to the baro offset during my drive.
Back_home_up_the_hill.JPG
Back_home_up_the_hill.JPG (99.93 KiB) Viewed 9181 times
:arrow: So right now the scalings that my modified APM_MAvlink_2frsky is doing ( 1/10 for GPS and 1:1 for baro), are the right factors for my current setup/gear/firmware in order to get a correct display on ArduP ( er9x 822z ).

[ Now to anyone doing similar experiment : I stayed DISARMED, because if you ARM arduplane , it will try to zero both the baro alt and the GPS alt (!) at the arming point; which includes applying whatever offset to the GPs alt before outputting MAvlink! then Mavlink GpsAltitude becomes GPSAGL ie no longer the same as AltAsl of Mission Planner ( the red line of my previous post becomes more complicated )... How not to get confused by the altitudes origins ... another topic entirely ! ]
nvd07
Posts: 63
Joined: Sat Aug 15, 2020 8:45 am
Country: France

Re: ArduP screen displaying/processing of GPS status (from Arduino/APMmavlink2Frsky)

Post by nvd07 »

As I have done more testing of the er9x ArduP screen, but will not be able to do any more in the coming weeks, it is time to summarize what I saw:

Part I - from to weeks ago:
GPS fix: so in er9x there was the right hand where gps_fix needs to be replaced by gps_sat
https://github.com/MikeBland/mbtx/blob/ ... .cpp#L8049

GPS hdop: in these two lines Mike you mentionned there is a difference between er9x where they are PREC1
https://github.com/MikeBland/mbtx/blob/ ... .cpp#L8067
https://github.com/MikeBland/mbtx/blob/ ... .cpp#L8072
whereas in ersky9x they are PREC2.
(however my understanding is that it does not explain the factor 10 difference I saw between Mission Planner and er9X ArduP, so in the end I might put a factor in my arduino APM_Mavlink2frsky sktech, in order to reconcile Mission Planner hdop and er9x hdop).



For the altitudes figures and factors that I showed last time - I further looked at the code to try to see if I could see a difference that might explain why I need different scaling factors in arduino IDE ( different between baro and gps ) and noticed the following:

-For GPS alt, the outdez function seem to be given, as arguments, the get_telemetry_value(TEL_ITEM_GALT), followed, or not, by any attr argument of a PREC format ; however regardless if the attr argument is there or not, in all cases, there is no scaling by a /10 factor onto the get_telemetry_value(TEL_ITEM_GALT) :
https://github.com/MikeBland/mbtx/blob/ ... .cpp#L8096
https://github.com/MikeBland/mbtx/blob/ ... cpp#L21182
So i turn this makes me wonder why a /10 is involved some times with the Baro alt in er9x and in ersky9x:

-For the Baro alt only, there are these lines, I would say they not only take care of showing more decimal places in cases when the Baro alt is small, but they also seem to apply a scaling factor of /10 in the opposite case; however i do not know how it is supposed to work together with attr=0 or PREC1 or PREC2 :
https://github.com/MikeBland/mbtx/blob/ ... cpp#L21159
https://github.com/MikeBland/mbtx/blob/ ... cpp#L21166
https://github.com/MikeBland/mbtx/blob/ ... cpp#L21170
nvd07
Posts: 63
Joined: Sat Aug 15, 2020 8:45 am
Country: France

Re: ArduP screen displaying/processing of GPS status (from Arduino/APMmavlink2Frsky)

Post by nvd07 »

Part II of the summary/ looking at the bottom of the er9x ArduP screen

( As my Ultimate LRS 433 Rx module no longer works (probably due to a brownout event , or worse), I do not need any of the previously mentionned stuff (GPS_fix..) solved urgently at all in er9x. Nor do I need any of the stuff below to be looked at with any degree of urgency whatsoever!

But as I will not be able to provide more inputs I thought it would be the right time to summarize and post here. )



So earlier this week I was able to replace my copper wires by a UltimateLRS 433MHz connection.
For a short period of time I was able to get the ArduP screen for telemetry display on er9x (through the Arduino Pro Mini APM_Mavlink2frsky) and at the same time the Mission Planner on the laptop (through the bluetooth stick), so I made comparisons and screenshots.
IMG_20210703_005106_ULRS433_ArduP.jpg
IMG_20210703_005106_ULRS433_ArduP.jpg (68.09 KiB) Viewed 9067 times
IMG_20210703_005106_ULRS433_Custom.jpg
IMG_20210703_005106_ULRS433_Custom.jpg (69.66 KiB) Viewed 9067 times
IMG_20210703_005115_ULRS433_MissionPlanner.jpg
IMG_20210703_005115_ULRS433_MissionPlanner.jpg (137.36 KiB) Viewed 9067 times
The RSSI displayed ok in ArduP - both the number and the Rx barchart below it. The true value of 128 seen in the custom telemetry display got truncated at 100 in ArduP, but this is consistent between er9x and ersky9x.
So if UltimateLRS goes up to 128 max, then I might put a scaling factor (100/128) in my arduino APM_Mavlink2frsky sktech.

Next, the TSSI/Rcq - this got me thinking. :?
The Tx bar chart got me concerned as it looked empty (unlike the Rx barchart which was full).
However the TSSI/Rcq figures (0) seemed to be received correctly and were displayed consistently in ArduP and in the Custom telemetry screen.
So I looked at other scenarios, when I am running the Frsky D16 with my Grx8 Frsky receiver and 4-in-1 multimodule ( instead of UltimateLRS 433 ), in a similar way, the Tx bar chart is also empty, and the bar is full for the Rx.
IMG_20210704_122606_FrskyD16_Grx8_Custom.jpg
IMG_20210704_122606_FrskyD16_Grx8_Custom.jpg (81.47 KiB) Viewed 9067 times
IMG_20210704_122555_FrskyD16_Grx8_ArduP.jpg
IMG_20210704_122555_FrskyD16_Grx8_ArduP.jpg (81.18 KiB) Viewed 9067 times
Looking back, I have seen the Tx bar chart , to be nearly full (as intuitively expected), but only for protocols like Flysky AFHDS2A like this
https://openrcforums.com/forum/viewtopi ... 30#p151609. Probably, to be able to show full bars in all scenarios would need complicated switch/case in the code for several screens. And this is a matter of conventions from a long time ago, now the difference between AFHDS2A and FrskyD16 has probably existed for so long that people by now are probably used to see, in the latter scenario, the Full Rx bar on the left and the Empty Tx bar on the right.

After the testing i looked at the code too;

I noticed that in ersky9x there is an additional switch to allow a Swr label, here
https://github.com/MikeBland/mbtx/blob/ ... cpp#L21198
instead of always showing a Rcq label in er9x
https://github.com/MikeBland/mbtx/blob/ ... .cpp#L8111


Now for other telemetry elements:

For the graphical square display for the heading in the middle:
There are 4 additional lines (with a ' if FrskyHubData[ Fr_Home_DIR ] ...' ) in ersky9x
https://github.com/MikeBland/mbtx/blob/ ... 228-L21231
which are not in er9x and might be needed (?) for consistency.


There is an additional convertRxv[ FR_RXV ] in this line in ersky9x
https://github.com/MikeBland/mbtx/blob/ ... cpp#L21252
instead of just FR_RXV straight unconverted in er9x here
https://github.com/MikeBland/mbtx/blob/ ... .cpp#L8166


next, this section is longer in ersky9x
https://github.com/MikeBland/mbtx/blob/ ... 257-L21273
but I believe this is normal because of the extra module[1].
However next the er9x code does not have this elseif found in erksy9x :
https://github.com/MikeBland/mbtx/blob/ ... 274-L21277


( Last there is in er9x a longer section , but I believe the call to a procedure was commented out and instead its code was incorporated directly:
https://github.com/MikeBland/mbtx/blob/ ... 8182-L8199
instead of :
https://github.com/MikeBland/mbtx/blob/ ... 767-L10786 )

And... it is the end of this lengthy post! :)
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ArduP screen displaying/processing of GPS status & other Telem data (from Arduino/APMmavlink2Frsky)

Post by MikeB »

If D16 protocol is active I think the TX SSI is then SWR (from a XJT), the TX SSI is not reported by a XJT.
er9x doesn't have a menu item to set the scaling for RxV, so doesn't need the convertRxV() function.
The FrSky vario reports Galt in cm, er9x stores the value/100 so just whole numbers. erksyTx stores value/10, so 1 decimal place. While I could change er9x to use /10, I need to then check the rest of the code to make sure it handles the resulting value correctly (e.g. voice output).

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
nvd07
Posts: 63
Joined: Sat Aug 15, 2020 8:45 am
Country: France

Re: ArduP screen displaying/processing of GPS status & other Telem data (from Arduino/APMmavlink2Frsky)

Post by nvd07 »

Ok so Flysky AFDHS2A or Frsky DJT will report, as long as there is a powered receiver, the Tx RSSI. And a full Tx bar means good.

whereas

FrskyXJT/ D16 will report, even if the receiver is not powered ( because it does not matter), the SWR of the Tx. And an empty bar means good.

Here on my pics it looked like OrangeRx433/ultimateLRS were not reporting any Tx SSI or any SWR, so the bar will remain empty all the time.

MikeB wrote: Mon Jul 05, 2021 3:17 pm The FrSky vario reports Galt in cm, er9x stores the value/100 so just whole numbers. erksyTx stores value/10, so 1 decimal place.
Ok I did not see the storage difference between er9x and erskyTx so I am probably all confused here.

Do you know - from users or from Frsky - if the Frsky GPSes use the same altitude units as the Frsky vario/alt (centimeters)?
( i do not have any Frsky GPS , just curious as always )

MikeB wrote: Mon Jul 05, 2021 3:17 pm While I could change er9x to use /10, I need to then check the rest of the code to make sure it handles the resulting value correctly (e.g. voice output).
Ok I was just listing the differences to try to understand my altitude units, but I do not mean that er9x and erskyTx absolutely need to be fully identical all the way to variables storage ( to change this now, might not be the best interest of the project). if they behave consistently with each other but are implemented differently then this is totally understandable.

Post Reply

Return to “er9x”