OpenXSensor SPORT Interface

[RightRudder]

Where is this extra telemetry setting? I don't see it. I am running ver 1.99 from the Mar 22 build. There is one new line says top bar and a check box for altitude (don't know what it means) but the rest of the vario telemetry settings looks like before. Variometer source is limited to Vspd, A1, A2, and dTE (don't know dTE but when I choose it there are no new options for telemetry).

[Kilrah]

They're in the radio settings.

[mstrens]

Where is this extra telemetry setting? I don't see it. I am running ver 1.99 from the Mar 22 build. There is one new line says top bar and a check box for altitude (don't know what it means) but the rest of the vario telemetry settings looks like before. Variometer source is limited to Vspd, A1, A2, and dTE (don't know dTE but when I choose it there are no new options for telemetry).

Bertrand worked on this before a nighlybuild 1.99 was available.

New fields are present on the panel to set up telemetry in special version that Bertrand send me and that I put in the post on link:
viewtopic.php?f=86&t=5081

The latest version was posted on 24 febr. The file name contains the number "15".

If you hear the new tones but do not see the new fields, it means that there is some bug in the nightly build.
I did not yet test the nightly build 1.99 on the Tx it self but I look at companion9x on the PC.
I noticed that the new fields where missing in companion9X and I reported it to Bertrand.
He confirmed me that they would be added.
An issue 808 is open.

Perhaps that those fields are presents on the Tx display but just not on the Pc screen (companion9x).

If you do not find the fields on the Tx display, you could use the bin file (version 15) provided in the link hereabove.
Take care that this bin was only for Taranis.
This version will not contains some other changes but will let you test the expected changes to vario in openTx 2.0.
In february, I was able to upload this firmware using the "old" version of companion9x but I had to save my EEPROM and to recalibrate the stick.
Please note (as said in the post) that this version (15) let generate the tone based on VSpd provide by the sensor OR based on the position of a stick. This was just in order to test the tones. In final version, tones should be generated only based on the data provided by the vario sensor. In Betrand config, the simulation was done using the Throttle stick but in my case it was with the elevator stick (and it could even be another one for some other user).

dTE as been added as a new telemetry field on request of users having a compensated vario. It means delta total energy I think.
In special version 15, this field was used to activate the simulation mode (controling tones with a stick).
Even if dTE is added for sound generation in version 15, I think that it was not yet possible to get this new field from Rx using SPORT (or Hub) protocol.

If you have more questions, don't hesitate.

[RightRudder]

Thanks for that Michel. There are so many threads going on this forum, hard to keep up with it all. I got it working the way I like. I had to use 3 logical switches to keep the silent band. It works like a real vario now. The audio is still glitchy but that's not an issue I guess.

Now back to oxs using SPORT. while testing the vario I had a jumper between the A2 pin (which is assigned for the current signal) and vcc so the current is max. EEPROM code is active. So the "fuel" level is decreasing from 100%. when it gets to zero it rolls over to 0xFFFF. Not a big deal but I thought you should know.

Joe

[RightRudder]

Interesting. I've been getting these altitude glitches too. I set up a custom play function to play the altitude voice message whenever it changes by more than 30m and every so often I'll hear a sick one like 20,000m etc. I got that on my sky9x and if memory serves it happened with taranis too but I was concentrating on another problem at the time and didn't have a chance to investigate it well so that's why I haven't said anything about it till now. It is something quite intermittent but I didn't know if it was originating in the vario or in the tx. I thought it might be my own problem like a loose connection somewhere but now your data has got me wondering about that.

Joe

Now that I have payed closer attention, this is not happening on Taranis (V1.99 unstable FW) but is happening on r2940 with sky9x. The nightly builds are not ready yet for the sky board so I will have to wait to see if the dev's have fixed that recently. Just thought I would update on that post for the info of others.

[mstrens]

FYI,
I am running 2940 on Taranis (same as NeilRogers).
I run XOS (letting it on a table) for more than 1 hour and I had no "high" values.

I also made a special version of XOS in order to test what happens when XOS send regular "cycling" values.
This version (only for test purpose) does exactly the normal job (calculating altitude, Vspd, voltages, Current,...) but each value to transmit is replaced (just before applying multiplier/divider/offset and transmission) by a dummy value that his continuously incremented/decremented by 1 in order to vary linearly between a min and a max value.
So putting the data from the log file in a chart, it is easy to see if there are some wrong values in a telemetry field.
I run this test version for more than 1 hour and I got no error ("high" value).
Neil used it yesterday during a flying session and got no error too.
So, I still do not understand the reason of the High values that Neil reported.
FIY , this special test functionality is available on the XOS version on google.
To activate it, you must uncomment this line in oxs_out_frsky.cpp :
//#define DEBUGWITHFIXVALUE
Note : this is only valid for SPORT protocol.

Michel

[RightRudder]

Yes I also did some long term tests with r2940 before I flashed the latest unstable code. It was also stable on my Taranis. I don't know what's up with Neil's telemetry log but I'm sure now my sky9x issue is unrelated and is a FW bug only in the sky9x version.

[NeilRogers]

Hi Michel
I've finally got some good weather to test the latest release r204 with the X8R,

There was no sign of previous error blips, even at the higher filtering I found it much more sensitive, running the -+0.2 dead band hardly gave any silent periods.
The sound on climbing was very good, I think its going to work well off of a flat field.

I've included the telemetry for todays 3 flights.

Please let me know if you like any other specific tests I'm on holiday this week.
The weather looks good with the wind on the slope decreasing in strength to virtually nothing by Sunday, which would be ideal to test the vspd in thermals.
Provided the weathermen have it correct of course
Thanks neil

[mstrens]

Hi Michel
I've finally got some good weather to test the latest release r204 with the X8R,

There was no sign of previous error blips, even at the higher filtering I found it much more sensitive, running the -+0.2 dead band hardly gave any silent periods.
The sound on climbing was very good, I think its going to work well off of a flat field.

I've included the telemetry for todays 3 flights.

Please let me know if you like any other specific tests I'm on holiday this week.
The weather looks good with the wind on the slope decreasing in strength to virtually nothing by Sunday, which would be ideal to test the vspd in thermals.
Provided the weathermen have it correct of course
Thanks neil

Neil,
thanks for the feedback.
I still do not know why there was some issues with a previous version.
Now the log seems ok but I made no bug fixing in this version.

Probably that setting sensitivity on max value is to much and generates to much "noise".
When there is no PPM to adjust it, I recomend to the sensitiviy around the default value set in the config file.
With PPM you can do what select what you prefer (eventually also depending on the weather).

I do not need new test but if you find some issues or if you think about some improvements, just let me know.

Hope that you will have good flights.

Regards,

Michel

[mstrens]

Neil,
I forgot to say that I saw some differences in the altitudes between the GPS and the baro.
Mainly in first flight, GPS altitude becomes negative. I presume that those are GPS errors and that the baro altitude is correct (even if there is some drift with the baro)

[NeilRogers]

Thanks Michel

It all looked and sounded good and agreed the gps accuracy is not good.

Cheers neil

[ReSt]

With my GPS module without moving it, I sometimes could watch the altitude drift away in the range of + - 50 m within some minutes.

But when i used it flying, the difference between starting and landing altitude mostly was within only some meters

Reinhard

[NeilRogers]

Hi Reinhard

Just for interest and show the accuracy of Gps location I've include a google earth trace of a typical flight.
The attachment is in kml format so just remove .txt extension and it can loaded directly into google earth

Neil

[ReSt]

Neil,
nice flight.
how do you create the kml files?

I still should have some logfiles that are in NMEA format.

Reinhard

[nique]

Has anyone already tested an air speed sensor? If so, please provide link to the module.

[NeilRogers]

Reinhard

Unfortunately my version of excel does not support macros so its not as easy as it could be.
I use the attached spreadsheet to do the conversion of the co=ordinates, add the telemetry data into sheet 1 and it calculates the co-ordinates into kml format in sheet 2 just make sure the gps data lines up
Then open a new single worksheet spreadsheet and copy in columns GHI on the 2nd sheet and save as csv.
Then insert this data in place of my data in the previous text file neil2302.kml.txt

Neil

[ReSt]

Thanks for the info, Neil.
I think I will have a look if there is a conversion program available to do the job.

Reinhard

[RightRudder]

An easy way to do this is using the GPS dump utility:

http://bhgcinfo.wikidot.com/tutorials:using-gps-dump

[ReSt]

Succeeded to convert my NMEA files into KML files. Did work with Google Earth

Thanks.

Reinhard

[RightRudder]

did you use GPS dump or some other?

[ReSt]

It was this
http://www.h-schmidt.net/NMEA/

You upload your file and get back a converted file.

And I saw that i could delete lots of stuff that was unnecessary for me.

The most important information out of the converted files was the required format of lon / lat that it is degree.parts of degree and not, as in NMEA degree minutes parts of minutes.

So if I eventually will use the GPS again (I originally introduced it because I wanted to know how high and how far i'm flying my planes; that's answered now and altitude I now get from the xVario) I now can write a small program to convert the files.

Reinhard

[RightRudder]

Doh. I just realised Companion ver.1.52 and higher can export logs containing GPS information in google earth format. What could be easier.

[xtrmtrk]

Doh. I just realised Companion ver.1.52 and higher can export logs containing GPS information in google earth format. What could be easier.

I'm not seeing that export facility. How do you do it?

[Kilrah]

Click on the little Earth image in the log viewer, after having configured the path to the Google Earth executable in companion preferences.

[xtrmtrk]

Cool! Is there a way to save the KML file on its own? I know I could export it from Google Earth.

[thnilsen]

Has anyone used an 32U4 based board with this code? Just took delivery of a Pololu A-Star 32U4 Micro (http://www.pololu.com/product/3101) which has a very nice footprint, but when trying to compile the openxsensor code the following error is generated:

'PCIE2' was not declared in this scope

According to a reply to this issue thread https://github.com/arduino/Arduino/issues/1546, the PCIE2 is not a valid bit on the 32U4 chips.... Get the same error with the Sparkfun Pro Micro board as well which has the Amtel same chip.

Regards,
Thomas

[mstrens]

OXS code has been developped in order to run on a Arduino pro mini (or equivalent) which uses an AVR 328P processor and not an 32U4.
AVR328P has 3 "pin change interrupts" (named 0, 1, 2) while 32U4 has only one (named 0).
XOS uses the "pin change interrupt" named 2 to support the communication between the receiver and XOS.

Perhaps it should be possible to change the code in order to use the "pin change interrupt" named 0 on a 32U4 MCU.
You could try replacing (in file ASerial.cpp) :
- PCIF2 by PCIF0
- PCIE2 by PCIE0
- PCMSK2 by PCMSK0

Still then, the signal (from and to the Rx) has to be connected to another pin because Interrupt 0 uses some pin from port "B" instead of port "D".
So this part has to be changed
from :
#define TRXDDR DDRD
#define TRXPORT PORTD
#define TRXPIN PIND

to:
#define TRXDDR DDRB
#define TRXPORT PORTB
#define TRXPIN PINB

Then, depending on the pin from port B that you should use to connect XOS and RX, you should change this code in order to activate the right mask:
#if PIN_SerialTX == 4
PCMSK2 |= 0x10 ; // IO4 (PD4) on Arduini mini
#elif PIN_SerialTX == 2
PCMSK2 |= 0x04 ; // IO2 (PD2) on Arduini mini
#else
#error "This PIN is not supported"
#endif

I hope this help.
May be I forgot some other change(?).

Note : I did not check if there are others differences between 328P and 32U4

[jhsa]

I see that sometimes you write OXS and sometimes XOS.. this happens in several of your posts.. are they different versions of the same thing or it is just a typo?

Thanks

João

Sent from my GT-I9195 using Tapatalk

[mstrens]

I see that sometimes you write OXS and sometimes XOS.. this happens in several of your posts.. are they different versions of the same thing or it is just a typo?

Thanks

João

Sent from my GT-I9195 using Tapatalk

Sorry for the confusion.
It is just a typo mistake that I made

[RightRudder]

I thought XOS was the version which was re-written by Michel for the SPORT and oXs was the version Rainer wrote to do vario plus current.