›

high frequency streaming

veronicaveronica
in Android
I am using Metawear SDK 3.0.0.

I am trying to get high frequency streaming by using packedAcceleration/packedAngularVelocity.

From the results I get, it doesn't look like there is any packing at all. As far as I understand from other threads, timestamp is set by ble receiver, thus if several samples where packed into 1 ble packet I would expect to see some identical timestamps between samples at least from time to time, but there is always at least 2-3 ms difference, which I interpret as different ble packets within one connection interval.

When streaming Gyro and Accel at 100 Hz, I do not lose samples, so maybe there is no need for packing. But if I stream both at 200 Hz, I do lose some gyro samples, and I still do not infer packing from the timestamps.

I am following instructions from https://mbientlab.com/androiddocs/3/advanced_features.html#high-frequency-streaming to enable packing when creating the routes, and I do packedAcceleration().start/packedAngularVelocity().start, as well as using the minimum max connection interval (11.25 ms in my case).

Acording to Metawear app, my Metawear board is already running latest firmware.

Is there something else I am missing to enable packing?

Follow up question: if I manage to get packing to work, will it ack regardless of frequency? It would be interesting to pack the data even if in lower frequencies, so as to improve overall BLE data rate, and be able to stream for several sensors in parallel without sample loss.

Comments

  • EricEric
    Which timestamps are you comparing?  Packing data combines values from the same sensor; it does not combine data from multiple sensors into 1 packet.  The packed functions are working as described so it seems like this is simply a misunderstanding of what data is packed together.

    Packing increases the data throughput not the communication frequency.  Streaming acc and gyro at 200Hz each means you are attempting to communicate at 133Hz.

    Yes, packing works for lower frequencies as well.
  • veronicaveronica
    edited March 2017
    OK, I thought different sensors would be packed together. Still, with only accelerometer @ 200 Hz, I do not see packing:
    timestamp    elapsed_time
    1489048955676
    1489048955683    7
    1489048955689    6
    1489048955693    4
    1489048955697    4
    1489048955702    5
    1489048955709    7
    1489048955715    6
    1489048955718    3
    1489048955723    5
    1489048955725    2
    1489048955731    6
    1489048955735    4
    1489048955738    3
    1489048955742    4
    1489048955765    23
    1489048955769    4
    1489048955771    2
    1489048955777    6
    1489048955780    3
    1489048955783    3
    1489048955788    5
    1489048955791    3
    1489048955795    4
    1489048955801    6
    1489048955803    2


    I would expect to see some 0s in the elapsed time column (that is, some identical numbers in the timestamps)






  • veronicaveronica
    edited March 2017
    Firmware version in the metawear device is 1.3.3.

    This is my code: 

    bmi160AccModule.packedAcceleration().addRouteAsync(new RouteBuilder() {
        @Override
        public void configure(RouteComponent source) {
            source.stream(new Subscriber() {
                @Override
                public void apply(Data data, Object... env) {
                    final Acceleration axes = data.value(Acceleration.class);
                    Utils.writeToFile(mAccelFilename, data.timestamp().getTimeInMillis() +
                            ";" + axes.x() + ";" + axes.y() + ";" + axes.z() + ";\n", true);
                }
            });
        }
    }).continueWith(new Continuation<Route, Void>() {
        @Override
        public Void then(Task<Route> task) throws Exception {
            bmi160AccModule.packedAcceleration().start();
            bmi160AccModule.start();
            return null;
        }
    });



  • EricEric
    Looking over the API implementation again, the API actually assigns a new timestamp to each data forwarded to the apply function.  Does your use case require that the packed data use the same timestamp?
  • veronicaveronica
    No, it doesn't. I am just looking for some proof that data is actually packed. I don't see why with gyro + acc at 200 Hz we should lose samples if data is packed, even if not mixed. (I am using android with 11,25 ms connection interval, so 6 packets every 11,25 ms, with 3 samples per packet should be more than enough to ensure no lost samples). Maybe the bottleneck is elsewhere, but I want to discard BLE comms efficiency.
  • EricEric
    Please see my previous post (2nd paragraph).
  • veronicaveronica
    I am now able to stream accelerometer and gyroscope at 200 Hz each. It seems to have been fixed by tearing down non packed routes which somehow had remained in the metawear board.

  • veronicaveronica
    I also see that in new SDK release timestamps of the same pack are identical. Just in time to check that I am now indeed packing the samples. Thanks!
  • DominicDominic
    A quick follow up question on the timestamps for packed values, why are they set to the same time for each value in the pack? Should the timestamps not be the time when the reading was taken (in which case they should all be different), or am I missing something and there is a different way to read the actual timestamp for when the measurement was made?
  • EricEric
    When streaming, the timestamps correspond to when the data was received by the device.  So if you're packing values, then you are receiving 3 samples at the same time.  You can recalculate timestamps yourself as described in this thread:

    http://community.mbientlab.com/discussion/comment/3780/#Comment_3780

    If you want accurate timestamps without any post-processing, you'll have to log the data.  
This discussion has been closed.