Open XVario lipo monitor

Development & General Chat for the superb openxvario project.

Moderator: rainer

RightRudder
Posts: 241
Joined: Tue Jan 15, 2013 9:41 pm
Country: -

Re: Open XVario lipo monitor

Post by RightRudder »

Ahh. I just found the answer to one of my questions in the first post of the 2.1.7 telemetry preview thread:

viewtopic.php?f=45&t=6887

There is a min function for a calculated sensor. You can use it to get the min cell from the cells1-2 field and another one to get the min from the cells3-4 field and then use a third line to get the min from this set in the case of a 3 cell setup. Very nice!

Still wondering if there is an advantage to using one or the other of the two methods I found for monitoring consumption. Both seem to be quite accurate based on simple tests. If anyone has any advice on this I'd like to know.

Joe

BlueSkyLark
Posts: 7
Joined: Sun Apr 17, 2016 9:48 pm
Country: -

Re: Open XVario lipo monitor

Post by BlueSkyLark »

VCC variation errors - and a software fix for it.

I built a potential divider using VCC as the voltage reference, thinking this would provide more accuracy. Unfortunately I find that there is some variation in the voltage supplied by my various BECs. This resulted in the same LIPO giving quite different readings when connected through different ESCs. I wished I'd used the internal voltage reference and was resigned to resoldering, but then I came across another solution.

I used the code posted by Scott Daniels here:

http://provideyourown.com/2012/secret-a ... y-voltage/

This reads the internal reference voltage against VCC, then inverts this to give a reading for VCC based on the internal reference. Once you know what VCC actually is you can use it to correct the values read for each cell. This allows the sensor to give the same results when powered by different BECs.

This saved me having to resolder the resistors on my board.

I hope this makes some sense!
mstrens
Posts: 1435
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: Open XVario lipo monitor

Post by mstrens »

It makes sense because you did not had to resolder the resistors.
Take care that the internal reference voltage need some calibration because there are some deviations from MCU to MCU. The datasheet of AVR328 gives a tolerance of 10% I think.
BlueSkyLark
Posts: 7
Joined: Sun Apr 17, 2016 9:48 pm
Country: -

Re: Open XVario lipo monitor

Post by BlueSkyLark »

Yes, I knew that I would have to recalibrate the OFFSET & MVOLT_PER_STEP values, but having done that I get correct readings irrespective of the voltage supplied by the BEC. That's what I wanted.

I actually found it was better to take a few readings of the VCC and average them out, otherwise I got slightly unstable results.
User avatar
MikeB
9x Developer
Posts: 17993
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: Open XVario lipo monitor

Post by MikeB »

The on chip reference (bandgap) is slow to settle after being selected as the A2D source, hence the need to take more than one reading.

Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

BlueSkyLark
Posts: 7
Joined: Sun Apr 17, 2016 9:48 pm
Country: -

Re: Open XVario lipo monitor

Post by BlueSkyLark »

I'm honoured that you take the time to reply to my post Mike. Thank you.

Yes, I saw in the code in voltage.cpp that you're reading the values twice. I'm new to the arduino and I wasn't really confident to modify Scott Daniel's code, so I just repeatedly called his readVcc() function. I can see that maybe I shouldn't be doing this, but it seems to work.

If I understand rightly this is what his code does:

long readVcc() {
// Read 1.1V reference against AVcc
// set the reference to Vcc and the measurement to the internal 1.1V reference
ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
delayMicroseconds(200); // Wait for Vref to settle
ADCSRA |= _BV(ADSC); // instruct ADC to start conversion
while (bit_is_set(ADCSRA,ADSC)); // wait for ADC to signal conversion complete
uint8_t low = ADCL; // must read ADCL first - it then locks ADCH
uint8_t high = ADCH; // unlocks both
long result = (high<<8) | low; // combine byte values into long
result = 1125300L / result; // Calculate Vcc (in mV); 1125300 = 1.1*1023*1000
return result; // Vcc in millivolts
}

I'm concerned that each time I call this function I'm resetting the ADC source and reference. Will this destabilise it each time?

I'm thinking I should repeat the three lines where the ADC is instructed to read as follows:

long readVcc() {
// Read 1.1V reference against AVcc
// set the reference to Vcc and the measurement to the internal 1.1V reference
ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);

// do initial ADC read
delayMicroseconds(200); // Wait for Vref to settle
ADCSRA |= _BV(ADSC); // instruct ADC to start conversion
while (bit_is_set(ADCSRA,ADSC)); // wait for ADC to signal conversion complete

// repeat ADC read now value has settled.
delayMicroseconds(200); // Wait for Vref to settle
ADCSRA |= _BV(ADSC); // instruct ADC to start conversion
while (bit_is_set(ADCSRA,ADSC)); // wait for ADC to signal conversion complete

uint8_t low = ADCL; // must read ADCL first - it then locks ADCH
uint8_t high = ADCH; // unlocks both
long result = (high<<8) | low;
result = 1125300L / result; // Calculate Vcc (in mV); 1125300 = 1.1*1023*1000
return result; // Vcc in millivolts
}

Or is this unnecessary?

I'm also wondering if I have to worry about interrupts coming in during the process.

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

Re: Open XVario lipo monitor

Post by MikeB »

The 200 uS delay is likely enough, so no need to change anything. There is always noise on analog values so reading several times and taking the average, particularly for something like this, is a good idea.
If you are getting a stable result for the cell voltages then don't change anything!

Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

Post Reply

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