Я немного просмотрел этот форум в отношении гироскопа L3G4200D и не нашел упоминания об этой проблеме, но я видел, как другие говорят об этом на других форумах. Я вижу странное большое значение на выходе, когда гироскоп неподвижен. К сожалению, похоже, никто не смог ответить, почему это так, поэтому я решил поспрашивать
Итак, я собираю данные с гироскопа с помощью i2c на частоте 400 кГц (быстрый режим), собираю данные с гироскопа с помощью многобайтового чтения (по шесть байтов за раз). Сэмплирование на 100 Гц (пробовал и верхние 800 Гц), также пробовал с включенной и выключенной фильтрацией на разных значениях. Я не использую вывод прерывания, но я использую атрибут «блокировать обновление данных» в GYRCTRLREG4, чтобы данные не выводились до тех пор, пока не будут прочитаны как LSB, так и MSB. Полные 2000dps и ничего не сделано с FIFO. Я могу опубликовать свои точные значения регистров, если это поможет, но полагаю, что у большинства из вас не будет под рукой таблицы данных.
На изображении ниже показана моя проблема. Выводимые данные хорошие, рассчитаны правильно (насколько мне известно), а общий шум очень приемлем. Но потом я заметил эти надоедливые «вспышки», появляющиеся случайным образом, когда устройство находится в стационарном состоянии. Если я оставлю его неподвижным на пару секунд, я получу один из этих пиков, всегда равный примерно 250-255 (таким образом, ~ 18 при преобразовании с использованием «(выход * 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. Хотя это вполне может быть проблема с кодом из-за прерывистой работы, сначала я бы проверил, как подключена шина. Несколько вещей, чтобы проверить/попробовать:
Если вы не используете внешние подтягивающие резисторы, попробуйте подтягивающие резисторы на 10 кОм на SDA и SCL. Внутреннее подтягивание на большинстве микроконтроллеров будет недостаточно сильным.
Если возможно, максимально уменьшите длину шины и постарайтесь проложить ее вдали от высокоскоростных сигналов.
Если вы используете макетную плату, старайтесь, чтобы соединения были как можно более прямыми, чтобы избежать избыточной емкости.
Если вы используете прототипы плат, которые уже включают в себя подтягивающие резисторы, они могут оказаться параллельными, и у вас может получиться слишком низкое значение подтягивающего сопротивления.
Если вы можете организовать доступ к области, это было бы идеально, чтобы убедиться, что линии часов и данных выглядят красиво и прямо и не слишком сильно перекошены.
Если эти шаги не сработают, у Texas Instruments есть отчет о применении протокола шины I2C для устранения неполадок , в котором более подробно рассказывается о расчете подтягивающих резисторов и проблемах, с которыми вы можете столкнуться с емкостью.
Что может случиться, так это то, что новая выборка берется между чтением LSB и MSB. Итак, если MSB = 0 и LSB = -4, вы должны получить 252 или около 1 г. Если следующее чтение MSB = 1 и LSB = 2, вы должны получить 258, что разумно. Проблема в том, что когда для 1 образца только старший бит обновился до 1, а младший бит по-прежнему равен -4, вы получаете 508, около 2 г, что может быть этим всплеском.
BDU на CTRL_REG4 должен предотвратить это. Может быть, прочитать этот регистр с датчика и убедиться, что блокировка включена?
попробуйте с медианным фильтром , и эти всплески исчезнут.
Пожалуйста, обратитесь к моему вопросу здесь, на StackExchange, а затем прочитайте этот пост о той же проблеме.
Тут
Джон
ловец