Introduction to the openx vario/altimeter

Post by **jhsa** » Sun Jul 13, 2014 5:12 pm

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

mstrens · Post by **mstrens** » Sun Jul 13, 2014 5:28 pm

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

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.

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.

Post by **jhsa** » Sun Jul 13, 2014 5:34 pm

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.

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..
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

Post by **jhsa** » Sun Jul 13, 2014 5:45 pm

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

Post by **jhsa** » Sun Jul 13, 2014 5:53 pm

And the video..

https://www.youtube.com/watch?v=85Ej1b7lel8

João

Post by **MikeB** » Sun Jul 13, 2014 7:03 pm

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.

davx · Post by **davx** » Sun Jul 13, 2014 7:08 pm

Another one, maybe related to the above problems ?

I've found the

Code: Select all

#define  SETUP_DATA_TO_SEND

being limited with the number of data to send, if the list is too long, it doesn't work correctly.

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

caused a compilation error.

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

ignore the divider factors.

Tested with Arduino Pro Mini 5v 16Mhz + D8R v2 + Taranis.

Bye

mstrens · Post by **mstrens** » Sun Jul 13, 2014 7:16 pm

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.

Yes, It sent on regular basis (500ms if there is only a voltage to be sent).
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).

Post by **MikeB** » Sun Jul 13, 2014 7:36 pm

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.

mstrens · Post by **mstrens** » Sun Jul 13, 2014 8:18 pm

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.

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.
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.

Post by **jhsa** » Sun Jul 13, 2014 8:29 pm

mstrens wrote:
I think that Jsha used a wrong configuration asking OXS to read a baro sensor that did not exist.

No I didn't, not when I setup my planes.. No Sir..
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

Post by **MikeB** » Sun Jul 13, 2014 9:39 pm

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.

mstrens · Post by **mstrens** » Sun Jul 13, 2014 9:58 pm

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.

Post by **jhsa** » Sun Jul 13, 2014 10:44 pm

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

mstrens · Post by **mstrens** » Mon Jul 14, 2014 6:39 am

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

mstrens · Post by **mstrens** » Mon Jul 14, 2014 6:55 am

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.

mstrens · Post by **mstrens** » Mon Jul 14, 2014 7:25 am

mstrens 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

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.cpp
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.

Post by **jhsa** » Mon Jul 14, 2014 9:46 am

ok, will try now. thanks..

João

Post by **jhsa** » Mon Jul 14, 2014 9:57 am

There was already "1" on the code

Here is a copy..

Code: Select all

 if ( (SwitchFrameVariant == 1) && (  arduinoData->mVoltAvailable[VoltToSend] == true )) {

So, the problem might be somewhere else..
João

mstrens · Post by **mstrens** » Mon Jul 14, 2014 10:08 am

jhsa wrote:The was already "1" on the code
Here is a copy..
Code: Select all
 if ( (SwitchFrameVariant == 1) && (  arduinoData->mVoltAvailable[VoltToSend] == true )) {
So, the problem might be somewhere else..
João

Sorry, I made a msitake in the post.
It must be 0 instead of 1

Post by **jhsa** » Mon Jul 14, 2014 10:17 am

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.

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??

https://www.youtube.com/watch?v=eO3Ttm5PpLQ

João

P.S. - Let the testing continue

Post by **jhsa** » Mon Jul 14, 2014 12:35 pm

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

Post by **jhsa** » Mon Jul 14, 2014 12:51 pm

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

Post by **jhsa** » Mon Jul 14, 2014 2:51 pm

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

davx · Post by **davx** » Mon Jul 14, 2014 4:44 pm

Hi,

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

And with a temp (Temp1) and a vario sensors:

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

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

Post by **jhsa** » Mon Jul 14, 2014 5:13 pm

jhsa wrote:
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.
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??

https://www.youtube.com/watch?v=eO3Ttm5PpLQ

João

With this change I didn't have alarms anymore.. It seems to be ok..

João

mstrens · Post by **mstrens** » Mon Jul 14, 2014 8:13 pm

davx wrote:Hi,

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

And with a temp (Temp1) and a vario sensors:

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

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

Davx,
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.

mstrens · Post by **mstrens** » Mon Jul 14, 2014 8:22 pm

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

In order to analyse, can you provide me a copy of the config. file you are currently using.

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

Post by **jhsa** » Mon Jul 14, 2014 9:28 pm

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..

mstrens · Post by **mstrens** » Tue Jul 15, 2014 6:46 am

[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

openrcforums

Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter

Re: Introduction to the openx vario/altimeter