Right, I've seen the list of which are and aren't. The MC70 doesn't support those calls - and I guess the customer was looking to find out how, in say, an MPA2.0 like the MC95, it's making those calls, and how can he mimic them in an MPA1.0 device. He believes the information is there in the battery, but the MC70 doesn't know how to access it. From what it sounds like you guys are saying, the information isn't there in an MC70 battery.

I believe most of this is in the battery but the interface to it may not be supported on certain products. Keep in mind we have a dedicated power micro that helps with this type of stuff. My feeling is this is more of an internal design of the interface more so then simply reading bit somewhere. WIth that said if he explicitly asking how to do this on a particular device, we need to hone on if it is supported or not and then from there look into what it would take to read this data. If they don't want to use the emdk this needs to be seen a above and beyond typical support. I wouldn't mind going to the HW guys with these questions but the support expectation would need to be to use at your own risk and it would be on a good faith basis, therefore it would not be supported. If he wants this on an mc70 like form factor, it may be best to simply get him an mc75a. hope that helps.

if the customer is asking for this on a device that supports the calls and thinks intermec's tester is providing more or different data, please ask him to provide the values he is seeing.   Also if he wants to see this on the mc65 it is not there.

the emdk documents tell us what devices support the battery APIs

From the 'MC65 Programming' section of EMDK fo C v2.4 Help file:
    2. The ChargeCycles and StateOfHealth fields in the SmartBatteryStatus structure are not supported.

I noticed that was mentioned only in ES400 and MC65, isn't that because they're not MPA devices?  (This was mentioned to me as the reason why they don't have the UISettings app, and that the functionality for SoH is tied to 1.5+ MPA devices).

if the customer is asking for this on a device that supports the calls and thinks intermec's tester is providing more or different data, please ask him to provide the values he is seeing.   Also if he wants to see this on the mc65 it is not there.

Also, a good reference is the 'API Compatibility Matrices' section of the EMDK for C Help file.

Hi Guys,   I did check out those documents, but none of them had what I was looking for. I guess I'm not asking the right questions. This was the customer's response:
"All the Battery Information SoH & Charge Cycle is stored in SEEP (Serial EEProm) of the Battery, we have an Honywell Battery tester that can read this information. The location of charge Cycle and SoH is as mentioned in my email. Since the EMDK API can read Charge Cycle it must be reading it by going thru the SEEP Data, we need a sample code that can dump this SEEP information, so that we can read the SoH directly from the battery.

We need a sample code that can show how we can dump all the data of the SEEP (Serial EEProm) of the battery."

Their belief is that SoH is stored in the battery, but their MC70 doesn't know how to access it. Is there the possibility to make a program that will read it?

When you're referring to the doc, is it in http://compass.mot-solutions.com/go/ECSG-Whitepapers? The customer was convinced that the device might not have the software/firmware, but the battery might (such as in the case of using a honeywell battery with a motorola device), so he's looking to find out if any of the MPA 1.0 device batteries have the SoH information and it's just not able to access the information correctly using the device.

Hi Guys,   Just looking for an update to my last question, whenever you have time. Thanks!

There are a couple of battery documents/presentations on these Compass links:     http://compass.mot-solutions.com/go/ses-whitepapers and     http://compass.mot-solutions.com/go/ses-presentations Also, there is a Battery Status utility with documentation (attached) attached to SPR 19434.

Hey Guys, Thanks for the answers, they definitely help. Ultimately, the customer believes that the information for State of Health exists in most/all (or at least, his) batteries, and that his device isn't designed to read it. So he's trying to develop something that will, using the aforementioned Serial EE Prom. He's able to read this on a HoneyWell battery. Obviously, there's no guarantee the information exists on our batteries, but just for clarification sake, do any devices that do not yet support MPA 1.5+ happen to have information like SoH in the battery? As in, theoretically, someone could access that information.

I believe the Mc70 supports these calls. If that is not what he is asking for then what device is he looking at? Also state of health is more than just cycle count(see doc referred to earlier). On the mc95, there is an applet that reports on health. The app I mentioned earlier mimics that tools for other deviices prior to MPA2.

Battery State of Health will be correctly reported in the corresponding field of the SMART_BATTERY_STATUS structure, if the GetSmartBatteryStatus() is properly supported by the device and the Smart Battery. note that the Battery State of Health also depends on the, e.g., RunTime, Power Management policy that is currently selected.

In the EMDK for C, GetSmartBatteryStatus() and the SMART_BATTERY_STATUS structure are part of the Motorola Smart Battery API, which is supported by the device's Motorola Smart Battery and the drivers (e.g., Power Management, Battery, etc.). SPR 19434 has a Battery Status Utility with documentation attached that contains more details.

to answer the other question you just posted, the customer should use the supported APIs in the emdk. I'm not sure what else they are looking for.

If someone is available to assist me with getting answers to the above questions, that would be great. I also have a couple more. The customer is looking to find out the memory locations for the various battery information is - possibly to write his own application to read battery information.

The second question is whether our batteries use Serial EE Prom (or, SEEP) for getting/storing/modifying the data contained within our batteries. If not SEEP, then what, and can a customer access that on their own/what could I give them to point them in the right direction.

I believe we have a doc posted on the ECSFG site which can help give more details on understanding battery lifetime and cycle count. It came along with a tool but I am not sure if that is needed here and it is only for certain devices. In any case,here some of my responses: -   I'm understanding that charge cycles is the number of full charges a battery has gone through, is that correct? GN : yes - So the more a battery is used and charged the higher the number? GN: batteries are rated for how many cycles that are expected to last (under normal conditions) that limit is not expected to change. As a battery is recharged, each cycle counts toward hitting that expected limitation. - State of Health : My understanding is that the unit requires certain DLLs in order for this property to work, specifically GN: That may or not be the case but we shouldn't be in the business of picking out the dlls that implement the values. In fact, some of this is done within the battery. We should answer this as what products support the smart apis and which do not. We should not copying Dlls to unsupported devices and expect them to work. -And finally, would using a third party battery (in this case, a HoneyWell) affect how GetSmartBatteryStatus is performing? GN: it most likey will since the smarts are in the battery but the interpertation is done at the higher levels.    - Currently there is no difference between the customer's HW and motorola batteries, but I'm curious about it  GN: we do often find some differences with 3rd party batteries. I recall one of them did not offer unique identifiers so it makes it harder to know if the user switched batteries. I'm sure there are other changes that ppl may or or may not know about. Hope this helps,. Gene