- 19 Dec 2023
- 2 Minutes to read
- Contributors
- Print
- DarkLight
Battery
- Updated on 19 Dec 2023
- 2 Minutes to read
- Contributors
- Print
- DarkLight
The M300XL and M300 are externally powered to allow adequate run time in enterprise applications.
The external power to the M300 is provided by the custom external battery pack (446MA0116) or from any 1.5 amp USB power source via the Micro USB Power Adaptor (446MA0120). The custom external battery pack (446MA0116) has the advantage that the M300 displays the power level of the external battery.
The external power to the M300XL can be provided by any 1.5 amp USB power power source.
To allow hot swapping of the external power, the M300XL and M300 have a small internal battery. This internal battery will not power the display, but maintains the microprocessor and other hardware while the external power supply is being changed.
When the external power is disconnected, the device begins a 60 second countdown. If a new external power source is not connected, the device will shut down gracefully to prevent loss of data. If a new power source is connected within 60 seconds, the device continues normal operation.
It may be useful for 3rd-party applications to know when the external battery becomes disconnected. This allows them to take necessary steps to prevent data loss, synchronize states, and provide operator feedback. As of M300XL and M300 version 1.4, the 3rd party applications can register for notification when the battery changes state.
Examples of cleanups might include:
Store all in-progress work to the network server so it may be resumed later
Log the current user out of a network system to prevent the server from later detecting duplicate sessions
Immediately terminate a video call so the remote party knows the operator is unavailable
Registering and Receiving the Notification
Register for the com.vuzix.action.EXTERNAL_BATTERY_CHANGE intent. This can be done dynamically, or in the manifest.
For example, to handle the notification in a class called BatteryReceiver, the following would be put in the AndroidManifest.xml
<receiver android:name=".BatteryReceiver">
<intent-filter>
<action android:name="com.vuzix.action.EXTERNAL_BATTERY_CHANGE" />
</intent-filter>
</receiver>
The received intent can be handled by any BroadcastReceiver. This example shows the creation of a class dedicated to receiving only these notifications.
public class BatteryReceiver extends BroadcastReceiver {
public static String TAG = "BatteryNotification";
@Override public void onReceive(Context context, Intent intent) {
if (intent.getAction().equals("com.vuzix.action.EXTERNAL_BATTERY_CHANGE")) {
boolean result = intent.getBooleanExtra("connected", false);
if(result){
Log.d(TAG, "Battery is connected!");
//Todo:
}
else{
Log.d(TAG, "Battery is unplugged!");
//Todo:
}
}
}
}
The boolean extra “connected” will always be present in the intent.
If it is true, it means the battery is connected. If it is false, it means the battery is unplugged.
Timing Notes
The device will wait 60 seconds before shutting down, after broadcasting this intent. The 3rd party application can choose to respond immediately, or start their own timer to do the cleanup work at the tail end of that 60 second interval.
For example, if designing an application where the cleanup logic is expected to take 5 seconds, the application could safely wait 50 seconds after receiving the battery-loss notification before staring the cleanup. This would leave a 5 second buffer after the cleanup completes before the device powers down. Using this scheme, if power is restored within the first 49 seconds, the user session can resume without executing the cleanup code.