TI Sensortag advertising and conversion periods

[micke]

Hi again Chris,

About the error in the you see in ti-sensortag.js in function sensorOn, as you say this indicates that device is null. It is weird that the execution comes this far, if device is not set it should not proceed and connect. Could it be that somehow instance.disconnectDevice is called (device is set to null in this function)? Can you put in a log to see if it gets called? The only point it is called in ti-sensortag.js is in connectToClosestDevice, perhaps connectToClosestDevice is called twice or something?

Sadly I have no idea really what could be causing the behaviour you see when using the TI app to make the JavaScript app "kick in". Would it be possible to put some log statements at various points in the code to see where the pause happens and where it kicks in again? Perhaps there is a problem with easy-ble.js?

It is hard to tell if this is a problem with the native part of the plugin or if it is some problem in ti-sensortag.js or in easy-ble.js. Some trace logging could help to clarify this. It can be especially helpful to monitor reading of services, characteristics and descriptors in easy-ble.js. Here is a tutorial/example app that does just that, you could try this with your SensorTag and see what happens: https://github.com/divineprog/evo-demos ... LEExplorer

I can also build an Android Evothings Client app for you with extended native logging in the BLE plugin.

Regarding the Rand Dusing plugin, it should work fine to build a Cordova app with it and still use Evothings Workbench for development. You would then use your own Cordova app in place of Evothings Client, and still connect to the Workbench. Here is documentation about how to do this: http://evothings.com/doc/build/cordova- ... rEvothings

Just want to add that in the recent examples in Evothings Studio 1.0.0, files have been renamed and restructured, for example it is now easyble.js and tisensortag.js (hyphen removed). Wanted to say this to avoid potential confusion.

If you wish to share some of your code with me I can take a look. My email is mikael@evothings.com.

Best regards, Mikael

[micke]

Hi Chris, if it is feasible for you to share the custom firmware with us we can flash a SensorTag with it and debug the problem.
Best, Mikael

[quilkin]

Hi Mikael
Thanks for all your suggestions.
Because of the problems I've been having I'm now behind schedule on my project so I'll be proceeding with the 'Rand Dusing' plugin for now, it does seem to be more stable. However I will try to get back to trying the Evothings plugin at some stage because I want to make sure that my app is robust for all scenarios, and it may be that on a different device (or with a different sensortag) the Evothings plugin works better.
However I have noticed some things during tests this evening, all done with the Evothings plugin, and apart from item 5 all done with the TI code in the sensortag rather than my own.
1. The BLE explorer app appears to connect OK every time with no errors.
2. The Sensor Tag 'demo' (that just measures the magnetometer) appears to connect OK and continues running for a long time (nearly an hour as I write).
3. The full SensorTag Sensors app (with all sensors active) connects and works OK after a full reset (see below) but after a few minutes it stops and has to reconnect. The more often this happens the shorter the time it runs before it stops again. Sometimes the app stops recording data but I can see from the Sensortag LEDs that it still thinks it is connected, so attempts by the app to reconnect fail until I reset the tag itself.
4. By modifying the full Sensor app , disabling all but one sensor , it appears to perform better, i.e. takes much longer to go wrong! From this observation (and the fact that the 'Demo' app works OK) suggests that with multiple sensors there is some timing issue in the operating system of either the tag or the phone. At present I have only one of each to test.
5. I have today found that if the active services in the tag are changed, the discovery service in the phone still reports the old set of services until either the phone is reset or bluetooth is turned off and on again. Restarting the app makes no difference; I was amazed to see the discovery list still reporting services that I had removed. It's therefore essential to reset Bluetooth before starting any new test, and I suggest you put a call in to evothings.ble.reset() at the start of all your apps! Because I didn't realise this problem before, it's confused my analysis of tests I have done. I don't know if it is relevant to the general connectivity issue, but if the phone caches the service list like this I wonder what else it is caching an addition to the confusion?
6. Finally a simple suggestion - I think it would be useful to put a timestamp into the log output in the tools console, then the log would provide evidence of how long it takes for things to happen. I've modified my own log function to do this.
Regards
Chris

[quilkin]

.
Regarding the Rand Dusing plugin, it should work fine to build a Cordova app with it and still use Evothings Workbench for development. You would then use your own Cordova app in place of Evothings Client, and still connect to the Workbench. Here is documentation about how to do this: http://evothings.com/doc/build/cordova- ... rEvothings

I can't get this to work, it won't find the plugins ( the RandDusing ble plugin or a media plugin ).
LOG: [ERR] Uncaught ReferenceError: Media is not defined [js/SensorTag.js: 139]
LOG: [ERR] Uncaught ReferenceError: bluetoothle is not defined [js/ti-sensortag-a.js: 103]
Here's my config:

Code: Select all

?xml version='1.0' encoding='utf-8'?>
<widget id="com.quilkin.blelog" version="0.0.1" xmlns="http://www.w3.org/ns/widgets" xmlns:cdv="http://cordova.apache.org/ns/1.0">
    <name>BleLog</name>
    <description>
        .......
    </description>
    <author email="quilkin2@gmail.com" href="http://www.quilkin.co.uk">
        Quilkin
    </author>
  <content src="http://192.168.1.73:4042" />
  <!--<content src="index.html"></content>-->
    <access origin="*" />
  <feature name="File">
    <param name="onload" value="true" />
    <param name="android-package" value="org.apache.cordova.file.FileUtils" />
  </feature>
  <feature name="Media">
    <param name="onload" value="true" />
    <param name="android-package" value="org.apache.cordova.media.AudioHandler" />
  </feature>
  <feature name="Device">
    <param name="onload" value="true" />
    <param name="android-package" value="org.apache.cordova.device" />
  </feature>
  <!--
  <feature name="Ble">
    <param name="onload" value="true" />
    <param name="android-package" value="com.evothings.ble" />
  </feature>
  -->
  <feature name="Bluetooth LE">
    <param name="onload" value="true" />
    <param name="android-package" value="com.randdusing.bluetoothle" />
  </feature>
 
  <preference name="SplashScreen" value="screen" />
  <preference name="SplashScreenDelay" value="3000" />
</widget>

and here's the result of checking the installed plugins in the project:

Code: Select all

C:\Users\chris\Documents\cordova\blelog>cordova plugins
com.randdusing.bluetoothle 2.0.0 "Bluetooth LE"
org.apache.cordova.console 0.2.11 "Console"
org.apache.cordova.device 0.2.12 "Device"
org.apache.cordova.file 1.3.1 "File"
org.apache.cordova.media 0.2.14 "Media"


Regards
Chris

[micke]

Hi Chris, sorry for slow response here.

Did you find the problem? This could perhaps be a JavaScript error. Errors saying something is not defined can be a sign that something went wrong in loading some script.

This could be a problem in the app itself, or a problem with Evothings Workbench not fetching the plugin JavaScript files properly.

Do the other plugins get loaded?

Have you tested to build an run the app without the Evothings Workbench URL enabled? Using index.html instead of the connect address. Does this work?

Which platform are you running Evothings Workbench on and which version or the OS and the Workbench?

Let me know how it goes, interesting project you have going.

Best regards, Mikael

[quilkin]

Hi Micke
Thanks for your message.
Well, it is working now, thanks. The problem turned out to be a corrupted 'cordova.device' plugin. I only used it in one call, and it wasn't critical to the app running, so didn't notice that a call to 'device.model' was always returning 'null'. (This was with the non-Evothings method of build). The odd thing was that with the Evothings build, 'device.model' did work but the other plugins did not .
Anyway, after uninstalling and re-installing the device plugin, 'device.model' started working in the non-Evothings build, and - amazingly - all the plugins now work in the Evothings build. So it appears the faulty device plugin was preventing the others from loading correctly in Evothings. I notice that the device plugin is already included in the Evothings build, so that's why it worked there.
Sorry for not reporting this earlier, but until today I hadn't tried to run the Evothings workbench again since re-installing the device plugin.

So, I can now use the Evothings workbench with the alternative BLE plugin, thanks. This gives me the fast turnaround with log messages. But, as I mentioned before, if a future version could also include the ability to single-step and view variables, that would be great. I appreciate that a log message can be added to view a variable, but if it means restarting the app, and then reconnecting to a BT device and getting to a certain stage of the operation , it's still a much longer turnaround than using the Chrome debugger without Evothings. Unless there's a way of using Chrome with Evothings? At present if I try I only get "ArrayBuffer is deprecated in XMLHttpRequest.send(). Use ArrayBufferView instead. " and I can't view any source code.

Regards
Chris

[micke]

Thanks for reporting your findings, Chris!

I have been planning to look into the issues you mention and how to use the Chrome debugger, but I have not had time.

Created an issue here for investigating this further:

https://github.com/evothings/evothings-studio/issues/51

Best, Mikael

[johnzhel]

What is the minimum period of refresh rate in milliseconds for each sensor? I see the example code uses different numbers - are they the minimum number we can set to each sensor? Thanks for your time!

[micke]

Hi John,

Thanks for asking. I did some searching and it looks like you can find info about the update period ranges for the various sensors on this page:

http://processors.wiki.ti.com/index.php ... User_Guide

Search for "period" on the page to find (at least some of the) relevant places in the document.

Very best, Mikael