L3G4200D случайные шипы

Я немного искал этот форум в отношении гироскопа L3G4200D и не видел упомянутой проблемы, но я видел, как другие говорили об этом на других форумах. Я вижу странное большое значение в моем выходе, когда гироскоп неподвижен. К сожалению, никто так и не смог ответить, почему это так, поэтому я подумал

Итак, я собираю данные с гироскопа, используя i2c на частоте 400 кГц (быстрый режим), собирая данные гироскопа с помощью многобайтового чтения (шесть байтов за раз). Сэмплирование при 100 Гц (пробовал и верхние 800 Гц тоже), также пытался с включенной и выключенной фильтрацией при разных значениях. Я не использую вывод прерывания, но я использую атрибут «блокировать обновление данных» в GYRCTRLREG4, чтобы данные не выводились до тех пор, пока не будут прочитаны как LSB, так и MSB. Полный 2000dps и ничего не сделал с FIFO. Я могу опубликовать свои точные значения регистра, если это поможет, но думаю, что большинство из вас не будет иметь таблицы данных под рукой.

Изображение ниже показывает мою проблему. Выводимые данные хорошие, рассчитаны правильно (насколько мне известно), и общий шум очень приемлем. Но потом я заметил, что эти раздражающие «всплески» появляются случайным образом, когда устройство неподвижно. Если я оставлю его на пару секунд, я получу один из этих пиков, всегда равный 250-255 (то есть ~ 18 при конвертации, используя '(output * 70) / 1000'). Шипы, как я уже сказал, случайные, могут появляться в любой плоскости (на рисунке ниже вы можете увидеть первый шип в плоскости X, второй в Y), всегда около одного и того же значения, и один, два или все три могут произойти одновременно. Большое значение только для одного образца, затем возвращается к нормальному.

В другом потоке я где-то видел, что я должен использовать функцию ожидания данных блока в GYRCTRLREG4, как я упоминал ранее, но без изменений. Я сузил проблему до того, что MSB равен нулю или выше, то есть положительному числу, а затем, когда MSB и LSB объединены, я получаю эти большие числа. Например, я беру два байта, необходимые для плоскости X, получаю -6 в LSB и 0 в MSB, объединяя их, получаю 250, затем преобразование дает (250 * 70) / 1000 = 17,5 dps ( т.е. слишком большой для стационарного / неправильного). В том же примере два байта для плоскости Y составляют -3 LSB и -1 MSN, их объединение дает -3, а преобразование дает -0.21 (то есть ожидаемое / правильное).

Я уже несколько дней сталкиваюсь с этой проблемой, я также вижу немного таких случайных пиков с помощью моего магнитометра, так что я думаю, что я неправильно читаю устройство (через i2c)?

Любые предложения или вещи, которые можно попробовать, действительно приветствуются!

Поскольку вы наблюдаете подобную проблему с вашим магнитометром, я предполагаю, что у вас есть проблема на шине I2C. Хотя это может быть проблема с кодом из-за прерывистой работы, сначала я проверю, как подключена шина. Несколько вещей, чтобы проверить / попробовать:

• Если вы не используете внешние подтягивающие резисторы, попробуйте 10K подтягивающие резисторы на SDA и SCL. Внутренняя нагрузка на большинство микроконтроллеров не будет достаточно сильной.

• Если возможно, максимально уменьшите длину шины и постарайтесь сохранить ее вдали от высокоскоростных сигналов.

• При использовании макета старайтесь держать соединения как можно более прямыми, чтобы избежать избыточной емкости.

• Если вы используете платы-прототипы, которые уже включают в себя подтягивающие резисторы, они могут заканчиваться параллельно, и у вас может быть слишком низкое значение сопротивления подтягиванию.

• Если вы можете организовать доступ к области, которая была бы идеальной, чтобы убедиться, что часы и линии данных выглядят красиво и квадратно и не слишком сильно перекошены.

Если эти шаги не работают, в Texas Instruments имеется отчет по приложению « Устранение неполадок I2C Bus Protocol» , в котором более подробно рассматриваются расчеты нагрузочных резисторов и проблемы, с которыми вы можете столкнуться при использовании емкости.

Может случиться так, что между чтением LSB и MSB берется новая выборка. Поэтому, если MSB = 0 и LSB = -4, вы должны получить 252 или около 1g. Если следующее чтение MSB = 1 и LSB = 2, вы должны получить 258, что является разумным. Проблема в том, что для 1 выборки только MSB обновился до 1, а LSB все еще равен -4, и вы получите 508, около 2g, что может быть этим проблеском.

BDU на CTRL_REG4 должен предотвратить это. Может быть, прочитать этот регистр с датчика и убедиться, что блокировка блока включена?

попробуйте с медианным фильтром, и эти шипы исчезнут.

Пожалуйста, обратитесь к моему вопросу здесь на StackExchange, а затем прочитайте этот пост об этой же проблеме