Здравствуйте.
Есть идея сделать цифровую метеостанцию. В частности, речь идет об определении направления ветра.
Используем абсолютный угловой энкодер с диском, размеченным кодом Грея. Дискретизация - 4 разряда, т.е. 16 румбов. На выходе датчика 4-х разрядный код Грея.
Подскажите, правильно ли думаю по алгоритму:
1. С некоторым интервалом опрашиваем входные линии с кодом Грея (опрашиваем так же как кнопки).
2. Преобразовываем в бинарный код, примерно так:
unsigned int graydecode(unsigned int gray)
{
unsigned int bin;
for (bin = 0; gray; gray >>= 1) {
bin ^= gray;
}
return bin;
}
3. Дальше. Алгоритм обработки помнит предыдущий результат, и при каждом измерении сравнивает - если изменение больше чем на 1 (по модулю) - то это явная ошибка, так?
4. Берем выводное значение (видимо, символьное, типа Северо-Восток и т.п.) из массива значений по данному (пункт 2) индексу .
Верно?

Можно и 32 и 64 сектора сделать - ну это "на вкус и цвет" .
2. Преобразовывать в двоичный код необязательно - можно сразу по таблице в символьные строки - и отображать типа : "С-В"
3. Не факт. Надо бы для того знать ещё и скорость ветра.
4. см. отв. п.2

ИМХО для розы ветров 16 румбов за глаза.
Можно разрядность и увеличить, но это увеличивает геометрию устройства и количество сигнальных линий. Как бы не дошло до отдельного мозгА для этого датчика, передающего данные в "голову" скажем, по SPI.
Хотя.. учитывая необходимость статистики (см. ниже) может быть до какого-нибудь простенького мозга и дойдет... типа тини13 или 24.

Переделываю я в двоичный код для того чтобы плюсминус1 ловить, то есть вероятную ошибку. Конечно, можно код Грея через CASE просунуть или через хитросортированный массив... Но хочется как то "колхозить поменьше", что ли... Чтоб алгоритм был понятный и прямой.

Скорость не ветра, а скорость изменения направления ветра, это разные вещи. Скорость ветра это другой датчик - крыльчатка и счетчик оборотов. Этот датчик это электронный флюгер.
Хотя надо предусмотреть качания, безусловно, и датчик должен стоять на открытой местности. Ну грубо говоря - утром с запада дует, а вечером с севера - изменение на 3 румба за 12 часов, то есть 1 измерение в 2 часа и нормально))))). Шутка. А насчет качаний - это же аналогия дребезга контактов, вот ее и решать дополнительно в двух направлениях - в механике и в софте (например, делать усреднение за период).

Кстати, вопрос из оптической области.
Вот с одной стороны диод, с другой фототранзистор скажем. Между ними шторка или иной загораживающий объект.
А дребезг в этом случае как гасится? Свет ведь может проходить и через полузакрытое окошко и т.п.?
Поправка - тут видимо не дребезг а "неопределенное состояние". Как его определить? или в любой схеме последний разряд в погрешность уходит?

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

(IMHO) разрядность 6 будет слегка избыточной - 64 сектора - но ведь потом можно будет и округлить запросто, а 6 "треков" и линий соответственно всего лишь в 1.5 раза больше 4 ( кэп "очевидность" ) при увеличении точности вчетверо. Так что лучше сделайте шестиразрядный.
SPI выглядит несколько "не в своей тарелке" в данном поделии ( паки IMHO)
Переделывать код Грея в двоичный для отслеживания ошибки есмь жуткая ерунда - ибо код Грея как раз таки и решает задачу устранения ошибок - соседние сектора обязаны различаться строго одним разрядом ( в отличие от двоичного кода ).
XOR текущего и предыдущего сразу же покажет в скольких разрядах есть различия - если нет отличий или только в одном разряде - тогда больше вероятность правильного значения - и без всяких там "хитрых CASE " ..
Дребезг контактов и/или неполное перекрытие тоже почти сами собой "разрулятся" - это тоже одно из свойств кода .
( ну для пущей уверенности - поставьте в конце линий триггеры шмитта навроде 555тл* - их как раз по шесть бывает в одной и.м.с. )

А насчёт скорости ветра - например был слабый южный ветер, и, вдруг, резкий порыв восточного - в таком случае резкая смена сектора на 90 объяснима, а вот слабый южный на слабый восточный быстро переменится навряд ли, что укажет на вероятную ошибку.
Всё это вроде как очевидно, даже странно, что Вы ещё не определились по всем этим вопросам.

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.

Подробнее>>

Несмотря на, то что это всё вроде как очевидно, у меня катастрофически мало практического опыта. И я не стесняюсь выглядеть тупым.
1. Таки не вижу, куда мне здесь точность выше 1/16. При 1/16 направление ветра хорошо описывается общепринятыми словами: север, северо-северо-восток, северо-восток, восток-северо-восток, восток и т.п. А при повышении точность измерять в чем? в градусах азимута? В них практический смысл слабо виден, неудобно в быту применять.
2. Оговорился, не SPI а I2C, вот как тут http://easyelectronics.ru/avr-uchebnyj- ... c-i2c.html
3. Переделка кода Грея в двоичный... Тут в общем немного криво я выразился. Безусловно, по-быстрому проверить входящее значение это поXORить его на предыдущее. Но для отсечки лишних качаний флюгера я хочу сделать еще вдобавок усреднение данных, то есть так:
Организуем очередь данных, скажем из 10 ячеек. Когда возникает новое измерение, самый старый результат выкидывается. Когда нужно снять данные - снимаем среднее со всей очереди. Пусть частота измерения, скажем, 1 раз в минуту. Тогда на выходе будет среднее направление за 10 минут. А мгновенное ИМХО и не несет никакой информации. Даже я бы и еще длиннее усреднение сделал, скажем, из 32 или 64 ячеек, чтоб делить удобнее.
Так вот для этой арифметики все равно код Грея проще на старте перевести.
4. Все таки про неопределенное состояние оптического датчика не понял - что значит ?

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Поясню насчёт того, что "дребезги" и неопределённости сами "разрулятся" : То есть ещё один пунктик "почему" лучше взять большую точность и потом уже огрубить.В быту и так точнее чем восемь направлений как правило не отмечают. А вот в других ситуациях уже и "зюйд-зюйд-вест" говорят, ну а румбы Вы сами изволили упомянуть. В розе ветров иногда рисуют радиальные отрезочки-линейки числом более 16 именуя лишь 8 из них и не именуя промежуточные. Так что всё нормально, можете не заморачиваться на таких мелочах.
Если вдруг не "нагуглился" код длиннее 4 бит ( что тоже странно, но .. всякое быввает .. ), то вот , пожалуйста :

Спойлер

Цитата:

Код:

Dec       Bin        Gray 
0        000000   000000
1        000001   000001
2        000010   000011
3        000011   000010
4        000100   000110
5        000101   000111
6        000110   000101
7        000111   000100
8        001000   001100
9        001001   001101
10       001010   001111
11       001011   001110
12       001100   001010
13       001101   001011
14       001110   001001
15       001111   001000
16       010000   011000
17       010001   011001
18       010010   011011
19       010011   011010
20       010100   011110
21       010101   011111
22       010110   011101
23       010111   011100
24       011000   010100
25       011001   010101
26       011010   010111
27       011011   010110
28       011100   010010
29       011101   010011
30       011110   010001
31       011111   010000
32       100000   110000
33       100001   110001
34       100010   110011
35       100011   110010
36       100100   110110
37       100101   110111
38       100110   110101
39       100111   110100
40       101000   111100
41       101001   111101
42       101010   111111
43       101011   111110
44       101100   111010
45       101101   111011
46       101110   111001
47       101111   111000
48       110000   101000
49       110001   101001
50       110010   101011
51       110011   101010
52       110100   101110
53       110101   101111
54       110110   101101
55       110111   101100
56       111000   100100
57       111001   100101
58       111010   100111
59       111011   100110
60       111100   100010
61       111101   100011
62       111110   100001
63       111111   100000

Ну и повторюсь :
И , хотя, , но для розы ветров это не очень и нужно - там просто напросто радиальные отрезочки должны быть пропорциональны количеству записей соответствующего направления. То есть не так уж важно будет ли за сутки 24 записи или 86400 например - рисунок розы ветров за N суток будет почти такой же. Тоже можно не заморачиватья. Считали положение(норд-норд-вест например) -> инкрементировали переменную{nord_nord_west} -> в конце недели нарисовали розу ветров . Вместо инкрементирования можно прибавлять силу ветра, тогда будет видно не только какие ветры чаще , но и какие сильнее дуют ..

ну-ну-ну, логгирование в самом МК это уже борщ, да и не влезу - там окромя этого датчика еще много чего предстоит.

Не хватит места для 64-ёх 32-битных переменных ?
Что за м.к. такой ?
Четырёхбитный какой нибудь - к1820ве1 или км1814ве3 ?

ТС - а почему для определения направления ветра просто не использовать магнетометр?

А по цене)
Энкодер Грея я сделаю, возможности есть (рекламное производство), диодов напаяю, логику напишу.
А магнетометр сколько бы стоил?

А какая разница, особенно если единичное устройство для себя делаете? Кстати, MAG3110 даже на плату распаянный стоит на Али всего 2.50 USD. Пусть даже энкодер Вам даром достанется, начнёте работать с электронным компасом - оцените удобство.

А можно посмотреть на схему... для определении направления и скорости ветра?
И если есть исполнение в железе.....одним глазом на фото взглянуть...
Тоже интересует вопрос по метеостанции....

А почему именно код Грея? А если просто: 16 площадок по кругу и центральный контакт?

Лично я не очень понял, каким с какого бока здесь можно приделать магнитометр, разве что саму плату крутить, так ведь опять-же, с неё показания снимать нужно, а вот магнитный датчик угла поворота типа AS5030 от Austriamicrosystems вполне будет уместен, но только для профессиональной метеостанции. Ибо в данном случае, IMHO, он будет давать избыточную точность и потребует относительно точной механики, специального магнита и последующей юстировки. Да и сам чип не из самых дешёвых.


О скорости ветра :
https://sdelaysam-svoimirukami.ru/224-anemometr.html

Можно взять электромотор от CD-ROM, сгородить формирователь, чтобы импульсы выдавал и так-же их считать, а можно считывать состояние встроенных в него датчиков Холла.
В общем много есть вариантов.

О направлении ветра уже, IMHO, достаточно насоветовали.

Так уже ж говорили - ошибко-устойчивость кода.
А "если просто" ,то, ошибки неизбежны и неустранимы никакими мат.методами.
Вот почему.

Сделано вот в таком плане.....
1.Скорость ветра - http://windpower-russia.ru/showthread.php?t=77&page=36
2.Направление ветра 16 герконов и центральный контакт......
3. Все остальное от китайцев
Сейчас в стадии тестирования...