Announcement

Collapse
No announcement yet.

Sampling rate and data dropouts

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Sampling rate and data dropouts

    I'm running an identical setup across two different computers and I'm getting differences in sampling rate. The first computer is a MacBook Pro 4,1 (early 2008) while the second computer is an iMac 12,1 (early 2011). Both are running OS X 10.6.8 and I'm using the same Wiimote across the two setups.

    I'm examining the largest sample-to-sample interval within an arbitrary time window (250 ms plus/minus one sample).

    On the MacBook Pro, the median sample-to-sample interval is 16 ms. However, 1% of the time it is greater than 300 ms. When this happens, the data drops out for 300+ ms, and then it comes pouring in with timestamps from 0 to 2 ms apart. So OSCulator is catching up, but applying the wrong timestamps to the incoming data.

    On the iMac, the median sample-to-sample interval is 32 ms. There are never any dropouts.

    Ideally, I'd like to have the best of both worlds: a high sampling rate (16 ms on the MacBook Pro) and no data dropouts. Is the unreliability a limitation or flaw in the Bluetooth hardware on the older MacBook Pro? I wonder if there's something I can change on the iMac to boost the sampling rate.

  • #2
    Hi Alfred,

    Here's an interesting question

    The bluetooth hardware has surely been improved between 2008 and 2011. Early this year, I've had reports from users that have been able to connect 7 Wiimotes on a new MacBook Pro, while my old MacBook Pro 2008 was painfully able to connect 4 of them.

    Even though both of your configurations share the same OS, the driver code for the bluetooth hardware is different, so it's difficult to make assumptions on the hardware only. To illustrate that with an example : When I received my MacBook Pro last march, it came with a special version of Mac OS X 10.6 that included drivers which I believe were not present in the Mac OS X public distribution at that time. The result is that some HID code I was working on was behaving differently than what I was expecting. What I mean by that is that the software drivers are also improved, even if the OS version is the same.

    Osculator receives and forwards data from the Wiimote as efficiently as possible, but this data is (unfortunately) not timestamped. Also, the "sample rate" is given by the Wiimote: it's the speed at which it sends its reports (approximately 100 reports every second). Therefore there is no proper way to minimize jitter. Finally, Osculator does not need to do anything to catch up with the delayed data: I guess there is a queue somewhere in the kernel where pending reports are waiting to be delivered. Again, so way to lower the bursts of data after a delay.

    I believe that what you are observing the discrepancies between both hardware and software revisions. It could be possible that the new hardware is better dealing with frequency hoping. Without timestamped data from a [wireless] device, it is impossible to predict the jitter.

    If you want to have more information about your Bluetooth adapters, I suggest you have a look at the local device info in the Bluetooth Explorer application that is bundled with the Xcode Developper Tools. This is very informative.


    Best Regards,
    Cam

    Comment

    Working...
    X