Introduction to the openx vario/altimeter
Moderator: rainer
Re: Introduction to the openx vario/altimeter
I will do what you ask.. I think I already did but will repeat..
Here is a video from the sensor with the vario working..
As I said, both sensors have the same code.. the difference is that one has a current sensor and the other has a pressure sensor.. but even if the vario is commented in software the problem will be there.. I think WE MUST HAVE THE PHYSICAL PRESSURE SENSOR connected for the oXs to update more often.. it doesn't matter if it is active in software..
I will do your tests but I'm pretty much convinced that it is what Mike says..
https://www.youtube.com/watch?v=6nHRqben5e0
Here is a video from the sensor with the vario working..
As I said, both sensors have the same code.. the difference is that one has a current sensor and the other has a pressure sensor.. but even if the vario is commented in software the problem will be there.. I think WE MUST HAVE THE PHYSICAL PRESSURE SENSOR connected for the oXs to update more often.. it doesn't matter if it is active in software..
I will do your tests but I'm pretty much convinced that it is what Mike says..
https://www.youtube.com/watch?v=6nHRqben5e0
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
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
Re: Introduction to the openx vario/altimeter
Having the vario activated in the software (with "#define VARIO") is not a valid option if there is no MS5611 connected .jhsa wrote:I will do what you ask.. I think I already did but will repeat..
Here is a video from the sensor with the vario working..
As I said, both sensors have the same code.. the difference is that one has a current sensor and the other has a pressure sensor.. but even if the vario is commented in software the problem will be there.. I think WE MUST HAVE THE PHYSICAL PRESSURE SENSOR connected for the oXs to update more often.. it doesn't matter if it is active in software..
I will do your tests but I'm pretty much convinced that it is what Mike says..
https://www.youtube.com/watch?v=6nHRqben5e0
I am afraid that OXS get some time out when it tries to read to sensor via I2C that do not exist.
This could give an explanation.
Therefore it is important not to activate it if there is no MS5611 connected to the Arduino.
In order to better debug, I am preparing a special test version for myself where I will send some delay to my PC.
I hope this will help.
It was difficult because I have several versions of OXS I am currently working on.
I had to push on google some changes I expected to publish later.
FYI, the version now on google would not generate anymore acompilation error when you use the wizard.
In the meantime I also found an error in explanation about the way the parameter #define mAmpPerStep would be calculated. I put the fix on google. But I will explain it to you later when the other issues are solved.
Re: Introduction to the openx vario/altimeter
I normally don't have the vario active on the plane with the current sensor, so that is not the problem.. I flashed both with the code I thought it was working (the glider code) to try to find the issue..mstrens wrote: Having the vario activated in the software (with "#define VARIO") is not a valid option if there is no MS5611 connected .
I am afraid that OXS get some time out when it tries to read to sensor via I2C that do not exist.
This could give an explanation.
Therefore it is important not to activate it if there is no MS5611 connected to the Arduino.
Please standby for another report.. I am flashing the code you asked for on both sensors..
And thanks for all.. I think when this problem is solved it will be better for everybody
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
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
Re: Introduction to the openx vario/altimeter
I think we found the problem.. Uploading the video With the minimalist code, both sensors behave the same.. If there is no vario sent, the problem is there. with a vario, no problem as far as I can see..
I am still surprised that the old receiver didn't detect the problem
João
I am still surprised that the old receiver didn't detect the problem
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
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
Re: Introduction to the openx vario/altimeter
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
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
- MikeB
- 9x Developer
- Posts: 17992
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: Introduction to the openx vario/altimeter
The most recent code I have on my PC is from MARCH this year. I haven't needed to update my (one and only) oXs as I've been using FrSky sensors.
This code looks like it does keep sending a frame on a regular basis, even if no new data has been made available.
I personally believe the oXs should keep sending a frame, at least every 500mS (preferably 200mS), whether new data is available or not.
Mike.
This code looks like it does keep sending a frame on a regular basis, even if no new data has been made available.
I personally believe the oXs should keep sending a frame, at least every 500mS (preferably 200mS), whether new data is available or not.
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: Introduction to the openx vario/altimeter
Another one, maybe related to the above problems ?
I've found the being limited with the number of data to send, if the list is too long, it doesn't work correctly.
These settings: caused a compilation error.
And these: ignore the divider factors.
Tested with Arduino Pro Mini 5v 16Mhz + D8R v2 + Taranis.
Bye
I've found the
Code: Select all
#define SETUP_DATA_TO_SEND
These settings:
Code: Select all
#define SETUP_DATA_TO_SEND \
DEFAULTFIELD , ALTIMETER , 1 , 1 , 0 , \
DEFAULTFIELD , VERTICAL_SPEED , 1 , 1 ,0 , \
FRSKY_USERDATA_VFAS_NEW , VOLT3 , 1 , 100 , 0 , \
FRSKY_USERDATA_TEMP1 , VOLT1 , 1 , 100 , 0 , \
FRSKY_USERDATA_TEMP2 , VOLT2 , 1 , 1 , 0 , \
DEFAULTFIELD , CELLS_1_2 , 1 , 1 , 0 , \
DEFAULTFIELD , CELLS_3_4 , 1 , 1 , 0
And these:
Code: Select all
#define SETUP_DATA_TO_SEND \
DEFAULTFIELD , ALTIMETER , 1 , 1 , 0 , \
DEFAULTFIELD , VERTICAL_SPEED , 1 , 1 ,0 , \
FRSKY_USERDATA_VFAS_NEW , VOLT3 , 1 , 100 , 0 , \
FRSKY_USERDATA_TEMP1 , VOLT1 , 1 , 100 , 0 , \
FRSKY_USERDATA_TEMP2 , VOLT2 , 1 , 1 , 0
Tested with Arduino Pro Mini 5v 16Mhz + D8R v2 + Taranis.
Bye
Re: Introduction to the openx vario/altimeter
Yes, It sent on regular basis (500ms if there is only a voltage to be sent).MikeB wrote:The most recent code I have on my PC is from MARCH this year. I haven't needed to update my (one and only) oXs as I've been using FrSky sensors.
This code looks like it does keep sending a frame on a regular basis, even if no new data has been made available.
I personally believe the oXs should keep sending a frame, at least every 500mS (preferably 200mS), whether new data is available or not.
Mike.
By "new" data you must understand that some new ADC conversion (or other read sensor) has been made "Available" for sending. New does not mean that the value is different from the previously sent. E.g. if the measured voltage remains always the same (even if equal 0), it will be sent again and again.
I can reduce 500 to 200 ms. It is very easy.
I had put 500 in order to get more stable values (OXS calculates averages on the enlapsed time).
- MikeB
- 9x Developer
- Posts: 17992
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: Introduction to the openx vario/altimeter
Yes, I understand that, however, we are seeing much more than 500mS between frames on occasions, sometimes over 700mS, and clearly sometimes over 900mS causing the timeout to expire.
Mike.
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: Introduction to the openx vario/altimeter
Yes but the delay of 500 ms applies only for a voltage. For other type of measurements (e.g. a current), the delay was lower.MikeB wrote:Yes, I understand that, however, we are seeing much more than 500mS between frames on occasions, sometimes over 700mS, and clearly sometimes over 900mS causing the timeout to expire.
Mike.
When Jsha made tests, it was foreseen that OXS sent some data that would be generated bout 100 or 200 ms.
So, there is another reason if OXS did not generate data within the 600 ms.
I think that Jsha used a wrong configuration asking OXS to read a baro sensor that did not exist.
I currently try to reporoduce it but I face a new problem that I do not understand.
When I activate the debug mode in OXS and that I try to get the messages on the PC terminal, it happens that :
- I get no message at all
- only part of the text (and then it block);
This occurs always at the beginning (after start up).
I already had a similar issue some months ago but I solved it adding a command micros() somewhere. It was unlogical but it works. Here I can't solved it.
Do you have an idea?????
If you can help, I can explain more and send you all the code to see if you get the same with your IDE.
Re: Introduction to the openx vario/altimeter
No I didn't, not when I setup my planes.. No Sir..mstrens wrote:
I think that Jsha used a wrong configuration asking OXS to read a baro sensor that did not exist.
Only when I started trying to find out what the problem was. Then yes, I tried different configurations with and without vario. With no sensors at all.. If that was the case, the problem wouldn't be there when I flashed the minimalist code as you asked.. And this time on both sensors, proving that the problem is there when a vario is not present and working..
If you want to reproduce the problem you will have to load ersky9x on your taranis because it seems that openTX ignore this problem.. Aparently er9x/ersky9x was also ignoring it until not long ago..
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
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
- MikeB
- 9x Developer
- Posts: 17992
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: Introduction to the openx vario/altimeter
That is the custom switches looking at whether a telemetry value is valid. If not, and you are performing a test like v<ofs, then the test is forced to set the custom switch as OFF. This is likely to hide this problem. The new voice alarms do not have that specific valid test included. While they could be changed to have it, I'm not sure if it it the 'right' thing to do.
I could also increase the timeout, but without knowing a definite maximum value between one telemetry packet and another from the oXs, I don't know to what to set the timeout. It would be best if the oXs did guarantee to send a packet well within 900mS.
Mike.
I could also increase the timeout, but without knowing a definite maximum value between one telemetry packet and another from the oXs, I don't know to what to set the timeout. It would be best if the oXs did guarantee to send a packet well within 900mS.
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: Introduction to the openx vario/altimeter
I make a test on an Arduino in debug mode using the code from Google.
In the config I did not activate the Vario.
I declared that there was a voltage divider and a current sensor.
I ask to transmit 3 fields with this line:
#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
Even if OXS runs for a long time I noticed that some data where ready to transmit every 100 msec or 200 msec.
Here an extract of the debug data I get on the PC:
Try to prepare a Frame1 variant= 0
look for param: 0
look for param: 1
look for param: 2
Frame ready after= 101 with: 5E 28 F4 FF 5E 4 FA D 5E
Try to prepare a Frame1 variant= 1
look for param: 0
look for param: 1
look for param: 2
Try to prepare a Frame1 variant= 0
look for param: 0
look for param: 1
look for param: 2
Frame ready after= 203 with: 5E 28 F4 FF 5E 4 A3 12 5E
Try to prepare a Frame1 variant= 1
look for param: 0
look for param: 1
look for param: 2
Try to prepare a Frame1 variant= 0
look for param: 0
look for param: 1
look for param: 2
Frame ready after= 203 with: 5E 28 F4 FF 5E 4 4C 17 5E
Try to prepare a Frame1 variant= 1
look for param: 0
look for param: 1
look for param: 2
Frame ready after= 102 with: 5E 39 2E 16 5E
Try to prepare a Frame1 variant= 0
look for param: 0
look for param: 1
look for param: 2
Frame ready after= 101 with: 5E 28 F4 FF 5E 4 F5 1B 5E
Try to prepare a Frame1 variant= 1
look for param: 0
look for param: 1
look for param: 2
Try to prepare a Frame1 variant= 0
look for param: 0
look for param: 1
look for param: 2
Frame ready after= 203 with: 5E 28 F4 FF 5E 4 9E 20 5E
Try to prepare a Frame1 variant= 1
look for param: 0
look for param: 1
look for param: 2
Frame ready after= 102 with: 5E 39 2E 16 5E
Try to prepare a Frame1 variant= 0
look for param: 0
look for param: 1
look for param: 2
Frame ready after= 102 with: 5E 28 F4 FF 5E 4 47 25 5E
Try to prepare a Frame1 variant= 1
look for param: 0
look for param: 1
look for param: 2
Try to prepare a Frame1 variant= 0
look for param: 0
look for param: 1
look for param: 2
Frame ready after= 203 with: 5E 28 F4 FF 5E 4 F0 29 5E
So the program try to prepare a Frame with version 0 ( all data except VFAS).
It formats all parameters to send if available and allowed in a version 0 (normally Current and Fuel).
It write in the debug log the enlapse time (in ms) since a previous set of data was prepared and the content of the buffer.
Data are then given to ASERIAL for transmission.
It tries again 100 sec later to prepare a frame version 1 (so with VFAS only); Once on 2, it does not success because the data are not yet available (the delay for voltage is set on 500 ms).
It tries again a frame version 0 ; it succeed always because the data are always available.
Etc...
So I do not see a mistake at OXS level.
I still have to check the code that Mike wrote in Aserial.
Perhaps that this code does not send the data as soon the buffer is filled by the rest of the code.
In the config I did not activate the Vario.
I declared that there was a voltage divider and a current sensor.
I ask to transmit 3 fields with this line:
#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
Even if OXS runs for a long time I noticed that some data where ready to transmit every 100 msec or 200 msec.
Here an extract of the debug data I get on the PC:
Try to prepare a Frame1 variant= 0
look for param: 0
look for param: 1
look for param: 2
Frame ready after= 101 with: 5E 28 F4 FF 5E 4 FA D 5E
Try to prepare a Frame1 variant= 1
look for param: 0
look for param: 1
look for param: 2
Try to prepare a Frame1 variant= 0
look for param: 0
look for param: 1
look for param: 2
Frame ready after= 203 with: 5E 28 F4 FF 5E 4 A3 12 5E
Try to prepare a Frame1 variant= 1
look for param: 0
look for param: 1
look for param: 2
Try to prepare a Frame1 variant= 0
look for param: 0
look for param: 1
look for param: 2
Frame ready after= 203 with: 5E 28 F4 FF 5E 4 4C 17 5E
Try to prepare a Frame1 variant= 1
look for param: 0
look for param: 1
look for param: 2
Frame ready after= 102 with: 5E 39 2E 16 5E
Try to prepare a Frame1 variant= 0
look for param: 0
look for param: 1
look for param: 2
Frame ready after= 101 with: 5E 28 F4 FF 5E 4 F5 1B 5E
Try to prepare a Frame1 variant= 1
look for param: 0
look for param: 1
look for param: 2
Try to prepare a Frame1 variant= 0
look for param: 0
look for param: 1
look for param: 2
Frame ready after= 203 with: 5E 28 F4 FF 5E 4 9E 20 5E
Try to prepare a Frame1 variant= 1
look for param: 0
look for param: 1
look for param: 2
Frame ready after= 102 with: 5E 39 2E 16 5E
Try to prepare a Frame1 variant= 0
look for param: 0
look for param: 1
look for param: 2
Frame ready after= 102 with: 5E 28 F4 FF 5E 4 47 25 5E
Try to prepare a Frame1 variant= 1
look for param: 0
look for param: 1
look for param: 2
Try to prepare a Frame1 variant= 0
look for param: 0
look for param: 1
look for param: 2
Frame ready after= 203 with: 5E 28 F4 FF 5E 4 F0 29 5E
So the program try to prepare a Frame with version 0 ( all data except VFAS).
It formats all parameters to send if available and allowed in a version 0 (normally Current and Fuel).
It write in the debug log the enlapse time (in ms) since a previous set of data was prepared and the content of the buffer.
Data are then given to ASERIAL for transmission.
It tries again 100 sec later to prepare a frame version 1 (so with VFAS only); Once on 2, it does not success because the data are not yet available (the delay for voltage is set on 500 ms).
It tries again a frame version 0 ; it succeed always because the data are always available.
Etc...
So I do not see a mistake at OXS level.
I still have to check the code that Mike wrote in Aserial.
Perhaps that this code does not send the data as soon the buffer is filled by the rest of the code.
Re: Introduction to the openx vario/altimeter
well something is not right, and as far as I understand, and according to my testing, depends on if there is a vario or not attached to the arduino.. Just look at my videos and you will see the difference on the LED. There is data being transmitted more often.. without vario, the data transmitted is clearly much less, or slower.. So, something is happening there
João
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
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
Re: Introduction to the openx vario/altimeter
I have perhaps now an explanation combining several thinks that have been said/seen yesterday.
My code (based on Rainer logic) tries to generate a frame every 100ms (in fact alterning 2 smaller frame) while Mike said that the frame has to be generate every 200 ms.
Jsha have seen that an old receiver works but not a newer.
I suspect that Frsky changed the specifications of the Hub protocol between the 2 receivers.
OXS generates data every 100 ms only if we ask for data present in the 2 different subframes 'e.g. combining a Voltage with a current or vspeed. In the other cases, it generates the frame only every 200ms and there seems to be no issue with the newer Rx.
In a few minute, I will try to give you a modification of code that would send all data in one type of frame every 200 ms. I hope that this should fix it. I will first test myself that the frame is generated as expected
My code (based on Rainer logic) tries to generate a frame every 100ms (in fact alterning 2 smaller frame) while Mike said that the frame has to be generate every 200 ms.
Jsha have seen that an old receiver works but not a newer.
I suspect that Frsky changed the specifications of the Hub protocol between the 2 receivers.
OXS generates data every 100 ms only if we ask for data present in the 2 different subframes 'e.g. combining a Voltage with a current or vspeed. In the other cases, it generates the frame only every 200ms and there seems to be no issue with the newer Rx.
In a few minute, I will try to give you a modification of code that would send all data in one type of frame every 200 ms. I hope that this should fix it. I will first test myself that the frame is generated as expected
Re: Introduction to the openx vario/altimeter
I am coming back on the parameters for the current measurement.
I had a look at the datasheet of the device you are using. I has an offset of 0.6 volt and a sensitivity = 60 mv/Amp
Based on it, I expect that when:
- current = 0, sensor gives 600 mvolt and so ADC would report a value = 1023 * 600 / 5000 (assuming that VCC = 5 volt) = 122
- current = 50 amp, sensor gives 600 mv + 50 amp * 60 mv/amp = 3600 mv and so ADC would report a value = 1023 * 3600 / 5000 = 736.
When OXS calculates the current (in mAmp) it uses following formula:
Current in mAmp = (value read from ADC - offset) * mAmp/step.
In order to get the expected result, it means that:
Offset must be equal to 122
mAmp/step must be equal to 50000 mAmp / (736 - 122) steps = 81.5
I see now that I made a mistake in the explanation in the config.h file.
I said that mAmp/step must be equal to 60 * 1024 / 5000 = 12.2
That is wrong. The good formula would have been
Vcc (in mvolt) / (sensitivity in mv/Amp * 1.023) = 5000 / (60 * 1.023) = 81.5
I fixed it on google.
I had a look at the datasheet of the device you are using. I has an offset of 0.6 volt and a sensitivity = 60 mv/Amp
Based on it, I expect that when:
- current = 0, sensor gives 600 mvolt and so ADC would report a value = 1023 * 600 / 5000 (assuming that VCC = 5 volt) = 122
- current = 50 amp, sensor gives 600 mv + 50 amp * 60 mv/amp = 3600 mv and so ADC would report a value = 1023 * 3600 / 5000 = 736.
When OXS calculates the current (in mAmp) it uses following formula:
Current in mAmp = (value read from ADC - offset) * mAmp/step.
In order to get the expected result, it means that:
Offset must be equal to 122
mAmp/step must be equal to 50000 mAmp / (736 - 122) steps = 81.5
I see now that I made a mistake in the explanation in the config.h file.
I said that mAmp/step must be equal to 60 * 1024 / 5000 = 12.2
That is wrong. The good formula would have been
Vcc (in mvolt) / (sensitivity in mv/Amp * 1.023) = 5000 / (60 * 1.023) = 81.5
I fixed it on google.
Re: Introduction to the openx vario/altimeter
In order to generate only one frame with all data every 200 ms, you just have to change 1 character(1 instead of 0) in file oxs_out_frsky.cppmstrens wrote:I have perhaps now an explanation combining several thinks that have been said/seen yesterday.
My code (based on Rainer logic) tries to generate a frame every 100ms (in fact alterning 2 smaller frame) while Mike said that the frame has to be generate every 200 ms.
Jsha have seen that an old receiver works but not a newer.
I suspect that Frsky changed the specifications of the Hub protocol between the 2 receivers.
OXS generates data every 100 ms only if we ask for data present in the 2 different subframes 'e.g. combining a Voltage with a current or vspeed. In the other cases, it generates the frame only every 200ms and there seems to be no issue with the newer Rx.
In a few minute, I will try to give you a modification of code that would send all data in one type of frame every 200 ms. I hope that this should fix it. I will first test myself that the frame is generated as expected
There is a line (nearly at the end)
if ( (SwitchFrameVariant == 0) && ( arduinoData->mVoltAvailable[VoltToSend] == true )) {
It must be
if ( (SwitchFrameVariant == 1) && ( arduinoData->mVoltAvailable[VoltToSend] == true )) {
In this case, OXS will send every 200msec the current and the consumption and additionnally (in the same frame) the voltage every 500 ms. If you want having the voltage every 200 ms too, you could change 1 character (2 instead of 5) in file oxs_arduino.cpp.
There is a line
if(millis() > ( lastVoltMillis + 500) ){ // calculate average only once every 500 msec
It must be
if(millis() > ( lastVoltMillis + 200) ){ // calculate average only once every 200 msec
Let me know if this fix the issues and if it works with all type of receiver.
If OK, I will put the code on google.
Re: Introduction to the openx vario/altimeter
ok, will try now. thanks..
João
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
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
Re: Introduction to the openx vario/altimeter
There was already "1" on the code
Here is a copy..
So, the problem might be somewhere else..
João
Here is a copy..
Code: Select all
if ( (SwitchFrameVariant == 1) && ( arduinoData->mVoltAvailable[VoltToSend] == true )) {
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
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
Re: Introduction to the openx vario/altimeter
Sorry, I made a msitake in the post.jhsa wrote:The was already "1" on the code
Here is a copy..
So, the problem might be somewhere else..Code: Select all
if ( (SwitchFrameVariant == 1) && ( arduinoData->mVoltAvailable[VoltToSend] == true )) {
João
It must be 0 instead of 1
Re: Introduction to the openx vario/altimeter
Changed this, and the LED looked much better immediately.. radio is on now for several minutes and no error reported until now.. Way to go??mstrens wrote:
In this case, OXS will send every 200msec the current and the consumption and additionnally (in the same frame) the voltage every 500 ms. If you want having the voltage every 200 ms too, you could change 1 character (2 instead of 5) in file oxs_arduino.cpp.
There is a line
if(millis() > ( lastVoltMillis + 500) ){ // calculate average only once every 500 msec
It must be
if(millis() > ( lastVoltMillis + 200) ){ // calculate average only once every 200 msec
Let me know if this fix the issues and if it works with all type of receiver.
If OK, I will put the code on google.
https://www.youtube.com/watch?v=eO3Ttm5PpLQ
João
P.S. - Let the testing continue
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
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
Re: Introduction to the openx vario/altimeter
Also, send current as FUEL.. Look at the values on the log please.. Wrong scaling?? or another bug?? Also look at the field mAh. it looks more real??
Still have to connect a wattmeter to check the current is correct..
João
Still have to connect a wattmeter to check the current is correct..
João
- Attachments
-
- Fire_Devil-2014-07-14.zip
- (2.13 KiB) Downloaded 132 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
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
Re: Introduction to the openx vario/altimeter
another funny situation.. When the voltage at the battery side is between approximately 9.3V and 9.5V, the radio displays around 3.0V. If i go under 9.3v or above 9.5V, the reading is normal and correct again..
Can someone else reproduce this situation? Mike, would this be in ersky9x or oXs? I guess I can test on a Analog port and see if it happens there too?
Thanks
João
Can someone else reproduce this situation? Mike, would this be in ersky9x or oXs? I guess I can test on a Analog port and see if it happens there too?
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
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
Re: Introduction to the openx vario/altimeter
It doesn't happen with the analog ports. However it does happen with the oXs on both my models. Mike could you test this with a real frsky sensor? Just to find out if the problem is in ersky or in the oXs. Thanks.. here is a picture.
João
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
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
Re: Introduction to the openx vario/altimeter
Hi,
I've logged the FrSky HUB serial output and I've isolated the repeating sequence:
Without any sensor:
And with a temp (Temp1) and a vario sensors:
As you can see, the Frame1 is sent every ~200 ms and not all the sensors are present, the Frame2 every ~1s and contains only the fuel level.
I never got the Frame3 as, I suppose, I don't have a GPS.
I hope it'll help you to find the problem...
Bye
I've logged the FrSky HUB serial output and I've isolated the repeating sequence:
Without any sensor:
Code: Select all
2014-07-14 18:05:52.440539:
5E 24 F0 FF 5E 25 F0 FF 5E 26 F0 FF 5E 10 70 00
5E 21 4B 00 5E 02 EF FF 5E 05 E9 FF 5E
2014-07-14 18:05:52.627287:
5E 24 F0 FF 5E 25 F0 FF 5E 26 F0 FF 5E 10 70 00
5E 21 4B 00 5E 02 EF FF 5E 05 E9 FF 5E
2014-07-14 18:05:52.814358:
5E 24 F0 FF 5E 25 F0 FF 5E 26 F0 FF 5E 10 70 00
5E 21 4B 00 5E 02 EF FF 5E 05 E9 FF 5E
2014-07-14 18:05:53.000824:
5E 24 F0 FF 5E 25 F0 FF 5E 26 F0 FF 5E 10 70 00
5E 21 4B 00 5E 02 EF FF 5E 05 E9 FF 5E
2014-07-14 18:05:53.236387:
5E 24 F0 FF 5E 25 F0 FF 5E 26 F0 FF 5E 10 70 00
5E 21 4B 00 5E 02 EF FF 5E 05 E9 FF 5E
5E 04 32 00 5E
Code: Select all
2014-07-14 18:10:36.838142:
5E 24 F0 FF 5E 25 F0 FF 5E 26 F0 FF 5E 10 45 0F
5E 21 49 00 5E 02 19 00 5E 05 EC FF 5E
2014-07-14 18:10:37.026047:
5E 24 F0 FF 5E 25 F0 FF 5E 26 F0 FF 5E 10 45 0F
5E 21 62 00 5E 02 19 00 5E 05 EC FF 5E
2014-07-14 18:10:37.212766:
5E 24 F0 FF 5E 25 F0 FF 5E 26 F0 FF 5E 10 45 0F
5E 21 62 00 5E 02 19 00 5E 05 EC FF 5E
2014-07-14 18:10:37.446572:
5E 24 F0 FF 5E 25 F0 FF 5E 26 F0 FF 5E 10 45 0F
5E 21 49 00 5E 02 19 00 5E 05 EC FF 5E
2014-07-14 18:10:37.633640:
5E 24 F0 FF 5E 25 F0 FF 5E 26 F0 FF 5E 10 45 0F
5E 21 49 00 5E 02 19 00 5E 05 EC FF 5E
5E 04 32 00 5E
I never got the Frame3 as, I suppose, I don't have a GPS.
I hope it'll help you to find the problem...
Bye
Re: Introduction to the openx vario/altimeter
With this change I didn't have alarms anymore.. It seems to be ok..jhsa wrote:Changed this, and the LED looked much better immediately.. radio is on now for several minutes and no error reported until now.. Way to go??mstrens wrote:
In this case, OXS will send every 200msec the current and the consumption and additionnally (in the same frame) the voltage every 500 ms. If you want having the voltage every 200 ms too, you could change 1 character (2 instead of 5) in file oxs_arduino.cpp.
There is a line
if(millis() > ( lastVoltMillis + 500) ){ // calculate average only once every 500 msec
It must be
if(millis() > ( lastVoltMillis + 200) ){ // calculate average only once every 200 msec
Let me know if this fix the issues and if it works with all type of receiver.
If OK, I will put the code on google.
https://www.youtube.com/watch?v=eO3Ttm5PpLQ
João
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
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
Re: Introduction to the openx vario/altimeter
Davx,davx wrote:Hi,
I've logged the FrSky HUB serial output and I've isolated the repeating sequence:
Without any sensor:And with a temp (Temp1) and a vario sensors:Code: Select all
2014-07-14 18:05:52.440539: 5E 24 F0 FF 5E 25 F0 FF 5E 26 F0 FF 5E 10 70 00 5E 21 4B 00 5E 02 EF FF 5E 05 E9 FF 5E 2014-07-14 18:05:52.627287: 5E 24 F0 FF 5E 25 F0 FF 5E 26 F0 FF 5E 10 70 00 5E 21 4B 00 5E 02 EF FF 5E 05 E9 FF 5E 2014-07-14 18:05:52.814358: 5E 24 F0 FF 5E 25 F0 FF 5E 26 F0 FF 5E 10 70 00 5E 21 4B 00 5E 02 EF FF 5E 05 E9 FF 5E 2014-07-14 18:05:53.000824: 5E 24 F0 FF 5E 25 F0 FF 5E 26 F0 FF 5E 10 70 00 5E 21 4B 00 5E 02 EF FF 5E 05 E9 FF 5E 2014-07-14 18:05:53.236387: 5E 24 F0 FF 5E 25 F0 FF 5E 26 F0 FF 5E 10 70 00 5E 21 4B 00 5E 02 EF FF 5E 05 E9 FF 5E 5E 04 32 00 5E
As you can see, the Frame1 is sent every ~200 ms and not all the sensors are present, the Frame2 every ~1s and contains only the fuel level.Code: Select all
2014-07-14 18:10:36.838142: 5E 24 F0 FF 5E 25 F0 FF 5E 26 F0 FF 5E 10 45 0F 5E 21 49 00 5E 02 19 00 5E 05 EC FF 5E 2014-07-14 18:10:37.026047: 5E 24 F0 FF 5E 25 F0 FF 5E 26 F0 FF 5E 10 45 0F 5E 21 62 00 5E 02 19 00 5E 05 EC FF 5E 2014-07-14 18:10:37.212766: 5E 24 F0 FF 5E 25 F0 FF 5E 26 F0 FF 5E 10 45 0F 5E 21 62 00 5E 02 19 00 5E 05 EC FF 5E 2014-07-14 18:10:37.446572: 5E 24 F0 FF 5E 25 F0 FF 5E 26 F0 FF 5E 10 45 0F 5E 21 49 00 5E 02 19 00 5E 05 EC FF 5E 2014-07-14 18:10:37.633640: 5E 24 F0 FF 5E 25 F0 FF 5E 26 F0 FF 5E 10 45 0F 5E 21 49 00 5E 02 19 00 5E 05 EC FF 5E 5E 04 32 00 5E
I never got the Frame3 as, I suppose, I don't have a GPS.
I hope it'll help you to find the problem...
Bye
Thanks for the data.
In fact I can generate it when I run OXS in debug mode and use a PC terminal in the arduino IDE.
Re: Introduction to the openx vario/altimeter
In order to analyse, can you provide me a copy of the config. file you are currently using.jhsa wrote:another funny situation.. When the voltage at the battery side is between approximately 9.3V and 9.5V, the radio displays around 3.0V. If i go under 9.3v or above 9.5V, the reading is normal and correct again..
Can someone else reproduce this situation? Mike, would this be in ersky9x or oXs? I guess I can test on a Analog port and see if it happens there too?
Thanks
João
Please note that I just fixed a bug that makes that multiplier/divider/offset in line #define SETUP_DATA_TO_SEND where not always correctly applied when sending a VOLT1, VOLT2, ...
The fix is on google
Re: Introduction to the openx vario/altimeter
Here are both config files from my plane and my glider. I used a variable power supply to change the voltage.
Until around 9.3V, the voltage reads normal.. between 9.3V and 9.5V, it reads 2.9V and 3.0V. Above 9.5V it reads normal again.
The voltage, apart from that little glitch is quite precise according to my multimeter..
João
EDIT: If you want I can put my multimeter alongside my tx and make a video of it happening..
Until around 9.3V, the voltage reads normal.. between 9.3V and 9.5V, it reads 2.9V and 3.0V. Above 9.5V it reads normal again.
The voltage, apart from that little glitch is quite precise according to my multimeter..
João
EDIT: If you want I can put my multimeter alongside my tx and make a video of it happening..
- Attachments
-
- configs.zip
- (23.63 KiB) Downloaded 133 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
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
Re: Introduction to the openx vario/altimeter
[quote="jhsa"]Here are both config files from my plane and my glider. I used a variable power supply to change the voltage.
Until around 9.3V, the voltage reads normal.. between 9.3V and 9.5V, it reads 2.9V and 3.0V. Above 9.5V it reads normal again.
The voltage, apart from that little glitch is quite precise according to my multimeter..
João
I understand what you explain.
9.3 V is an Hexadecimal value = 0x5D.
9.4 V is an Hexadecimal value = 0x5E.
Those values are handled in the Hub protocol in a very special way.
When oXs want to send 0x5E, it has to send to Rx 0x5D + 0x3D (hexadecimal).
I will check if oxs send it really as foreseen. If so, it means that the mistake should be on Tx side (or at Frsky level) when the conversion in the opposite direction is done again.
I will let you know
Until around 9.3V, the voltage reads normal.. between 9.3V and 9.5V, it reads 2.9V and 3.0V. Above 9.5V it reads normal again.
The voltage, apart from that little glitch is quite precise according to my multimeter..
João
I understand what you explain.
9.3 V is an Hexadecimal value = 0x5D.
9.4 V is an Hexadecimal value = 0x5E.
Those values are handled in the Hub protocol in a very special way.
When oXs want to send 0x5E, it has to send to Rx 0x5D + 0x3D (hexadecimal).
I will check if oxs send it really as foreseen. If so, it means that the mistake should be on Tx side (or at Frsky level) when the conversion in the opposite direction is done again.
I will let you know