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 »

@jsha
I have checked OXS and I found a bug. E.g. 0x5D was converted into 0x5D + 0x7D instead of 0x5D + 0x3D.
It is strange that noboddy saw this bug because it was already there in the Rainer code.

I put a new version of file oxs_out_frsky.cpp on google to fix it.

Can you test it again with this version.

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

Re: Introduction to the openx vario/altimeter

Post by mstrens »

@jsha
I had a look at your log file about the fuel.
I saw that when you cut throttle quickly, the fuel increases a lot.
In fact in one case, I saw that the Amp becomes negative. This negative value generates the jumps in fuel.

I made 2 corrections:
- a negative amp is handled as 0
- even if later on we would handle the negative value again, OXS will not have jumps.

I put a new version of oxs_current.cpp on google.
Can you test it.

Note : the fuel calculated by oxs could be slightly different from consumption calculated on Tx side.
OXS consumption should normally be more accurate because:
- current transmitted to Tx is probably rounded
- Tx does not have the same accuracy when measuring enlapsed time between 2 measurements.
The difference should remains small.
User avatar
jhsa
Posts: 19480
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: Introduction to the openx vario/altimeter

Post by jhsa »

Wow, I will digest all this and try to test it..
For the current, I used the values you gave me according to the datasheet. One thing I have learnt is that with this sensors they seem to behave different from the datasheet. I always did with my trial and error, and a wattmeter. It takes time and now it won't be any different. ;)

About the voltage problem, maybe no one caught it because 9.5V is already a bit low to let a 3 cell lipo get there, and 9.3V is a bit too high for a 2 cell Lipo. It is a range that is normally not used. I just had the idea of calibrating the sensor with a variable power supply because of your recommendation on the log file to use a multimeter and 2 voltages on both sides of the range. And that proved to be quite accurate.
So, you also fixed something on the voltage, right? I will have to recalibrate the voltage or just move the decimal point? :)

Thanks.
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW
mstrens
Posts: 1435
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: Introduction to the openx vario/altimeter

Post by mstrens »

jhsa wrote:Wow, I will digest all this and try to test it..
For the current, I used the values you gave me according to the datasheet. One thing I have learnt is that with this sensors they seem to behave different from the datasheet. I always did with my trial and error, and a wattmeter. It takes time and now it won't be any different. ;)

About the voltage problem, maybe no one caught it because 9.5V is already a bit low to let a 3 cell lipo get there, and 9.3V is a bit too high for a 2 cell Lipo. It is a range that is normally not used. I just had the idea of calibrating the sensor with a variable power supply because of your recommendation on the log file to use a multimeter and 2 voltages on both sides of the range. And that proved to be quite accurate.
So, you also fixed something on the voltage, right? I will have to recalibrate the voltage or just move the decimal point? :)

Thanks.
The change I made for the voltage is just in order to get correct values even if the voltage is between 9.3 and 9.4 volt. Those values where calculated correctly but a conversion while sending them was wron.
So you do not have to recalibrate.
Just one point.
Usually the voltage is supposed to be measured internally in OXS in millivolt. To get it so, you have to set the value of the parameter 100 times higher. So e.g. #define mVoltPerStep_1 0.1323
should be
#define mVoltPerStep_1 13.23
Still when a voltage measured in millivolt is sent as VFAS_NEW then it has to be divided by 100 because the Tx expect VFAS being in 1/10 of volt (instead of millivolt) and it will be the Tx that will reformat it to display 1 decimal. So instead of
#define SETUP_DATA_TO_SEND FRSKY_USERDATA_VFAS_NEW , VOLT1 , 1 , 1 , 0 , DEFAULTFIELD , CURRENTMA , 1 , 1 , 0 , FRSKY_USERDATA_FUEL , MILLIAH , 1 , 1 , 0

you should then have
#define SETUP_DATA_TO_SEND FRSKY_USERDATA_VFAS_NEW , VOLT1 , 1 , 100 , 0 , DEFAULTFIELD , CURRENTMA , 1 , 1 , 0 , FRSKY_USERDATA_FUEL , MILLIAH , 1 , 1 , 0

In fact with your setup, it works too because you let VOLT1 be directly in 1/10 of volt following the explanation I put in the config file. So if you want you can let it as it is.
Having VOLT1, 2, 3... in millivolt is really needed when you ask OXS send the voltage of each cell individually using a parameters like
#define CELLS_1_2 13 // Only DEFAULTFIELD can be used
#define CELLS_3_4 14 // Only DEFAULTFIELD can be used
#define CELLS_5_6 15 // Only DEFAULTFIELD can be used
This supposes to use several dividers (one for each cell).
This is not your case, so it is not so important.
User avatar
jhsa
Posts: 19480
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: Introduction to the openx vario/altimeter

Post by jhsa »

You don't seem to have corrected the telemetry lost problem in oxs_arduino.cpp. it is still

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

and it should be:

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

or there will be the same problem I reported of the fake alarms

João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW

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

Re: Introduction to the openx vario/altimeter

Post by MikeB »

I update from googlecode this morning, looks like I got r215.
I set up the config file to just send voltage, nothing else.
Monitoring the serial output with a 'scope, I see a packet, then the next packet is either 400mS or 600mS later, followed by another packet 600mS or 400mS later.

Changing the line João mentions results in a packet every 200mS.

I've set my 'scope (digital storage) to trigger on a negative pulse of 250mS. I'll leave it running for a while and see if it triggers at all. So far, a couple of minutes, it hasn't, so it is sending a packet at least every 250mS.

Mike.

Edit: I just got a trigger at 250mS, with the next packet following 150mS later, a gap of 400mS.
I'm goint to guess there is a phasing problem. Two things (voltage and output) both looking for 200mS since the last time. Occasionally the voltage test may just follow the output test resulting in a 'missed' update.
This can be caused by the code doing this:
if(millis() > ( lastVoltMillis + 200) ){ // calculate average only once every 200 msec
...
lastVoltMillis = millis() ;
}
The value stored into lastVoltMillis is NOT 200 more than the previous, it may be significantly more.
I would suggest changing the line to:
lastVoltMillis += 200 ;
so as to avoid 'slipping' the time. The exact time between successful tests of
if(millis() > ( lastVoltMillis + 200) )
may vary a bit, but over a long time this will keep an average of 200mS per update.
This may need to be done in other places.

Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
User avatar
jhsa
Posts: 19480
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: Introduction to the openx vario/altimeter

Post by jhsa »

so, Mike I should change that line in oxs_arduino.cpp to 200, right? or was it fixed somewhere elase?

Thanks,

João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW
User avatar
jhsa
Posts: 19480
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: Introduction to the openx vario/altimeter

Post by jhsa »

Ok, downloaded all the files from google code, configured, uploaded and the sensor doesn't produce any signal on pin 4. it is not working.
Flashed the previous version and it works..
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW
User avatar
jhsa
Posts: 19480
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: Introduction to the openx vario/altimeter

Post by jhsa »

yep, 215 doesn't work.. checking with a LED, it doesn't blink..
re-flashing version 205, all works again and the LED blinks meaning that serial is being sent..
So, big problem somewhere

João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: Introduction to the openx vario/altimeter

Post by MikeB »

Slight problem between us is my oXs is wired to use pin 2 as the output.
I've left mine running and I have had at least one trigger of a 400mS gap in over an hour.
At the moment everthing is operating asynchronously, doing it's own timing. So as loop() is processed you can get the following:
1. Read the sensors, they look at the elapsed time and find it is just below, say, 200mS. Not over 200mS so no update.
2. Check for sending data, time has moved on a bit and now 200mS has passed, so an attempt to send data is made, but if nothing has been updated, nothing is sent. This means a 200mS 'slot' is missed. If the 200mS was 500mS, then a whole second could pass with no update.

I think the whole timing should be changed a bit to something like this:
At the start of loop(), read millis() and store it in a global variable, say, ThisLoopMillis.
Now, everything that needs to test millis(), reads ThisLoopMillis instead. This means everything uses the same time stamp.
Anything that is waiting for a time, e.g. comparing ThisLoopMillis to lastVoltMillis should also simply add the time delay on, e.g.: lastVoltMillis = += 200 ;

This way, everthing operates synchronously, and time delays do not slip over time.

Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: Introduction to the openx vario/altimeter

Post by MikeB »

Here are the source files as I have modified them. Still using just voltage and I'm using pin 2 as the output.
Based on r215.
I'll leave it running for a while and see if I get a trigger at 250mS, none so far.
oxs.zip
Files modified to use ThisLoopMillis instead of millis().
(42.09 KiB) Downloaded 212 times
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
User avatar
jhsa
Posts: 19480
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: Introduction to the openx vario/altimeter

Post by jhsa »

Mike, how come you are having a serial output and I'm not? I downloaded all the files from the google code.. even chanded the serial pin to 2, nothing, nada..
If i load the old 205 version, it works..
I'm trying this in 2 arduinos..

João

EDIT: the problem seems to be in the config file.. Loaded the config file from 205 in 215 and flashed it and I've got pulses now..
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW
User avatar
jhsa
Posts: 19480
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: Introduction to the openx vario/altimeter

Post by jhsa »

Mike, patched version 215 with your files and it seems to be working.. at least with the LED.. Will inset my configs on your config file and test it on my sensors..

EDIT: Used Mike's files to patch 215, configured the config file for my glider, and all seems to be working..
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: Introduction to the openx vario/altimeter

Post by MikeB »

I have had mine running now for 1.25 hours and the 'scope hasn't triggered on 250mS yet. So it has been sending packets at least as often as every 250mS.
I'll give it another hour or so.

Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
davx
Posts: 210
Joined: Sun Sep 15, 2013 7:01 am
Country: -

Re: Introduction to the openx vario/altimeter

Post by davx »

Hi,

This time I've logged the OXS serial output:

Code: Select all

2014-07-15 15:02:35.994446:
5E 10 87 00 5E 21 09 00 5E 30 FA FF 5E

2014-07-15 15:02:36.198236:
5E 10 87 00 5E 21 0B 00 5E 30 00 00 5E 5E 39 09
00 5E 02 00 00 5E 05 04 00 5E 06 00 00 5E 06 10
00 5E 06 20 00 5E 5E 10 87 00 5E 21 0B 00 5E 30
00 00 5E

2014-07-15 15:02:36.605761:
5E 10 87 00 5E 21 0A 00 5E 30 00 00 5E 5E 39 09
00 5E 02 00 00 5E 05 09 00 5E 06 00 00 5E 06 10
00 5E 06 20 00 5E 5E 10 87 00 5E 21 0A 00 5E 30
00 00 5E

2014-07-15 15:02:37.012940:
5E 10 87 00 5E 21 0B 00 5E 30 00 00 5E

2014-07-15 15:02:37.216466:
5E 10 87 00 5E 21 0C 00 5E 30 00 00 5E 5E 39 09
00 5E 02 00 00 5E 05 04 00 5E 06 00 00 5E 06 10
00 5E 06 20 00 5E 5E 10 87 00 5E 21 0A 00 5E 30
00 00 5E

2014-07-15 15:02:37.623893:
5E 10 87 00 5E 21 0B 00 5E 30 00 00 5E 5E 39 09
00 5E 02 00 00 5E 05 04 00 5E 06 00 00 5E 06 10
00 5E 06 20 00 5E 5E 10 87 00 5E 21 0C 00 5E 30
00 00 5E
and as Mike and jhsa already found, the timing is not as it should be...

The oxs_config.h with the settings I used is attached.

I will try your files Mike.

Bye.
Attachments
oxs_config.h
(44.03 KiB) Downloaded 298 times
davx
Posts: 210
Joined: Sun Sep 15, 2013 7:01 am
Country: -

Re: Introduction to the openx vario/altimeter

Post by davx »

@Mike,

With only vario defined and original oxs code (215), Frame1 was sent every ~200ms, no problem (apart the fact that it was set to 100 in the code...).

Bad timing is for with vario + voltages + cells, as in my log above.
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: Introduction to the openx vario/altimeter

Post by MikeB »

The 'slipped' timing only occurs occasionally.
I still have no triggers at 250mS.

Mike.

Edit: I've stopped my test after 2.5 hours with no problems.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
User avatar
jhsa
Posts: 19480
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: Introduction to the openx vario/altimeter

Post by jhsa »

I have a sensor sending only voltage on since quite a while and still didn't have an alarm.. I'm using Mike's files..
I'm logging..
João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW
mstrens
Posts: 1435
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: Introduction to the openx vario/altimeter

Post by mstrens »

I was out this PM (flying).
I see that there was a lot of discussion.

Here some more comments:
as said in aprevious post, in Hub protocol, OXS try currently to generate a frame evey 100 ms (INTERVAL_FRAME1) but it does not always generate a frame.
In fact it try to generate once a frame 1 versio A and once a frame 1 version 2. Both does not contains the same measurements.
I just kept the logic from Rainer (perhaps an old Frskry protocol).
If you just ask for sending 1 measurement, The frame containing this measurement will in fact be send every 200 ms (about) but there is a second condition: it must contains at least a measurement that is made "available" since a previous transmission.
Some measurement like "current" are available every 100ms; So if you just ask for current, it will for sure be sent every 200ms.

Volt measurement are in the normal code available only every 500 ms. So if you ask only for a VOLT, it is "normal" that it is send every 600 and 400 ms (alterning).

Now if you ask in the config to send 2 measurements , one foreseen in frame version A and the other in frame version B, OXS will try to send a frame every 100 ms (VOLT being available only every 500 ms, there will still be some frame missing but there should be at least a frame every 200 ms). This is what happens initilally with the first test from jsha.

This morning I though that the issue was perhaps because OXS send, with this config, some frames within the 100ms (to fast for the newer Rx). An easy solution to test if there is no issue anymore when frame are send only every 200 ms was to let OXS send the measurement VOLT in the same frame as the other used by jsha in his config.
To test it it was asked to change
if ( (SwitchFrameVariant == 1) && ( arduinoData->mVoltAvailable[VoltToSend] == true )) {
in
if ( (SwitchFrameVariant == 0) && ( arduinoData->mVoltAvailable[VoltToSend] == true )) {

Because this was only a test, I did not upload on google a new version including this change.
If this is really THE solution (e.g. if it works with all type of Rx), I can change the code but I have to change it in a different way because CELL is also currently in the other frame. If one type of frame is good, I can remove lot of tests from the code.

Changing the delay used to make a VOLT or a CELL available (currently 500 ms) is another story. It is required to change it if there is an alarm when such a measurement is not sent within the (about) 600 ms.
Note that when other measurements like current or Vspeed is also sent, the max delay would normally be around 200 ms and exceptionnally 400.
Again, I did not yet change the delay for VOLT on google because we were still in test fase.

I hope this clarify the topic (for those that follow).

I will explain in another post why the tests on delay are asynchrone.
davx
Posts: 210
Joined: Sun Sep 15, 2013 7:01 am
Country: -

Re: Introduction to the openx vario/altimeter

Post by davx »

@mstrens,

Just look at my OXS log above (taken from the actual pin 4 output, not the debug monitor) and you'll see that frames are not always sent every 200ms, there's gaps of 400 and 500ms.
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: Introduction to the openx vario/altimeter

Post by MikeB »

In my opinion, the way I have the timing done in the files I posted above is the 'correct' way to do them (lastTime += 200 type). I have used this method many times before in various code. In addition, reading millis() once at the start of loop(), and using the same value through the various code also avoids phasing between tests for "Is it time to generate new output" or "Is it time to send new output".

I understand that the actual millis() value may be needed for actual calculation to do with the vario, I thought I left those unchanged.

We clearly were seeing delays in output of over 700mS at times, and must have had a delay of over 900mS to cause the alarm João was seeing.

The FrSky hub protocol does indeed send
"①Three-axis Acceleration Values, Altitude (variometer-0.01m), Tempature1, Temprature2, Voltage ,
Current & Voltage (Ampere Sensor) , ②RPM"
every 200mS. I can see no reason not to do the same.

Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
mstrens
Posts: 1435
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: Introduction to the openx vario/altimeter

Post by mstrens »

davx wrote:Hi,

This time I've logged the OXS serial output:

Code: Select all

2014-07-15 15:02:35.994446:
5E 10 87 00 5E 21 09 00 5E 30 FA FF 5E

2014-07-15 15:02:36.198236:
5E 10 87 00 5E 21 0B 00 5E 30 00 00 5E 5E 39 09
00 5E 02 00 00 5E 05 04 00 5E 06 00 00 5E 06 10
00 5E 06 20 00 5E 5E 10 87 00 5E 21 0B 00 5E 30
00 00 5E

2014-07-15 15:02:36.605761:
5E 10 87 00 5E 21 0A 00 5E 30 00 00 5E 5E 39 09
00 5E 02 00 00 5E 05 09 00 5E 06 00 00 5E 06 10
00 5E 06 20 00 5E 5E 10 87 00 5E 21 0A 00 5E 30
00 00 5E

2014-07-15 15:02:37.012940:
5E 10 87 00 5E 21 0B 00 5E 30 00 00 5E

2014-07-15 15:02:37.216466:
5E 10 87 00 5E 21 0C 00 5E 30 00 00 5E 5E 39 09
00 5E 02 00 00 5E 05 04 00 5E 06 00 00 5E 06 10
00 5E 06 20 00 5E 5E 10 87 00 5E 21 0A 00 5E 30
00 00 5E

2014-07-15 15:02:37.623893:
5E 10 87 00 5E 21 0B 00 5E 30 00 00 5E 5E 39 09
00 5E 02 00 00 5E 05 04 00 5E 06 00 00 5E 06 10
00 5E 06 20 00 5E 5E 10 87 00 5E 21 0C 00 5E 30
00 00 5E
and as Mike and jhsa already found, the timing is not as it should be...

The oxs_config.h with the settings I used is attached.

I will try your files Mike.

Bye.
What you show here is very interesting.
I thake e.g. the first sequence
2014-07-15 15:02:36.198236:
5E 10 87 00 5E 21 0B 00 5E 30 00 00 5E 5E 39 09
00 5E 02 00 00 5E 05 04 00 5E 06 00 00 5E 06 10
00 5E 06 20 00 5E 5E 10 87 00 5E 21 0B 00 5E 30
00 00 5E

In fact OXS has not generate all this at the same time.
In fact it contains 3 frames:
- a frame type A with the measurements other than VOLT and CELL 5E 10 87 00 5E 21 0B 00 5E 30 00 00 5E
- a frame type B with the measurements VOLT and CELL 5E 39 09 00 5E 02 00 00 5E 05 04 00 5E 06 00 00 5E 06 10 00 5E 06 20 00 5E
- a frame type A with new measurements other than VOLT and CELL 5E 10 87 00 5E 21 0B 00 5E 30 00 00 5E.

How do you collect those data.
It should be 3 frames with at least about 100 ms between each.
User avatar
jhsa
Posts: 19480
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: Introduction to the openx vario/altimeter

Post by jhsa »

mstrens wrote:
Volt measurement are in the normal code available only every 500 ms. So if you ask only for a VOLT, it is "normal" that it is send every 600 and 400 ms (alterning).
Allow me to disagree as it will trigger an alarm saying that it lost telemetry.. in openTX the alarm doesn't sound because it is ignoring this situation and you can miss a real alarm in some situations.
Now if you ask in the config to send 2 measurements , one foreseen in frame version A and the other in frame version B, OXS will try to send a frame every 100 ms (VOLT being available only every 500 ms, there will still be some frame missing but there should be at least a frame every 200 ms). This is what happens initilally with the first test from jsha.
Before i was sending voltage and current and I had the same problem.. Please read my posts above somewhere.. There are videos with a LED so you can see it really well..

This morning I though that the issue was perhaps because OXS send, with this config, some frames within the 100ms (to fast for the newer Rx). An easy solution to test if there is no issue anymore when frame are send only every 200 ms was to let OXS send the measurement VOLT in the same frame as the other used by jsha in his config.
To test it it was asked to change
if ( (SwitchFrameVariant == 1) && ( arduinoData->mVoltAvailable[VoltToSend] == true )) {
in
if ( (SwitchFrameVariant == 0) && ( arduinoData->mVoltAvailable[VoltToSend] == true )) {
I didn't change anything there because the number was already "1", so i didn't change anything as it was already as you said.
The only thing that gave results was changing the line in oxs_arduino.cpp

Changing this line:

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

to:

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


And you didn't change this line on version 215 from today, so obviously the problem is still there.. :)

I tested Mike's changes for one hour (please check my log file attached) and never had an alarm.. the smaller number in the "UsrValid" field is 67. Yes I checked the complete file ;) 56 minutes, every second.
My setup was sending only voltage..

Please have a look at the files Mike posted here as it seems to be working:

viewtopic.php?f=86&t=2629&p=83009#p82990

João

P.S. - forgot to attach the log file.. is there now
Attachments
Substitute-2014-07-15.csv
(298.08 KiB) Downloaded 237 times
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: Introduction to the openx vario/altimeter

Post by MikeB »

There's a 66 in there somewhere. I just added a 'min' entry at the bottom of the column.
Still 66 indicates a maximum delay of 240mS. This is reasonable as there may be a delay between bytes being sent to the receiver, and the same bytes being sent out by the Tx module.

Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
User avatar
jhsa
Posts: 19480
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: Introduction to the openx vario/altimeter

Post by jhsa »

How did you do that?? You must have rolled on the floor laughing when I said I checked all the lines :mrgreen:
I didn't see the 66 though.. I saw a few 67. but definitely better than 13, right??

João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW
mstrens
Posts: 1435
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: Introduction to the openx vario/altimeter

Post by mstrens »

Dear all,

Please read slowly and carrefully.
I suspect that the issue is not that OXS has a to long delay between 2 frames (even it becomes an issue if it is really to long) but just the opposite.
I suspect that the new Frsky receiver does not accept getting frames with an interval as low as 100 ms.

As long as you test only with sending voltage (or cell) measurement (one or several) OXS will not send 2 frames with an interval of 100ms. It will be 200ms or more ; my code or the Mike code does not change anything.
OXS will send 2 frames at 100 ms interval ONLY if your config file asks sending a VOLT measurement AND another like current or fuel.

You can easily verify if what I suspect is right ot not.
Modify your config in order to send VOLT1, current and fuel. Use your receiver that gives the issue yesterday (the D8R-II I think) and let see what happens.
The test can be done with the code that Mike provided if you want.
User avatar
jhsa
Posts: 19480
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: Introduction to the openx vario/altimeter

Post by jhsa »

I can do, and I'm sure with your code will have the alarm.. I will load the code sending the fields you just said and will make a video with the LED..
The problem is not the rx.. it is in oxs.. :) By the way, no one can buy the old receivers anymore, so the oxs will have to adapt to the new ones, right :)
Please standby for the video..

João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW
mstrens
Posts: 1435
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: Introduction to the openx vario/altimeter

Post by mstrens »

jhsa wrote:I can do, and I'm sure with your code will have the alarm.. I will load the code sending the fields you just said and will make a video with the LED..
The problem is not the rx.. it is in oxs.. :) By the way, no one can buy the old receivers anymore, so the oxs will have to adapt to the new ones, right :)
Please standby for the video..

João
What I suspect is not "normal" (sending to fast some data) but it is the only one explanation I found for the fact that yesterday it worked with 1 receiver and not the other one.
If what I suspect is the real reason, it is easily fixed.
I can do it very easily but the first point is to confirm/infirm it.
davx
Posts: 210
Joined: Sun Sep 15, 2013 7:01 am
Country: -

Re: Introduction to the openx vario/altimeter

Post by davx »

mstrens wrote: In fact it contains 3 frames:
- a frame type A with the measurements other than VOLT and CELL 5E 10 87 00 5E 21 0B 00 5E 30 00 00 5E
- a frame type B with the measurements VOLT and CELL 5E 39 09 00 5E 02 00 00 5E 05 04 00 5E 06 00 00 5E 06 10 00 5E 06 20 00 5E
- a frame type A with new measurements other than VOLT and CELL 5E 10 87 00 5E 21 0B 00 5E 30 00 00 5E.

How do you collect those data.
It should be 3 frames with at least about 100 ms between each.
I don't think you need to split the Frame1, FrSky don't do this and oxs should follow the HUB protocol more closely. It worked well with the original HUB so why change ?

To log the oxs output, I use a FTDI based converter with inverted signals, and capture the data in a linux terminal with the jpnevulator utility. The stream I've posted is continuous so there is really no delay between the 3 frames you describe otherwise it should have been logged.

Another point to consider: in their protocol notes, FrSky recommends to not exceeding 1200 bps of pure data to the receiver.
mstrens
Posts: 1435
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: Introduction to the openx vario/altimeter

Post by mstrens »

davx wrote: I don't think you need to split the Frame1, FrSky don't do this and oxs should follow the HUB protocol more closely. It worked well with the original HUB so why change ?
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)
davx wrote: To log the oxs output, I use a FTDI based converter with inverted signals, and capture the data in a linux terminal with the jpnevulator utility. The stream I've posted is continuous so there is really no delay between the 3 frames you describe otherwise it should have been logged.
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.
davx wrote: Another point to consider: in their protocol notes, FrSky recommends to not exceeding 1200 bps of pure data to the receiver.
Yes but I do not think that we exceed it.

Post Reply

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