Page 25 of 26

Re: Introduction to the openx vario/altimeter

Posted: Tue Jul 15, 2014 8:19 pm
by davx
mstrens wrote: I do not know if we can thrust FTDI for this. FTDI can introduce some fuffering too.
I think we need a digital analyser to check the delay between each frame.
Yes, a logic analyzer will do the job but, according to the datasheet, the FTDI chip is supporting up to 3Mbaud so I don't think it misses anything at 9600.

Re: Introduction to the openx vario/altimeter

Posted: Tue Jul 15, 2014 8:25 pm
by mstrens
davx wrote:
mstrens wrote: I do not know if we can thrust FTDI for this. FTDI can introduce some fuffering too.
I think we need a digital analyser to check the delay between each frame.
Yes, a logic analyzer will do the job but, according to the datasheet, the FTDI chip is supporting up to 3Mbaud so I don't think it misses anything at 9600.
For sure it don't miss but probably it groups byte that have small delay in betwwen because it send by packet.
And so you get 3 frames at the same timestamp on the PC.
So it is not relevant for our case.

Re: Introduction to the openx vario/altimeter

Posted: Tue Jul 15, 2014 8:51 pm
by mstrens
In order to save time in test and discussion, I just put 2 new changes on google.
In the first, I avoid sending a frame after 100 ms (alterning 2 types of frame) and I send all data in one frame every 200 ms (about) if at least one data is available. If no data is available it will wait 200 ms before trying to generate a frame.
Note: I can even change the code in such a way that if no data is send because none are available, it will check about every 10 ms if at least one data becomes available and so, it would not wait up to 200 ms. This last improvement is not (yet) done.
In the second, I reduced the delay to calculate VOLT and CELLS from 500 to 200 ms.

I hope this solve the issue.
Please check it (with both Rx if possible)

Re: Introduction to the openx vario/altimeter

Posted: Tue Jul 15, 2014 9:02 pm
by jhsa
[quote="mstrens"
Probably there is no need to split it but it is just a logic that Rainer had initially implemented and it makes the task more complex. So I expect there was a for. Perhaps has Frsky changes his spec in the meantime.
The change I asked to jhas (changing the 1 in 0) was an easy way to check it)

[/quote]
Please, please, please.. I already said 3 times that I didn't change that in the code because it was already changed..
The only thing that worked was changing this:

if(millis() > ( lastVoltMillis + 500) ){ // calculate average only once every 500 msec

to this:

if(millis() > ( lastVoltMillis + 200) ){ // calculate average only once every 200 msec


It was the only thing that worked and I will stick to it, or probably to Mike's files as they are working..
I don't know what to do anymore to convince you that it isn't working as it should.. Opentx is masking the problem so you are not able to see it..
I quit :( but I will leave here the 3 videos I made a little while ago.

The first one is from Mike's files sending only voltage..
Mike's code sending only voltage - YouTube [360p].mp4
(302.07 KiB) Downloaded 1774 times
The next is from your code sending only voltage. You can see the difference.. That will trigger false alarms for sure.
This one is from your code sending voltage, current, and capacity as FUEL

Re: Introduction to the openx vario/altimeter

Posted: Tue Jul 15, 2014 9:14 pm
by MikeB
The FrSky hub sends data every 200mS whether they have been updated or not. I don't see why the oXs can't do the same. Why complicate things checking to see if a value has been updated? Just send the data.
I listed the items, in this post: viewtopic.php?f=86&t=2629&start=690#p83018, the hub sends every 200mS. It sends a total of 49 bytes (before byte stuffing). It only sends the data for one cell in each packet.

Surely the oXs can send the same sort of data length every 200mS.

Mike.

Re: Introduction to the openx vario/altimeter

Posted: Tue Jul 15, 2014 9:29 pm
by davx
Are you sure it sends only one cell at a time Mike ? It's not so clear in the doc...
I can't test as I don't have a FLVS sensor.

Re: Introduction to the openx vario/altimeter

Posted: Tue Jul 15, 2014 10:15 pm
by MikeB
The FrSky document only shows a single entry for a cell in the 200mS packet.

Mike.

Re: Introduction to the openx vario/altimeter

Posted: Wed Jul 16, 2014 6:00 am
by davx
Yes, I read that, but FrSky don't shine by their doc quality... And as it can have up to 12 cells to transmit, it means also up to 2.4s between new voltage values. Perhaps a little too long, but OXS only supports 6, so 1.2s seems acceptable ;)

Re: Introduction to the openx vario/altimeter

Posted: Wed Jul 16, 2014 6:12 am
by mstrens
davx wrote:Yes, I read that, but FrSky don't shine by their doc quality... And as it can have up to 12 cells to transmit, it means also up to 2.4s between new voltage values. Perhaps a little too long, but OXS only supports 6, so 1.2s seems acceptable ;)
FYI, currently OXS send the n (n being the parameter defined in config) cells values in the same frame. Each value contains the cell ID.
Please note that the first cell get an id = 0 ; this is perhaps wrong and I should start from 1.
A test should show what is the right value.

Re: Introduction to the openx vario/altimeter

Posted: Wed Jul 16, 2014 6:27 am
by mstrens
I just put on google a new version of oxs_out_frsky.cpp.
In this version, for the hub protocol only, OXS fills always all measurements (defined in config.h) in only one frame.
It does not test if a measurement has been recalculated since the previous or not.
With this version,
- the plus: the frame is always generated every 200 ms (parameter in the .h file) and contains all expected data
- the min: there is no way for the Tx to detect that some data has not been recalculated (e.g. if OXS lost communication with an external sensor like MS5611)

This version does not 100% respect the Frsky spec because "fuel" is sent within the same frame as the other data but I do not expect it should be an issue(it was already the case before)

Re: Introduction to the openx vario/altimeter

Posted: Wed Jul 16, 2014 8:19 am
by jhsa
I will test on other arduino. Now my plane is running the files Mike posted yesterday as they seemed to be working correctly. The plane has been disassembled on the table for too long. ;) and wife will kill me in a while because of that. So, calibrated the current and voltage, and all looks to be consistent with the wattmetter. As I said before, with the ACS758 sensors the datasheet seems to not be exact. So, the calculation said 81.5 and my trial and error found a value of 80 as at higher amps the radio showed more than the meter. It still does a bit but inside the resolution tolerance I would say. Anyway, this is the model I'm flying more and I can't afford to have it on the table in summer when the weather is good. I did my best to help with this issue but sometimes I felt that I was going around and around :(
As I said, I will test with another arduino from now on. Will try to learn how to get data out of my logic analyzer and post it. :)

João

Re: Introduction to the openx vario/altimeter

Posted: Wed Jul 16, 2014 9:03 am
by mstrens
jhsa wrote:I will test on other arduino. Now my plane is running the files Mike posted yesterday as they seemed to be working correctly. The plane has been disassembled on the table for too long. ;) and wife will kill me in a while because of that. So, calibrated the current and voltage, and all looks to be consistent with the wattmetter. As I said before, with the ACS758 sensors the datasheet seems to not be exact. So, the calculation said 81.5 and my trial and error found a value of 80 as at higher amps the radio showed more than the meter. It still does a bit but inside the resolution tolerance I would say. Anyway, this is the model I'm flying more and I can't afford to have it on the table in summer when the weather is good. I did my best to help with this issue but sometimes I felt that I was going around and around :(
As I said, I will test with another arduino from now on. Will try to learn how to get data out of my logic analyzer and post it. :)

João
Ok thanks.

Re: Introduction to the openx vario/altimeter

Posted: Wed Jul 16, 2014 10:17 am
by ReSt
Some time ago I recorded the data that the FrSky Hub (probably with a GPS module attached), transmitted via a standalone 'modem', so, no FrSky receiver/transmitter in the way

If I call a frame a stream of data that starts and ends with a 5E then the hub does not always send full frames as described in the "Protocol V02 FrSky Hub.pdf"


I found the following mix of 'frames' transmitted in a great variety of sequences, as data of certain frames are sent at different repetition rates

Pure Hub data frames (1-7):
=============

1. acc-x, acc-y, acc-z, Alt.bef, Alt.aft, Temp1, Temp2

2. fuel

3. Course.bef, Course.aft, Lat.bef, Lat.aft, Lat.N/S, Lon.bef, Lon.aft, Lon.E/W, Spd.bef, Spd.aft, Fuel

4. DateMonth

5. Year, HourMinute, Second

6. Volt, Current, Volt.bef, Volt.aft, RPM

7. GPSAlt.bef, GPSAlt.aft, Fuel


Following frame 1 was either frame 2, or frame 3 or frame 6

following frame 3 was either frame 4 or frame 7


Reinhard

Re: Introduction to the openx vario/altimeter

Posted: Wed Jul 16, 2014 10:40 am
by mstrens
ReSt wrote:Some time ago I recorded the data that the FrSky Hub (probably with a GPS module attached), transmitted via a standalone 'modem', so, no FrSky receiver/transmitter in the way

If I call a frame a stream of data that starts and ends with a 5E then the hub does not always send full frames as described in the "Protocol V02 FrSky Hub.pdf"


I found the following mix of 'frames' transmitted in a great variety of sequences, as data of certain frames are sent at different repetition rates

Pure Hub data frames (1-7):
=============

1. acc-x, acc-y, acc-z, Alt.bef, Alt.aft, Temp1, Temp2

2. fuel

3. Course.bef, Course.aft, Lat.bef, Lat.aft, Lat.N/S, Lon.bef, Lon.aft, Lon.E/W, Spd.bef, Spd.aft, Fuel

4. DateMonth

5. Year, HourMinute, Second

6. Volt, Current, Volt.bef, Volt.aft, RPM

7. GPSAlt.bef, GPSAlt.aft, Fuel


Following frame 1 was either frame 2, or frame 3 or frame 6

following frame 3 was either frame 4 or frame 7


Reinhard
Thanks for the information.
Do you have any idea of the smaller delay (ms) between the first caracter of 2 successive frames.

It is quite srange that Fuel is present in 3 types of frame.
In frame 6, do you know what is Volt (because there is also a Volt before and a Volt after)?

Perhaps that the hub groups the data in packets based on the timestamp it got the data and splitting the data on 2 frames if there would be to many data in one frame.

Re: Introduction to the openx vario/altimeter

Posted: Wed Jul 16, 2014 10:59 am
by MikeB
volt will be a single cell from the lipo sensor.
volt.before and volt.after are the whole pack voltage from a FasV.

Mike.

Re: Introduction to the openx vario/altimeter

Posted: Wed Jul 16, 2014 12:02 pm
by davx
mstrens wrote:I just put on google a new version of oxs_out_frsky.cpp.
Just tested and it doesn't work, nothing is sent from OXS...

Re: Introduction to the openx vario/altimeter

Posted: Wed Jul 16, 2014 12:10 pm
by jhsa
I reported the same yesterday but no one noticed. Use your old config file and I think it will work..

Re: Introduction to the openx vario/altimeter

Posted: Wed Jul 16, 2014 12:12 pm
by mstrens
jhsa wrote:I reported the same yesterday but no one noticed. Use your old config file and I think it will work..
Indeed.
Please take care that when I put a version on google I don't really take care of the set up in the config.h file because everybody has to put his own value.
Default in the config file, the hub protocol is not activated.

Re: Introduction to the openx vario/altimeter

Posted: Wed Jul 16, 2014 1:10 pm
by jhsa
Ahhh, that was the problem then.. I did post that it wasn't working but no answer. Then I used mike's config file and it worked.. then my own old file and it also worked.
I know that I don't have much knowledge about all this programming stuff, but I think I'm not that bad at testing and therefore my posts shouldn't be ignored when I test something, even when they sound stupid. It's not the first time I catch stupid bugs ;)
This problem for example was there since probably the beginning of oXs.. And no one caught it. Thanks to Mike for making the new custom switches work as they should it was possible to catch this insect..

Re: Introduction to the openx vario/altimeter

Posted: Wed Jul 16, 2014 3:25 pm
by ReSt
mstrens wrote: Thanks for the information.
Do you have any idea of the smaller delay (ms) between the first caracter of 2 successive frames.
No idea about it, I was reading the serial data into a file.
And, I'm sorry that I can no longer recreate or investigate these data because my Hub died some time ago :cry:

It is quite srange that Fuel is present in 3 types of frame.
In frame 6, do you know what is Volt (because there is also a Volt before and a Volt after)?
Volt is ID 06 and Volt before/after is ID 3A/3B

Reinhard

Re: Introduction to the openx vario/altimeter

Posted: Wed Jul 16, 2014 4:13 pm
by davx
jhsa wrote:I reported the same yesterday but no one noticed. Use your old config file and I think it will work..
I was talking about the modifications that mstrens did this morning and I was using a correct config file (attached) ;)
So, with my config, OXS r218 is not working at all...

Re: Introduction to the openx vario/altimeter

Posted: Wed Jul 16, 2014 5:30 pm
by mstrens
davx wrote:
jhsa wrote:I reported the same yesterday but no one noticed. Use your old config file and I think it will work..
I was talking about the modifications that mstrens did this morning and I was using a correct config file (attached) ;)
So, with my config, OXS r218 is not working at all...
I will check the version on google.
In fact, currently I am working on 3 versions at the same time.
I test (but without receiver) in a specialversion that I made for the issues notified.
If OK and usefull I rewrite it in the version I uploadin google.
And finally I rewrite the changes in a new version that will support 2 MS5611 or 1 MS5611 +a differential pressure sensor in order to get airspeed and probably dTE vario.

So it can be that I forget something when I rewrite in the google version.

I let you know.

Re: Introduction to the openx vario/altimeter

Posted: Wed Jul 16, 2014 6:40 pm
by mstrens
@davx,

I made the following test:
I synchronise my pc with google in order to have the same versions of all files.
I updated the config.h based on your config.
Still :
- I did not activate the vario because I have no MS5611 connected to the Arduino
- I did not ask for sending Alt and Vspeed because I have no MS5611 connected to the Arduino
- I put some value in the Offset parameter (for the 3 voltages) because I have no voltage connected and so ADC will return 0.
Finally,I activated the #define
- DEBUG (in config.h)
- DEBUGHUBPROTOCOL (in oxs_out_frsky.cpp)

Furthermore I updated oxs_out_frsky.cpp in order to format the lipo cell voltage (according to our other post).

I loaded the code in the arduino and I looked at the PC terminal in arduino IDE.

I get something like this:
Send Data at = 402
FRSky output module: SendFrame1A:Data to send = 5E 2 A0 F 5E 5 A4 1F 5E 39 E0 2E 5E 6 7 D0 5E 6 18 2 5E 6 27 9E 5E
Send Data at = 603
FRSky output module: SendFrame1A:Data to send = 5E 2 A0 F 5E 5 A4 1F 5E 39 E0 2E 5E 6 7 D0 5E 6 18 2 5E 6 27 9E 5E
Send Data at = 804
FRSky output module: SendFrame1A:Data to send = 5E 2 A0 F 5E 5 A4 1F 5E 39 E0 2E 5E 6 7 D0 5E 6 18 2 5E 6 27 9E 5E
Send Data at = 1005
FRSky output module: SendFrame1A:Data to send = 5E 2 A0 F 5E 5 A4 1F 5E 39 E0 2E 5E 6 7 D0 5E 6 18 2 5E 6 27 9E 5E
Send Data at = 1206
FRSky output module: SendFrame1A:Data to send = 5E 2 A0 F 5E 5 A4 1F 5E 39 E0 2E 5E 6 7 D0 5E 6 18 2 5E 6 27 9E 5E
Send Data at = 1407
FRSky output module: SendFrame1A:Data to send = 5E 2 A0 F 5E 5 A4 1F 5E 39 E0 2E 5E 6 7 D0 5E 6 18 2 5E 6 27 9E 5E
Send Data at = 1608
FRSky output module: SendFrame1A:Data to send = 5E 2 A0 F 5E 5 A4 1F 5E 39 E0 2E 5E 6 7 D0 5E 6 18 2 5E 6 27 9E 5E
Send Data at = 1809
FRSky output module: SendFrame1A:Data to send = 5E 2 A0 F 5E 5 A4 1F 5E 39 E0 2E 5E 6 7 D0 5E 6 18 2 5E 6 27 9E 5E
Send Data at = 2010
FRSky output module: SendFrame1A:Data to send = 5E 2 A0 F 5E 5 A4 1F 5E 39 E0 2E 5E 6 7 D0 5E 6 18 2 5E 6 27 9E 5E
Send Data at = 2211
FRSky output module: SendFrame1A:Data to send = 5E 2 A0 F 5E 5 A4 1F 5E 39 E0 2E 5E 6 7 D0 5E 6 18 2 5E 6 27 9E 5E
Send Data at = 2412
FRSky output module: SendFrame1A:Data to send = 5E 2 A0 F 5E 5 A4 1F 5E 39 E0 2E 5E 6 7 D0 5E 6 18 2 5E 6 27 9E 5E
Send Data at = 2613
FRSky output module: SendFrame1A:Data to send = 5E 2 A0 F 5E 5 A4 1F 5E 39 E0 2E 5E 6 7 D0 5E 6 18 2 5E 6 27 9E 5E
Send Data at = 2814
FRSky output module: SendFrame1A:Data to send = 5E 2 A0 F 5E 5 A4 1F 5E 39 E0 2E 5E 6 7 D0 5E 6 18 2 5E 6 27 9E 5E
Send Data at = 3015
FRSky output module: SendFrame1A:Data to send = 5E 2 A0 F 5E 5 A4 1F 5E 39 E0 2E 5E 6 7 D0 5E 6 18 2 5E 6 27 9E 5E
Send Data at = 3216
FRSky output module: SendFrame1A:Data to send = 5E 2 A0 F 5E 5 A4 1F 5E 39 E0 2E 5E 6 7 D0 5E 6 18 2 5E 6 27 9E 5E

As far I can see, it seems ok (all data are there every 200 msec, I find nearly the offset values I put in config, the small difference is the noise on analog pins want they are not connected).

So it seems ok but the test is not 100% meaningfull because I did not set up the vario.

Could you please make a similar test deactivating the vario.
If it works without the vario and not with the vario, I will have to look more trying to find back an arduino with a MS5611.

Please note that if you activate the option vario on an arduino having no working MS5611, OXS will currently just enter in an infinite loop. Solving this is onmy todo list.

NOTE: did you downloaded from google all updates I have made those last days.

Note: in in attachement the config I used for my test.

Re: Introduction to the openx vario/altimeter

Posted: Wed Jul 16, 2014 6:51 pm
by davx
@mstrens,
mstrens wrote: Could you please make a similar test deactivating the vario.
I will try with your config.
NOTE: did you downloaded from google all updates I have made those last days.
I have two OXS sources on my disk, one is my personal test version and the other is entirely downloaded from the repository every time you tell us you've made a change.

Re: Introduction to the openx vario/altimeter

Posted: Wed Jul 16, 2014 6:52 pm
by MikeB
I notice a small drift in the 200mS time. Did you not use my idea of adding 200 to the "lastTime" value rather than loading it with millis(). This should remove the drift.
While, at 200mS, it should not cause a problem, it is this sort of drift that was actually responsible for the occasional problem before.
From memory, the test is >200. This could also explain why you get 201mS between outputs and another reason to use the +200 idea.

Mike.

Re: Introduction to the openx vario/altimeter

Posted: Wed Jul 16, 2014 7:09 pm
by davx
@mstrens,

I've just tried with your config and the voltages are working, so the problem comes from the vario part of the code.

Re: Introduction to the openx vario/altimeter

Posted: Wed Jul 16, 2014 7:14 pm
by mstrens
MikeB wrote:I notice a small drift in the 200mS time. Did you not use my idea of adding 200 to the "lastTime" value rather than loading it with millis(). This should remove the drift.
While, at 200mS, it should not cause a problem, it is this sort of drift that was actually responsible for the occasional problem before.
From memory, the test is >200. This could also explain why you get 201mS between outputs and another reason to use the +200 idea.

Mike.
Sorry Mike, currently I had no time to look in detail at the mofications you proposed.
Still I think I saw a small mistake in your file oxs_current.cpp because there is still 200 in the "if" sentence.
I tried first to find the root of the issue and I still suspect that sending some frame at 100 ms (for some config) is the main reason.
A small drift can't be an issue.
Anyway, when the vario is activate, I think that the main loop is sometime entered with a delay of 2 or 3msec. There would then be a delay too in the generation of the frame.

Furthermore, in the SPORT protocol, the logic is more complex because the process is asynchrone. The master is the rx and OXS must be ready to provide one and only one measurement when it is polled. I build a logic in order to send a measurement like vspeed with a higher priority but still ensuring that when a measurement is available it will be sent within a reosonable time.

Re: Introduction to the openx vario/altimeter

Posted: Wed Jul 16, 2014 7:15 pm
by mstrens
davx wrote:@mstrens,

I've just tried with your config and the voltages are working, so the problem comes from the vario part of the code.
OkI will look further but I do not understand directly where I made the mistake.

Re: Introduction to the openx vario/altimeter

Posted: Wed Jul 16, 2014 7:59 pm
by mstrens
davx wrote:@mstrens,

I've just tried with your config and the voltages are working, so the problem comes from the vario part of the code.
@davx,
Could you check again your MS5611.
I remove my vario from my glider and I checked it (in debug mode so not with a D8R-II rx).
I used the same config as before but I activated the vario and I add Alt and Vspeed as fields to be transmitted.
On my side it works.
If it still does not work on your side perhaps that it would help if you send less data. Perhaps that the Rx can't follow.

Here a sample of the data being generated
FRSky output module: SendFrame1A:Data to send = 5E 10 F4 FF 5E 21 54 0 5E 30 0 0 5E 2 A9 F 5E 5 A8 1F 5E 39 E9 2E 5E 6 17 D4 5E 6 27 25 5E 6 37 A0 5E
Send Data at = 90093
FRSky output module: SendFrame1A:Data to send = 5E 10 F4 FF 5E 21 53 0 5E 30 0 0 5E 2 A9 F 5E 5 A8 1F 5E 39 E9 2E 5E 6 17 D4 5E 6 27 25 5E 6 37 A0 5E
Send Data at = 90293
FRSky output module: SendFrame1A:Data to send = 5E 10 F4 FF 5E 21 54 0 5E 30 0 0 5E 2 A9 F 5E 5 A8 1F 5E 39 E9 2E 5E 6 17 D4 5E 6 27 25 5E 6 37 A0 5E
Send Data at = 90493
FRSky output module: SendFrame1A:Data to send = 5E 10 F4 FF 5E 21 54 0 5E 30 0 0 5E 2 A9 F 5E 5 A8 1F 5E 39 EE 2E 5E 6 17 D4 5E 6 27 25 5E 6 37 A3 5E
Send Data at = 90693
FRSky output module: SendFrame1A:Data to send = 5E 10 F4 FF 5E 21 56 0 5E 30 0 0 5E 2 A9 F 5E 5 A8 1F 5E 39 E9 2E 5E 6 17 D4 5E 6 27 25 5E 6 37 A0 5E
Send Data at = 90893
FRSky output module: SendFrame1A:Data to send = 5E 10 F4 FF 5E 21 55 0 5E 30 0 0 5E 2 A9 F 5E 5 A8 1F 5E 39 E9 2E 5E 6 17 D4 5E 6 27 25 5E 6 37 A0 5E
Send Data at = 91093
FRSky output module: SendFrame1A:Data to send = 5E 10 F4 FF 5E 21 55 0 5E 30 0 0 5E 2 A9 F 5E 5 A8 1F 5E 39 E9 2E 5E 6 17 D4 5E 6 27 25 5E 6 37 A0 5E
Send Data at = 91293
FRSky output module: SendFrame1A:Data to send = 5E 10 F4 FF 5E 21 54 0 5E 30 0 0 5E 2 A4 F 5E 5 A8 1F 5E 39 EE 2E 5E 6 17 D2 5E 6 28 25 5E 6 37 A3 5E
Send Data at = 91493
FRSky output module: SendFrame1A:Data to send = 5E 10 F4 FF 5E 21 56 0 5E 30 0 0 5E 2 A9 F 5E 5 A8 1F 5E 39 E9 2E 5E 6 17 D4 5E 6 27 25 5E 6 37 A0 5E
Send Data at = 91693
FRSky output module: SendFrame1A:Data to send = 5E 10 F4 FF 5E 21 58 0 5E 30 FA FF 5E 2 A9 F 5E 5 A8 1F 5E 39 EE 2E 5E 6 17 D4 5E 6 27 25 5E 6 37 A3 5E
Send Data at = 91893
FRSky output module: SendFrame1A:Data to send = 5E 10 F4 FF 5E 21 57 0 5E 30 FA FF 5E 2 A9 F 5E 5 A8 1F 5E 39 E9 2E 5E 6 17 D4 5E 6 27 25 5E 6 37 A0 5E
Send Data at = 92093


Note: in this test,asMike suggested, I also change the test on > 200 to >= 200 and now the delay is 200 instead of 201.

There is only one strange point: the first timestamp being generated is around 24000 milli but after a reset it is generated much faster than 24 sec.
Here the top of the debug:
Vario Sensor:MS5611 I2C Addr=77
openXsensor starting..
freeRam=942
calibration data #1 = 53094
calibration data #2 = 53319
calibration data #3 = 32193
calibration data #4 = 27758
calibration data #5 = 32262
calibration data #6 = 27974
done.
FRSky Output Module: TX Pin=4
FRSky Output Module: Setup!
Number of fields to send = 7
0 , 1 , 1 , 1
0 , 2 , 1 , 1
2 , 5 , 1 , 1
5 , 6 , 1 , 1
39 , 7 , 1 , 1
0 , 13 , 1 , 1
0 , 14 , 1 , 1
End of general set up
Send Data at = 200
FRSky output module: SendFrame1A:Data to send = 5E 10 0 0 5E 21 0 0 5E 30 0 0 5E 2 0 0 5E 5 0 0 5E 39 0 0 5E 6 10 0 5E 6 20 29 5E 6 10 0 5E 6 20 0 5E
Send Data at = 24093
FRSky output module: SendFrame1A:Data to send = 5E 10 0 0 5E 21 0 0 5E 30 0 0 5E 2 B3 F 5E 5 CB 1F 5E 39 F8 2E 5E 6 17 D9 5E 6 28 25 5E 6 37 96 5E
Send Data at = 24293
FRSky output module: SendFrame1A:Data to send = 5E 10 F5 FF 5E 21 9 0 5E 30 0 0 5E 2 B3 F 5E 5 CB 1F 5E 39 F8 2E 5E 6 17 D9 5E 6 28 25 5E 6 37 96 5E
Send Data at = 24493
FRSky output module: SendFrame1A:Data to send = 5E 10 F5 FF 5E 21 1C 0 5E 30 0 0 5E 2 A9 F 5E 5 A8 1F 5E 39 E9 2E 5E 6 17 D4 5E 6 27 25 5E 6 37 A0 5E

Re: Introduction to the openx vario/altimeter

Posted: Wed Jul 16, 2014 8:47 pm
by davx
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...