Communications Bottleneck

Former Member over 6 years ago

Hello,

I started developing with connect iq a week ago and im building an application (type=widget) that allows to see ship data (speed, depth, course, windangle etc.) provided by a raspberrypi in a local (boat) wifi network. It also allows to send commands to the rpi to be able to control the autopilot of the boat. If anybody is interested in that topic feel free to grab my code from github https://github.com/beat843796/signalk-garmin-smartwatchapp

The application is already done and works great except for performance. While on the simulator everything is perfect and i have an average response time of about 200ms which allows me to render at least 3 frames per second the responsetime on the device is around 1.5 to 3 seconds!! I have tested on my Forerunner 935.

Im corious where the bottleneck of the communication is. In my understanding/guessing the communication architecture works like the following:

1. Widget calls makeWebRequest()
2. Watch wraps request into a BLE call and sends it to GCM app
3. GCM app makes acutal request to webserver
4. GCM takes response and wraps it into BLE call to send back to Watch (widget)
5. Widget handles the handler call of makeWebRequest (parses JSON, updatesUI...)

While on the simulator this all works like 3-5 times a seconds, on the acutal device im able to update the UI every 2 to 4 seconds - thats not optimal and my goal is to be able to update twice a second or at least once per second.

My question is: is this doable at all?
- What am i making wrong and where is the time killed?
- Is it within the GCM App? Is it the BLE transmission?
- Or is WatchUi.requestUpdate() the bottleneck? (wich i dont think as i logged the drawTimes)

The widget is only making 1 request at a time, onReceive: a timer is started that starts the next request after 250ms and son on. The request i am making is a simple GET request without params. The reponse is just 800 bytes and just contains a JSON body with 10 key-value pairs.

Example Resonse:
{
"speedThroughWater": 3.46,
"log": 17442877,
"speedOverGround": 3.64,
...
7 more here...
}

Will i get better performance implementing an iOS companion app or will perfomance just be the same as with the GCM app?

Thanks in advance for your help.

jim_m_58 over 6 years ago

One thing that's not involved in the sim is BT and the phone. In the sim, you are just using the speed of the network connection to your PC. Comm will be slower on a real device.

You might do better with a companion app, and I say might, as I've never tried. It could be there is an additional bottle neck between your phone and raspberry pi.

When you send the request from the app, are you looking for errors in onReceive? Seems to me there's a max of three open requests between the device and phone and with the slower BT speeds, you might be running into problems there. Instead of a timer, maybe chain the request - do a request, and when there's a response, do the next and so on.

Former Member over 6 years ago

there are defenitly no errors as i am handling those to display the error in the UI.

also chaining is what i am doing already, there is never more than one request pending, i even added a short delay with a timer (50ms) after a response is received. From my application architecture there is a maximum number of 2 parallel requests (1 request for getting data, and one to send a command based on a user action).

in the meantime i read about ios background modes, and i think a lot of time also gets wasted by iOS waking up a process (for example GCM) to do webrequests.

Seems that there is basically nothing to do about those bottleneck(s) and connect iq cannot be used for "real time" data visualisation at least when the data provider is accessed by webrequests.

Why in gods sake it is not possible to directly connect to a bluetooth peripheral :) - I hope this feature is coming soon to the sdk, i think there are a lot of applications for accessing BT deivces.

Anybody knows about the possible range of sending/receiving commands to an ANT+ device. i read about ant+ usb dongles so this would be a "realtime" solution. ANT documentation says sth about 30m in theory (7m would be fine for my usecase) but i read a lot about people complaining that they do not achieve even more than 2 meters in real life

thanks for your reply jim.

Former Member over 6 years ago

i did some further investigations and it turned out that the bottleneck is indeed the wake-up process of the phone companion app. when the GCM is opened and in foreground the response time is superfast. what i dont know yet is if a custom companion app might bring a speedup in background state. will post my findings as soon as i have them

Former Member over 4 years ago

Hello, I would be interested in using your app for garmin as I have Openplotter with SignalK installed and the Garmin smartwatch. Where can I find the app / widget to install on Garmin? Then I would need detailed explanations as I don't have much experience in programming .... Thanks for the fantastic job.
Good wind
Nicola

Upgrade, I have an android phone (I don't know if you need the information)

jim_m_58 over 4 years ago in reply to Former Member

Some things have changed over the last couple years that may make it easier to do something like this - and eliminate the phone all together. Using CIQ BLE to talk to the pi directly.

forums.garmin.com/.../would-you-like-some-raspberry-pi-with-your-connect-iq

Former Member over 4 years ago in reply to jim_m_58

Thanks, but as I said I have no programming experience. is there anyone who connected Garmin Quatix to Openplotter / SignalK via Raspberry PI? And how ? What are the steps to take. The latest news you suggested seems like a good step to me, but how could I transfer everything to make the above link?