Почему журналы акселерометра содержат два значения x,y,z для одной отметки времени?

Я просматриваю журналы, сделанные с помощью примера приложения movesense, и журналы акселерометра содержат такие значения:

{
    "Body": {
        "Timestamp": 110033,
        "ArrayAcc": [{
            "x": 0.60114991664886475,
            "y": 6.7324004173278809,
            "z": 3.0943653583526611
        }, {
            "x": 0.78317141532897949,
            "y": 7.0437526702880859,
            "z": 3.3697926998138428
        }]
    },
    "Uri": "ECKIAEBA141A/Meas/Acc/26",
    "Method": "PUT"
}

Почему массив содержит два значения из одной отметки времени?

3 ответа

Решение

Хорошие ответы выше. (Надеюсь) прояснить ситуацию: причиной нескольких измерений в одном пакете с одной временной отметкой является экономия вычислительных ресурсов на многих уровнях:

  • Внутри датчика ОЗУ очень ценно, и это позволяет избежать 0-7 * 4 байта на каждую копию результата.
  • При хранении данных с использованием DataLogger дополнительные 28 байт на измерение будут стоить ~20% хранилища данных.
  • Пропускная способность BLE также является ограниченным ресурсом, и те же данные должны передаваться по BLE при подписке с мобильной стороны. Здесь также учитывается каждый байт
  • Мы подумали об альтернативе возврата только одного измерения на уведомление, но это вызвало бы слишком большое количество уведомлений в секунду в случаях, когда частота дискретизации велика (>400 Гц), что могло привести к плохой работе системы. Также вышеуказанная экономия памяти была бы потеряна.

Судя по всему, обратная сторона необходимости интерполировать ts для оставшихся измерений считалась гораздо менее дорогостоящей.

Полное раскрытие: я работаю в команде Movesense

Это связано с точностью Гц до отметки времени в мс.

13 Гц должен содержать 1 значение.

26 Гц - 2 значения.

52 Гц - 4 значения.

104 Гц и + - 8 значений.

ОБНОВЛЕНИЕ:@Dotevo, пожалуйста, проверьте еще раз, потому что я вижу правильные значения в моем сообщении.

Пример 52 Гц:

  Mds SDSInternalCallback()  taskId:20 sdsCallType:2 header:
SdsHeader{status=0, uri='MDS/EventListener/20', reason='CUSTOM_STATUS', contentLength=415, contentType='null', location='', taskId=0}
 dataBody:{"Body": {"Timestamp": 916161, "ArrayAcc": 
    [{"x": -0.1892065554857254, "y": -0.29937744140625, "z": 10.03513240814209}, 
    {"x": -0.25387206673622131, "y": -0.3544628918170929, "z": 10.071057319641113}, 
    {"x": -0.19878663122653961, "y": -0.32572266459465027, "z": 10.049502372741699}, 
    {"x": -0.16286133229732513, "y": -0.31135255098342896, "z": 10.075847625732422}]},
 "Uri": "ECKI89CB9A98/Meas/Acc/52", "Method": "PUT"}

104Hz:

Mds SDSInternalCallback()  taskId:20 sdsCallType:2 header:
 SdsHeader{status=0, uri='MDS/EventListener/20', reason='CUSTOM_STATUS', contentLength=742, contentType='null', location='', taskId=0} dataBody:{"Body": {"Timestamp": 725, "ArrayAcc":
 [{"x": -0.21076172590255737, "y": -0.26345217227935791, "z": 10.063872337341309}, 
 {"x": -0.23950196802616119, "y": -0.30656251311302185, "z": 9.9680719375610352}, 
{"x": -0.22992187738418579, "y": -0.33530274033546448, "z": 10.061477661132812},
 {"x": -0.19399659335613251, "y": -0.26345217227935791, "z": 10.025551795959473},
 {"x": -0.15328125655651093, "y": -0.28021728992462158, "z": 10.054292678833008}, 
 {"x": -0.19399659335613251, "y": -0.28021728992462158, "z": 10.008787155151367},
 {"x": -0.19878663122653961, "y": -0.32572266459465027, "z": 10.013577461242676},
 {"x": -0.19160157442092896, "y": -0.30656251311302185, "z": 10.02076244354248}]}, 
 "Uri": "ECKI89CB9A98/Meas/Acc/104", "Method": "PUT"}

@Esperanz0 написал почти правду. Это немного сложнее, и пакеты объединяются в корзину из-за пропускной способности BLE. Что важно, что количество зондов может быть разным. Например, если какой-то ResourceClient запрашивает данные с "204 Гц", тогда другой:

104 Гц имеет 4 значения

52 Гц имеет 2 значения

26 Гц имеет одно значение

13 Гц имеет одно значение

так далее

Так что вы все равно должны быть готовы к ведру другого размера.

Другие вопросы по тегам