Introduction to the openx vario/altimeter

[MikeB]

A dump of the user data as output by the DJT (recovered from the complete data stream)
5E
5E10CCFF5E2123005E300D005E05F6FF5E2832005E02BD135E391D005E
5E
5E10CCFF5E2124005E3004005E05F6FF5E2832005E02BD135E391D005E
5E

There seem to be some extra 5E bytes.
It appears to be sending data with IDs:
0x10 ALT bp
0x21 ALT ap
0x30 unknown in the FrSky data protocol
0x05 T2
0x28 Current
0x02 T1
0x39 unknown in the FrSky data protocol

I'll try blocking the light completely, it's a very dull day here and I'm indoors!

Mike.

[MikeB]

I wondering if there is a problem with the altitude values compared to the FrSky vario (new version). The bp part may be positive or negative, while the ap part is always sent as positive, but should have the same sense as the bp part.
-1.5 is sent as -1,50
+1.5 is sent as +1,50
Frsky acknowledge ther is a problem with values between 0 and -1. Anything from 0 to -0.49 is sent as 0, anything from -0.5 to -0.99 is sent as -1.

On startup today, I have a reading of around -50.8 As I raise the sensor the reading gets to -50.5, then jumps to -49.4.
I'll chack the er9x code, but I noticed the code in the Taranis was wrong, not treating the ap part as negative when necessary.

I've just repeated the test using a FrSky vario. This changes the display smoothly in steps of 0.1m without the sudden jump, so I reckon er9x code matches the FrSky sensor!

Mike.

[MikeB]

I'm not sure this code works correctly!

Take altcm as -5090 (so -50.9m)

uint16_t Centimeter = uint16_t(abs(altcm)%100); Centimeter set to 90
long Meter;
if (altcm >0){ FALSE
Meter = (altcm-(long)Centimeter);
}
else{ TRUE
Meter = -1*(abs(altcm)+(long)Centimeter); abs(altcm) = 5090, add Centimeter and *-1 becomes -5180 in Meter
}
Meter=Meter/100; Meter becomes -51

So value of -50.9 sent as -51.9.

Mike.

[MikeB]

I've done a code change and now the altitude changes properly and is stable. This problem only occurs if you switch on and are at a negative altitude, which I frequently am Ias I'm near sea level at home.
I've PMed the code change to rainer, but it is not complete as I havent handled the 0 to -1 problem(yet).

Mike.

[MikeB]

This is my complete fix, for anyone that wants to try it.

Code: Select all

void OXS_OUT_FRSKY::SendAlt(long altcm)
{
  ldiv_t qr ;
	
  qr = ldiv( altcm, 100 ) ;

  uint16_t Centimeter =  abs((int16_t)qr.rem);
  int16_t Meter = qr.quot ;
//#ifdef FORCE_ABSOLUTE_ALT
//  altcm-=1;
//#endif
  if (altcm <0)
	{
		if ( Meter == 0 )
		{
			if ( Centimeter >= 50 )
			{
				Meter = -1 ;
			}
			Centimeter = 0 ;				
		}
	}

  SendValue(FRSKY_USERDATA_BARO_ALT_B, (int16_t)Meter);
  SendValue(FRSKY_USERDATA_BARO_ALT_A, Centimeter);
}

It is difficult to test the 0 to -1 bit unless you are actually at between -1 and 0.

Mike.

Edit: Just noticed the next function may need the same fix:
void OXS_OUT_FRSKY::SendGPSAlt(long altcm)

[pwarren]

Hi guys, I've built my openxvario, but I only have a 3.3v FTDI adapter, will that work to write the program to the arduino?

Failing that, can I connect all the pins except for power, and power the arduino by the servo connector at 5v, then upload the program?

I will get a 5v FTDI thingo eventually, but want to make sure everything's working now!

[Rob Thomson]

A dump of the user data as output by the DJT (recovered from the complete data stream)
5E
5E10CCFF5E2123005E300D005E05F6FF5E2832005E02BD135E391D005E
5E
5E10CCFF5E2124005E3004005E05F6FF5E2832005E02BD135E391D005E
5E

There seem to be some extra 5E bytes.
It appears to be sending data with IDs:
0x10 ALT bp
0x21 ALT ap
0x30 unknown in the FrSky data protocol
0x05 T2
0x28 Current
0x02 T1
0x39 unknown in the FrSky data protocol

I'll try blocking the light completely, it's a very dull day here and I'm indoors!

Mike.

Check with kilrah.

I am pretty sure he had to do a strange crc check in opentx related to the same issue.

Sent from my GT-I9300 using Tapatalk 2

[MikeB]

Working on windows, I seem to have got the eclipse IDE working for the Arduino. I followed the instructions here:
http://sun0.cs.uca.edu/~administrator/r ... ndows.html.
I did one or two things slightly diferently as I pointed to the compiler I already had installed (4.8.0) rather than use the one installed as part of the arduino IDE.

I've got as far as getting the "blink" program to compile for a "mini light" with M328 on it. Not tried to execute it yet.

Eclipse is sooo much better than the default arduino IDE, although I still prefer to use the multiedit editor program I normally use. At least eclipse noticies you have edited a source file outside of eclipse, which the arduino IDE failed to do.

Mike.

[MikeB]

Has anypne tested the SPORT varsion of the code?

Mike.

[Kilrah]

Yep, it works fine. I've also completed it with voltage and current, but don't have commit rights in the project. Can post my file later.

One thing, the openxsensor branch currently has an excessive filtering on the output values, so response is super slow. Don't understand why it was done that way, I toned it down and it's much better.

Sent via mobile

[MikeB]

The reason I ask is I can't see any code that "turns the Sport pin round" between receive and transmit, I may be missing it though. It looks to me that the pin is initialised first to an output (setTX), then as an input(setRX). This means when used to send data it is actually turning the internal pullup resistor on and off, not driving the signal line.

Mike.

[Kilrah]

Hmm I didn't really look at the code, I built a new oXv with sport wiring, hooked it up and it worked, so I didn't check that. Just added the other 2 values and sorted my filtering issues.

But now you say that it reminds me that at some point I hooked my logic analyser, and wasn't seeing what the oXv was supposed to be saying. Would explain it.
Would want to manually switch the pin to output before a write and back to input afterwards...

[MikeB]

I can't see any byte stuffing code either!

Mike.

[ReSt]

Question respective analog inputs on the XVario:

I'm going to add a connector to my xVario where I want to connect the voltages of the 3s flight battery (taken form the balancer connector)

When I connect analog voltages (Cell1 to 3 of the 3s ) to the analog input pins A0, A1, A2 via voltage dividers, should all three voltage dividers be of the same relation (e.g. 3kohm + 1 kohm) ?

I suppose, the maximum input voltage at the processor pins should be below 5 volt ?

Where and what will I see from these voltages on the radio ?
Cell 1 to 3 displayed as V1, V2, V3 ?
Or will V1 - V3 show cell1, cell1+cell2, cell1+cell2+cell3 ?

Reinhard

[rainer]

Hi Reinhard,
you cannot add your balance connector directly via a voltage divider.
or at least it would not result in the expected readings, as all readings would be the voltage related to GND, not to the previous cell.
Rainer

[MikeB]

Are we relying on the 5V supply regulator for the analog voltage reference?

Mike.

[rainer]

voltage measurements are being done against the internal voltage ref. think it was a 1.1v source.
what i meant above was that using voltage diividers for the single cells, we would end up having the actual cell voltage for the first cell, the summ of cell1+2 for the 2nd cell 1+2+3 for the third one and so on.
i thought about a routine to calculate the actual voltages, but actually with all those small tolerances adding up, i don't think it would be worth it.

[MikeB]

Be aware the internal bandgap has minimum and maximum values of 1.0V and 1.2V from chip to chip. The 1.1V value is a typical value.

Mike.

[ReSt]

That means, it's not simply possible to get the single cell voltages ( nothing calculated in the radio?) ?

Voltages will be displayed as V1, V2, Vn ?

With three identical voltage dividers, one would get the single cell voltages without too big errors, when the xVario subtracts the measured analog value of the 'lower ' cells (before scaling it to the real voltage value) ?

Reinhard

[rainer]

yes, possible, but the resolution would suffer as you would have to scale all 3 voltage dividers to the highest possible voltage of the highest cell. this wouldn't be the best resolution if you are just interested in e.g. 2.7..4.3v

[ReSt]

It's running.
As voltage deviders I used 2.2k - 1.0 k smd resistors that I selected with the Ohm meter. That gives me a range of around 15 volts max.
I adapted the Xvario code to calculate the difference of the voltages between cell(n) and cell(n-1), a voltage of 4 volt gives a raw analog value of around 270

I admit, the voltage dividers seem to have small differences, but it's acceptable for me.

The values that I get are:
measured with the voltmeter: 3.93 3.84 3.85 total 11.62
displayed at the radio v1:0.00 v2:3.88 v3:3.90 v4:3.84 CTot:11.6

I don't know in the moment, why I get v2 to v4 while I use PIN_VoltageCell 1 - 3

btw. there is a typo in the Cell1 definition as it shows Pin 2 (same as Cell 3)

Reinhard

[ReSt]

I don't know in the moment, why I get v2 to v4 while I use PIN_VoltageCell 1 - 3

Discovered it.

ER9x holds cell1 free for VREF and therefore shifts cells 1 to ... one cell position up

But in openxvario I know if I'm sending VREF or not.
So in case I do not send VREF, for transmission I reduce the cell number of the single cells by 1 ( that is, cell 1 to 3 wil be sent as 0 to 2) .
Now ER9x displays cell 1 to 3 as v1 to v3

Reinhard

[MikeB]

ER9x holds cell1 free for VREF and therefore shifts cells 1 to ... one cell position up

Not sure what you mean about VREF. The FrSky hub sends index 0 for cell1, index 1 for cell 2 etc. so this is what you need to send (and are now sending).

Mike.

[ReSt]

ok, that's the reason why.

I do not have the FrSky Hub nor a FrSky receiver in between that changes anything in the protocol.

I'm using a separate transmitter modem (APC200) sending the data of the XVario exactly as it is produced.
And in the radio I use the N2F option to receive and save the data packages that afterwards are handled from the normal frsky.cpp routines. And there is some code, that stores a VREF value into the first cell and shifts the single cell voltages up one position (if I interpreted the code right).

Reinhard

[MikeB]

Still confused, is this code in the openXsensor?
I don't think er9x ever uses the cell1 location for a VREF value.

Mike.

[ReSt]

You are right (as always )
Nothing in Frsky.cpp

I mixed some things up.

It is really in the openXvario code.
As I understand it now:
OpenXVario hardcoded reserves cell0 to send the

"internal voltage ... the way, the vfas voltage gets displayed"

and therefore cell 1 to n are sent with index 1 to n

And that's the reason why I see my flight pack cell voltages (measured with analog input A0 to A2) as v2 to v4 and not as v1 to v3 as I expected.

My solution now is, let openxvario check if the "internal voltage" has to be sent or not. Then reserve or free cell0 and change the indexes accordingly when sending analog voltages as cell voltages.

Reinhard

[Kilrah]

Or change oXv to send internal voltage as the 6th cell, which is the least used one.

[rainer]

i had one additional voltage available which is the internally measured voltage of the arduino board. as no ID exist to transfer that this has been transfered as cell0

Code: Select all

#ifdef SEND_VREF
// internal voltage as cell 0 which is not optimal. somebody will probably have to add another id
// for this or change the the way the vfas voltage gets displayed
SendCellVoltage(0,readVccMv());
#endif 

The cell voltage transmission has been prepared, but not really been used before, due to the concerns i mentioned earlier. the idea was always to add the possibility to use e.g. the FRSky cell monitor, but that has not been done yet as it is quite difficult to retrieve the data from that device.

so if you need it different, those lines of code should be well documented.

Rainer.

[MikeB]

Er9x adds up the individual cell voltages received to give the total pack voltage. Sending anything in "unused" cells will cause this to be incorrect.

Since FrSky are now heading down the SPort route, we can probably add some new ID fields if required for our own use.

Mike.

[ReSt]

Rainer, yes, it's very well documented (even I can understand it ).

In SendCellVoltage() I check with #ifdef SEND_VREF
If it is defined, I leave the code as is, if it is not defined I subtract 1 from the cellID

btw the total voltage is always correctly calculated as the VREF voltage, if not connected, sends a 0 value.

Reinhard