Новые баги utorrent или что для нас готовят программисты Bittorrent

Многие пользователи utorrent переходят на новые версии программы по привычке или до того момента пока у них не перестаёт что-то работать. Кто-то остановился на 2.2.1 или 2.0.4 как последних более-менее стабильных, а кто-то по сей день верен 1.8.2 и даже 1.7.7. Чем же так пугает и привлекает третья версия utorrent? Попробуем проследить и разобраться в изменениях которые были и тех, что ожидают нас в будущем.

Эволюция utorrent

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

Потом разработчики пытались довести до ума альфа версию 1.9, которая имела много новшеств. Из заметных такие как: поддержка udp трекеров, новый utp протокол, приложения, работа дополнительных параметров в магнет-ссылке. Но в стабильный релиз ушла версия 2.0, которую достаточно долго пытались подлатать до версии 2.2.1.

И вот тут начинается самое интересное. С версии 3.0 в программу приходят радикальные изменения, к ним нас подготавливали специальными альфа версиями utorrent под названиями «Falcon» и «Griffin». Но большинство из нас заметило только огромное количество глюков и проблемы в работе жёсткого диска. По этому продолжительное время многие справедливо отказывались переходить с 2.2.1 на 3.х. А нового в 3.х было много:

Достаточно интересной была технология под названием DNA. Под это название пытались впихнуть сразу две задумки:

1. Загрузка файлов через p2p с помощью специальных файлов, которые запускались на компьютере без торрент-клиента, либо их можно было запустить в самом utorrent, при этом в главном окне utorrent появлялся синий значёк DNA (к сожалению скриншот не сохранился). Такие специальные файлы предлагал загрузить своим клиентам например сайт ASUS в разделе загрузок драйверов. Запустив их, пользователь потом мог скачать сами файлы драйверов через p2p.

2. Просмотр видео в встроенном на http странице плеере с частичной подгрузкой из p2p.

Магнет-ссылки понимали новые дополнительные параметры ws (веб-сид) и fl (загрузка торрент-файла по прямой http ссылке)

В клиент был встроен механизм стриминга медиа файлов, когда можно было качать и одновременно смотреть фильм.

Многие провайдеры дождались включённой по умолчанию опции isp.bep22

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

Просмотр «рейтингов» и «комментариев».

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



Достаточно лишь перетянуть любой файл или папку в окошко программы и utorrent создаст специальную ссылку на http страничку, с которой ваш знакомый не догадывающийся о существовании торрентов и p2p сможет скачать с вашего компьютера файлы даже если вы оба будете за NAT провайдера. К сожалению, судя по всему, скоро разработчики удалят эту настройку из программы, потому как в новых версиях utorrent она работает только под танцы с бубном. Но кто всё ещё хочет вернуть её работоспособность в свой utorrent 3.x измените следующие параметры в скрытых настройках программы.

Нажав и не отпуская SHIFT и F2 зайдите в Настройки----Дополнительно. В самом низу списка найдите и измените значения в строках:

webui.raptor_host — raptor.utorrent.com

webui.raptor_port — 80

webui.raptor_secure — false

webui.talon_host — remote.utorrent.com

webui.talon_port — 80

webui.talon_secure — false

В настройке Удалённый доступ обязательно придумать и вписать имя и пароль, без них работать не будет!

Последующие версии до 3.3.2 включительно можно назвать работой над ошибками. И всё в итоге было бы хорошо со стабильностью программы в будущем… если бы не новые идеи и вместе с ними новый utorrent 3.4

Utorrent 3.4 — забытая революция ?

Думаете после неудач с DNA и raptor.utorrent.com разработчики закинули планы по интеграции торрента и веб в долгий ящик? Как бы не так! Всё начинается по новому кругу. На этот раз utorrent должен превратиться в файловый http сервер, но конечно же со своими p2p особенностями.

Небольшое отступление перед продолжением.

Вы должны понимать, что компания Bittorrent — это коммерческая организация, которой уже давно не интересна децентрализация p2p. Многие фичи в программе исчезают и появляются, а большинство из нас о их существовании даже и не догадывается. Все стремления в разработке utorrent направлены на зарабатывание денег. По этой причине не ожидайте ничего хорошего в новых билдах программы. С огромной вероятностью, всё о чём будет написано ниже, в utorrent 3.5 будет убрано или радикально переделано, то есть пользоваться этим уже вы не сможете.

Из мелких заметных изменений в utorrent 3.4.2 для меня, наверное, будет работа с https веб-сидами (таки Dropbox по прежнему ещё раздаёт некоторые мои торренты на рутрекере) и неотключаемая реклама Pro версии.

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

Первая подсказка спрятана в настройке Playback

Дальше нашлась опция копирования ссылки файла

Copy Stream URL

Скопированная ссылка получилась такого вида

http://ift.tt/188MjGP">

Вставив эту ссылку в свой браузер — получите проигрывание файла встроенным плеером браузера, либо просто скачивание его в папку загрузок.

В этой ссылке есть несколько параметров связанных с настройками utorrent

webui.allow_pairing

webui.proxy_auth

webui.token_auth

Но так как половина параметров в ссылке не работает (всё что связано с хешами), можно укоротить её до

 http://ift.tt/1G2G1ar

Если это вставить в браузер, произойдёт то же самое что и с полной ссылкой. Работающие параметры ссылки:

sid= номер торрента (может быть любым, выдаётся utorrent при добавлении торрента).

file= номер файла ( вроде как постоянный, назначается по положению в колонке Путь)

15906 — выбранный порт в настройках utorrent

Вот тут возникает вопрос: «А что с этим всем можно сделать ?» Пока наверно, получится только немного пофантазировать и поэкспериментировать. В принципе можете сами поиграться с этими настройками и посмотреть как они работают. Вот например как можно использовать этот встроенный в программу http-сервер:

Передача файлов на прямую по http

Для этого у вас должен быть белый статический или динамический IP в интернете или хотя бы в локальной сети, а так же проброшен порт указанный в настройках utorrent. В скопированных ссылках 127.0.0.1 нужно заменить на ваш интернет или локальный IP.

http://ift.tt/1zpyvhs

В зависимости от того собираетесь ли вы передавать файлы всем или избранным, можете включить или отключить в настройках опцию webui.proxy_auth. Если будет включено, перед открытием страницы utorrent может попросить пройти авторизацию. По этому в начале не забудьте вписать имя и пароль в настройках Веб-интерфейса utorrent (гостевой логин не работает)

авторизация

Если webui.proxy_auth будет отключён, контент станет доступен всем без выскакивающего окошка авторизации.

Последовательная загрузка и просмотр медиа файлов торрента

Как вы уже вначале догадались, название самой опции «Copy Stream URL» и все скопированные ссылки с IP 127.0.0.1 сделаны только для воспроизведения загружаемого контента на этом же компьютере. Однако зачем разработчикам пришлось делать так сложно (со встроенным http сервером) не совсем понятно…

Интересен сам механизм работы клиента по таким ссылкам. К примеру, вы скачиваете торрент-файл с трекера и запустив его в utorrent ставите задание на остановку (не загружаете), затем копируте ссылку Copy Stream URL какого-нибудь файла из списка и вставляете эту ссылку в свой браузер. Как только браузер переходит по ссылке в utorrent запускается процесс последовательной загрузки частей только этого файла, с постепенной передачей его браузеру. Если в браузере остановить загрузку и/или вообще закрыть программу браузера, utorrent так же отреагирует остановкой задания.

база сайта или каталога в p2p сети

Новые возможности utorrent были замечены и The Pirate Bay http://ift.tt/1zpyvhA Но как-то всё сложно у них там с юзабельнстью получается.

Step 2. Install and configure xampp

Download and Install xampp. (Visit the Xampp homepage here). Once Installed go to: Start->All Programs->Apache Friends->XAMPP->XAMPP Control Panel. Then complete the following operations:

К сожалению utorrent работает не совсем как веб-сервер, а скорее как файловый http сервер. Соответственно он может подгружать только файлы из p2p сети, затем браузер забирает из utorrent эти файлы и показывает их на своей странице. В добавок ко всему, загруженный торрент с файлами, на разных utorrent будет иметь различный sid=, но file= должны быть одинаковы так как названия и количество фалов в торренте у всех будет одинаковое.

Для того что-бы перенести сайт в торренты, необходимо сделать механизм глобальной правки sid= в ссылках в виде юзер-скрипта или расширения в браузере, который установит каждый юзер. А так же в торрент-файле необходимо будет поместить невероятно огромную кучу html страничек на каждую раздачу. Другое дело, если на компьютер пользователя будет установлена специальная программа для просмотра, умеющая работать по ссылкам utorrent. В настройках программы пользователь смог бы указать свой sid= торрента. Отображение онлайн раздач на трекере и в специальной программе может быть примерно одинаковым как по виду так и по содержимому. Общий вес загруженных пользователем файлов такого архива будет существенно меньше, чем если бы скачивался весь архив целиком. Юзер не должен и не будет качать/хранить на компьютере темы, которые ему не интересны. А вот раздавать сохранённые у себя части тем которые ему интересны он может.

Содержимое ахива сайта можно разбить на несколько торрент-файлов, а не пихать всё в один. Так в главном торрент-файле будет файл/файлы со всеми ссылками «карты сайта», остальные торрент-файлы будут относиться к определённой категории и хранить в себе как файлы с ссылками на файлы описания (скриншоты, текст, магнет-ссылки и пр.) так и к примеру файлы постеров и скриншотов (хотя, опять же их можно выделить в отдельный торрент-файл(ы), с возможностью указать дополнительные sid= ).

Ах мечты, мечты…

Автоматическое обновление торрент-файлов

К сожалению, эта тема раскрыта и исследована не полностью, так как мои знания в программировании примерно равны нулю.

Может быть, кто-нибудь из вас сможет исследовать эту тему и выяснит как должен работать этот механизм. Буду благодарен, если вы поделитесь своими мыслями по этому поводу.

В utorrent 3.4 была добавлена возможность автоматического обновления задания в клиенте. Так скачав с трекера торрент-файл какого-нибудь сериала, в дальнейшем можно не следить за выходом новых серий и обновлением раздачи на форуме, а сразу получать обновлённый торрент и новые серии.

В процессе создания торрент-файла (специальной программой) или в Свойствах торрента задания utorrent прописывается http ссылка обновления торрент-файла.



После перезапуска клиента, возле задания появится синяя «точка», означающая что utorrent периодически опрашивает сайт на предмет загрузки нового торрент-файла.

В самом utorrent можно посмотреть ленту обновлений по каждому торренту (дата и файлы)

Разработчики utorrent опубликовали специальный мануал http://ift.tt/1zpyvhH

Так же получилось раздобыть их экспериментальный торрент-файл, который внутри содержит соответсвующие записи в секции info.

внутренности

На момент когда я достал этот торрент-файл, по ссылке обновления загружалось

{
   "message": "no update",
   "success": true
}

В переписке с разработчиком utorrent получилось вытянуть только это

For the torrent to be updatable, it has to have either a «collections» key or «similar» key or both, and torrent downloaded by the update-url must be signed by the original torrent's originator.

«collections» key or «similar» key is described in:

http://ift.tt/1G2FYLR

update-url is described in:

http://ift.tt/1cMfhaI

the signing is described in:

http://ift.tt/1G2G1az

thanks,

-Jeanette

Другие не исследованные настройки utorrent 3.4.х

Одной из интересных опций наверно будет vpn.dark_mode. Если её включить, клиент теряет обычную связь с трекерами и пирами. Что собственно и должно происходить для того, что бы «не палить» IP. Если логически развивать мысль дальше, работать это должно примерно как remote.utorrent.com, с той лишь разницей, что некий сервер должен быть одновременно прокси-сервером и ретрекером. То есть, при включении этой опции utorrent должен качать/раздавать только через этот сервер. При этом другие пиры должны так же, по идее, включить эту опцию.

Однако экспериментально заставить работать эту опцию у меня не получилось.

Загадочной и пугающей настройкой является distributed_share.enable и связанные с ней скрытые настройки (SHIFT+F2). Есть подозрение, что в Bittorrent делают некое подобие социальной сети с элементами p2p…

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

[recovery mode] Работы по модернизации эксплорера в ReactOS завершены

сегодня в 14:25

Коммитом 66418 была фактически завершена основная часть работ по модернизации графической оболочки ReactOS, и теперь она очень сильно напоминает файловый эксплорер из Windows 2000.

После этого Giannis Adamopoulos посчитал работу над новым проводником в целом завершённой и закрыл баг-репрорт класса «эпик» CORE-7330. Основной разработчик новой оболочки, David Quintana, помимо контрактных денег получил ещё и постепенно собранные через Bountysource 100$.

На левый компьютер я поставил windows 2000, на правый — ReactOS.

Кстати, нескучные обои рабочего в ReactOS можно ставить уже не только в *.bmp формате, но и в форматах *.png и *.jpg

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

[recovery mode] Анонс MongoDB 3

Как-то незаметно прошел анонс новой версии MongoDB. Изменение номера версии с 2 на 3 указывает на значительные изменения внутри базы данных. Разработчики заявляют о значительном увеличении производительности и более лучшей маштабируемости. Немного подробнее под катом.





Непосредственно анонс был 3 февраля. Если коротко, то третья версия теперь использует по умолчанию отрытый движок хранения данных WiredTiger, который был основан и разработан доктором Майклом Кэхиллом (Dr Michael Cahill), который ранее внес вклад в развитие PostgreSQL, и Кейтом Бостик (Keith Bostic), который известен своим вкладом в развитии Unix. Использование нового ядра поможет лучше и быстрее реализовать новый функционал, избавиться от узких мест и выдерживать более высокие нагрузки. Также в новой версии предоставят новое API.

Интеграция с WiredTiger позволит использовать сжатие, блокировки на уровне записи, обработку транзакций с множеством документов и поддержки дерева слияния со структурой журнала (Log-Structured Merge-Trees, LSM), а также позволит управлять конкурентным доступом с помощью многоверсионности (MultiVersion Concurrency Control, MVCC).

Чтобы не быть голословным, по этой и этой ссылке можно посмотреть бенчмарки.

Если хочется пощупать сейчас, то на сайте mongodb.org на данный момент можно скачать 11 релиз — кандидат.

По этой ссылке можно узнать подробный changelog.

ВНИМАНИЕ!(на всякий пожарный) Это не финальная версия и поэтому разработчики очень просят не использовать текущую версию в продакшине.

UPDATE. Также пока что не поддерживается SSL шифрование

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

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Разбираемся с LCD экраном LPH9157-2 от Siemens C75/ME75

Внятной документации на этот экран я не нашел поэтому пришлось разбираться с тем что есть и экспериментировать. В качестве управляющего устройства я использовал Raspberry PI. Так-же была написана программа позволяющая превратить этот экран в мини-монитор.

Описание

Данный дисплей имеет разрешение 135 x 176 пикселей и даёт возможность работать с тремя цветовыми палитрами 16(6-5-6), 12(4-4-4) и 8(3-3-2) бит.

Распиновка и подключение

Тут всё просто, экран питается напряжением 2,9 вольт, подсветка (LED±) запитывается отдельно напряжением примерно 12 вольт(я использовал батарею аккумуляторов соединённую с подсветкой через резистор на 510 Ом).

Pin description
#	Name	Function
1	RS	Low=CMD, High=DATA
2	~RST	Reset input, active low
3	~CS	Chip select, active low
4	SYNC	External frame synchorization input, unused by default
5	CLK	SPI Clock-in signal (High-to-Low)
6	DATA	SPI Data-in signal (MSB first)
7	VCC	Power supply, normally 2.9V (I tested with 3.3V)
8	GND	Ground
9	LED+	Backlight voltage, approx. 12V (depends on required current)
10	LED-	Backlight common pin

Как можно заметить экран управляется через интерфейс SPI (контакты CS/CLK/DAT(MOSI)), предположительно это лишь половина интерфейса так как отсутствует контакт MISO, следовательно писать данные в экран мы можем, а вот читать — нет(здесь следует упомянуть что SPI может работать в двунаправленном режиме с использованием одного провода (MIMO) но так как отсутствует какие либо команды чтения данных из экрана будем считать что этот режим экраном не используется).

И перед тем как переходить непосредственно к управлению экраном надо бы этот экран к чему-нибудь подключить. В моём случае это будет Raspberry Pi. Контакты SPI экрана подключены к соответствующим им контактам SPI «малины», RS и RST к GPIO_17 и GPIO_27 соответственно. Данное подключение актуально для RPI Revision-2, если у вас иная модель то названия и номера контактов GPIO могут отличаться.

Заморачиваться с разъёмом подключения экрана я не стал и просто подпаялся к выводам проводом МГТФ. Экран в данном подключении питается от 3.3В, а не от 2.9 как в описании.

Вот так выглядит вся схема в сборе

Команды управления экраном

Экран управляется достаточно просто — путём посылки по SPI команд и данных. Отличить одни от других экрану помогает состояние пина RS где высокий уровень(лог. 1) означает передачу данных, а низкий(лог. 0) передачу команд. При передаче используется тупоконечный(big-ending) порядок байт.

Список команд:

• CMD_RESET 0x01 — программный сброс


• CMD_MEMORY_ACCESS_CONTROL 0x36 — установка направления заполнения области дисплея, имеет однобайтовый аргумент 0bVHRXXXXX, где
  
  V — заполнение по вертикали (0 — сверху-вниз, 1 — снизу-вверх),
  
  H — заполнение по горизонтали (0 — слева-направо, 1 — справа-налево),
  
  R — меняются местами строки и столбцы (при этом заполнение остается сверху-вниз, слева-направо))


• CMD_WAKEUP 0x11 — выход из спящего режима


• CMD_PALETTE 0x3A — установка цветовой палитры 8(0x02), 12(0x03) и 16(0x05) бит


• CMD_ENABLE 0x29 — включение дисплея


• CMD_SET_X 0x2A — задаем область рисования по X


• CMD_SET_Y 0x2B — задаем область рисования по Y


• CMD_START_WRITE 0x2C — начало записи в видеопамять

Код

Работа экрана была проверена во всех 3х цветовых режимах но, дабы не захламлять исходник, далее я буду рассматривать только 16-битный. Во всех остальных режимах работа экрана не отличается, за исключением, разве что 12-битного — в нём на 2 пикселя приходится 3 байта, а если нужно вывести лишь одну точку то посылается 2 байта(4 младших бита последнего экраном игнорируются).

Для доступа к GPIO «малины» была использована библиотека bcm2835.

Начальная инициализация GPIO

int init_gpio()
{
    if (!bcm2835_init())
        return 0;

    bcm2835_spi_begin();
    bcm2835_spi_setBitOrder(BCM2835_SPI_BIT_ORDER_MSBFIRST);

// CPOL = 0, CPHA = 0, Clock idle low, data is clocked in on rising edge, output data (change) on falling edge
    bcm2835_spi_setDataMode(BCM2835_SPI_MODE0);

// в телефоне экран работает на частоте SPI в 13 МГц
// поэтому небольшое превышение по частоте ему не повредит
// хотя у меня он продолжал работать и при вдвое большей частоте (30 МГц)
    bcm2835_spi_setClockDivider(BCM2835_SPI_CLOCK_DIVIDER_16);  ///< 16 = 64ns = 15.625MHz
    bcm2835_spi_chipSelect(BCM2835_SPI_CS0);                    /// Select Our Device
    bcm2835_spi_setChipSelectPolarity(BCM2835_SPI_CS0, LOW);

    // настроим порты на запись
    bcm2835_gpio_fsel(LCD_RS, BCM2835_GPIO_FSEL_OUTP);
    bcm2835_gpio_fsel(LCD_RESET, BCM2835_GPIO_FSEL_OUTP);

    return 1;
}

Несколько вспомогательных функций

void send_cmd(char cmd)
{
        bcm2835_gpio_write(LCD_RS, RS_CMD); // следующий байт - команда
        bcm2835_spi_transfer(cmd);
}

void send_data(char data)
{
        bcm2835_gpio_write(LCD_RS, RS_DATA); // следующий байт - данные
        bcm2835_spi_transfer(data);
}

Задание области рисования

void set_draw_area(char x1, char y1, char x2, char y2)
{
        send_cmd(CMD_SET_X);
        send_data(x1);
        send_data(x2);

        send_cmd(CMD_SET_Y);
        send_data(y1);
        send_data(y2);
}

В результате экспериментов с экраном выяснилось что необязательно задавать область перед выводом каждого кадра, достаточно задать её лишь единожды и послав команду начала записи просто гнать по SPI последовательность кадров непрерывным потоком.

Подготовка к выводу и передача данных

void draw_start()
{
        send_cmd(CMD_START_WRITE);
        bcm2835_gpio_write(LCD_RS, RS_DATA);
}

void send_draw_data(char* data, int size)
{
        bcm2835_spi_transfern(data, size);
}

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

Инициализация экрана

void reset_LCD()
{
        // аппаратный сброс
        bcm2835_gpio_write(LCD_RESET, LOW);
        bcm2835_delay(50);
        bcm2835_gpio_write(LCD_RESET, HIGH);
        bcm2835_delay(50);

        // программный сброс
        send_cmd(CMD_RESET);
}

void init_LCD()
{
        reset_LCD();

        send_cmd(CMD_MEMORY_ACCESS_CONTROL);
        send_data(0b00000000);

        send_cmd(CMD_WAKEUP);

        bcm2835_delay(20);

        send_cmd(CMD_PALETTE);
        send_data(_16_BIT_COLOR);

        bcm2835_delay(20);

        send_cmd(CMD_ENABLE);
}

Это была подготовка, а теперь самое вкусное — попробуем вывести на экран 16-битную картинку. Первый блин как известно — комом, после запуска программы я получил довольно странное изображение, оказалось — неверный порядок байт, после исправления всё заработало.

Код

int main(int argc, char **argv)
{
        if (!init_gpio())
                return 1;

        init_LCD();

        set_draw_area(0, 0, SCREEN_WIDTH - 1, SCREEN_HEIGHT - 1);
        draw_start();

        uint16_t screen[SCREEN_HEIGHT][SCREEN_WIDTH];

        FILE* f_scr = fopen("test.bmp", "r");
        fseek(f_scr, 0x42, SEEK_SET); // skip bmp header

        fread(&screen, 1, SCREEN_HEIGHT * SCREEN_WIDTH * 2/*16bit*/, f_scr);
        fclose(f_scr);

        // change byte order
        for(int x = 0; x < SCREEN_WIDTH; x++)
                for(int y = 0; y < SCREEN_HEIGHT; y++)
                        screen[y][x] = (screen[y][x] >> 8) | (screen[y][x] << 8);

        send_draw_data((char*)&screen[0][0], SCREEN_WIDTH*SCREEN_HEIGHT*2/*16 bit*/);

        close_gpio();
        return 0;
}

изображение до и после правок

LCD как монитор

С самого начала экспериментов меня не покидала мысль использовать экран как монитор для «малины», что я и поспешил реализовать.

Идея проста — изображение берётся из /dev/fb0, оно там как раз 16-битное, ресайзится и выдаётся на экран.

Так как результат сжатия картинки 1024x768 => 176x132 малоинформативен, для фреймбуфера было установлено разрешение 320x240, это можно сделать правкой config.txt на FAT разделе «малиновой» флешки.

framebuffer_width=320
framebuffer_height=240

После этого изображение всё равно жмётся с использованием примитивной интерполяции, но результат уже можно назвать приемлемым. Так-же был добавлен пропуск одинаковых кадров для экономии CPU.

Исходник LPH9157-2_RPI.c

#include <bcm2835.h>
#include <stdio.h>
#include <sys/mman.h>
#include <fcntl.h>

#include <time.h>
#include <string.h>
#include <unistd.h>

// соответствия контактов GPIO и LCD
#define LCD_RS RPI_V2_GPIO_P1_11
#define LCD_RESET RPI_V2_GPIO_P1_13

#define RS_CMD 0
#define RS_DATA 1

#define CMD_RESET 0x01
#define CMD_MEMORY_ACCESS_CONTROL 0x36 // Memory Access Control
#define CMD_WAKEUP 0x11 // Выход из спящего режима
#define CMD_PALETTE 0x3A // Установка цветовой палитры
#define CMD_ENABLE 0x29  //Включение дисплея

#define CMD_SET_X 0x2A // задаем область по X
#define CMD_SET_Y 0x2B // задаем область по Y
#define CMD_START_WRITE 0x2C // начало записи в память

#define _8_BIT_COLOR 0x02
#define _12_BIT_COLOR 0x03
#define _16_BIT_COLOR 0x05

#define SCREEN_WIDTH 132
#define SCREEN_HEIGHT 176

int init_gpio()
{
    if (!bcm2835_init())
        return 0;

    bcm2835_spi_begin();
    bcm2835_spi_setBitOrder(BCM2835_SPI_BIT_ORDER_MSBFIRST);
    bcm2835_spi_setDataMode(BCM2835_SPI_MODE0);                 /// CPOL = 0, CPHA = 0, Clock idle low,
                                                                /// data is clocked in on rising edge,
                                                                /// output data (change) on falling edge
    bcm2835_spi_setClockDivider(BCM2835_SPI_CLOCK_DIVIDER_16);  ///< 16 = 64ns = 15.625MHz
    bcm2835_spi_chipSelect(BCM2835_SPI_CS0);                    /// Select Our Device
    bcm2835_spi_setChipSelectPolarity(BCM2835_SPI_CS0, LOW);

    // настроим порты на запись
    bcm2835_gpio_fsel(LCD_RS, BCM2835_GPIO_FSEL_OUTP);
    bcm2835_gpio_fsel(LCD_RESET, BCM2835_GPIO_FSEL_OUTP);
    
    return 1;
}

int close_gpio()
{
    bcm2835_spi_end();
    bcm2835_close();
}

void send_cmd(char cmd)
{
    bcm2835_gpio_write(LCD_RS, RS_CMD);
    bcm2835_spi_transfer(cmd);
}

void send_data(char data)
{
    bcm2835_gpio_write(LCD_RS, RS_DATA);
    bcm2835_spi_transfer(data);
}

void send_data_array(char* data, int size)
{
    bcm2835_gpio_write(LCD_RS, RS_DATA);
    bcm2835_spi_transfern(data, size);
}

void set_draw_area(char x1, char y1, char x2, char y2)
{
    send_cmd(CMD_SET_X);
    send_data(x1);
    send_data(x2);

    send_cmd(CMD_SET_Y);
    send_data(y1);
    send_data(y2);
}

void draw_start()
{
    send_cmd(CMD_START_WRITE);
    bcm2835_gpio_write(LCD_RS, RS_DATA);
}

void send_draw_data(char* data, int size)
{
    bcm2835_spi_transfern(data, size);
}

void reset_LCD()
{
    bcm2835_gpio_write(LCD_RESET, LOW);
    bcm2835_delay(50);
    bcm2835_gpio_write(LCD_RESET, HIGH);
    bcm2835_delay(50);

    send_cmd(CMD_RESET);
}

void init_LCD()
{
    reset_LCD();

    send_cmd(CMD_MEMORY_ACCESS_CONTROL);
    send_data(0b00000000);

    send_cmd(CMD_WAKEUP);

    bcm2835_delay(20);

    send_cmd(CMD_PALETTE);
    send_data(_16_BIT_COLOR);

    bcm2835_delay(20);

    send_cmd(CMD_ENABLE);
}

#define FB_WIDTH 320// 176
#define FB_HEIGHT 240// 144

int main(int argc, char **argv)
{
    if (!init_gpio())
        return 1;

    int smooth = 0;
    int dynamic_fps = 0;
    int argn = 1;
    while(argn < argc)
    {
        if(argv[argn][0] == '-')
            switch(argv[argn][1])
            {
            case 'i':
                init_LCD();
                close_gpio();
                printf("lcd initialized\n");
                return 0;
                break;

            case 's':
                smooth = 1;
                break;
            case 'd':
                dynamic_fps = 1;
                break;
            default:
                printf("Usage: lcd [options]\n");
                printf("Options:\n");
                printf("  -i   initialize lcd (hardware reset)\n");
                printf("  -d   dynamic FPS (skip same frames)\n");
                printf("  -s   smooth image (enable basic intrpolation)\n");
                return 0;
                break;
            }
        argn++;
    }

    ///------------------------------------------------
    /// draw screen

    set_draw_area(0, 0, SCREEN_WIDTH - 1, SCREEN_HEIGHT - 1);
    draw_start();
    
    uint16_t screen[SCREEN_HEIGHT][SCREEN_WIDTH];

    uint16_t old_fb[FB_HEIGHT * FB_WIDTH];

    int fd_scr = open("/dev/fb0", O_RDONLY);
    int scr_sz = FB_HEIGHT * FB_WIDTH * 2/*16bit*/;
    uint16_t* fb_screenshot = mmap(0, scr_sz, PROT_READ, MAP_PRIVATE, fd_scr, 0);

    // scaling
    float scale_X = FB_HEIGHT / (float)SCREEN_WIDTH;
    float scale_Y = FB_WIDTH / (float)SCREEN_HEIGHT;

    int frame_cnt = 0;
    struct timespec ts1, ts2;
    clock_gettime(CLOCK_MONOTONIC, &ts1);

    for(;;) // forever
    {
        if(dynamic_fps)
            if(memcmp(&old_fb, fb_screenshot, sizeof(old_fb)) == 0)
            {
                usleep(10000);
                continue;
            }
            else
            {
                memcpy(&old_fb, fb_screenshot, sizeof(old_fb));
            }

        for(int x = 0; x < SCREEN_WIDTH; x++)
            for(int y = 0; y < SCREEN_HEIGHT; y++)
            {
                int fb_x = y * scale_X;
                int fb_y = x * scale_Y;

                uint16_t px = fb_screenshot[fb_x + fb_y * FB_WIDTH];

                if(smooth)
                {
                    // look around
                    if((fb_x - 1 >= 0) && (fb_x + 1 < FB_WIDTH) && (fb_y - 1 >= 0) && (fb_y + 1 < FB_HEIGHT))
                    {
                        for(int dx = -1; dx <= 1; dx++)
                            for(int dy = -1; dy <= 1; dy++)
                                if((dx == 0) ^ (dy == 0))
                                {
                                    uint16_t add_px = fb_screenshot[(fb_x + dx) + (fb_y + dy) * FB_WIDTH];
                                    px = ((px & 0xf7de) >> 1) + ((add_px & 0xf7de) >> 1);
                                    /// ^thank you habr => http://ift.tt/1vIjXyi
                                }
                    }
                }
                screen[y][SCREEN_WIDTH - 1 - x] = (px << 8) | (px >> 8);
            }

        send_draw_data((char*)&screen[0][0], sizeof(screen));

        /// calc fps
        frame_cnt++;
        if(frame_cnt >= 100)
        {
            clock_gettime(CLOCK_MONOTONIC, &ts2);

            float allsec = (ts2.tv_sec - ts1.tv_sec) + (ts2.tv_nsec - ts1.tv_nsec) / 1000000000.0;
            float fps = frame_cnt / allsec;

            printf("%f FPS\n", fps);

            frame_cnt = 0;
            clock_gettime(CLOCK_MONOTONIC, &ts1);
        }

        usleep(1000);
    }

    munmap(fb_screenshot, scr_sz);
    close(fd_scr);
    close_gpio();

    printf("fin\n");    
    return 0;
}

Сборка:

pi@raspberrypi ~ $ gcc -o lcd LPH9157-2_RPI.c -lbcm2835 -lrt -std=gnu99

Запуск:

pi@raspberrypi ~ $ sudo ./lcd -i
pi@raspberrypi ~ $ sudo ./lcd -d -s

параметры:

-i — первичная инициализация (дёргаем хардварный reset)

-s — включить сглаживание

-d — динамический fps (одинаковые кадры пропускаются — экономит CPU)

Результат

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

[Перевод] Практика функционального программирования на JavaScript с использованием Ramda

Мы в rangle.io давно увлекаемся функциональным программированием, и уже опробовали Underscore и Lodash. Но недавно мы наткнулись на библиотеку Ramda, которая на первый взгляд похожа на Underscore, но отличается в небольшой, но важной области. Ramda предлагает примерно тот же набор методов, что и Underscore, но так организовывает работу с ними, что функциональная композиция становится легче.

Разница между Ramda и Underscore – в двух ключевых местах – каррирование и композиция.

Каррирование

Каррирование – превращение функции, ожидающей несколько параметров в такую, которая при передаче ей меньшего их количества возвращает новую функцию, которая ждёт остальные параметры.

R.multiply(2, 10); // возвращает 20

Мы передали функции оба параметра.

var multiplyByTwo = R.multiply(2);
multiplyByTwo(10); // возвращает 20

Круто. Мы создали новую функцию multiplyByTwo, которая по сути – 2, встроенная в multiply(). Теперь можно передать любое значение в нашу multiplyByTwo. И возможно это потому, что в Ramda все функции поддерживают каррирование.

Процесс идёт справа налево: если вы пропускаете несколько аргументов, Ramda предполагает, что вы пропустили те, что справа. Поэтому функции, принимающие массив и функцию, обычно ожидают функцию как первый аргумент и массив как второй. А в Underscore всё наоборот:

_.map([1,2,3], _.add(1)) // 2,3,4

Против:

R.map(R.add(1), [1,2,3]); // 2,3,4

Комбинируя подход «сначала операция, затем данные» с каррированием «справа налево» позволяет нам задать то, что нам надо сделать, и вернуться к функции, которая это сделает. Затем мы можем передать этой функции нужные данные. Каррирование становится простым и практичным.

var addOneToAll = R.map(R.add(1));
addOneToAll([1,2,3]); // возвращает 2,3,4

Вот пример посложнее. Допустим, мы делаем запрос к серверу, получаем массив и извлекаем значение стоимости (cost) из каждого элемента. Используя Underscore, можно было бы сделать так:

return getItems()
  .then(function(items){
    return _.pluck(items, 'cost');
});

Используя Ramda можно удалить лишние операции:

return getItems()
    .then(R.pluck('cost'));

Когда мы вызываем R.pluck('cost'), она возвращает функцию, которая извлекает cost из каждого элемента массива. А именно это нам и надо передать в .then(). Но для полного счастья необходимо скомбинировать каррирование с композицией.

Композиция

Функциональная композиция – это операция, принимающая функции f и g, и возвращающая функцию h такую, что h(x) = f(g(x)). У Ramda для этого есть функция compose(). Соединяя два этих понятия, мы можем строить сложную работу функций из меньших компонентов.

var getCostWithTax = R.compose(
    R.multiply(1 + TAX_RATE), // подсчитаем налог
    R.prop('cost') // вытащим свойство 'cost' 
);

Получается функция, которая вытаскивает стоимость из объекта и умножает результат на 1.13

Стандартная функция “compose” выполняет операции справа налево. Если вам это кажется контринтуитивным, можно использовать R.pipe(), которая работает, R.compose(), только слева направо:

var getCostWithTax = R.pipe(
    R.prop('cost'), // вытащим свойство 'cost' 
    R.multiply(1 + TAX_RATE) // подсчитаем налог
);

Функции R.compose и R.pipe могут принимать до 10 аргументов.

Underscore, конечно, тоже поддерживает каррирование и композицию, но они там редко используются, поскольку каррирование в Underscore неудобно в использовании. В Ramda легко объединять эти две техники.

Сначала мы влюбились в Ramda. Её стиль порождает расширяемый, декларативный код, который легко тестировать. Композиция выполняется естественным образом и приводит к коду, который легко понимать. Но затем…

Мы обнаружили, что вещи становятся более запутанными при использовании асинхронных функций, возвращающих обещания:

var getCostWithTaxAsync = function() {
    var getCostWithTax = R.pipe(
        R.prop('cost'), // вытащим свойство 'cost' 
        R.multiply(1 + TAX_RATE) // умножим его на 1.13
    );

    return getItem()
        .then(getCostWithTax);
}

Конечно, это лучше, чем вообще без Ramda, но хотелось бы получить что-то вроде:

var getCostWithTaxAsync = R.pipe(
    getItem, // получим элемент
    R.prop('cost'), // вытащим свойство 'cost' 
    R.multiply(1 + TAX_RATE) // умножим на 1.13
);

Но так не получится, поскольку getItem() возвращает обещание, а функция, которую вернула R.prop(), ожидает значение.

Композиция, рассчитанная на обещание

Мы связались с разработчиками Ramda и предложили такую версию композиции, которая бы автоматом разворачивала обещания, и асинхронные функции можно было бы связывать с функциями, ожидающими значение. После долгих обсуждений мы договорились на реализации такого подхода в виде новых функций: R.pCompose() и R.pPipe() – где “p” значит “promise”.

И с R.pPipe мы сможем сделать то, что нам нужно:

var getCostWithTaxAsync = R.pPipe(
    getItem, // получим обещание
    R.prop('cost'), // вытащим свойство 'cost'
    R.multiply(1 + TAX_RATE) // умножим на 1.13
); // возвращает обещание и cost с налогом

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

[Перевод] Создаём своё первое десктопное приложение при помощи HTML, JS и Node-WebKit

В наше время при помощи JavaScript и HTML можно сделать практически всё. А благодаря Node-WebKit (недавно переименован в NW.js) можно делать даже десктопные приложения, которые выглядят, как нативные и имеют доступ ко всем частям ОС. Сегодня мы покажем, как создать простое десктопное приложение при помощи Node-WebKit, используя jQuery и несколько модулей для Node.js.

Node-WebKit — комбинация Node.js и встроенного браузера WebKit. Код JavaScript выполняется в особом окружении, из которого есть доступ и к стандартному API браузеров, и к Node.js.

Устанавливаем Node-WebKit

Для разработки нужно скачать исполняемый файл node-webkit и вызывать его из командной строки. Позже всё вместе упакуется в одну программу, которая будет запускаться пользователем.

Скачайте файлы, подходящие для вашей системы, и распакуйте их в подходящее место. Запускать их нужно так:

# если у вас linux/osx

/path/to/node-webkit/nw /your/project/folder

# если у вас windows

C:\path\to\node-webkit\nw.exe C:\your\project\folder

# (пути указаны только для примера)

Откроется новое окно node-webkit, в которое будет выведено множество отладочных сообщений.

Первое приложение

Мы подготовили для вас тестовое приложение для примера. Оно скачивает последние статьи с Tutorialzine и делает из них карусельку при помощи jQuery Flipster.

структура каталогов

В архиве содержатся вышеуказанные файлы. Выглядят они как статический сайт, но работать в браузере при запуске index.html не будут – им нужны модули Node.js. Для запуска воспользуйтесь командой

/path/to/node-webkit/nw .

Она и запустит наше превосходное приложение.

Как это сделано

Всё начинается с файла package.json, который node-webkit ищет при запуске. Там описано, что нужно загружать и даны разные настройки окна.

package.json

{
  "name": "nw-app",
  "version": "1.0.0",
  "description": "",
  "main": "index.html",
  "scripts": {
    "test": "echo \"Ошибка: тест не задан\" && exit 1"
  },
  "author": "",
  "window": {
    "toolbar": false,
    "width": 800,
    "height": 500
  },
  "license": "ISC",
  "dependencies": {
    "pretty-bytes": "^1.0.2"
  }
}

В свойстве window описана необходимость открыть окно размера 800 х 500 пикселей и спрятать у него тулбар. В него загрузится файл из свойства main. У нас это

index.html

<!DOCTYPE html>
<html>
<head>

    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">

    <title>Tutorialzine Node-Webkit Experiment</title>

    <link rel="stylesheet" href="./css/jquery.flipster.min.css">
    <link rel="stylesheet" href="./css/styles.css">

</head>
<body>

    <div class="flipster">
        <ul>
            <!-- Tutorialzine's latest articles will show here -->
        </ul>
    </div>

    <p class="stats"></p>

    <script src="./js/jquery.min.js"></script>
    <script src="./js/jquery.flipster.min.js"></script>
    <script src="./js/script.js"></script>
</body>
</html>

И наконец, наш файлик с JavaScript. Вот где самое интересное.

// Смешать в одном файле код jQuery и Node.js? Да не вопрос!

$(function(){

    // Показать данные о компьютере, используя модуль os 

    var os = require('os');
    var prettyBytes = require('pretty-bytes');

    $('.stats').append('Number of cpu cores: <span>' + os.cpus().length + '</span>');
    $('.stats').append('Free memory: <span>' + prettyBytes(os.freemem())+ '</span>');

    // Нативная библиотека Node webkit для UI. Понадобится попозже
    var gui = require('nw.gui');

    // Загрузить последние посты с Tutorialzine

    var ul = $('.flipster ul');

    // Ограничений на запрос данных с других доменов нет, поэтому
    // мы можем отправить ajax-запрос на другой сайт.

    $.get('http://ift.tt/Ok5owE', function(response){

        var rss = $(response);

        // Найдём статьи в RSS фиде

        rss.find('item').each(function(){
            var item = $(this);
            
            var content = item.find('encoded').html().split('</a></div>')[0]+'</a></div>';
            var urlRegex = /(http|ftp|https):\/\/[\w\-_]+(\.[\w\-_]+)+([\w\-\.,@?^=%&:/~\+#]*[\w\-\@?^=%&/~\+#])?/g;

            // Загрузим первую картинку из статьи
            var imageSource = content.match(urlRegex)[1];

            // Создадим li для каждой статьи и добавим в ненумерованный список

            var li = $('<li><img /><a target="_blank"></a></li>');

            li.find('a')
                .attr('href', item.find('link').text())
                .text(item.find("title").text());

            li.find('img').attr('src', imageSource);

            li.appendTo(ul);

        });

        // Инициализируем плагин flipster 

        $('.flipster').flipster({
            style: 'carousel'
        });

        // По клику на карусельке откроем страницу в дефолтном браузере.
        // Иначе она открылась бы в нашем окне, а нам это не надо.

        $('.flipster').on('click', 'a', function (e) {

            e.preventDefault();
            
            // откроем URL в дефолтном браузере
            gui.Shell.openExternal(e.target.href);

        });

    });

});

В браузере нельзя получить доступ к информации на другом домене через jQuery. Но node-webkit убирает эти ограничения.

Использованные модули:

• Shell – модуль node webkit для работы с десктопом


• OS – встроенный в Node.js модуль. Умеет возвращать объём свободной системной памяти


• Pretty Bytes – преобразует байты в человеко-читаемые строки 1337 → 1.34 kB.

Также есть jQuery и плагин jQuery-flipster. И всё!

Пакуем и распространяем

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

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

Есть и минус – исполняемые файлы получаются уж очень большими (бывает, что и 40-50 Мб), поскольку в них упихивается и браузер webkit и node.js, и ваш код. Возможно, для создания простых небольших десктопных приложений это не идеальный вариант.

Заключение

Node-webkit – мощная штучка, открывающая новые возможности для веб-разработчиков. С её помощью можно создавать вспомогательные приложения для ваших веб-сервисов и делать десктопные клиенты, у которых будет полный доступ к компьютеру пользователя. Подробнее о node-webkit читайте в их wiki.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Блог департамента информационных технологий города Москвы на «Хабрахабре»

Привет, Хабр! Вот, наконец, и мы как часть большого и не самого поворотливого механизма дошли до того, чтобы завести тут свой блог.

Вообще, мы довольно давно думали над этим и присматривались к вашим дискуссиям, но решающим событием стала публикация про «несанкционированный» доступ к тысячам московских камер, мы поняли, что лучше с этим не тянуть и включиться в диалог. Можно спорить о правомерности способа получения информации с камер, однако, как мы уже писали, открытие доступа к камерам было в наших планах.

Раз заговорив, уже трудно остановиться. Тем более, что из разгоревшейся дискуссии мы поняли, что жители «Хабрахабра» к жизни города неравнодушны, и что мы как ИТ-департамент можем и должны взаимодействовать с людьми, которые сами тесно связаны с ИТ и готовы помочь сделать наши сервисы лучше, по меньшей мере, чтобы за город не было стыдно, а в идеале – чтобы было чем гордиться и чем похвастаться перед друзьям-иностранцами.

Поэтому в самое ближайшее время мы запустим с «Хабрахабром» совместный спецпроект, на котором можно будет протестировать, а может – и попробовать поломать, доступ к 120 тыс. городских камер через наш новый сервис video.mos.ru. А пока все желающие могут оставить свою почту на стартовой странице, чтобы получить приглашение в числе первых. Инвайтов совсем немного.

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

Спасибо за внимание, ждем в комментариях!

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Качество сетей передачи данных. Транспорт

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

Среда передачи

Начну, пожалуй, с последнего пункта — качества среды передачи. Как уже написано выше, про нее ничего не говорилось в предыдущем повествовании, поскольку само по себе количество сред и их характеристики очень сильно различаются и зависят от просто колоссального множества факторов. Разбираться во всем этом многообразии задача соответствующих специалистов. Всем очевидно использование радио-эфира в качестве среды передачи данных. Я же помню в конце 90-х начале 00-х особой популярностью у операторов связи стали пользоваться такие экзотические способы передачи, как лазерные атмосферные передатчики. Выглядели они, в зависимости от производителя и конфигурации примерно как на картинке слева (да, почти такой себе светотелефон из радиолюбительского детства). Преимущество их было в том, что не надо было получать разрешение ГРКЧ, да и скорости, по сравнению с радиомостом были несколько больше, кроме того существовали модификации для организации каналов с временным разделением (E1 и т.п.), а подобное оборудование радио-доступа стоило непомерно дорого. Почему не оптический кабель? Потому что в те счастливые времена дикого провайдинга оптика еще была довольно дорогой, а за конвертер интерфейса или активное оборудование, способное принять оптический линк напрямую давали небольшой (а кто-то и большой) брусок золота. Были еще спутниковые каналы, но это вообще из области фантастики и позволить их себе могли разве что компании нефтяного сектора и прочего национального благосостояния. Но работа канала через спутник сводится к использованию радио-эфира, со всеми вытекающими и внесением огромной задержки.

Соответственно погружаясь в вопрос в результате будем иметь множество сред и ни одной обобщенной характеристики. Тем не менее для нас среда это всего лишь транспорт, передающий информацию из точки А в точку Б. А для транспорта (даже общественного) характеристикой отражающей его качество будет доставка всех битов (ну или пассажиров) без искажений и потерь (не хотелось бы лишиться части тела при перевозке, согласитесь). Т.е. мы приходим к такой обобщенной метрике качества транспорта как количество битовых ошибок, или BER (Bit error rate). В чисто пакетных сетях она практически не используется, поскольку ошибки передачи выявляются на уровне пакета, например подсчетом контрольных сумм: FCS (Frame check sequence) для L2 или сhecksum IP для L3. Если контрольная сумма не совпадает, то пакет целиком отбрасывается как невалидный. Если же рассмотреть гетерогенные сети, те в которых транспортом может служить непакетная сеть, а, например, один из вариантов описанных выше, либо вообще используется транзит через ATM, PDH, SDH и подобное без непосредственной (но с восстановлением) передачи пакета, то битовые ошибки транспорта могут значительно влиять, конечно в зависимости от технологии. Рассмотрим инкапсуляцию и передачу Ethernet-фрейма в HDLC. Другие технологии используют практически такую же технику.

Схема читается слева-направо (взята здесь).

1. Какой-то узел сети А отправляет пакет в сторону какого-то узла сети Б


2. Транспорт между сетями построен на сети PDH


3. Узел на границе выхода сети А вырезает из Ethernet-фрейма область полезной нагрузки (поля от DestinationAddress до FCS включительно), оборачивает в HDLC заголовки, и отправляет на граничный узел входа сети Б


4. Граничный узел входа сети Б выделяет область полезной нагрузки и восстанавливает Ethernet-фрейм


5. Фрейм с граничного узла отправляется получателю

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

Но не всегда используется надстройка инкапсуляции, либо передается вообще не полноценный фрейм, а лишь поле payload. Т.е. вырезается область, оборачивается во внутренний протокол, а на другой стороне восстанавливаются недостающие данные, включая отсутствующие заголовки L2. Соответственно пропадает и FCS — она просто рассчитывается заново. Таким образом получается, если данные были повреждены, а FCS рассчитан на основании “испорченных” данных, то получатель принимает совсем не тот пакет, который ему отправляли. Это довольно часто встречается в спутниковой связи, чтобы повысить полезную утилизацию канала, избегая передачи условно “лишней” информации. Резюмируя, получается что метрика BER может быть интересна в случаях когда:

• необходимо проверить стабильность физического канала, например для оптики это 10E-12 (упоминается в IEEE802.3)


• Ethernet-фреймы упаковывают в SDH(GFP), PDH, ATM и другие транспортные сети.


• используются технологии xHSL, PPP протоколы в которые упаковывают IP пакеты

BER тест

Метрика известна — это отношение количество битовых ошибок к общему числу переданных битов. Методика измерения для сетей TDM известна как спецификация ITU-T G.821. Классически для проверки каналов используется BERT (BER Test) первого уровня, но с учетом специфики работы протоколов инкапсуляции пакетных сетей и самого принципа работы пакетных сетей необходимо иметь возможность проводить тесты на L1-L4. Немного далее будет рассмотрено подробнее. Ну а сейчас следует определиться что проверять и как проверять. На вопрос:” Что проверять?” Отвечает ITU-T 0.150. В его пункте 5 рассмотрены типы ПСП (псевдослучайных последовательностей), из которых просто берутся данные для формирования пакета. Т.е. нужно просто взять и заполнить соответствующий уровень пакета данными выбранной ПСП. У нас в приборах используются следующие ПСП:

• ПСП 2е9 (ITU-T 0.150 пункт 5.1)


• ПСП 2е11 (ITU-T 0.150 пункт 5.2)


• ПСП 2е15 (ITU-T 0.150 пункт 5.3)


• ПСП 2е23 (ITU-T 0.150 пункт 5.6)


• ПСП 2е31 (ITU-T 0.150 пункт 5.8)


• пользовательская последовательность (32 бита)


• все нули


• все единицы


• альтернативная последовательность (01010101)

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

Вопрос как проверять пока что открыт, попробуем разобраться. Допустим мы умеем генерировать определенные пакеты. Если отправить такой пакет на другой конец транспорта, то как понять, что он не изменился (следует абстрагироваться от пакетного принципа, поскольку у нас может не быть FCS и других типов контроля, как описано ранее)? Самый простой вариант — завернуть пакет обратно (в TDM называется “сделать петлю”, в Ethernet — установить шлейф). Заворот, во многих случаях, можно сделать на выходе канала без изменения среды передачи, т.е. реально поставить петлю на выходе E1 и все будет работать. Но т.к. данные проделывают двойной путь, то вероятность возникновения ошибки также возрастает в 2 раза. Да и каналы могут быть асимметричными или однонаправленными. Соответственно идеальным было бы иметь возможность обладать информацией о корректном следовании и сравнивать приходящие пакеты с уже известной информацией. Первый, и наиболее простой вариант, применимый когда оба выхода канала располагаются рядом (например такое возможно при TDM коммутации, или тестировании оптического “кольца”) заключается в том, что один порт прибора генерирует тестовый трафик, а другой порт этого же прибора его получает и сравнивает, а т.к. сравнение происходит в том же узле, что и генерация, то проблем со сравнением данных последовательности не возникает. Второй вариант предполагает восстановление первоначальной последовательности и сравнение ее с приходящими данными. В случае с полностью случайной последовательностью реализовать такое не представляется возможным, а вот если последовательность псевдослучайная, то вполне. Какое-то время затрачивается на синхронизацию в самом начале теста, но затем сравнение не представляет сложности. Поскольку ПСП первого прибора и ПСП второго известны и одинаковы, синхронизация сводится к поиску места начала сравнения в ПСП второго прибора. Таким образом существуют следующие топологии:

1. «сам на себя» 1 — один прибор на одном порту, на другом конце транспорта стоит шлейф


2. «сам на себя» 2 — один прибор с одного порта своего порта на другой свой порт


3. с одного прибора на другой прибор, с синхронизацией

Еще раз стоит отметить, что тест BER не рекомендуется использовать на сетях лишь с пакетной коммутацией. Приведу пример. Допустим, уже идет тестовый поток и приборы синхронизированы (топология 3). В какой-то момент времени происходит следующее:

1. формируется Ethernet-фрейм, содержащий данные ПСП


2. для такого фрейма рассчитывается FCS и он укладывается в выходной буфер


3. фрейм отправляется по сети на другой прибор


4. по каким-то причинам происходит изменение всего одного бита внутри пакета


5. получатель принимает пакет


6. FCS принятого пакета не соответствует содержимому


7. пакет отбрасывается (если между отправителем и получателем есть, например, коммутатор, то “кривой” пакет вообще не дойдет до получателя, т.к. будет уничтожен до него)


8. отправитель формирует следующий пакет (все начинается с п.1)

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

А как в железе?

Как у других не знаю, но у наших приборов Беркут (ET, ETX, ETL, B100, а также модуль B5-GBE для MMT) дела обстоят следующим образом. Помня принцип о генерации и анализе трафика как можно ближе к физическому сегменту из первой статьи, все подобные задачи были возложены на FPGA. Упрощенная структурная схема выглядит так:

MAC ядро представлено двумя блоками: один на прием, другой на передачу. Это позволяет независимо принимать и отправлять пакеты, т.е. нет взаимовлияния очереди отправки на очередь приема и наоборот. Также с двух независимых блоков возможно вести общую статистику по полученному и отправленному трафику независимо от типа теста. Данные с блока передачи поступают на трансмиттер и отправляются в сеть, а входящие данные с трансивера поступают в блок приема.

Поскольку для некоторых топологий тестов необходим функционал шлейфа (loopback, петля), то он реализован отдельным блоком. Возможно установить шлейф уровня L1-L4:

• L1 — просто заворачивает трафик обратно (происходит это еще в трансивере)


• L2 — меняет DstMAC<->SrcMAC местами, пересчитывает FCS


• L3 — меняет DstMAC<->SrcMAC и DstIP<->SrcIP местами, пересчитывает FCS


• L4 — меняет DstMAC<->SrcMAC, DstIP<->SrcIP и DstPort<->SrcPort, пересчитывает FCS

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

Модуль генератора для каждого типа теста свой, для BERT он содержит генератор ПСП всех заявленных типов.

Работает это следующим образом. От генератора ПСП поступают данные на мультиплексор (проще говоря коммутатор), который, если не включен какой-то другой канал в данный момент, направляет поток в MAC tx модуль. MAC tx модуль, в соответствии с настройками теста (уровень BERT, размер пакета, данные полей) формирует из ПСП валидный Ethernet-фрейм и отправляет его в трансивер, который в свою очередь отправляет его в сеть. В зависимости от топологии теста фрейм либо заворачивается удаленной стороной, либо анализируется. В любом случае первичная обработка пакета не отличается. Фрейм попадает на MAC rx ядро, которое отправляет его на мультиплексор. Мультиплексор в зависимости от режима работы прибора направляет пакет либо в Loopback модуль, откуда после обработки он сразу же направляется в MAC tx для отправки, либо в модуль обработки и статистики теста, где, если потребуется, будет проведена попытка синхронизации ПСП и выполнено сравнение исходной последовательности с полученной. Результаты обработки отдаются в модуль вывода статистики.

Использование FPGA или ASIC позволяет все операции проводить параллельно, что не вносит какие либо задержки на обработку и исключает взаимовлияние модулей обработки.

Заключение

Несмотря на всю кажущуюся простоту алгоритмов и методик, за ними стоит много лет серьезных исследований. Огромное число факторов до сих пор влияет как на точность измерений, так и на стоимость приборов (прецизионные элементы, высокоскоростные ПЛИС). Например, приведенный выше BER тест не отличается значительной сложностью в общем алгоритмическом плане, но требует знаний в области математики, информатики и теории информации для разработки жизнеспособной модели. Модификация BER теста для пакетных сетей (поддержка уровней L2-L4) требует глубокого понимания принципов коммутации и маршрутизации. Надеюсь, что подобного рода статьи интересны и приносят пользу. В следующих публикациях планирую написать про сертифицированные тесты, генераторы трафика, фильтры и аналитические комплексы. Ведь как сказал Джон Фицджеральд Кеннеди на выступлении перед гражданами США перед стартом Лунной программы:

“И мы сделаем это. Не потому, что это легко, а потому что трудно.”

_{PS. Задавайте вопросы и предлагайте темы, в рамках нашей компетенции готовы на все :)}

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

[Из песочницы] Светодиоды, ленты и их питание от ЭТ переменного тока

Наверное, не ошибусь, если скажу, что более 90% жителей России знающих, что такое светодиодные ленты, на вопрос «можно ли трансформаторы от „галогенок“ использовать для питания светодиодных лент?» ответят «нет, нельзя!». Самым распространенным объяснением станет банальное «электронный трансформатор – это переменный ток, а светодиодам нужен постоянный». Именно так нам говорят в магазинах, именно такой лейтмотив имеют подавляющее большинство «профессиональных» статей на эту тему, чем, в общем-то, и приучили людей тратить заметно больше денег.

Всегда ли это оправдано и как на самом деле ведут себя светодиоды в самых распространенных СД лентах при питании переменным током мы и попробуем узнать в процессе изложения чтения этой статьи.

Сразу оговорюсь, что для обозначения «светодиод» я и далее буду применять само собой напрашивающееся и вполне естественное сокращение СД и намеренно не буду использовать для этого понятия английскую техническую аббревиатуру LED (Light Emitting Diode). В нашей нынешней стране отсутствие какой либо должной технической подготовки менеджеров и продавцов в магазинах уже привело к замусориванию и появлению таких неестественных для технического языка, юродивых для слуха и ужасных в написании буквосочетаний «леды», «led’ы», «ледовые», или как недавно увидел бегущей строкой — «LEDовые светодиоды». Мало того, что «масло – масляное», я просто вторить и плодить это «словомутие» не хочу…

Её идейным источником стало давнее желание опровергнуть необоснованные и безаппеляционные утверждения подавляющего большинства продавцов электротехники в России о недопустимости питания светодиодных лент (СД лент) от 12-ти вольтовых электронных трансформаторов (ЭТ) переменного тока, предназначенных для питания так называемых «галогенок». В общем-то спорность этого утверждения наверняка бросается в глаза любому специалисту (а равно и «неспециалисту»), понимающему, что светодиод, хоть и излучает свет, есть прежде всего – ДИОД. А это значит, что излучать под воздействием переменного напряжения он все же будет, но только в свой полупериод.

По сути, нам необходимо будет последовательно ответить на три вопроса:

1) Сможет ли ЭТ «запуститься» при подключении нагрузки в виде полупроводниковых диодов;

2) Если ЭТ запустится, не превысит ли импульсное «переменное» электрическое воздействие допустимых параметров отдельных СД в лент. Если все же превысит, то как долго протянет СД в таких условиях;

3) Какова экономическая эффективность от использования ЭТ в конструкциях освещения на светодиодных лентах.

Итак, полгода назад у меня как раз подвернулся удобный для экспериментов случай.

Мне нужно было осветить пространство в ящиках и тумбах столов моей мастерской. После оборудования кухни в моем распоряжении осталось 1,2 метра одноцветной СД ленты общей мощностью около 17 Вт (Aztech 14Ватт/метр) и один электронный трансформатор от «галогенок» — EAC 12V 20-60Вт, самый распространенный и дешевый, купленный за 74 рубля в декабре 2014 года. Для начала, чтобы запустить ЭТ, я нагрузил его обыкновенной галогеновой лампой 20 Вт и затем параллельно подключил все 1,2 метра ленты (Рис. 1). Как и ожидалось, лента зажглась. При этом свечение ленты было равномерным, средней яркости, без какого либо заметного глазу мерцания, что неудивительно, т.к. выходной меандр ЭТ промодулирован по амплитуде малозаметной глазу частой 100Гц. В ходе эксперимента отключение лампы в такой схеме тут же приводило к прекращению свечения СД ленты, что говорило о невозможности запуска ЭТ на одной полуволне напряжения. Тогда я разбил ленту на два участка и включил их встречно-параллельно (Рис.2), что по замыслу должно было обеспечить работу выходного каскада ЭТ на обоих полупериодах. При этом, что бы исключить перекос токов противоположного направления и перегрев выходной обмотки ЭТ от появление постоянной составляющей, я обеспечил равенство (по 8 Вт) количества СД в обоих плечах нагрузки. Сразу после подключения по такой схеме (Рис.2) трансформатор благополучно вышел на режим генерации, а обе светодиодные ленты равномерно зажглись и были оставлены на 1 час, за который ни они, ни сам ЭТ совершенно не нагрелись, что свидетельствовало скорее о вполне нормальных электрических режимах, чем нет.

Итак, ответ на первый вопрос, — запустится ли ЭТ при замене галогеновых ламп на светодиод – положительный. Да, запустится! Если обеспечить встречно-параллельное включение лент как на Рисунке 2.

И забегая вперед ...

Забегая вперед, скажу, что как показал дальнейший эксперимент, ЭТ с паспортной минимальной мощностью запуска в 20 Вт, благополучно запускался даже при 10 Вт суммарной светодиодной нагрузки (по 5 Вт в каждом плече).

Идем дальше. Теперь пробуем найти ответ на второй вопрос нашего исследования. Но сейчас нам одних опытов мало, потребуется знание из ТЭРЦиЭ (Теории электро-радиоцепей и элементов), которое в итоге позволит нам предположить: можно ли долговременно питать СД ленты в таком режиме без серьезного ущерба для их долговечности, если вообще рассуждать об ущербе?

Начнем с устройства СД ленты. Лента состоит из соединенных параллельно рабочих участков (Рис.3) из трех излучателей ( обозначены на схеме — E) представляющих собой три отдельных светодиода под общим слоем люминофора. Каждый диод (на схеме — D) излучателя последовательно соединен в триады с диодами из других излучателей и резистором, устанавливающим расчетную рабочую точку диодов (См. Рис. 4).

Резистор в триаде подобран таким образом, что бы при питании от 12 В и расчетной рабочей точке диода Uпр =3,3 В, Iпр = 14 мА на нем гасился избыток напряжения около 2 Вольт.

Между прочим, интересно...

Такая компоновка триады надежна и практична, ибо в случае выхода из строя одиночного СД в триаде, ни один из излучателей полностью не отключится, а продолжит гореть, хоть и с меньшей на треть яркостью. Можно конечно создать триаду на базе одиночного излучателя (и такие ленты встречаются в продаже). В них, рабочим участком определяющим её нарезку будет фрагмент с одиночным излучателем и резистором, но в таком случае, выход из строя одиночного СД в триаде приведет к потере свечения целым излучателем, что будет сразу заметно в любом светильнике.

Покопавшись у производителей SMD светодиодов несложно найти и электрические параметры примененных СД:

Для полноты полученного исследования я дополнительно снял вольтамперную характеристику (ВАХ) рабочего участка ленты (Рис.5), а и путем несложного пересчета получил ВАХ для отдельного СД (Рис.6).

Надеюсь вы...

Надеюсь вы не сомневаетесь, что это можно было сделать и физически, и результаты бы совпали.

Рис.5

Рис.6

Приведенные на рисунках ВАХ не требуют дополнительных пояснений. Добавлю только, что при напряжении менее 2,35 В на отдельном СД его свечение полностью отсутствует, что соответствует напряжению питания рабочего участка около 7 В., а напряжение питания в 15,5 Вольт на ленте является полностью безопасным, т.к. ток через отдельный светодиод не превышает нормальных эксплуатационных 30 мА.

Однако все эти численные выражения рабочих параметров актуальны только для постоянного тока. Мы собираемся испытывать диод при воздействии переменного напряжения, т.е. импульсного напряжения разных направлений. Однако при таком питании предельно допустимые значения токов и напряжений на диоде могут быть в разы, а то и в десятки раз больше пределов для постоянного тока (это общеизвестно и сомневающиеся менеджеры могут почитать лекции по ТЭРЦ) – все зависит от длительности и периодичности воздействия. Но вот беда: выходное напряжение ЭТ имеет достаточно сложную форму, что не позволяет математически достоверно описать его в пределах данной статьи, а ТТХ на светодиоды не снабжены разделом абсолютных значений для импульсных режимов работы. Хотя там, правда, имеется один параметр (Iпр имп), но для какой длительности импульса он актуален – не ясно, для какой скважности воздействия это применимо, тоже можно только догадываться.

Все дело в том....

Все дело в том, что p-n переход полупроводника при работе от переменного (импульсного) тока работает с переменной нагрузкой. Токовые периоды, вызывающие нагрев и работу светодиода по излучению световых волн сменяются паузами покоя (при которых ток через переход не течет) и в которых полупроводник остывает. И вопрос здесь уже не столько в абсолютном значении тока через полупроводник, а сколько в том, успеет ли полупроводник в период безтоковой паузы остыть настолько, что бы скомпенсировать нагрев произошедший в токовый период. Т.е. не допустить теплового пробоя.

Здесь, я хочу напомнить «физику» отказа полупроводника. Это нам позволит понять суть происходящих процессов. Она, физика, в общем-то известна, но все же своими словами: долговечность любого прибора определяется его отказоустойчивостью. Отказы диодов при штатной эксплуатации происходят в случае теплового, либо электрического пробоя.

Электрический пробой, как правило, возникает при превышении допустимого обратного напряжения (Uобр). При этом диод теряет свойство односторенней проводимости и начинает проводить в обе стороны. В большинстве случаев электрический пробой обратим и работоспособность прибора восстанавливается.

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

Суть здесь такова, что пока не созданы условия для возникновения теплового пробоя – полупроводник работает. Повторюсь, что в общем то не важно какое абсолютное значение имеет ток через него протекающий. Он может быть очень большим! Главное, что бы наш диод не успел перегреться. В паспорте на любой диод указываются два максимально допустимых параметра: Максимальный прямой ток Iпр mzx и Максмальное обратное напряжение U обр макс, для длительного воздействия постоянным током, которые при стандартных условиях эксплуатации гарантированно не приведут ни к электрическому, ни к тепловому пробою.

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

Как же мы оценим производимую светодиодом работу? Да очень просто. Светодиод под действием протекающего через него тока совершает работу по выделению световой энергии и тепловой. А эти два параметра мы как раз очень легко можем замерить и сравнить для обоих видов тока, а значит определить, как сильно нагружает светодиод выходное напряжение ЭТ по сравнению со стандартным 12 В стабилизатором.

Для оценки световой энергии излучаемой отдельным рабочим участком СД ленты я снял зависимость освещенности от напряжения питания. Освещенность замерялась на расстоянии 10 см от излучателей (Рис 7).

Рис.7

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

Приступим.

Для начала исследуем выходное напряжение нашего ЭТ:

Рис.8

Сразу скажу, что использовать бытовой электронный тестер-ампервольтметр для измерения амплитуды напряжения такой формы нельзя. Он рассчитан на измерение строго гармонического колебаний, а в нашем случае он будет очень сильно врать, ибо мы имеем дело с переменным импульсным напряжением промодулированным по амплитуде удвоенной частотой промышленной частоты. Частота модуляции 100 Гц, частота заполнения: 10КГц – двунаправленный меандр, амплитуда сигнала Uа = 18 Вольт. Отдельных выбросов амплитудой более 18 В осциллограф не зафиксировал. Так как заполнение меандр, то действующее значение напряжения будет целиком подчиняться закону модулирующего сигнала, а поэтому в нашем случае Uдейст =Uа/√2= 18/1,41 = 12,7В. Именно поэтому в паспорте на ЭТ указано, что выходное напряжение составляет ~12В.

Глядя на эпюры и сопоставляя их с ТТХ и ВАХ становится ясно, что при действии прямого тока на СД, мы едва ли выйдем за пределы допустимых параметров. Заявленный предельный прямой импульсный ток для одиночного СД в 60 мА достижим только при Uпр > 3,9 В, т.е. при напряжении питания на ленте более 20 В (см. вольт-амперные характеристики), но таких значений мы, как видим все равно не достигаем. С другой стороны, легко видно, что длительность воздействия напряжения свыше упомянутых и совершено безопасных 15,5 В (при которых ток через СД не более 30 мА) составляет не более 8% от общего времени питания от рассматриваемого ЭТ. Думаю едвали это опасно для СД. Ок. Запомним. Проверим чуть позже.

Теперь прикинем, не выйдем ли мы за пределы допустимого обратного напряжения и при воздействии обратного полупериода напряжения. В этом случае сопротивлением R в триаде можно пренебречь, Uа (18В) равномерно распределится по СД в триаде, и амплитудное значение напряжения на диода составит 6 В, что больше заявленных 5В. Но, длительность превышения опять не превысит 8% от общего времени работы СД, и второе, что меня очень сильно смутило, это то, что допустимое обратное напряжение, во всех даташитах как то уж очень подозрительно одинаково для разных серий светодиодов. Оно всегда равно 5В. Ок. Запомним и это и начнем подводить первые итоги.

Итак, теоретически, при прямом полупериоде мы не должны превысить прямых токов для СД, а при обратном полупериоде, превышение заявленного допустимого обратного напряжения мало, — как по продолжительности воздействия, так и по абсолютному значению.

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

Запитав ленту от ЭТ встречно параллельно измеряем светоотдачу единичного рабочего участка ленты из трех излучаетелей и сравниваем значения с характеристикой на Рис. 7. Люксметр фиксирует значения на уровне 970-990 люкс, что соответствует питанию ленты от источника напряжения чуть ниже 10 В!!! Нагрев ленты оказался ничтожны и через 1 час работы не превысил 35 градусов Цельсия, при температуре окружающего воздуха 25°C. В аналогичных условиях, но при питании постоянным током Uпр=12В, лента нагревалас до 49°C, а создаваемая освещенность составляла около 2000 Люкс. Эти результаты совершенно однозначно говорят о том, что несмотря на все маркетологические увещевания, полупроводник при питании от ЭТ работает в недогруженном режиме и ожидать его скорой смерти едва ли приходится. Кстати, посмотрев на Рис. 9, и произведя замеры площадей фигур светло синего и кирпичного цветов можно понять, почему именно СД светятся так, будто питаются от 10В. Дело в том, что светло-синяя фигура характеризует условия, при которых СД лента совершает полезную работу (помним, что это происходит при Uпит > 7 Вольт). Светло-коричневая фигура за вычетом светло-синей – это условия, при которых СД лента простаивает – не работает! Соотношение их площадей как раз 10 к 8. Все сходится, однако, хе-хе.

Рис.9

И тем не менее, на фоне положительного ответа второй вопрос нашего исследования, мысль о пусть и незначительном, но все же превышении допустимого обратного напряжения мне не давала покоя. Короче, я решил по жесткому: подключил ленту к источнику постоянного тока и плавно увеличивая обратное напряжение стал ожидать, когда же милливольтметр зафиксирует электрический пробой. Доведя обратное напряжение на отдельном светодиоде почти до 20 Вольт я так и не добился пробоя. Обратный ток при этом не превышал 15 мкА. Оставив все это дело почти на сутки – я убедился, что ничего с излучателями не случилось, а уж видимо от коротких импульсных воздействий 6В против 5В и подавно ничего не должно произойти в обозримой перспективе.

Конечно, надо признать....

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

Выводы и ответ на третий вопрос

Использовать ЭТ от галогенок для питания светодиодных лент можно и похоже это вовсе не скажется на долговечности работы СД лент и источников света. Скорее даже наоборот скажется, но служить они будут дольше. Наверное. Пока получается, что так. Незабудьте только про встречно параллельное включение и равенство плеч.

Теперь главный вопрос не в том, что — можно ли? Вопрос в том, — А стоит ли?

Ответ следующий – если вы собираете смонтировать систему освещения с нови, то наверное не стоит. Так дешевизна ЭТ будет перекрыта покупкой большего количества, либо большей мощности светодиодов, ведь при 10 В световой поток создаваемый СД лентой в два раза меньше того, что имеем при 12В (см. Рис. 7)

Питание от ЭТ оправдано в случаях, когда:

• — у вас уже есть действующее световое решение на галогенках, и вам хотелось бы без дополнительных затрат на БП и лишних проводов поставить еще и светодиоды. У меня, например, так на кухне сделано;


• — у вас остались незадействованные ЭТ (коих сейчас будет высвобождаться все больше и больше), а требования к мощности планируемого освещения не велики;


• — когда у вас созрело решение заменить галогеновые лампы на светодиодные, а изменения в проводку внести по каким то соображениям не получается.

Спасибо.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Как сисадмину не остаться без работы

И при этом не попасться

Если ты админ, тебе нечем заняться, и твоя компания не нуждается в тебе ежедневно, то тебя, возможно, сократят в ближайшее время за ненадобностью. В данной статье я собрал лучшие практики от системных администраторов, которые умеют обеспечить себя работой настолько, что компания не может прожить без них и дня. Эти практики позволяют даже строить целые ИТ-отделы, там, где тебе было нечем заняться. Применять их или нет – остается на твое усмотрение:

1. Решай любые проблемы пользователей

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

2. Ручная работа – всегда в цене

Если устанавливать операционную систему и приложения на рабочее место пользователя за одно нажатие клавиши и 15 минут, то у сотрудников компании может сложиться впечатление, что работенка у админа непыльная. По этой причине исключай автоматизацию в работе с пользователями: операционные системы ставь с диска вводом ключа лицензии вручную, байтик за байтиком ставь приложения, каждый раз ищи драйверы для принтеров в интернете и выполняй ювелирную настройку систем. Обновить платформу 1С на компьютерах – это вообще задача на неделю, а не на два клика мышью.

3. Не трать деньги компании на ненужные причиндалы

Дополнительный блок питания в сервер, диск горячей замены, стекируемый коммутатор, розетки и патч-панели для организации сети – именно на них ты можешь сэкономить денег компании, и именно благодаря их отсутствию руководство узнает, что сбои в ИТ не такая уж и редкость и системный администратор должен быть всегда рядом «на всякий случай».

4. Больше свободы для пользователей

Отсутствие ограничений на запуск неизвестных приложений, права локальных администраторов на компьютерах, антивирус, подконтрольный пользователю – это то, что позволяет чувствовать пользователям себя как дома и это то, что создает работу сисадмину. То пользователи вирус занесут на компьютер, то с корня диска C удалят «лишние» файлы, то компьютер тормозит из-за количества наставленных «ускорителей интернета». Ничего не поделаешь – за свободу можно и заплатить, наняв дополнительно парочку технических специалистов.

5. Приобретай только брендовые сервера

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

6. Внедряй системы, которые нужны компании сейчас

Если компании нужна просто почта, то ее можно развернуть на бесплатном или платном почтовом хостинге. Когда компании потребуется, чтобы письма клиентов всегда доставлялись, а увольняемый сотрудник не мог уничтожить свою переписку бесследно, можно будет развернуть в компании свой простенький почтовый сервер. Когда же компании потребуется чуть больше, чем просто почта, можно будет перейти на «тот самый» почтовый сервер. В итоге почта в компании одна, а у сисадмина три внедрения и две миграции. Поступая также и с другими системами, сисадмин точно не оставит себя без работы.

7. Делай работу быстро

Тратить рабочее время на планирование – это слишком затратно для компании и затягивает сроки проведения работ. Любую систему можно внедрить/модернизировать на раз-два, а все мелкие недочеты быстренько устранить за пару-тройку дней или даже еще быстрее, если будут помощники.

8. Полагайся на рекламу и маркетинг

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

9. Меняй оборудование только когда его уже нельзя починить

Чем дольше работают старые компьютеры в компании, тем больше денег компания экономит на покупке новых и тем больше у админов работы. Можно даже нанять отдельного специалиста для ремонта старой техники, чтобы еще сильнее экономить деньги компании. Ну а о том, чтобы офис хотя бы день прожил без сисадмина даже и речи не идет – проблемы на каждый день гарантированы.

10. Создавай собственные разработки

Если компания не может позволить себе покупку какого-то решения, то для этого есть сисадмин, который может собрать почти такую же систему, но дешевле. Да, возможно у собранного админом решения будет парочка небольших недочетов, которые будут требовать регулярного обслуживания, но это же лучше, чем если бы компания потратила кучу денег на «то самое» решение. Конечно, никто кроме тебя в данной системе не разберётся, но это уже мелочи – ведь и без этого уволить тебя уже будет непросто.

P.S:

Если следовать перечисленным выше советам, то можно полностью занять одного ИТ-специалиста поддержкой 20-30 пользователей, а при размерах инфраструктуры в 100-150 пользователей уже создать свой ИТ-отдел на 5-6 человек. Если же вы в одиночку обслуживаете 50-60 пользователей и вас хотят сократить в связи с тем, что «в компании задач по обслуживанию на один день в неделю» – покажите эту статью руководству, и пусть они решат, хотят ли они, чтобы новый админ был всегда занят работой или нет.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Как мы делали сингл на Ubuntu Studio 14.04

От создателей Как мы создавали сингл на Ubuntu Studio 13.10 . Второй сингл мы делали тоже на Ubuntu Studio 13.10, так не хотели новых приключений. И созрели к ним только к осени. Каемся, но KXStudio так и не попробовали. По

объективным причинам.

лень

Так что ждём статей про этот дистрибутив от других хаброюзеров.

Сразу выводы

Xubuntu стала сырее и баговее дефолта, а Ubuntu Studio баговее и сырее Xubuntu. Я заметил, так как сижу на Xubuntu+LXDE. На свой ноутбук буду ставить Xubuntu и в неё low-latensy версию ядра с софтом и плагинами.

Я специально нагоняю драматизма в статье для тех, кто ещё только собирается встать на этот путь. Свободное ПО — это свободное ПО, вам никто не обязан. Иногда придётся копаться или какое-то время терпеть неудобства. Для меня же как было верно, так и осталось следующее: «Нет ОС для творчества, кроме Linux, и разрабы Ardour пророки её».

Как это было

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

Железо было то же, что и в прошлой статье.

Радует, что ПО, в частности, Ardour развивается. Но есть и проблемы, куда же без них?

С этим мы уже встречались

Купленный свежий Ardour 3 не стал открывать старые проекты. Методом научного тыка нашли решение: открыли в Ardour 3 из репозитория Ubuntu. Он удалил, как любит, несколько звуковых файлов из проекта. Он иногда это делает и без такого шикарного повода, кстати. Проект сломал всего один раз. Время от времени падает, поэтому сохраняйтесь почаще.

Детективная история: серый кардинал плагинов

Плагины Calf создали профсоюз. Они не хотели работать, когда их использовали больше 5 штук за раз. А это был костяк нашего пролетариата. Но костяку было плевать, у них был гуманизм и

Error in `/opt/Ardour-3.5.380-dbg/bin/ardour-3.5.380': corrupted double-linked list: 0x00007f570800e590

Так что процесс встал.

Стали искать тайного плагинового лидера и вдохновителя. Первым подозрение пало на библиотеку FFT (обсуждение на форуме Ardour , обсуждение на GitHub ). Она вызывалась кучей плагинов, в ней явно были баги и авторы ничего не собирались делать. Дождались обновления Ardour с костылём, решающим проблему с FFT. Но Calf продолжали бастовать.

Метод научного тыка и бубен не помогли. Осталось только два средства — поставить обратно Ubuntu Studio 13.10 и молитва. Начали со второго, и главный разработчик Ardour Paul её услышал. Он написал, что проблема в Calf из репозитория в Ubuntu. И если установить свежую версию, то профсоюз перестанет безобразничать. Установили ветку Calf experimental, заодно TAP-плагины на всякий случай обновили. Правда, на деле этого оказалось недостаточно, и пришлось расстрелять удалить старый набор этих плагинов. После чего переместить новые Calf в правильную папку.

Я слишком хорош для того, чтобы экспортировать ваши жалкие псевдомузыкальные потуги!

Да, один из проектов Ardour отказывался экспортировать в звуковой файл. Мол,

Exported ended unexpectedly: Exception thrown by AudioGrapher::SilenceTrimmer: process() after reaching end of input
28.10.14        
Export ended unexpectedly: Exception thrown by AudioGrapher::SilenceTrimmer<float>: process() after reacing end of input

Debug указывал на сервер Jack. Перед глазами были тысячи ошибок и хватание за голову/сердце/бубен. «Давай поставим 13.10 обратно». А решение было простым — не ставить полосы воспроизведения и перемотки ровно на начало. Видимо, где-то деление на ноль возникало.

Разрабы знают лучше

У одного из ladspa-плагинов сменилась логика работы и теперь бас у нас звучит иначе. Так что пресеты это хорошо, но не вечно. Воспроизвести старое звучание точь-в-точь так и не смогли. Сам я слышал раньше про такое, но столкнулся лично в первый раз.

Обложка в Gimp

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

Параллельно с этим

Выступили на новосибирском SFD-afterparty с Ardourна ноутбуке. Через него шёл проект с ритм-секцией, а так же синтезатор. Один раз Ardour всё же упал при попытке запустить проект. Пришлось беседовать с залом, пока его перезапускали. Решили больше так не выступать.

Итого

Третий сингл мы сделали. Ссылку давать нанего не вижу смысла. Разве что если сильно будут требовать. Звучит получше, но не кардинально по сравнению с прошлыми. Петь я так и не доучился, микрофон всё тот же Behringer за 500 рублей, а мониторы Rinon достал себе только через несколько дней после релиза.

кстати

он сразу послушал на них наши записи и загрустил. Сказал, что в следующий раз будет лучше

Вместо этого добавлю видеоконтента just for lulz:

он тут

Планы и дальнейшие дела

Из полезного сообществу — Rinon собирает новую библиотеку ударных, по кусочкам. Она будет свободной и лучше звучащей. Да, поделитесь кто-нибудь хорошими свободными семплами хэта и томов, никак не можем найти нормальные! Остальное есть. Ещё готовим скринкасты по Ardour и Hydrogen. Партии песен так же выкладываем на гитхабе, все песни под CC-BY-SA 4.0.

P.S. Поделитесь в комментариях своим опытом работы с музыкой на ubuntu-based дистрибутивах, находками и победами. И дайте, пожалуйста, ссылки на группы, которые делают качественную музыку на свободном софте. Наверняка такие есть.

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

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.