BLE data transfer rate and max heap size

As far as the speed, that's probably a question for the Garmin folks. They'll be back here on Tuesday.

As far as the max memory, you see that on the bottom line in the sim, as well as the current memory usage. With 2.3.5 and the 935, for a watch-app the max is 122k. You can get more info from file>view memory in the sim when it comes to peak memory and info on object usage.

It takes ~20 seconds to load PNG (~10kb, 240x240x16, no dithering) and BMP files (~28kb, no compression, 240x240x16, no dithering). That is quite slow even for BLE, I expected about 0.27mbit/s or close figures. Map tiles are loaded directly from an android phone, so it is not for sure a wifi networking delay. I am having difficulty to bring it under 5 sec without caching.
Are there any information on BLE data transfer rate for Garmin watches and are there any ways to speed it up, could it be a limit within the Connect IQ mobile app?

As mentioned in the documentation for makeImageRequest and elsewhere in the forums, GCM will dither and process the requested image so it can be displayed using the palette available on the screen of the device, so the size of the image transfered over BLE might be independent of the incoming image size, and not vary greatly between a PNG/BMP/etc so long as the resolution and color depth of the given images are the same. I would guess that this processing also adds a slight time delay as well, but I do not know how significant it is.

That 0.27 mbps (33.7 kBps) figure for BLE throughput is a relatively optimistic estimation, especially given that some garmin devices, I believe the fenix 3 at least, use the nRF51422 which I think has a maximum total BLE data throughput of 250 kbps (31 kBps) not counting any protocol/application overhead. That also does not consider the limitations of the bluetooth stack on the phone though, which from what I have seen can vary pretty greatly among manufacturers. As laid out by a Nordic employee in the below linked post, on many devices using the BLE-only version of that chip you can expect anywhere from 1 to 10 kBps.

Obviously your (potentially newer) phone and the 935 differ from the setup described above, but if you release your app for devices other than the 935 you might want to account for the minimum possible rate. With the 20 second transfer time you give and the provided resolution, it is transferring around 2880 pixels per second, with the bits per pixel unknown. If it is 8 bpp, then 2.8 kBps isn't too bad imo, not including the setup time. It might not be 8 bpp though given the color capabilities of the 935. As a result, I would highly recommend dithering your images down to a reduced palette, as in my experience that can greatly reduce the transfer time. Since you are using OSM, you might be able to identify some of the most frequently occurring colors, and use their closest neighbors in the 935 device palette to form a more concise reduced palette. As mentioned elsewhere, these values can be found in the devices.xml included in the SDK.

https://devzone.nordicsemi.com/quest...or-a-ble-link/

Thank you guys for such great info and advice!

With the 20 second transfer time you give and the provided resolution, it is transferring around 2880 pixels per second, with the bits per pixel unknown. If it is 8 bpp, then 2.8 kBps isn't too bad imo, not including the setup time. It might not be 8 bpp though given the color capabilities of the 935. As a result, I would highly recommend dithering your images down to a reduced palette, as in my experience that can greatly reduce the transfer time.

I am definitely trying to keep bitmap size as small as possible, original tiles were down-sampled to match the resolution of 935, and colors reduced to 16-color palette. However, these colors are not those from device palette (I saw available values in devices.xml), so I agree with you and there is an opportunity for some optimization. I can adjust the stylesheet for Mapnik or other tool so it uses only provided values. I did some research and looks like if an image uses 16 colors but palette is not specified in makeImageRequest then full 64-color palette will be used for a bitmap. When I provided a palette within an image request I could store more then one tile in memory without OOE, this allows at least zoom in/out with a delay of a second.