• State Not Answered
  • Replies 5 replies
  • Subscribers 20 subscribers
  • Views 4103 views
  • Users 0 members are here
Options
Related

Maximum amount of messages per second over BLE connection

8543760

Hi,

I'm developing a proof of concept/app for my Garmin Forerunner 245 music and Android 9 smartphone. I would like to send the current GPS status (accuracy and lat/long) and compass heading to an Android app running on my phone.

I have set this all up using the documentation and it works fine, but I notice that if I try to send a message more than once per second it never arrives on my phone (but it doesn't throw an error).

My current setup:

 - At a 1 second interval check for changes in GPS heading, send message to phone if changed since last interval

 - Use the onlocationchanged callback to detect changes in GPS lat/long/accuracy, send message to phone if changed since last sent message


These both work fine, but if both change at the same time, there are two attempts to send a message in a second (one for gps one for heading) and one of them just never arrives but doesn't throw an error in the connectionlistener.

I have 'solved'/worked around this by just checking for changes once a second and including both updates in one message, but I can't seem to find anything in the docs about limitation to the amount of messages you can send.

I use this to transmit data:

https://developer.garmin.com/downloads/connect-iq/monkey-c/doc/Toybox/Communications.html#transmit-instance_method

  • 0

    Are you sure there's no error?  I know in the case of makeWebRequest you'll see one if you are overdriving things.  In that case, there's a max of 3 outstanding requests, and after that you start getting an error, and I'd expect the limit is something like 3 here too.

    Combining the data and sending every second will help to avoid the "max of 3", but if you really want the data fast, maybe do your own queueing, so that the next one is sent when one complete.  If you really don't need the data that fast, I'd looking at saving the data for say 5-10 seconds, and sending it all at one time.

    GPS will only update once a second, so any faster than that will just be duplicate data for the location, and if you find the accuracy isn't that great for GPS, you may not want to send anything at all.

    Heading might not be what you expect, as there are a couple ways to see that.  CIQ uses "best source" for some things, and for example, if you are standing still, it will be the compass (assuming the device has one), but at a certain speed, it will switch to GPS based on the past location and the current one (the direction you are actually moving, and not which way the top of the watch is pointing)

  • 0 in reply to jim_m_58
    jim_m_58 said:
    Heading might not be what you expect, as there are a couple ways to see that.  CIQ uses "best source" for some things, and for example, if you are standing still, it will be the compass (assuming the device has one), but at a certain speed, it will switch to GPS based on the past location and the current one (the direction you are actually moving, and not which way the top of the watch is pointing)

    Are you sure thats the case? Even in a driving car, it appears to still return the true north heading (which is what I want), using this:

    https://developer.garmin.com/downloads/connect-iq/monkey-c/doc/Toybox/Sensor/Info.html#heading-instance_method

    jim_m_58 said:
    Are you sure there's no error?  I know in the case of makeWebRequest you'll see one if you are overdriving things.  In that case, there's a max of 3 outstanding requests, and after that you start getting an error, and I'd expect the limit is something like 3 here too.

    I'm gonna triple check theres no errors, but I'm pretty sure yeah.

    jim_m_58 said:
    GPS will only update once a second, so any faster than that will just be duplicate data for the location, and if you find the accuracy isn't that great for GPS, you may not want to send anything at all.

    Well I use the locationchanged callback, so that will only fire if the position actually changed. The location accuracy has a 'QUALITY_LAST_KNOWN' status, which basicaly as far as I can tell means there is no gps fix and current values will be based on the last known location. What I find odd is that sometimes coordinates start to update even if the accuracy is QUALITY_LAST_KNOWN

  • 0 in reply to 8543760
    8543760 said:
    Are you sure thats the case? Even in a driving car, it appears to still return the true north heading (which is what I want), using this:

    As I said, it depends on how you get heading.  You can get heading in a couple different ways.

  • 0 in reply to 8543760
    8543760 said:
    The location accuracy has a 'QUALITY_LAST_KNOWN' status

    Are you seeing this in the sim or on a real device?  There you might keep seeing LAST_KNOWN even though you're playing back a .fit or simulating data.  With the sim, there is a setting for GPS accuracy.

    LAST_KNOWN means it's not gotten a GPS fix and it's just returning what it knew last.  If this is on a real device, are you starting up GPS?  You might be LAST_KNOWN while it's getting a fix and will change as things change

  • 0

    Nothing to do -almost- but do you think it's possible to send a message to an Android app during an activity (datafield) ?