Can we get even faster telemetry?

[philletourneau]

Hello, thank you very much for your work on this, it's very helpful!

I'm happy to see the increased raw data rate from R02_3.00.06_FasterRawValuesMOD.bin however is it possible to increase the speed even more? I'm not concerned with battery life or anything like that, I'm trying to reach near-real-time readings from the accelerometer specifically.

Thanks!

[ttshaw1]

I'm also interested. I care about heartrate rather than accelerometer data, though. The ideal for me would be if we can get gadgetbridge to read heartrate every 5s or less, but the fast the better. 5 minutes is too infrequent to be useful in a workout.

I have an R06 that's too big for me that I'm happy to use as a testbed.

[halsbox]

Hello, thank you very much for your work on this, it's very helpful!

I'm happy to see the increased raw data rate from R02_3.00.06_FasterRawValuesMOD.bin however is it possible to increase the speed even more? I'm not concerned with battery life or anything like that, I'm trying to reach near-real-time readings from the accelerometer specifically.

Thanks!

Hi!
It's easy, just set lower value for byte at offset 0x9B0A in OTA firmware v3.00.06, then recalculate the CRC32 checksum from offset 0x100 to the end of file and put new checksum to the bytes 0x04-0x07 in reverse byte order (ref).
According to fw dissambly, the value of byte at offset 0x9B0A is used to calculate the delay between notifications in Raw sensor data mode (0xA1 0x04 0x04 cmd):

movs       r7,#0x7d
...
lsls       r7,r7,#0x3

Original OTA fw has 0x7d (125) value @0x9B0A.
R02_3.00.06_FasterRawValuesMOD.bin has 0x20 (32) @0x9B0A
Try the mod I made that has has 0x04 @0x9B0A, it's ~8x-10x faster then R02_3.00.06_FasterRawValuesMOD.bin:
R02_3.00.06_EvenFasterRawValuesMOD.bin

[philletourneau]

great! It does indeed stream in at a super fast rate! That being said, it seems to cause the bluetooth connection to fail after 30 second to a minute or so. I can reconnect and do it again over and over, but do you know what would cause it to disconnect like that every time? @halsbox

[halsbox]

I don't really know. Maybe some buffers on device side are being overflowed. I'll do more experiments with different values and let you know. Next week I hope to find more time for reverse engeniering the fw including the bt stack part.

[atc1441]

The used value I added in the fast version was already the fastest that worked reliable :)
It also makes no sense to go even faster since the battery runtime is not getting better

[philletourneau]

Ok thanks, I tested on a couple devices to see if it was the ring or the device connecting to it. Seems on the ring side afaik.

I would settle for an in-between value or anything faster than the previous fast one.

I'd love to be able to build the firmware myself, but it seems maybe a little bit beyond my capabilities, haha.

Personally I only need the accelerometer data, so I could conceivably not send all the raw data values?

[philletourneau]

The used value I added in the fast version was already the fastest that worked reliable :) It also makes no sense to go even faster since the battery runtime is not getting better

Understood, thanks for letting me know. Here's a very brief demo of why I want faster telemetry and why battery life doesn't matter in my case... I'm testing using the accelerometer to drive kinetic sculptures like this one

[jackprophesy]

@philletourneau Great application! We've been playing using it as a controller as well. It seems like the lack of gyro in the device puts some hard limits on the precision. We've also been having problems with it randomly dropping but just doing quick reconnect and it's OK not great.

[philletourneau]

@philletourneau Great application! We've been playing using it as a controller as well. It seems like the lack of gyro in the device puts some hard limits on the precision. We've also been having problems with it randomly dropping but just doing quick reconnect and it's OK not great.

I'd kill to find a similar ring with a gyro and maybe capacitive touch or some other kind of button or something.

[zachary-kaelan]

I'd kill to find a similar ring with a gyro and maybe capacitive touch or some other kind of button or something.

At first I was looking for a 9 DoF ring with accelerometer + gyroscope + magnetometer. Then I was just looking for accelerometer + gyroscope. And now I'm just looking at accelerometer. I know technology is fully capable of cheap, compact rings with gyroscopes, but there's just absolutely nothing on the market.

What kind of data rates can this bad boy achieve?

[antoniodangelophoto]

Hi all, I'm working on a R06 in order to receive ppg data quickly. Playing with the variable 0x9B0A, I noticed that the pgg is updated at 5Hz, so even if I lower the value of 0x9B0A, the same values ​​are sent in output but with a higher sample rate, for example with 0x04 I get to 51Hz, compared to 0x20 with 5Hz. Do you know if I can get at least 25/50Hz of updated values ​​on the ppg? Otherwise these raw measures are almost useless for most algorithms. Thank you in advance!

[edumylogin]

Likewise, I'm looking for decent sampling rate on the PPG, 50hz sort of a minimum. Has anyone actually succeeded in getting there?

[franciumgod]

@halsbox Hello, may I ask if you know how to modify the accelerometer measurement range? Or is it possible to change the accelerometer range by modifying the firmware?

[harryaskham]

On my R02 I landed on a 0x0A delay for accelerometer data; 0x04 to 0x09 still gave disconnects (0x09 is stable for 2-3 minutes), 0x0A I can run indefinitely at about 9Hz on an Android app I've made. Same patch crashes connected to my MBP - guess the device sets the BLE interval and MBP runs it at about 18Hz which triggers the overflow / issue.