[jdl]

I've just flashed this same HEX on my CC3D quad. Of couse, NO TEL COM error as it runs firmware LP next 735 and the OSD firmware is for older 16.09, this was expected.

But battery voltage monitoring stuff works flawlessly!  I've tested it with 4s and with 2s batteries and I confirm the code is ok, cells count is detected correctly and battery voltage too, i.e. 15.33V on the 4S battery. The voltage reading is steady. Battery percentage is steady, too.

My best guess is an electrical issue in your setup like a floating / loose ground or some kind of ground loop. But I would not bet on either of these particular suggestions
Its resembles like there is a large capacitor between the voltage divider and the Atmega adc pin?!

Cell warning threshold of 3.0V is suitable for Liion, for Lipo this is disastrously low!

Correct, batt_type is force set to 1 (lipo) in this particular firmware as BatteryType Selection code is not included / disabled in it.

num_cells starts with value "1" on OSD boot. Later, it can go only up if higher voltage is detected, but never goes down. This meanes the cells count depends on the highest voltage seen from OSD firmware since boot up.

Code: [Select]

          if (voltage > 21.8)                            // min 3.63V for 6-cell (21.0-25.2)    (21.0-26.1)
            num_cells=6;
          else 
            if ((voltage > 17.45) && (num_cells < 5))    // min 3.49V for 5-cell (17.5-21.0)    (17.5-21.75)
              num_cells=5;
            else 
              if ((voltage > 13.2) && (num_cells < 4))   // min 3.30V for 4-cell (14.0-16.8)    (14.0-17.4)
                num_cells=4;
              else
                if ((voltage > 8.8) && (num_cells < 3))  // min 2.93V for 3-cell (10.5-12.6)    (10.5-13.05)
                  num_cells=3;
                else 
                  if ((voltage > 5.0) && (num_cells < 2))// min 2.50V for 2-cell (7.0-8.4)      (7.0-8.7)
                    num_cells=2;                             

This explains your observation that cells count stays at 4s while voltage drops down.

What value is displayed for battery percent when voltage drops below 4V while cells count remains 4s?

[trust]

In the scenario where I plug the V into the OSD first, and get 4 cells, the V displayed settles on 3.94V, but capacity keeps getting smaller and smaller and eventually goes down to like 2%.
I tried another test. I have the V into the OSD batt1 pin on separate plug. I plugged in everything except the batt1 pin. The OSD displays 0V and 1 cell - oddly capacity shows at 55%. Then I plug in the batt1 pin. Battery voltage V climbs to 3.94V (the correct V of a 4s divided by 4) - but num_cell stays at 1. Capacity climbs to 82% and holds.
I wasn't too concerned about the battery low warning - I usually just look at the voltage to determine the cutoff point, but I'll change that in the setup to a more reasonable value like 3.5V

[jdl]

Thanks for tests!
I've got something ! If per-cell voltage is far below what I've considered a completely depleted cell (under load) - appox. 3.4635V (or even "0" in extreme case) the percent calculated is negative. When Voltage-to-Remaining Capacity correction curves are used, this could cause Out-Of-Range (index > 99) error situation when performing table read (0..99) with this negative value converted to unsigned int.

I've made some code changes. This is the fixed HEX file. It should fix the abnormal voltage percent display in your second test when voltage is read "0V" and one cell detected.

Do not know, however, if it'll help with the problem with voltage reading creeping from approx 16V to 3.94V...

[trust]

Ok. Tested. Yes, it fixed the bat capacity issue. Now if I plug in everything except the batt1, it reads 1 cell and 0V. Plug in batt1 and it rises up to 3.94V, and the capacity goes up to 81%. Good!
But it still only reads 1 cell.
Reversing the order, plugging in batt1, then the cam/xmtr, then the fc+OPOSD+, it starts at 4cells and 15+V, then ramps down to 3.94V, plus capacity goes to about 2%, but num_cells stays 4.

I did have another weird issue. I had changed the voltage divider value, the bat capacity value to 2200 and the warning level to 3.0 in previous versions. I did a read OSD of the device, then tried changing the batt warning value in the config tool. I enter 3.5, hit enter, and the config tool crashes and goes away. I note also there were some odd values on the current items in the GUI.
I restarted the config tool, then manually reentered all the values BEFORE doing anything to the device, then hit write. Then everything was ok, and now the battery low warning is gone.

[jdl]

Ok. Tested. Yes, it fixed the bat capacity issue. Now if I plug in everything except the batt1, it reads 1 cell and 0V. Plug in batt1 and it rises up to 3.94V, and the capacity goes up to 81%. Good!
But it still only reads 1 cell.
Reversing the order, plugging in batt1, then the cam/xmtr, then the fc+OPOSD+, it starts at 4cells and 15+V, then ramps down to 3.94V, plus capacity goes to about 2%, but num_cells stays 4.

Expected this. Glad to know that battery percent is now correct even in extreme cases.

But why OSD reads 3.94V remains a mystery... It might even be a deffective atmega chip or bad solder joint on OSD PCB. Still cannot replicate the situation, and never had similar...

Have you tried with another battery or the same one, but charged to a different level, e.g approx. 16.8V (4.2V per cell). Does OSD displays agaiv 3.94V or smth. like 4.18V?

I did have another weird issue. I had changed the voltage divider value, the bat capacity value to 2200 and the warning level to 3.0 in previous versions. I did a read OSD of the device, then tried changing the batt warning value in the config tool. I enter 3.5, hit enter, and the config tool crashes and goes away. I note also there were some odd values on the current items in the GUI.

Batt capacity has no use in this firmware (04). It it saved to EEPROM but not even read by this OSD firmware (N#04).
If you had odd values on current items, I can suggest either previous write to EEPROM (from Config tool) had failed or you hadn't set them to "0" when initially setting up OSD.
If you don't have current sensor connected, these values must be set to "0".

I restarted the config tool, then manually reentered all the values BEFORE doing anything to the device, then hit write. Then everything was ok, and now the battery low warning is gone.

This is the best practice in this situation. OSD firmware does not reset EEPROM to defaults upon initial install (discarded the corresponding code to save space), user has to do this manually with Config tool (as you did)!

[trust]

Another data point.
I recoded another OSD device on a quad I have using this latest firmware and charset, using the config from the other boards. It is not identical PCB, but pretty close.
I ended up resetting the divide ratio to the default.
On this system, I have to plug in the cam/xmtr first, or for some reason the OSD will not run - I get nothing on the display.
But when I do, it DOES display properly, and gets the correct cells and battery voltage! Yah! Pix enclosed.
One oddity - the battery voltage and capacity are fluctuating a lot.

[trust]

Here's a suggestion you might try:
Disconnect your battery input to the OSD or put a switch inline.
Plug everything else in.
Then switch in the batt1 connection - see if it gets to the correct cells and voltage.

[TheOtherCliff]

Unrelated to your discussion with @trust

num_cells starts with value "1" on OSD boot. Later, it can go only up if higher voltage is detected, but never goes down. This meanes the cells count depends on the highest voltage seen from OSD firmware since boot up.

I wonder if some setups could see more cells than they have, like from LC resonance with long wires and not enough C.  I worry too much.  They should just smooth the voltage reading with an RC network; add C in the voltage divider.

(Interesting story:  One cheap model I bought that came with motor in a pod and ESC had long ESC wires.  You could hear a high whine that changed a lot during load changes in a loop; smoothly increased whine frequency (sounded about ~1kHz) under high load, opposite of what you would expect from prop.  I actually suspect this was from the ESC output wires but smoothly changing frequency doesn't fit my expectation of fixed frequency 8kHz 16kHz PWM?)

Forgive me.  I must be bored. 

Code: [Select]

          if (voltage > 21.8)                            // min 3.63V for 6-cell (21.0-25.2)    (21.0-26.1)
            num_cells=6;
          else 
            if ((voltage > 17.45) && (num_cells < 5))    // min 3.49V for 5-cell (17.5-21.0)    (17.5-21.75)
              num_cells=5;
            else 
              if ((voltage > 13.2) && (num_cells < 4))   // min 3.30V for 4-cell (14.0-16.8)    (14.0-17.4)
                num_cells=4;
              else
                if ((voltage > 8.8) && (num_cells < 3))  // min 2.93V for 3-cell (10.5-12.6)    (10.5-13.05)
                  num_cells=3;
                else 
                  if ((voltage > 5.0) && (num_cells < 2))// min 2.50V for 2-cell (7.0-8.4)      (7.0-8.7)
                    num_cells=2;                             


Sample code could be replaced with a loop to save some space (and even increase max cell count) if you are code space critical. 

Code: [Select]

  #define MAX_CELLS     8
  #define MAX_CELL_V    4.40 /* high voltage lipo is 4.35 */
  #define TOTAL_V_FUDGE 0.20 /* help for inaccurate v dividers */

  // even calcs correct cell count for zero / near-zero / negative volts
  for (int cell_count=MAX_CELLS; cell_count>=0; --cell_count) {
    // if voltage is higher than the next smallest cell count max v
    if (voltage > (cell_count-1)*MAX_CELL_V + TOTAL_V_FUDGE) {
      num_cells = cell_count;
      break;
    }
  }

Test program output and program

Code: [Select]

cliff@i925 ~/Desktop $ ./celltest
voltage +0.10
cell count 8   requires more than 31.00V   requires more than  3.88V/cell.
cell count 7   requires more than 26.60V   requires more than  3.80V/cell.
cell count 6   requires more than 22.20V   requires more than  3.70V/cell.
cell count 5   requires more than 17.80V   requires more than  3.56V/cell.
cell count 4   requires more than 13.40V   requires more than  3.35V/cell.
cell count 3   requires more than  9.00V   requires more than  3.00V/cell.
cell count 2   requires more than  4.60V   requires more than  2.30V/cell.
cell count 1   requires more than  0.20V   requires more than  0.20V/cell.
num_cells 0

cliff@i925 ~/Desktop $ cat celltest.c
#include <stdio.h>
#include <stdlib.h>

#define MAX_CELLS     8
#define MAX_CELL_V    4.40 /* high voltage lipo is 4.35 */
#define TOTAL_V_FUDGE 0.20 /* help for inaccurate v dividers */

void main() {
  float voltage;
  int num_cells;

  voltage = 0.1f;
  printf("voltage %+5.2f\n", voltage);

  // even calcs correct cell count for zero / near-zero / negative volts
  for (int cell_count=MAX_CELLS; cell_count>=0; --cell_count) {
    if (cell_count) printf("cell count %d   requires more than %5.2fV   requires more than %5.2fV/cell.\n", cell_count, (cell_count-1)*MAX_CELL_V + TOTAL_V_FUDGE, ((cell_count-1)*MAX_CELL_V + TOTAL_V_FUDGE) / cell_count);
    // if voltage is higher than the next smallest cell count max v
    if (voltage > (cell_count-1)*MAX_CELL_V + TOTAL_V_FUDGE) {
      num_cells = cell_count;
      break;
    }
  }

  printf("num_cells %d\n", num_cells);
}


[trust]

It occurred to me I could try this myself on the older OSD. I did. After power up V was 0.
Plugged in batt1. It quickly ramped to 4 cells and 15.X volts. So it does work there too.
There must be something weird in the new versions of the newer boards I have, or some strange grounding issue on my mini Hellaplane (the eVTOL planes we're building).
I am having some trouble with the video. Everything is fine until I ramp up the power - then the OSD data flickers.
If I turn off the video input, the OSD data is fine by itself with the power ramped up.
I do have grounds out to the camera and video xmtr coming from the gnds next to the in/ou pins.

[TheOtherCliff]

I had an OSD flicker problem that turned out to be voltage.  It only happened with fresh battery at high motor load, or more often at the end of the flight.

Using 3S for the OSD 12V requirement didn't work well for me.

[trust]

Cliff did you get the new versions of the OSD you ordered yet? Another data point will be helpful.

[jdl]

(Interesting story:  One cheap model I bought that came with motor in a pod and ESC had long ESC wires.  You could hear a high whine that changed a lot during load changes in a loop; smoothly increased whine frequency (sounded about ~1kHz) under high load, opposite of what you would expect from prop.  I actually suspect this was from the ESC output wires but smoothly changing frequency doesn't fit my expectation of fixed frequency 8kHz 16kHz PWM?)

Could that be the switching 5V voltage regulator inside the ESC? It varies its frequency depening on the load and input voltage. But it must be  much higher than 1kHz... The whine could be emitted from the (low quality?) inductor? Just guessing...

Sample code could be replaced with a loop to save some space (and even increase max cell count) if you are code space critical. 

Code: [Select]

  #define MAX_CELLS     8
  #define MAX_CELL_V    4.40 /* high voltage lipo is 4.35 */
  #define TOTAL_V_FUDGE 0.20 /* help for inaccurate v dividers */

  // even calcs correct cell count for zero / near-zero / negative volts
  for (int cell_count=MAX_CELLS; cell_count>=0; --cell_count) {
    // if voltage is higher than the next smallest cell count max v
    if (voltage > (cell_count-1)*MAX_CELL_V + TOTAL_V_FUDGE) {
      num_cells = cell_count;
      break;
    }
  }


Very helpful comment, thanks!! 
Initially this code was intended to just distinguish 3S from 4S LiPo batteries...

I admit nested "if"s are ugly solution. Lot of code space is wasted. Your suggestion saves 90 bytes

However I see some drawbacks. Equally spaced thresholds do not always properly work for cells count detection for 4S and above. For example a voltage 17.4V can be either fully charged 4S LiHV battery or a relatively discharged 5S LiPo (or LiHV) battery under heavy load.

These are the thresholds and the respective ranges I consider more suitable:

Cells	Total V Threshold	Min V per cell	LiPo range	LiHV Range
6	21.80V	3.63V	21.0 - 25.2	21.0 - 26.1
5	17.45V	3.49V	17.5 - 21.0	17.5 - 21.75
4	13.20V	3.30V	14.0 - 16.8	14.0 - 17.4
3	8.80V	2.93V	10.5 - 12.6	10.5 - 13.05
2	5.00V	2.50V	7.0 - 8.4	7.0 - 8.7

The cells count calculator code continuously monitors the sampled (and filtered) battery voltage. Once detected, num_cells should not be allowed to go down during flight. If allowed to be decreased, at some moment under heavy load and near depleted battery, the voltage will drop well below the threshold and once the cells count goes down, the estimated per_cell voltage will become erroneously high and this will disable "LOW BATT" alarm (which is per_cell threshold dependant) when it is most necessary.

I've slightly evolved your suggested code (now it suits for 1S-6S batteries) to use predefined thresholds and prevent num_cells from being decreased.

Code: [Select]

          // OSD_Vars.h
          static int num_cells = 1;
          ......

          // FlightBatt.ino
          static const float batt_levels[5] = {5.0f, 8.8f, 13.2f, 17.45f, 21.8f};

          for (int cell_count=6; cell_count>1; --cell_count) {
              if ((voltage > batt_levels[cell_count-2]) && (num_cells <= cell_count)) {
                  num_cells = cell_count;
                  break;
              }
          }

This saved two more bytes.
Again, thanks for pointing me that!!

[jdl]

Another data point.
I recoded another OSD device on a quad I have using this latest firmware and charset, using the config from the other boards. It is not identical PCB, but pretty close.
I ended up resetting the divide ratio to the default.
On this system, I have to plug in the cam/xmtr first, or for some reason the OSD will not run - I get nothing on the display.
But when I do, it DOES display properly, and gets the correct cells and battery voltage! Yah! Pix enclosed.
One oddity - the battery voltage and capacity are fluctuating a lot.

It looks like the charset is not uploaded sucessfully?!

Neither voltage, not capacity should fluctuate... Looks like you have a lot of noise in the power system, this may be caused by noisy switching voltage regulator, it can emit noise not only on its output, but can inject it in its input line, too! A simple LC filtering circuit between battery and the OSD Batt1 pad may help.

[TheOtherCliff]

Cliff did you get the new versions of the OSD you ordered yet? Another data point will be helpful.

Sorry.  I haven't ordered any OSDs in a couple years.  I might have referred to new OSDs as being my Micro MinimOSD with the KV team mod?

[jdl]

I am having some trouble with the video. Everything is fine until I ramp up the power - then the OSD data flickers.
If I turn off the video input, the OSD data is fine by itself with the power ramped up.
I do have grounds out to the camera and video xmtr coming from the gnds next to the in/ou pins.

I suppose the flickering you describe is caused by ground loop!

On the other hand, MicroMinimOSD is quite demanding for its +5V power supply. To avoid blackouts/flickering  during throttle bursts and/or interference from ESCs, I do always power MicroMinimOSD from a reliable +5V supply through an aditional LC filter (100 to 330uH inductor / 1000uF(6.3V) capactior), the capacitor being soldered directly to MicroMinimOSD power pads. And ONLY ONE ground wire goes to OSD board!