Introduction to the openx vario/altimeter

Development & General Chat for the superb openxvario project.

Moderator: rainer

mstrens
Posts: 1435
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: Introduction to the openx vario/altimeter

Post by mstrens »

davx wrote:With vario defined, I've got nothing on the TX, no vario, no voltage.
What you see is the debug print, not the real output.

It's not a problem of too much data, we've got 240 bytes possible every 200ms and as I said, when I tried to log the output, nothing was sent, something blocks the output.

It worked better before you comment all the "available" tests, the frames was not constant but I could receive the data on the TX...
Thanks for the test.
I think that the issue is due to the size of a buffer in Aserial.
The size of the buffer is currently 30 and the frame being generated has 37 bytes.
If we want to take the really worst case that all data bytes would be "stuffed" we should even add 18 bytes.

I am not sure that the Rx can follow because if the max rate = 1200 baud => 120 bytes/sec = 29 bytes per frame (when the frames contains all data and are generated every 200ms). So we are above the specification.

I presume that if you let vario active but that you reduce the number of data being sent, then it would work.

Some days ago, you put a post saying that having many telemetry fields in the config did not work.
This is probably the reason.

I do not have a solution. I can extend the buffer but it is not THE solution.

davx
Posts: 210
Joined: Sun Sep 15, 2013 7:01 am
Country: -

Re: Introduction to the openx vario/altimeter

Post by davx »

@mstrens,
davx wrote: we've got 240 bytes possible every 200ms
yes, I wrote too fast...
mstrens wrote:I am not sure that the Rx can follow because if the max rate = 1200 baud => 120 bytes/sec = 29 bytes per frame (when the frames contains all data and are generated every 200ms). So we are above the specification.
but I think FrSky have been very conservative with their spec because, as Mike said above, they send 49 bytes/Frame1.
Considering their 2 way protocol, I've calculated a theoretical maximum of 52 bytes/s for the User bytes data.
Some days ago, you put a post saying that having many telemetry fields in the config did not work.
In fact, it was a compilation problem with the formatting of these fields...

The simplest solution is to do what Frsky do, the HUB has always worked for me, so we should stick to their frame definition.
mstrens
Posts: 1435
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: Introduction to the openx vario/altimeter

Post by mstrens »

@davx
I just made a test with a receiver D4R-II (so not a D8R-II because I do not have this model).
I made a set up sending all the fields you intend too (alt,vspeed,3 volts & 2 cell*2).

It works.
So I don't understand why it did not work on your side.

Anyway, I will change the code in order to increase the buffer size and to avoid that OXS writes outside the max length.

By the way, in this test, I saw that cell1 is 0volt and cell2 has the voltage expected for cell1.
So I presume that the first cell has to get an Id = 0 instead of 1.
I will change all this and make a new test.
mstrens
Posts: 1435
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: Introduction to the openx vario/altimeter

Post by mstrens »

mstrens wrote:@davx
I just made a test with a receiver D4R-II (so not a D8R-II because I do not have this model).
I made a set up sending all the fields you intend too (alt,vspeed,3 volts & 2 cell*2).

It works.
So I don't understand why it did not work on your side.

Anyway, I will change the code in order to increase the buffer size and to avoid that OXS writes outside the max length.

By the way, in this test, I saw that cell1 is 0volt and cell2 has the voltage expected for cell1.
So I presume that the first cell has to get an Id = 0 instead of 1.
I will change all this and make a new test.
I just put all those changes in google.
I tested with several max buffer sizes. It seems ok (the last data being discarded).
I currently put the max size on 70.

Please test it but, on a D4R-II, it works (I get the expected values on Tx)
Here the config I used.

Davx, if you think that there are to much "noise" in the voltage measurements, I can put back the averaging delay on 500 instead of 200ms. This would not change anything anymore to the frequency of frame generation because I do not check anymore if a new data is available.
Attachments
oxs_config.h
(43.86 KiB) Downloaded 318 times
davx
Posts: 210
Joined: Sun Sep 15, 2013 7:01 am
Country: -

Re: Introduction to the openx vario/altimeter

Post by davx »

mstrens wrote:Please test it but, on a D4R-II, it works (I get the expected values on Tx)
I can confirm the r220 is working for me !
Whatever the problem was with r218, it's resolved now.

mstrens
Posts: 1435
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: Introduction to the openx vario/altimeter

Post by mstrens »

mstrens wrote: Davx, if you think that there are to much "noise" in the voltage measurements, I can put back the averaging delay on 500 instead of 200ms. This would not change anything anymore to the frequency of frame generation because I do not check anymore if a new data is available.
Must I change back or not?
davx
Posts: 210
Joined: Sun Sep 15, 2013 7:01 am
Country: -

Re: Introduction to the openx vario/altimeter

Post by davx »

Let it as it is, I will see later in real use if it needs adjustments.
Good job !

Post Reply

Return to “OpenXVario - an open source vario supported by the open source firmwares!!”