Прошу (как обычно при таких вопросах говорят на форумах) сильно не пинать...
Поправьте меня пожалуйста если я где то ошибся: имеем панель 24х32 пиксела, 3 цвета > итого у нас есть 24*32*3=2304 физических точки. Идем далее => необходимо развернуть картинку из озу 100 раз (100 Гц), но при этом!!!! требуется создать еще и градации серого ШИМом для каждой точки (8 битный шим, т.е. 256 градаций), отсюда вытекает мне необходимо разворачивать картинку 1 сек/100 Гц=10 мСек => 10 мСек/256 (1 такт ШИМа)=39 мкСек , т.е. на разворот 2304 бита мне надо это время. Далее: пусть у меня стоит ПЛИС опрашивает озу (в озу зашиты данные о шим каждого пиксела) сравнивает с счетчиком и выставляет соответствующие данные на шине данных для регистров (если регистры 16-разрядные их требуется всего 2304/16=144 шт) стробит и в конце цикла защелкивает. Значит для того чтобы считать данные о шим для каждой точки требуется 39 мкСек/2304 бита=16-17 нСек. Справится ли современная электроника с этим бредом? или все же ЭТИ дела делают таким же способом но не 24х32 а поменьше???

ЭТИ дела делаются на драйверах светодиодов с возможностью управления током каждого выхода.
ШИМ - это решение для табло в пионерском кружке

ммммм.... Т.е. китайцы до сих пор пионеры и строят по такой технологии тоже?
Просто я сколько видел на выставках на таких драйверах как DM163 совсем нет экранов, а вот на простых mbi почти все!!!! и при чем статическая индикация. Так как они ими управляют?

И кстати мне почему то кажется, что именно на этом принципе строит (или строил) уважаемый ledmaster. Как я посмотрел на форумах он вроде как хорошо отзывался о драйверах TI, а они почти аналоги MBI5026 к примеру. (и при этом он упоминал о тысячах используемых этих драйверов в его разработках).

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

Т.е. ГРУБО говоря у них обновление как ШИМ так и КАДРОВ идет к примеру с частотой 100 Гц????

Не верьте ему! Он фальшивый
yagger
У вас расчёт верный. Только умные люди перезагружают эти регистры по параллельной шине, а не через одну линию. Например через 24 линии и по каждой будет передано 32 бита для перезагрузки всех регистров табло. Таким образом длительность одного бита вырастет в 24 раза и будет 400 нс. Все подобные вещи уже давно можно было делать на уже состарившейся элементной базе. Сейчас база озволяет делать всё в десятки раз круче.

Ошибся. По каждой из 24 линий будет передано 32*3 бит. То есть 6 регистров MBI5026 (16-разрядных) в цепочке.

А тут все фальшивые, настоящие только (оглянувшись) модераторы.

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

GetSmart дело в том что я пока в расчете и не затрагивал "загон" в регистры меня на самом деле интересует время считывания из озу... Даже если взять озу с временем доступа 5-10 нс (а я расчитывал на 12-20) то за 16-17 мс необходимо сделать все остальное (записать с другой строны байты(я имею ввиду со стороны приемника потока 25-30 кадров), далее загнать в регистр текущий бит, но перед этим сравнить в счетчике шима и т.д. не говоря уже о том что я наверное еще что то упускаю)
Я кстати на параллельную шину сразу и расчитывал, ввиду многих причин...
Но что то я не понял как это время вырастет до 400 нс???? мне то разницы на самом деле нет выставлять бит на параллельную шину или на последовательную (если бы БАЙТ это другое дело)...

Да и еще, Dog Pawlowa, в одном форуме видел хорошее замечание " Титаник делали профессионалы, а ковчег - любитель!" и если придерживаться позиции что китайцы всех победят, то можно завтра закрывать почти все фирмы и производства и у нас и у вас в стране...(хотя на самом деле я не знаю откуда вы). Просто есть такая вещь как маркетинг или например личные договоренности в особых кругах сбыта, где ни какие китайцы не пробьются.

Что-то вы не то насчитали. У вас 24*32*3*8*100 бит/с для приведенных вами условий, иными словами - 542,5 нс/бит.

Начните уже сразу мыслить широко. У вас что однобитное ОЗУ ? Тогда вам труба! Профи всё это делают внутри FPGA. Там и ОЗУ бывают по 10 КБ и логики выше крыши. Да и скорости еденицы нансек. Я конечно разжёвывать всё до мелочей в схемотехнике и алгоритмах не буду, так, пару советов могу дать.

Хм, это не форум сантехников? Всякий уважающий себя инженер должен пахать широко


Угу.
"Зато мы делаем ракеты..." (с) Ю.Визбор
Тогда договориться можно и с президентом.

??? что то мне подсказывает что у вас не то что то...
хотя я все же могу ошибаться.
24*32*3=2304 физических точки.
теперь следую алгоритму: берем из озу 1 байт(8 бит) сравниваем его со счетчиком (к примеру в ПЛИС) и по результату сравнения выставляем 0 или 1 на шине данных, стробим, читаем след байт(8 бит) и так 2304 шт, после этого подаем строб LE. На этом этапе первый такт ШИМа загружен в регистры. И таких разворотов нам надо 256 (так как шим 8 битный). И вот эта последовательность и есть картинка за 10 мСек так как 1 сек/100 Гц=10 мСек. а Если так, то 10 мСек/256=39 мкСек на 2304 байта, а соответственно 39 мкСек/2304~17 нСек на выборку 1 байта (который сравнивается с счетчиком) и установку 1 бита на шине данных. Где ошибка???

Так делают любители, вроде ledmaster. Ковчег наверно тоже он делал. Зачем по 256 раз сравнивать один и тот же байт (яркость)? Берёте младший бит, отображаете его 1 такт. Берёте второй, отображаете 2 такта. ... Берёте 4-ый бит, отображаете его 16 тактов. ... Берёте старший 7-ой бит, отображаете его 128 тактов. Никаких сравнений не надо. Сразу после начала отображения 7-ого бита оперативка освобождается для перезагрузки новыми данными. То есть 1/2 времени она гарантированно не используется (реально 97%). Что бы не париться и не читать из ОЗУ байт ради одного бита, делается так:
Заранее в ОЗУ записываются не байты яркости пикселей друг за другом, а уже разрезанные на 8 плоскостей данные. Таким образом если память байтовая, то чтение одного байта извлечёт данные для 8-ми пикселей и должно длиться 17*8 ==> 136 нс. Однако, уже подчёркивал, что делать это на рассыпухе - школьное подельничество. FPGA или ARM-проц. Они же могут раскрутить в 10 раз большее табло.

GetSmart, огромное спасибо за достаточно подробное описание алгоритма, я прошу прощения, возможно бестактно с моей стороны будет спросить, Вы строили данные девайсы? Конечно можете не отвечать, просто я сколько читаю форумы там чуть ли не 90 процентов теоретики и философы. А по поводу ledmaster я просто видел его высказывания в форуме ledforum.ru и у меня сложилось о нем некоторое мнение.(я его не считаю любителем). Любитель это я точно... Правда стараюсь выбраться повыше. Как говорится "Завтра начну жить с нуля. Только до него еще добраться надо."

Да, строил. Знаю там каждую крупинку. Поверьте мне, никаких побочных эффектов на неподвижном табло не наблюдается. Даже на не сильно подвижном тоже.

Не сочтите за назойливость, а почему СТРОИЛ? сейчас это, как говорилось выше, китайцами задавлено, или все же есть другие причины? Может поделитесь с какими подводными камнями могу столкнуться? например нужна ли синхронизация всех модулей, минимальная частота кадров без потери качества видео, может драйверы посоветуете и ПЛИС... При случае проставлюсь в Минске.

Далековато от меня. В Минске я ещё не разу не был.

Скажем так, количество знаний в какой-то области не всегда пропорционально оплачиваются. Вобщем по разным причинам сейчас занимаюсь другими делами, но тоже связанными с электроникой. Я уже давно не интересовался драйверами, спросите у ledmasterа. А FPGA выбирайте сами между Altera и Xilinx. Соответственно Cyclone или Spartan. Я бы выбрал самую дешёвую из них, подходящую по размеру ОЗУ. Хотя лично я скорее всего сделал всё на ARMе, но это долго объяснять что и как.

GetSmart,Спасибо еще раз... А в Минск милости просим. У нас тут весьма неплохо. А по поводу знаний... У меня с детства сложилось такое отношение ко всем делам (наверное глупое) сначала сделать, а потом теорию изучать. Т.е. я по натуре чистейший практик. Но вот в последнее время начинаю понемногу и думать перед тем как сделать. По поводу ваших объяснений как шим получается в экране... Ведь именно с этим у меня пока туговато, так ноги а контроллерах доргаю (там часы всякие табло спортивные и строки бегущие) а вот с математикой двоичной как то не получается пока дружить. Скажем так нет учителя по этим вопросам, а самому разбираться с 0 как то страшновато долго получится... Можно я буду задавать глупые вопросы? С надеждой на толковые ответы? В ранг учителя вас возведу...

Главное - изначально продумать иерархичную наращиваемую систему. Все остальное приложится



Синхронизация модулей не нужна, правда, у меня она всегда получалась автоматически. Минимальная частота кадров - порядка 75 герц, но нелишним будет задрать ее до нескольких сотен герц. У китайских товарищей в основном 200-300 герц.
Лично я использую драйверы MBI5026 и ПЛИС Альтера (Циклон1/2), которая тянет модули размерностью порядка 64 на 32 полноцветные точки. Обычно хватает внутренней памяти, но иногда приходится ставить внешнюю.

Да, глубина цвета (разрядность ШИМ), что выбрана Вами (8 бит - 256 значений), абсолютно неприемлема (проблемы с воспроизведением "темных" полутонов). Минимум - 10 бит; опять-таки, у китайцев от 12 до 14 бит. Я делал не менее 12 бит для статической индикации.

Будут вопросы - милости просим.

Спасибо за советы. Очень помогает, на душе легче становится. А что означает обычно? Вы все время применяете для своих девайсов разную схемотехнику?



А как данные о 10-12 разрядном шиме грамотно в памяти располагать? 2 байта на пиксель занимать приходится?

Уважаемый GetSmart, что-то не припомню, когда я Вам рассказывал, что и как я делаю
Я не отношу себя к числу людей, которые всегда и во всем считают себя суперпрофессионалами, но некоторые приемы построения экранов и мне доступны
Хотите подробностей, их есть у меня!

Уже на раз слышал упоминание о Вас в контексте алгоритма с постоянным сравнением яркости точек на больших экранах.
Ни в коем случае. Тем самым сразу увеличите поток данных от компьютера или чего-то ещё в экран. Внутри FPGA вообще проблем нет. Сразу можно поделить на 8..10 плоскостей. Хотя это не принципиально. Главное не передавать и не хранить лишние пустые ~6 бит. Только если памяти некуда девать.

ЗЫ. Для уличного экрана 8 бит на точку вполне приемлемо. Особенно если это сказывается на экономии чего-нибудь. Желательно конечно 10.

Господа, извините что вмешиваюсь... Но мне совершенно не понятно, в чем прелесть постройки экрана, с такой разверткой и шимом ? Почему все же, не DM163 и ей подробные ? Грубо говоря, весь экран, это три длинных сдвиговых, с програмным управлением каждой точкой. Или я чего-то кардинально не понимаю ?

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



Уважаемый GetSmart, а где я могу почитать или может даже посмотреть в картинках , как это в адресном пространстве делается. Я понимаю для 8 бит, 8х8 переворачиваю на 90 градусов вот у меня готовые байты на выдачу. а 10-12 бит???



На сколько я понимаю приемлемо из-за того что общая освещенность бОльшая и "ньюансов" видно не будет?

Да. Все зависит от размерности управляемого объекта. Если два полных кадра лезут в память ПЛИС - нафига внешняя память?
А вот если не лезут, то приходится ее ставить.



Память ПЛИС может быть организована не байтами. Можно хоть 13 бит без потерь сделать 12 бит в Альтере - три блока памяти разрядностью 4 бита.

А если память внешняя, то ее обычно дофига, и не проблема потерять четверть 16-ти битного слова.

Уважаемый _LD, может Вы поделитесь? чем (интерфейс, протокол) вы доставляете к блокам видеопоток (не сжимать же его, а то аппаратное сжатие стоит огогого, а програмное мне не потянуть с моими знаниями это точно в ближайшее время ). Спасибо за разъяснения по поводу памяти альтеры, я как раз это изучил. Я думал про 2 байта ПОЛНЫХ с лишними битами в видеопотоке, как их там не передавать? (грамотно).
Вопрос к Вам (ибо вижу вы не просто любитель, а вроде как знающий человек ), Вы тоже применяете способ ШИМа взвешиванием (тактированием) весовых коэффициентов разрядов или же у Вас иной способ? (и вообще какие еще бывают способы создания ШИМа без потери времени на прием данных и обслуживание ОЗУ без применения драйверов с шимом)?
З.Ы. Какую внешнюю память Вы применяете (если такая все же необходима)?

Вот еще перечитывал возник вопросик, Вы тут имели ввиду 12-14 бит на 1 ЦВЕТ?! Раз так то откуда их снимать? Ведь по тому же DVI прет по 8 бит на цвет, откуда лишние биты берутся? Неужели их приходится добавлять самому при преобразовании(так называемой гамма коррекции)?
Еще вопрос. я наверное слишком много их задаю... в ПЛИСке у Вас организована память 2-х портовая? (если так то, тогда понятно как она успевает независимо и шим вывести и принять DVI, или что там еще...)

Китайские товарищи вовсю используют гигабитный ethernet, а я не захотел
В небольших поделках - манчестер 8 мбит по витой паре, в больших - 100 мбит ethernet.



Уже сменил род деятельности. Задолбало лампочками управлять
Но несколько лет просидел на этом.



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




Асинхронную статику Samsung.



Именно так.



Конеюно, двухпортовая. Если два полных кадра в ПЛИС не лезут, идет прием во внешнюю память с перебросом ее во внутреннюю при смене кадров.

А в чём приемущества такого "гибрида"?

Именно из-за этого. При низком освещении уже будут видны "ступеньки" на малых яркостях. Кстати, если для уличного экрана не применяется изменение гаммы в зависимости от времени суток (день/ночь), то 10 и более битный экран всего-лишь "пыль в глаза". Другими словами - рекламный трюк.

Был бы благодарен за информацию о том, чем плохи DM163.

У нас сделали 2 экрана на этих драйверах - один с SMD светодиодами, шаг 10мм, другой с колбочками, шаг 28мм. Так вот, плата с SMD диодами - это один длинный сдвиговый регистр на 96 последовательно включенных DM163. Никаких сбоев не наблюдается, что меня сильно порадовало, даже на это и не рассчитывал, думал, придется распараллеливать. Правда, плата вышла 4-хслойная.

Поскольку тупую работу ШИМ выполняют сами драйверы, снижена нагрузка на ПЛИС, один Cyclone управляет 4-мя такими платами, снимая данные с LVDS линии.

Вот, хотелось бы узнать, чем действительно плохи DM, может, я рано обрадовался?

а какого разрешения модули и экран?

ну если я правильно понимаю, то исходя из соображений что DM163 24 канала(8 пикселей RGB) то в итоге получается 96 микросхем это 32х24 это если статика конечно... (кстати я как раз где то читал , что именно при динамике у этих микросхем всякие пошлости... только вот не помню где читал )

GetSmart, может Вы можете поделиться секретом: какие еще бывают способы создания ШИМа без потери времени на прием данных и обслуживание ОЗУ без применения драйверов с шимом.(я как буратино - хочу все знать.

Абсолютно правильно подсчитали - плата именно 32х24 и именно статика. Из 4-х плат собран блок, управляемый контроллером. А размерность экрана - по количеству блоков.

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

А ШИМ чем создаете? Я имею ввиду на PWC вход что подаете на каждой плате свой отдельный генератор? и какова частота его у Вас? LVDS - это вы прямо DVI в блок пихаете или свое что то? Да кстати, на смд диодах экран не греется? как охлаждение сделали?

Ребята, А может расскажите принцип масштабирования? или у Вас в программе на компе есть область куда и сгружается все видео, и эта область по масштабу (по пикселам) соответствует экрану. В DVI по-моему минимально 60 Гц кадры бегут, какой принцип получения 25 кадров? ну я так понимаю 30 кадров можно через кадр забирать из потока, а вот 25? неужели через 1, а иногда через 2?

Масштабирование мы не применяли. У нас делалось так. На мониторе проигрыватель видео жёстко привязан к координатам экрана. А из потока DVI просто "вырезается" это окно и загоняется в ОЗУ FPGA. С кадровой частотой всё проще. Две страницы видеопамяти переключаются друг за другом. После полного заполнения пассивной, она становится активной и отображается, но обязательно синхронно со сменой кадров экрана. В другом варианте, когда видеопоток идёт не с DVI там можно по запросу заполнять единственную страницу ОЗУ. (если используется тот алгоритм с "взвешиванием" разрядов)

На каждой плате контроллера, управляющего до 8ми светодидных плат, свой генератор GCK 1.25 МГц, на более низких частотах заметно мерцание.
LVDS получается из DVI соответствующим преобразователем от TI.
А вот с охлаждением вопрос непростой. В модулях стоят блоки питания с вентиляторами, они обеспечивают какой-то принудительный обдув, на платы все равно заметно теплые. Спасает, что в помещении не надо выводить максимальную яркость, а на улице придется ставить дополнительные вентиляторы.

Ага, я как раз именно так и представлял этот процесс и это, на сколько я понимаю, на много проще чем применять какие то ни было масштабирования, будь они программные или аппаратные...

Я очередной раз прошу прощения если я правильно понимаю, в этом варианте используется 2 страницы памяти озу с разным адресным пространством??? ну то есть дабы иметь одновременный НЕЗАВИСИМЫЙ доступ к своей памяти (активной/пассивной) как со стороны драйверов, так и со стороны потока видео? и в момент заполнения памяти пассивной со стороны потока, выжидаем пока не "отстреляет" до последнего бита активная часть и переключаем памяти??? я правильно рассуждаю? Если так, то как я и писал получается все равно из 60 кадров входных, я исскуственно должен забирать только 25-30 кадров пропуская некоторые из них?


В таком варианте я понимаю тоже можно, в принципе, использовать не 2х портовое а 1портовое озу???
А по поводу алгоритмов без "взвешивания" разрядов. Я действительно осознаю что в варианте с взвешиванием >95% времени свободно. В других алгоритмах так же дела с свободным временем обстоят, и сколько вообще можно насчитать таких алгоритмов?

а кто вам мешает работать с родной частотой 60 Гц, зачем ее искусственно снижать?

хм. сам дурак. действительно зачем. Но почему тогда все производители пишут типа 25-30 кадров? зачем они тогда снижают? или все же есть затык в чем то? 'Галстук' а у Вас какова частота кадров?

Ну 60Гц. У нас экран работает от компа, 60 Гц. Будет источник 25 Гц - можно и 25 Гц.

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

А по поводу кадровой частоты, так в начале темы вообще был расчёт на 100 Гц. Какие проблемы? У мониторов тоже частота не 25, а 60 и выше герц. Они прекрасно показывают 25 Гц фильмы. При желании можно вообще сделать автосинхронизацию экрана с идущей от DVI потока.

http://www.leds.ru/forum/viewtopic.php?t=26
тут давненько немного обсуждали тему?
что означает фраза (для меня пока слегка загадочная) "Сейчас буду пробывать MEGA128 с внешним сумматором (для вычисления уровня ШИМ) в адресном пространстве. Думаю смогу из нее 256 градаций на модуль 16х16 RGB вытянуть. у мастера дениса?"

'GetSmart' этот ДРУГОЙ алгоритм секрет?

Это к афтору фразы. Судя по всему проц только адреса перебирает, а данные из рамы сразу через сумматор идут на линию данных сдвигового регистра.


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

Я так понял, алгоритм с постоянным сравнением с счетчиком уже вообще не рассматривается... Но в фразе есть слово ЕСЛИ (если используется тот алгоритм с "взвеш........), по-этому я и подумал, что все же имеется ввиду еще какой то способ. Но ледмастер писал в ледфоруме, что все же у него есть ноу-хау. Может и Вам известна эта военная тайна?

Ссылку можно? Попробую силой мысли угадать что он от всех "скрывает"

http://www.d-sign.com/viewtopic.php?t=626&...asc&start=0
Добавлено: Пн Фев 18, 2008 2:49 pm
"хотя правды я тоже не скажу, это ноу-хау."

Для справки, на 200-рублёвом АРМе без какой-либо внешней обвязки (простые буфера не в счёт) можно сделать "мозг" RGB модуля 96*96 кластеров с кадровой 60 Гц. Или 85*64 100 Гц. Или вообще любое разрешение. Только такие большие платы (на весь модуль) вроде как нереально изготовить.

Выигрыш по времени... Конечно же не 256 тактов, а только 8. Хотя цена минимального такта действительно 1/256-ая. Я в этом не вижу никакой проблемы, ведь 100 Гц * 256 = 26 КГц. Разве это много? Вся хитрость только в том, как за этот период обновить все сдвиговые регистры новыми данными. Как уже говорилось - мысли "шире" - грузи как можно больше параллельных данных.

Есть ещё теоретически другой вариант, когда яркость регулируется не только временным интервалом, но и регулировкой тока. Это в теории легко, а на практике почти нереально. Во всяком случае на дешёвых драйверах MBI5026. Вобщем байт яркости делится на два полубайта. Оба полубайта выводятся вобщем одинаково друг за другом. Либо просто сравнением, либо 4-мя плоскостями со взвешиванием. Только электрическая схема позволяет при выводе младшего полубайта уменьшить ток через светодиоды ровно в 16 раз. Если она уменьшит не в 16, а в 15 или 17, то на экране будут наблюдаться "глюки". Таким образом кол-во так называемых (ledmaster-ом) тактов уменьшается до 16+16 = 32 тактов.

У меня ещё есть оч. красивый вариант полу-динамической RGB-индикации. Он позволяет в 3 раза уменьшить количество драйверов MBI5026 или любых других. Дело в том, что каждый выход драйвера цепляется сразу к трём катодам светодиодов R,G и B. А вот аноды через мощные ключи (R, G и B канала) подключаются к питанию по очереди. Плюсы - экономия большого кол-ва регистров, места на плате и большая надёжность из-за меньшей длины цепочек регистров их емкостей и токов потребления. Однако драйвер MBI5026 должен будет выдавать на каждый свой выход утроенный ток, но он легко это делает, т.к. расчитан до 90 мА. Скорость перезагрузки регистров остаётся та же, т.к. кол-во регистров в цепочках уменьшилось втрое. Минус мне видется только в том, чтобы качественно сделать последовательное переключение питания R-G-B цветов. Чем реже переключаются эти ключи тем лучше. Если частота кадров 100 Гц, то 1/300 сек выводится цвет R, потом столько же G и B. Общий период будет как раз 1/100 сек. При желании можно переключение RGB увеличить в 2,4,8 раз.

Теперь что касалось вопроса "а что же делать 90% времени если нечё делать?". Ну с DVI-ем действительно нечего делать. А вот если канал передачи видео не DVI, то можно слать сжатый поток и декодировать его в рилтайме.