Thanks, it's working now on Debian Stretch.

ps. sudo apt-get purge modemmanager is still needed as that keeps resetting Mono.

Still same error. Running dpkg-deb -c openmono_1.7.0.deb | grep monoCyLib shows nothing, i.e. the required file is not included anywhere in the package.

The package openmono_1.7.0.deb of this release seems to be missing many files which are supposed to be installed to directory /usr/lib/openmono/mono.

Because of this, building an app does not work, and even the example hello_world exits with error:

make: *** No rule to make target /usr/lib/openmono/mono/monoCyLib.a', needed by 'hello_world.elf'. Stop.

(The file monoCyLib.a is missing from filesystem, along with whole directory /usr/lib/openmono/mono).

I just added initial framework-version to GitHub (commit).

I decided to reverse the lookup-table for percentage calculation and always use 1% resolution to make code simpler. If user wants less resolution it's easy to just calculate e.g. ReadPercentage() / 10 * 10 or even supply a custom lookup-table.

Also I think it would be better to not use special return values in CalculatePercentage and just return value from 0 to 100.

@stoffera said in Reading battery voltage?:

@malaire, this is great :-) ! We should put this into the framework!

May I suggest a class that lives in the namespace mono::power and that can return the remaining percentage of battery charge.

Maybe just extend the BatteryPower class I sent you some days ago. Tell me what you think.

Sounds good. I'll test this few days to see if there are any problems, and I'll also add few changes:

• return <0 when percentage can't be calculated (e.g. -1 when charging, -2 when mV is zero)
• include internal battery_percent_mV table, but allow overriding it with custom table
• manually "fix" the graph between 16% to 23% so that it's a straight line there

With three logs so far, discharge graph is nearly equal between logs, except at around 16% to 23% percent remaining, where there are significant variations.

The 'Combined' line here is what my script calculates, and battery percentage is then determined based on that.

I just added initial version of battery percentage calculation to my battery-logger app.

I decided to make Mono-side of code really simple, so I created a script log-analyzer.pl (source) which calculates mV limits from given logs, which can then be used to easily determine battery percentage.

For now the app is showing battery percentage at 1% resolution while testing this, but actual accuracy is lower. The script can also generate data with other resolutions, and I think something like 5% might work better generally.

ok, I added pull request.

As for libc functions, timegm doesn't seem to be available and it seems to be a non-standard function. But as it seems to do basically same what I just added as DateTime::toUnixTime, I'm not sure if that is really needed.

UTC is somewhat simple to handle even without library functions, but localtime and especially daylight saving time is definitely not.

I'm still testing this, but so far this seems to work:

    /**
     * @brief Return Julian day number of the DateTime
     */
    uint32_t toJulianDayNumber() const;

    /**
     * @brief Returns Unix time of the DateTime
     */
    uint32_t toUnixTime() const;

...

uint32_t DateTime::toJulianDayNumber() const
{
    if (type == LOCAL_TIME_ZONE) return toUtcTime().toJulianDayNumber();
    
    // this formula is from https://en.wikipedia.org/wiki/Julian_day
    
    uint32_t a = (14 - month) / 12;
    uint32_t y = year + 4800 - a;
    uint32_t m = month + 12 * a - 3;
    uint32_t jdn = day + (153 * m + 2) / 5
        + 365 * y + (y / 4) - (y / 100) + (y / 400) - 32045;
    
    return jdn;
}

uint32_t DateTime::toUnixTime() const
{
    if (type == LOCAL_TIME_ZONE) return toUtcTime().toUnixTime();

    uint32_t jdn = toJulianDayNumber();
    uint32_t hms = hours * 3600 + mins * 60 + secs;
    uint32_t unix_time = (jdn - 2440588) * 86400 + hms;

    return unix_time;    
}

It seems that converting from Gregorian calendar to Unix Time is easiest to do by first converting to JDN (Julian day number).

Wikipedia article https://en.wikipedia.org/wiki/Julian_day has needed formulas, from Gregorian year/month/date to JDN and then from JDN to Unix Time.

I can try to write this in C++ shortly.

ps. I wonder who came up with the JDN formula, it's fun trying to understand it - http://www.cs.utsa.edu/~cs1063/projects/Spring2011/Project1/jdn-explanation.html