Architecture to stream data to cloud

Former Member over 9 years ago

I want to stream small packets of data (location, speed, distance) every second from a Connect-IQ-enabled watch to GCM to the cloud/web app, for up to 2 hours.

To do this, I call Communications.makeWebRequest from my app every time my position updates.

During my trial runs I ran into two problems:
1. One second is not enough time for the request to be made in some circumstances, so I encountered error -101 BLE_QUEUE_FULL several times. To get around this I drop requests if the queue is full, but it is not ideal as having real-time data is critical to my scenario.
2. On my first long test, about 40 minutes into streaming, we started getting the error -2 BLE_HOST_TIMEOUT somewhat sporadically from the makeWebRequest call. At that time the refresh rate on the web app went down significantly from 15 - 20 updates per minute down to 1 - 3. I couldn't find any information on how I could get around this error, as I suspect it's host-specific.

I suspect this architecture is not right, but I'm unsure of alternatives or if Garmin Connect IQ could support this. My code currently looks like this:

var data = {

    "instantaneousSplit" => number,

    "averageSplit" => number,

    "metersTraveled" => number,

    "timestamp" => Time.now().value().toNumber(),

    "lat" => float,

    "lng" => float

};



makeWebRequest(

    "xxx.firebaseio.com/" + PATH,

    data,

    {

        :method => HTTP_REQUEST_METHOD_PUT,

        :headers => {

            "Content-Type" => REQUEST_CONTENT_TYPE_JSON

        },

        :responseType => HTTP_RESPONSE_CONTENT_TYPE_JSON

    },

    callback);

I have not tried optimizing the packet size, but this does not seem like a significant amount of data to me.

Do you have any suggestions for how to make this scenario real?

Thanks
David

travis.vitek over 9 years ago

Do you really need to transmit data every second? Could you cache the data and send it in blocks as frequently as is possible/reasonable? This could potentially reduce the amout of power required by your application (both from the Garmin and mobile devices) as well as reducing the amout of data that would need to be sent (every request has a bunch of headers). Of course it does create a new set of problems that you'd need to handle. One such problem would be what to do when you have no more memory to store samples and you haven't been able to transmit in some time. You could just throw out the old data, or you could throw out every other sample.

If you don't need to transmit every second, you should be able to write a wrapper around makeWebRequest() that queues requests (so you don't overflow the request queue). I believe the code in this post should work for that. You'd probably want to add a a bit of functionality to track the number of pending requests (so you don't run out of memory when the app fails to transmit buffers).

Travis

Former Member over 9 years ago

Thanks Travis, ideally I would send data every rowing stroke, usually between every 1.2 to 4 seconds. I won't need to cache data and send it in blocks (for now), as it's streamed live to a coach, so only the latest data is relevant.

I admit my trials have been very limited, but power has not been a concern for the watch or the phone.

I have solved the request queue full problem with a method similar to what you described, so error -101 is no longer an issue. But I am wondering if there is something I can do for -2 BLE_HOST_TIMEOUT.

Your post makes me reconsider the frequency of sending data, so I'll look into whether 2+ seconds is ok and whether it changes anything.

travis.vitek over 9 years ago

If you are doing real-time analysis, I think it would make way more sense to just write a PC application that talks to the rowing hardware via ANT+. It would require you to get an ANT+ dongle and write a PC application (which I'm guessing you're already doing). If the coach is remote, you'd want to add client software to view the data in real time as well.

Travis

Former Member over 9 years ago

It's not clear how you view the topology here, so let me share more info:

1. The boat being instrumented and the coach are both on the water, separated by up to 100m. (It could be more, but I'm okay with this as an upper bound.) Data from the boat needs to make it to the coach in real-time.
2. My intention is that the coxswain (steersman) carries a Connect IQ-enabled watch + phone, which could then transmit to the coach's device (another phone in a waterproof case at this time) via the cloud. PC pretty dangerous to bring out in inclement conditions--couldn't get much buy-in with that approach.

The experience from my old HR monitor days with Garmin was that ANT+ wouldn't support 100m separation between devices. That true?

I'm not too interested in the devices that are sending/receiving data here. Looking for the right protocol that makes this a reality. Maybe Connect IQ is not the right play.