Форум РадиоКот

Откидывать коробки при невалидном баркоде - это надо ещё механику придумывать.
Достаточно будет если линия остановится. Всё же не так много пересортицы... Но 1 "невалидная" пачка среди 1-10 тысяч... уже проблемы.

Чем сложна оптика у оптических мышей? Там ведь передатчик и приёмник... работают на отражение.

И кстати - почему ручной сканер - для моих целей не подойдёт? Не будет успевать?

Не пойдёт, потому что он тут нахрен не нужен. Всё проще делается.
А если готовый сканер баркодов, то вы от него сами отказались.

Про мыши - разберите, да посмотрите.

Спасибо за наводку и подсказки.
С мышой так и сделаю
Уже полгода не занимался с МК. До этого мелочи типа счётчика и мигание диодом.
Теперь реальная задача Надеюсь получится её решить... Это нужно мне в первую очередь - с целью изучения МК...

Предлагаю такой вариант штрих-кодов:

Считывается двумя фотодиодами, подключенными через инверторы к штатному USI интерфейсу микроконтроллера, настроенному в SPI режим. Синхроимпульсы подаются на вход SCK микроконтроллера, а данные на DI(MOSI) МК. На рисунке изображён 1 байт (8 бит)
Можно растянуть на 4 байта и один-два контрольных байта.

Не подойдёт т.к. нужно будет настраивать что бы кажды йдиод видел только свою часть.
Всё же когда |||| проще. Даже если сдвинется штрихкод параллельно движению - ничего страшного не произойдёт.
В общем буду ждать USBee AX, копаться в мышах... и пробовать всё это на макетке.

Моё дело было предложить, а там сами решайте.
Я такой метод применял на карточках. Правда там скорость чтения не такая быстрая там была.
Зависит от того, как быстро юзер проведёт карточкой по считывателю.

В обычном варианте Вы будете сильно зависеть от скорости конвейера. Длинный\короткий импульсы отсчитываются временем измерения. Обычный RS232 считыватель имеет внутри шаговик с зеркалами, который управляет лучом. Чтение штрих-кода и управление лучом сильно взаимосвязаны. Так-же он считывает один и тот-же код несколько раз и пишет считанное в многомерный массив. Потом ведёт сравнение: каких последовательностей оказалось больше всего, тот он и принимает за правильный. Если скорость конвейера немного упадёт, то МК будет думать что короткие импульсы - это единицы, в то время, как они должны быть нулями.
Мой метод не зависит от скорости конвейера, будь то производительность 50 шт\сек или 1 шт\час. Хвостики штрих-кода можно удлинить, если он мелким показался. Например так:

А как решил проблему того что пользователь проводит одну карточку не с постоянной скоростью? Т.е. скорость меняется по мере продвижения карточки через сканер.

Если следовать вашему предложению... и из своих ограничений. То высота штрихов у меня будет максимум 4мм. т.е. в сумме две строки штрихов 8мм. А вот ширина баркода у меня может быть до 50мм.

С вами можно будет в будущем напрямую связаться для консультаций?

А как решил проблему того что пользователь проводит одну карточку не с постоянной скоростью?

Синхроимпульсами. Сначала выставляется значение данных, потом проскакивает синхроимпульс.(см. на бар-код) МК считывает ногу во время синхроимпульса и проверяет, ноль там или один. То есть синхроимпульс является командой контроллеру "Проверить состояние входа данных" Программу проверки особо писать не надо. Аппаратный\полуаппаратный USI есть почти во всех МК.


Ну если, что, то можно.

А нафига вообще эти специальные риски? По-любому синхро можно формировать либо по фронту баров, либо по спаду. По фронту, наверно, перспективнее. И от извращенческих баров при этом избавитесь.

walkerru писал(а):А нафига вообще эти специальные риски? По-любому синхро можно формировать либо по фронту баров, либо по спаду. По фронту, наверно, перспективнее. И от извращенческих баров при этом избавитесь.

Вот и у меня мысль - почему так не сделать?

Не забываем про скорость конвейера. Она переменная. Брать синхронизацию с меток данных - это опять надо измерять временем длину меток. А тут мы от времени не зависим. На линии данных выставляется значение (есть полоска\нет полоски) за тем с рисок синхронизации поступает импульс. МК, получив этот импульс проверяет состояние входа данных (есть полоска\нет полоски) и пишет этот бит в свой встроенный сдвиговый регистр. Как считается 8 меток, так и сформируется 1 байт. Почитайте про SPI интерфейс в интернете и будет понятнее, что я имею в виду.
Решайте сами. Вмешиваться больше не буду.

DX168B, вы опять не про то. Чем разительно ваши дополнительные метки отличаются от начала основных баров? Это одна и та же точка.

Поразмыслив - нашел ещё одну проблему.
Бывает что перед/после баркодом, по ходу движения есть текст... или другие надписи.
Как быть в этом случае?

Я вижу это так. перед основной частью баркода есть три полоски. Расстояние между ними (допустим 4мм), толщина штрихов (допустим 1мм), частота работы МК, нам известны. Тогда получив первый импульс, ждём второй.... если он наступает раньше некоторого времени Х1, сбрасываем и ждём. Поступил импусль, потом второй. Времени между импульсами прошло больше некоторого значения Х1 и меньше Х2, то считаем что у нас валидные первые две полоски. Рассчитываем скорость по фронтам двух импульсов. Зная расстояние между вторым штрихом и третим, вычисляем время Х3 через которое должен прийти третий контрольный импульс.... Если он приходит, значит всё нормально - мы знаем что дальше расположен штрихкод а не текст или т.п., у нас есть скорость, есть данные о толщине коротких и широких штрихов... Ждём поступления импульсов от баркода и их расшифровываем. Зная количество штрихов в баркоде - мы знаем когда он закончится и ждём поступление импульсов от контрольных меток.

Вот как-то так я думаю нужно организовать фильтр от ненужных помех.
Конечно в баркоде, в конце будет контрольный бит.

Spirit412, а на кой, по вашему, мы синхробары обсуждаем чуть ли не с начала?

Повторюсь: если синхробары будут как узкие, так и широкие, можно заодно длительности узкой и широкой полосок ожидаемые мерять.

Для этого и обсуждаем.
Просто я наконец-то понял принцип их работы... Ну или думаю что правильно понял.

Сильно не пинайте... зеленый ещё в этом деле.

Меня вот знакомец один, склоняет к тому что бы под этот проектик взять Arduino (с ATmega168 интерфейсы USB, UART, SPI, i2c). Типа проще его взять и изучить не сложный язык кнему. чем париться с макеткой... обвязкой МК и пр.
Я же склонен использовать СИ и макетку... и т.д. А когда всё будет более менее стаб. работать - ЛУТ и паяльник

Про Ардуино ничего не скажу, ибо не знаю.

Подведу итоги:

Про синхробары: по времени между началами их определяем период баров в баркоде (т.е. через какое время ожидается следующий бар).
По времени между началами и концами - длительность узкой и широкой полосок.
Считаем единицы в коде - проверяем чётность последней полоской. Я тут подумал, чётность двоичного числа зависит только от младшего разряда. Значит недостаточно проверять чётность числа. Чётность числа единиц - правильнее.

Все бары считываем тремя фотодиодами (фоторанзисторами). Далее - либо АЦП на каждый, что избыточно, либо сначала компараторы, а потом цифровые входы.
Значение бита определяем по значению, которое намеряло минимум два фотодиода.

walkerru писал(а): Все бары считываем тремя фотодиодами (фоторанзисторами). Далее - либо АЦП на каждый, что избыточно, либо сначала компараторы, а потом цифровые входы.
Значение бита определяем по значению, которое намеряло минимум два фотодиода.

Если брать внешний компаратор, то взять что-то типа LM339?
А три пары фотодиодов стоят параллельно и одновременно считывают? Может одним достаточно? Ведь и так уже будет реализован фильтр и синхронизация.

Мне не понятно почему не использовать встроенный в МК АЦП?
Вот схема где это нормально реализуется http://www.radioparty.ru/index.php/comp ... attiny2313
Там две оптические системы напрямую подсоединены.

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

А так-то к АЦП можно. Если уровень сигнала не на уровне шумов.

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

Запачкать, и пр. Истину говорите - обычное дело
Но на этапе склейки (сразу после вырубки) обычно всё чистое.
Вот только что делать, если баркод не черный, а допустим тёмносиний, коричневый и т.п. и напечатан на белом. Контраст баркода относительно белого картона сохраняется, а вот уровень сигнала уж меньше. Фототранзистор(фотодиод) будет ведь отраженный от пачки свет ловить.

Попробую за выходные накидать план логики работы МК.

И ещё, я правильно понимаю... если используем внешний компаратор, то на входе в МК у нас 0 или 1. А время высчитываем по след. принципу:
- ждём 1 на входе В1.
- получили 1 на входе В1, начинаем отсчет сколько опросов входа В1 будет показывать 1.
- получили 0 на входе В1
- отсчитываем количество опросов дающих в результате 0, до тех пор пока не получим на входе 1.
- складываем оба количества отсчётов - получаем количество импульсов по фронтам первой и второй "рисок" синхронизации.
... и т.д. Я опустил момент сравнения с Х1 и Х2 некоторыми контрольными временными константами.
Я правильно понимаю суть работы будущей программы в МК?
Хватит ли для моих вычислений скорости работы МК в 8МГц или взять больше?

Для того, чтобы рассматривать разные цвета, вводится коридор запрещённых уровней. То есть, например, больше 3.5В - единица, менее 0.5В - ноль. Или как-то еще. Попробовать надо и уровни подобрать, чтоб на разных цветах работало. Ну и дизайнера проинструктировать, конечно, чтобы баркод бледно-жёлтым не делал, а делал контрастным. Т.е. как есть у вас требования к макету, так должны быть и требования к баркоду.

Про 0 и 1 - скорее наоборот. Белый - света много - 1. Чёрный - света мало - 0. Либо инвертировать.

Кстати, с АЦП можно и самокалибровку предусмотреть:
не было не фига - не фига (точнее засветка паразитная от ламп, окон и т.д.) - пошёл какой-то сигнал, отражённый от коробки - усредняем - считаем фоном. Пошёл сигнал уровнем ниже - усредняем - считаем чёрным. Конечно, в этом случае должен быть усилитель, который вы предварительно настроите. Чтобы без коробки, с коробкой, с баркодом отличались. Чем больше отличаются, тем лучше.

Про алгоритм, ща нарисую вам баркод и сигналы, раз не понимаете.

Про 8МГц: напишете программу, прикинете сколько тактов она выполняется, прикинете минимальную тактовую частоту.
В принципе, и красивые картинки - тоже ваша задача. Равно как и измерения.
А как будуте усреднять - ваша задача, как разработчика. То ли программно, то ли ФНЧ поставите...