GPS sensor

[nigelsheffield]

mstrens i am a little confused with the numbering of the split gps,
not sure if i am understanding it wrong or if its a typo.
but I dont see how the hubgpscount is reaching 4?
I noticed it when thinking of sending the course more often.

else if ( hubGpsCount == 4 ) {
SendValue(FRSKY_USERDATA_GPS_CURSE_B , (uint16_t) ( GPS_ground_course / 100000 ) ) ; // Course degrees
SendValue(FRSKY_USERDATA_GPS_CURSE_A , (uint16_t) ( (GPS_ground_course % 100000) / 1000 ) ) ; // Course 2 decimals of degrees
}
hubGpsCount++ ;
if ( hubGpsCount >= 3 ) hubGpsCount = 0 ;

[jhsa]

Too much spinning lately

João

[mstrens]

mstrens i am a little confused with the numbering of the split gps,
not sure if i am understanding it wrong or if its a typo.
but I dont see how the hubgpscount is reaching 4?
I noticed it when thinking of sending the course more often.

else if ( hubGpsCount == 4 ) {
SendValue(FRSKY_USERDATA_GPS_CURSE_B , (uint16_t) ( GPS_ground_course / 100000 ) ) ; // Course degrees
SendValue(FRSKY_USERDATA_GPS_CURSE_A , (uint16_t) ( (GPS_ground_course % 100000) / 1000 ) ) ; // Course 2 decimals of degrees
}
hubGpsCount++ ;
if ( hubGpsCount >= 3 ) hubGpsCount = 0 ;

You are right. It is a bug. Last line should test on "5" instead of "3".

It is fixed now on Github.

[mstrens]

@nigelsheffield

Since we split the GPS data into several frames for the hub protocol, did you check if the GPS Altitude is still right on Tx display.
Another member (using openTx 2.1.x) says that GPSAlt is wrong.
It could be that, to handle it properly, openTx expect GPSAlt in the same frame as Long and Lat. I see some old code in oXs where Long and Lat where forced to a dummy value when telemetry field GPSAlt was (mis) used to transmit another data (this code could be used before GPS has been implemented).

[nigelsheffield]

Could it be that GPS alt was wrong because of the bug just found?
Before I changed the counter reset line I was not getting any gps altitude ....I have it displayed now.

[nigelsheffield]

I will do a short test with logging enabled to see if its correct now in the Google maps as before this was wrong...

[mstrens]

Could it be that GPS alt was wrong because of the bug just found?
Before I changed the counter reset line I was not getting any gps altitude ....I have it displayed now.

Normally, changing the counter reset line should not have an impact on GPS Alt.
Normally GPS Alt was already sent (because it is based on counter == 2).

[nigelsheffield]

a short test shows in logs -23 rather then old tests where alt was +47.
but this may not be conclusive as my gps lock is poor ( indoors as dark and raining outside...)

[nigelsheffield]

swapping between x6r and d8r the gps alt is off, x6r is plus 50 and d8r is minus 20 around....
I will experiment with sending alt data with lat and long,

[nigelsheffield]

OK I tried all combinations and no difference, even reverting back to sending all gps data in one go and still gps alt is lower on d8 then x6r,
x6r reports higher then it should be but again this could be my gps reception.
d8r reports about minus 5 and x6r reports plus 56
But thinking back now altitude has not been right for a while when I tried to look at logs.
either way I dont think this is related to splitting gps.

[mstrens]

Thanks for the tests.
30 min ago, I put on github a new version that will perhaps fix this issue (I am not sure).
The last change I just made is not related to the split of GPS data but it goes over a conversion from 32 bits to 16 bits.

Perhaps you can test this last version

[nigelsheffield]

that looks same as x6r now.

[nigelsheffield]

I have to change this line every time I test to get hub to be same as s.port, heard nothing from opentx on the difference in decimal place...
I will probably change my code from using the temp1 and temp2 to accx,y,z to make more sense and to free up the temp in case of someone wanting them
#elif defined(ACCZ_SOURCE) && ( ACCZ_SOURCE == TEST_3)
SendValue( FRSKY_USERDATA_ACC_Z , (int16_t) test3.value * 10) ;

is it definitely sending same to both s.port and hub?

[mstrens]

Yes, oXs fills the telemetry field in the same way for Hub and SPORT for fields like TEMP and ACC.
Depending on the protocol, the same field (e.g. AccY) is sent with a different fieldID that identifies the field.

OpenTx handles them in different ways. E.g. for Temp1 or Temp2, openTx just display the received value (no decimal point added, no digit lost).
For the 2 Acc, in the hub protocol, I remember that the 2 last digits are lost (at least on the display, I do not know in the log). That is the reason why I often use Temp1 or Temp2 in the setup when possible.
So, I am nearly sure that openTx has also a special handling over Acc for HUB.

Now, it could be that the HUB protocol as defined by Frsky requires from the sensor to send a value 10 X bigger then the SPORT. Perhaps has openTx taken this into account. I do not know because I do not have the detailed specifications of both protocols.
If really Frsky has defined that acc values in Hub protocol have to be 10 X bigger, I could for sure change oXs accordingly.

[mstrens]

I had a look at openTx source.
I found 2 tables where the field ID are defined.
One is for SPORT and one is for Hub.
In the table for SPORT, ACC are defined with 2 décimals while for Hub with 3 decimals.
This explains the results you got.

Now, the question remains : is this difference foreseen by Frsky or is it a bug in openTx?
Kilrah would probably be able to answer this question.

[MikeB]

According to the spec. for the SPort and hub protocols, both should be sending the Acc values as g/1000, so 3 decimals. Without actual sensors I can't check what they actually send.

Mike.

[nigelsheffield]

https://github.com/opentx/opentx/issues/3274

A link to my issue raised, no response yet.
Kilrah looks very busy..
If the problem is opentx and it sounds like it is then I will just change my code for now I guess and change it back if the problem gets fixed.

[nigelsheffield]

an update on the response from opentx,
they admit the error and are considering the fix but note that other projects use the acc numbers as is now and so would need changing back in the other projects too ...
I will have to keep changing that line for now i guess. No big deal..

[nigelsheffield]

Mstrens, I have ordered a compass board with 5883l like the one on gy-86 and intend to put it on the tx on s.port connector in order to give me my own compass heading so I can know which way I am facing in relation to the aircraft when flying by instruments display.
once I upgrade to openxtx 2.1 I can also have a second gps connected and could fit that on same arduino to give my actual position as home rather then the first gps lock position, this could be handy if I dont want to wait for gps lock before flying and or I move around.
I was told i would probably need the gy521 which I have in order to get proper no drift heading.
Question would I be better off writing a separate code for it or could it be added to openxsensor do you think?
note this is not going to happen quickly as china post is notoriously slow lol but Im just getting an idea of what I need to think about.

[mstrens]

I have never used a compass still I do not think that you have to add the gy521.
As far I know, gy521 has only a 6050 (accelerometer + gyro). Gyro provides rates of rotation but is unable to find North, South...
If fact in initial system, a magnetometer is added to the gyro in order to (re)align the yaw calculated by the gyro (otherwise, it would drift).

The orientation (North/South...) provided by a magnetometer is not always accurate due to electromagnetic pertutbations.
If electromagnetic perturbations changes continously in all directions, I can imagine that combining gyro and compass can increase the accuracy (gyro is then used for short terms movement and compass is used to realign the gyro).
The question is : how big are the electromagnetic perturbation in your application?
Easiest would probably be to start without GY521 and to check if the orientation is stable enough. It is also very easy to add some king of filter on the orientation provided by the compass (averaging the values or using a smoothing filter).

About adding code to openXsensor: Are you sure that the same Sport signal/protocol can be handled by the Rx and the Tx?
If not, it is for sure better to use another sketch for your project.
If yes, it could perhaps be added but I think that it should not be done in the master branch because nearly all memory is already used. Furthermore, adding a 5883 board would require another code than using the compass from a gy-86 (because with the gy-86, the compass has to be read through the 6050).

[kcaldwel]

Just as a heads-up, I am getting an OXS GPS speed reading of about 2x the actual in a test against a calibrated car speedometer and another GPS. The N2 airspeed sensor is also reading the same, about 2x too high, using the 47.1 ratio in the Taranis telemetry. This is with a B model Taranis using OpenTx 2.1.7, metric set for the Tx, kph for the GPS and airspeed units.

I posted this to OpenTx GitHub as well, because I suspect something has happened to the units conversion in OpenTx. I think I was getting correct GPS speed with a previous version of 2.1.x and a FrSky GPS, but I can't find the log file today.

https://github.com/opentx/opentx/issues/3043

Kevin

[mstrens]

I read shortly issues/3043.
I understand that it was related to airspeed and not to GPS speed.
I think that at the beginning of 2.1, openTx team had expected that airspeed was transmitted by the sensor in km/h.
In fact Frsky sensor sent the value in knot/h (in fact in 1/10 of knot/h=
OpenTx fix it.

I think that FRSKY GPS is also expected in 1/10 of knot/h. OpenTx team as far I know has always expected that GPS speed would be in 1/10 of knot/h.
If you are using oXS, please use in oXs the setup that ask for sending GPS speed in knot/h and not in km/h. The conversion in km/h will be made by openTx.

In fact, I think I should change oXs in order to discard the setup km/h or knot/h when SPORT protocol is used.
In Hub protocol, it is already discarded.
This set up should be applied only for other protocols like Multiplex.

[nigelsheffield]

To test the sensor connected to s.port on tx
I connected a openxsensor with just vario to RX ( tried both d8r and x6r ) and then put my own s.port pitch roll sensor on the tx s.port pin, both vario and pitch roll worked at the same time.
I know the heading thing could be done with ppm but doing GPS could not be done with ppm.
Also i believe this opens up some interesting possibilities such as communicating data between the s.port sensor in tx and the s.port sensor in RX , one use for this might be sending data to control individually addressable LEDs or tuning sensor settings.( not sure how this is done but I remember reading its possible).

I have never used a compass still I do not think that you have to add the gy521.
As far I know, gy521 has only a 6050 (accelerometer + gyro). Gyro provides rates of rotation but is unable to find North, South...
If fact in initial system, a magnetometer is added to the gyro in order to (re)align the yaw calculated by the gyro (otherwise, it would drift).

The orientation (North/South...) provided by a magnetometer is not always accurate due to electromagnetic pertutbations.
If electromagnetic perturbations changes continously in all directions, I can imagine that combining gyro and compass can increase the accuracy (gyro is then used for short terms movement and compass is used to realign the gyro).
The question is : how big are the electromagnetic perturbation in your application?
Easiest would probably be to start without GY521 and to check if the orientation is stable enough. It is also very easy to add some king of filter on the orientation provided by the compass (averaging the values or using a smoothing filter).

About adding code to openXsensor: Are you sure that the same Sport signal/protocol can be handled by the Rx and the Tx?
If not, it is for sure better to use another sketch for your project.
If yes, it could perhaps be added but I think that it should not be done in the master branch because nearly all memory is already used. Furthermore, adding a 5883 board would require another code than using the compass from a gy-86 (because with the gy-86, the compass has to be read through the 6050).

[kcaldwel]

I read shortly issues/3043.

I think that FRSKY GPS is also expected in 1/10 of knot/h. OpenTx team as far I know has always expected that GPS speed would be in 1/10 of knot/h.
If you are using oXS, please use in oXs the setup that ask for sending GPS speed in knot/h and not in km/h. The conversion in km/h will be made by openTx.

In fact, I think I should change oXs in order to discard the setup km/h or knot/h when SPORT protocol is used.
In Hub protocol, it is already discarded.
This set up should be applied only for other protocols like Multiplex.

So I can just comment out the kmh lines in OXS for the GPS and airspeed, and the OXS airspeed and GPS speeds should be correct - again!

By the way, a knot is a nautical mile per hour, so you don't need to say knot/h.

Thanks again.

Kevin

[nigelsheffield]

Just did a test to see how much drift there is just using the 6050, its a lot less then I expected, left it on for 20 mins and it drifted by only 6 degrees.
So calibrating it will not be required very often and could even be done in my script by comparing it to plane heading when in same orientation as tx or by using the heading to plane whilst holding tx pointing at plane in sky. This would need manually Calibrating though of course and only once GPS is locked and providing good data.
Once I have a compass I could do away with manual calibration so I will still prefer it if that can be made to fit in code too.
All this and I still have not even flown with GPS or IMU enhanced vario yet lol.
Roll on summer!

[nigelsheffield]

I got the heading working in tx using the 6050 and s.port pin , needed to use termp1 in tx and acc values RX sensor as the acc values belong to same sensor and it would not work splitting them .
To get the heading working I had to enable vario so code for ms5611 is in too, this did not seem to matter though as there was no ms5611 on board so tx responded the the one on the RX sensor.
I made it so that when I pull a switch it calibrates the tx heading to "heqading_to" so I just face the plane and pull the switch to calibrate.

[Carbo]

I am fighting with a GY-521 on a "recycled" arduino pro mini to get the TX-heading. Before i change the hardware: what does it mean, if the Arduino LED blinks in 1s intervall? The oXs sketch was written successfully. Is there a debug routine always active, that causes the blinking? Debug is disabled in the config.h. The oXs works neither in the TX nor connected to a RX.

By the way: Nigel, is it sufficient, to aktivate the S-Port mirror for the module bay, or do i have to aktivate S-Port-telemetry input for the module?

[nigelsheffield]

I tested it with opentx 2.0 and 2.1 and it worked OK just on the tx s.port pin or the RX s.port pin.
Sounds like you have a problem if it's flashing led and you get nothing from it..
Do you see it in sensor page if you discover new sensors?

[Carbo]

No, the oXs was never detected. Probably a hardware issue. Only the blinking LED makes me wonder, if it gives a hint about the reason of the malfunction. I have a new arduino here, to test further.

[mstrens]

Does the LED blink only at power on during a few second or does it blink continously?
At startup, I think that the bootloader that is preloaded in Arduino blinks the led.
I think that oXs blinks the led only when using the push button option or when the option #define DEBUG_BLINK is activated in the config.h.
This option (DEBUG_BLINK) can be activated (even without activating the option DEBUG) in some cases.
It can be usefull e.g. to check that oXs program runs without slowing the process down like (what is the case when characters are sent to the Pc terminal ). It is normally only used by me and I would have to check the code to see what happens in latest version when this option is activated.