Почему 'плавают' показатели датчика оборотов.
- Войдите на сайт для отправки комментариев
Пт, 27/09/2019 - 01:05
Использую щелевой датчик оборотов на lm393. В системе кроме датчика и двигателя никого нет. Считаю обороты через разницу во времени которую получаю в прерывании, там кроме разницы ничего нет. Обороты(показатель с датчика) плавают в тысячу раз. При этом если просто считывать сигнал с датчика и когда он есть, моргать светодиодом на ардуине, моргает синхронно со светодиодом на датчике. Т.е. Датчик, вроде, рабочий. В этой же системе другой датчик, на датчике холла, работает корректно. Что и как проверить, чтоб выяснить кто виноват, дребезг(подтягивал, ставил проверку), датчик или прерывания.
Без схемы подключения и скетча можно долго, но безрезультатно, гадать на кофейной гуще.
На прерывании всегда так. Любой чих в системе и прерывание срабатывает. Попробуйте на pulseIn сделать. Намного устойчивее работает.
Если подключено через Ж то и pulseIn будет фигню выдавать. А если подключено нормально, то и прерывания будут нормально работать.
Я бы не был столь категоричен. pulseIn иголку наводки с большой вероятностью пропустит, прерывание всегда сработает. Если на pulseIn показания более устойчивы, то надо искать откуда идут наводки. Если также плохо работает, то тогда поможет только осцилограф.
Вывод после pulseIn
Диск на 100 прорезей, но и с 2-мя лопастями поведение тоже нестабильное.
И обратил внимание, при выводе в порт в момент когда происходят резкие изменения, вывод "подтормаживает".
так ясное дело! Вы выводите строки по 15 байт. На скорости 9600 это порядка 15мс. А каждая новая строка формируется через 2-10мс. Буфер отправки заполняется и начинается работа в блокирующем режиме, что замедляет луп. В результате вызов pulseIn как попало ложится на импульс и меряет что попало.
Видимо без разницы, задержка 1500мс
в строчке 45 всегда будет получаться ноль, потому что она считается в целых числах, а только потом результат (ноль) приводится к типу флоат
rula, попробуйте считать обороты таймером, как частоту. Пример.
Чудак человек. Перед duration=pulseIn(senserpin, HIGH); нужно обязательно ставить пустой duration=pulseIn(senserpin, LOW); потом два раза duration1=pulseIn(senserpin, HIGH); duration2=pulseIn(senserpin, LOW);и сложить первое и второе измерение. Это и будет период. А с твоим лупом всегда будет плавать, потому что если выход HIGH то начала следующего HIGH ждать не будет и будет считать время с текущей случайной позиции.
Чудак человек. Перед duration=pulseIn(senserpin, HIGH); нужно обязательно ставить пустой duration=pulseIn(senserpin, LOW); потом два раза duration1=pulseIn(senserpin, HIGH); duration2=pulseIn(senserpin, LOW);и сложить первое и второе измерение. Это и будет период. А с твоим лупом всегда будет плавать, потому что если выход HIGH то начала следующего HIGH ждать не будет и будет считать время с текущей случайной позиции.
Однако херню несете, уважаемый. PulseIn работает корректно независимо от того в какой момент его запустили. Он сначала ждет перехода сигнала в заданную сторону и только потом запускает счетчик.
Reads a pulse (either
HIGH
orLOW
) on a pin. For example, ifvalue
isHIGH
,pulseIn()
waits for the pin to go fromLOW
toHIGH
, starts timing, then waits for the pin to goLOW
and stops timing. Returns the length of the pulse in microseconds or gives up and returns 0 if no complete pulse was received within the timeout.А ТС, скорее всего, с подключением датчика проблемы.
Внешние прерывания у Атмеги обрабатываются синхронно. Т.е. состояние пина считывается каждый такт. Если "иголка" проскочила между тактами, то ничего не сработает. PulsIn работает сходным образом, только помедленне, поскольку опрос пина происходит програмно. Та часть PulsIn-а, что следит за изменеием пина написана на ассембере и работает достаточно быстро. Я точно не считал, но по виду можно говорить про время реакции всего раз в 10 большие чем прерывания. То есть "иголки" длительностью в несколько сотен наносекунд вполне себе могут привести к сбоям в работе PulsIn.
Я бы порекомендовал ТС взять скоп с полосой, хотя бы, 50 Мгц и посмотреть что у него там на выходе его датчика творится.
На ICR защитой от иголок является трехкратное считывание и только после этого райзинг прерывания, например...
На ICR защитой от иголок является трехкратное считывание и только после этого райзинг прерывания, например...
А еще керамикой пикофарад в 10 вход зашунтировать.
Залез, посмотрел код. Действительно ждет окончания предыдущего, потом считает. Но вот считать только high или low не правильно. Нужна сумма low и high. Дырки могут быть разными. Там ещё есть что типа pulseInlong который сразу считает период, вот только у меня он не заработал как надо.