• State Verified Answer
  • Replies 2 replies
  • Subscribers 74 subscribers
  • Views 813 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 259426
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Question regarding CSCS demo measurement values

daubsi

I am currently experimenting the the nRF52 DK and the CSCS Peripheral example.

The provided example from the SDK creates random values for cycling speed and cadence, i.e. wheel revolutions and wheel time as well as crank revolutions and crank time.

I am working with: 

https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=261450

Using the nRF Connect app and Lightblue app I captured the following values during measurement notify

Device Nordic CSC

16:47:44.484 0x03DF03000088AA44010CA5 => 0x03, 0x000030df, 0xaa88, 0x1044, 0xa5ca
16:47:45.472 0x03E003000068AD450100B0 => 0x03, 0x000030e0, 0xad68, 0x1045, 0xb000
16:47:46.466 0X03E203000023B3450100B0 => 0x03, 0x000030e2, 0xb323, 0x1045, 0xb000
16:47:47.454 0x03E3030000BAB5450177B0 => 0x03, 0x000030e3, 0xb5ba, 0x1045, 0xb077
16:47:48.445 0x03E50300008DBA460184B9 => 0x03, 0x000030e5, 0xba8d, 0x1046, 0xb984

As we know the values on the right side are: Included Measurements flag (0x3 = Cadence and Wheel), CumWheelRevs (32 bit), Wheel Time (16 bit), CumCrankRevs (16 bit), Crank Time (16 bit)

Converting this to decimal and writing with "d=XX" the delta between the current value and the previous measurement we get:


16:47:44.484 0x03, 0x000030df/12511, 0xaa88/43656, 0x1044/4164, 0xa5ca/42442  (I) 
16:47:45.472 0x03, 0x000030e0/12512, 0xad68/44392 (d=736), 0x1045/4165, 0xb000/45056 (d=2614) (II)
16:47:46.466 0x03, 0x000030e2/12514, 0xb323/45859 (d=1467), 0x1045/4165, 0xb000/45056 (d=0) (III)
16:47:47.454 0x03, 0x000030e3/12515, 0xb5ba/46522 (d=663), 0x1045/4165, 0xb077/45175 (d=119) (IV)
16:47:48.445 0x03, 0x000030e5/12517 0xba8d/47757 (d=1235), 0x1046/4166, 0xb984/47492 (d=2317) (V)

Here is my question:

Quoting the GATT spec: 

"The ‘wheel event time’ is a free-running-count of 1/1024 second units and it represents the time when the wheel revolution was detected by the wheel rotation sensor. Since several wheel events can occur between transmissions, only the Last Wheel Event Time value is transmitted. This value is used in combination with the Cumulative Wheel Revolutions value to enable the Client to calculate speed and distance."

As we can see by looking at the cumulative wheel revolutions, we have at least an increase of 1 between every transmission. (12511->12512->12514, etc.). We also see that the transmission interval is more or less 1 second (1st column). I understand the "wheel time" is the time when the last "one rev complete" event was recorded according to the spec.

How is it then possible that in line III we have a wheel time which is 1467ms created since the last event time? (Yes, 1s = 1024*1/1024 parts, but approximating it as 1000 should be good enough for this example?)

If there was at least an increase of 1 in the cumulative sum, that increase must have occured between the previous and the current transmission, thus the delta time must in all cases be <= 1000ms? How come it is 1467ms in the 3rd and 1235ms in the 5th row? Similar quesiton regarding the crank time, where we even have 2614ms and 2317ms. Also here we have NO increase between line III and IV (cumulative sum = 4165) but we have a crank time of 119ms.

Is this just due to the randomness of the provided demonstration project or am I missing something which is mentioned in the spec and which would explain all this?

In other words: Are those plausible, valid measurements or are there some invalid readings among them? I do not intend to nitpicking on the provided demonstrations, I am just struggeling a little bit with understanding this new field, so clarifying that point would greatly help me understanding all the mechanics better. 

Thank you!

Parents
  • +1

    Hi,

    As far as I can understand the last_wheel_event_time delta is the time spent for increasing the cumulative wheel revs. The example only adds full revolutions to the cumulative_wheel_revs parameter, while the remainder is saved for next measurement. If the remainder is close to a full revolution, it may cause the next measurement to increase multiple revolutions (like you see happens on line 3 and 5), but parts of the revolutions may have happened in different measurement intervals. If you average the delta over many measurements, it should get close to 1024 if I'm not mistaken.

    I'm not exactly sure what is causing the crank time of 119, but it could be that if the remainder of the crank_rev_degrees modulo operation is larger than the degrees_per_sec will give a negative increase in event_time, which may cause some strange behavior. I do not think that the simulator values should be taken as a reference, the accuracy of this may not be very high. It simply generates increasing/decreasing values, and there are performed some calculations on these to give pseudo-random numbers for the service.

    Best regards,
    Jørgen

Reply
  • +1

    Hi,

    As far as I can understand the last_wheel_event_time delta is the time spent for increasing the cumulative wheel revs. The example only adds full revolutions to the cumulative_wheel_revs parameter, while the remainder is saved for next measurement. If the remainder is close to a full revolution, it may cause the next measurement to increase multiple revolutions (like you see happens on line 3 and 5), but parts of the revolutions may have happened in different measurement intervals. If you average the delta over many measurements, it should get close to 1024 if I'm not mistaken.

    I'm not exactly sure what is causing the crank time of 119, but it could be that if the remainder of the crank_rev_degrees modulo operation is larger than the degrees_per_sec will give a negative increase in event_time, which may cause some strange behavior. I do not think that the simulator values should be taken as a reference, the accuracy of this may not be very high. It simply generates increasing/decreasing values, and there are performed some calculations on these to give pseudo-random numbers for the service.

    Best regards,
    Jørgen

Children
Related
Terms of service