›

Receiving data using new API (2.0.0-beta.01)

TylerTyler
in Android
I've successfully received DeviceInformation and BatteryLevel values through the new manner using AsyncResult, as well as switch presses using the routeData() and subscribe() as shown at the bottom of (https://github.com/mbientlab/Metawear-AndroidAPI/wiki/MetaWearBoard-Class)

However, can't get the same to work for GPIO (analog abs read) or Temperature. Here is my temp method:

public void startTemp() {
mwBoard.routeData().fromTemperature().subscribe(new DataSignal.MessageProcessor() {
@Override
public void process(final Message msg) {
MainActivity.this.runOnUiThread(new Runnable() {
@Override
public void run() {
tVtempVal.setText(msg.getData(Float.class).toString());
}
});
}
}).commit();
}

It never seems to run the process() part within the MessageProcessor...

Comments

  • TylerTyler
    also, could not format code above for posting. on firefox and chrome, comment box looks like:
    http://oi60.tinypic.com/fjdhdi.jpg
  • EricEric
    Sorry about the forum bug, we are in the middle of updating the website and the forums got caught in the path.

    Date routes simply tell the board what to do with sensor data; they do not poll or sample data.  Your code for the temperature route looks correct so now you need to tell the board to read temperature.  To do that, you can use the Timer module to schedule periodic temperature reads.  The example module in the MetaWear API project has sample code showing you how to use said module.

  • TylerTyler
    edited July 2015
    Ah the Timer module!  I knew I was missing something.  I've got it working now just like your example.

    One strange behavior was that for some time neither the new example app (MetaWearTest) or my code could get GPIO (analog abs) or Temp data until I issued a RESET from the app.  - It is apparently problematic to connect to the metawear from two different apps at the same time?

    I have reviewed (http://developer.android.com/guide/components/bound-services.html) where it is stated "Multiple clients can connect to the service at once. However, the system calls your service's onBind() method to retrieve the IBinder only when the first client binds. The system then delivers the same IBinder to any additional clients that bind".  - Does this mean more than one app can or can not bind to the same ble service and use the metawear?

    About reset:
    Is calling resetDevice() the same as reset by removing power to PCB & pressing pushbutton while connecting USB cable?  Does reset clear the board to its initial state?  I assume this would clear the flash (logs) as well?  stored macros ?

    Thanks
  • EricEric
    edited July 2015
    What I think is happening is the BluetoothGattCallback functions are still being called from one app even though another app is initiating the request.  

    Clients refer to activities (or fragments) that initiate a bindService request.  Under "Creating a Bound Service" section:

    If your service is private to your own application and runs in the same process as the client (which is common), you should create your interface by extending the Binder class and returning an instance of it from onBind(). The client receives the Binder and can use it to directly access public methods available in either the Binder implementation or even the Service.
    This is the preferred technique when your service is merely a background worker for your own application. The only reason you would not create your interface this way is because your service is used by other applications or across separate processes.

    You can also declare in the manifest XML file that the service is available only to your app, as mentioned on the Services page (http://developer.android.com/guide/components/services.html#Declaring):

    Additionally, you can ensure that your service is available to only your app by including the android:exportedattribute and setting it to "false". This effectively stops other apps from starting your service, even when using an explicit intent.

    No, resetDevice is a soft reset.  What you are describing (pushing the button while powering on) is putting the board in boot loader mode, which does clear the flash memory as a side effect.
This discussion has been closed.