Как отследить исходящий сигнал USB

АлексейКр

Ух, мне даже интересно стало!
Давайте начнём обсуждение, только без детских аллегорий и если я в чём то буду не прав, то скажите.

Речь идёт о USB 1.1 Full Speed 12Mb/s
Начнём с самого начала:

1. Частота передачи данных 6Мгц (1бит – это полупериод).

2. Основываясь на статью http://www.softelectro.ru/usb.html Пункт 3.5 Протокольный уровень USB1.1. - типы пакетов, делаю вывод что пакеты которыми обменивается хост с устройством не более 32бит. Кроме пакета Data Packets(DP) (пакет данных), который и несёт полезную информацию (в нашем случае звук).

Если всё верно, то продолжим, если нет - обсудим.

Реклама

Мурик

АлексейКр писал(а):Частота передачи данных 6Мгц (1бит – это полупериод).

Вы очень многое не учитываете. Важна не частота, а содержимое пакетов. А ваша схема меряет напряжение. Это все равно что светодиод использовать в качестве логического анализатора. Вот вы видите что он светится, но сможете ли вы сказать какие данные при этом на шине и как их интерпретировать?
Кроме того, шина USB слишком универсальна чтобы полагаться что схема будет работать всегда и со всем железом без сбоев.
Но если хотите "прогуляться по минному полю" где кроме "мин", "грабли" на каждом шагу, дело ваше.

Реклама

АлексейКр

Мурик, Вы наверное не на ту схему посмотрели. по этой ссылке http://24dx.ru/forum/viewtopic.php?f=16&t=749 это начало эксперементов, там схема да, детектор. Ниже второе изделие и там другая ссылка на "Облако", Вот она: https://cloud.mail.ru/public/b927c5187f ... %D0%BC.rar

YS · Сообщение YS » Вс янв 04, 2015 23:17:25

Ух, мне даже интересно стало!

Для начала, чтобы понять, как работает USB, почитайте это.

Смысл в том, что наличие сигнала на шине USB совершенно никак не коррелировано со звуком. По стандарту хост должен посылать пакеты SOF все время работы устройства на шине (каждую миллисекунду для Low Speed и Full Speed). Если пакетов SOF нет более 3 мс - устройство должно уходить в сон.

Вам повезло - как, похоже, оказывается, стандарные драйвера USB Audio (которые скорее всего портированы из одних исходников на все проверенные ОС) как раз таки переводят звуковую карту в режим сна, когда софт закрывает поток вывода. Но они могут и не делать этого. Согласно спецификации USB Audio Class, хост может просто выбрать альтернативную конфигурацию или интерфейс, например, без изохронной конечной точки, и продолжать поддерживать обмен по шине. Такие дела. Это отдается на усмотрение хоста.

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

Ну и я уже не говорю о том, что ваше устройство нарушает соглашения о электрических характеристиках шины.

Реклама

АлексейКр

YS, я понял что Вы хотите до меня донести. Start-of-Frame Packets(SOF) пакет определяющий начала кадра. Этот пакет у меня передаётся постоянно, с частотой 1мс, в сон карточка не уходит. Примитивным осциллографом это видно, но этот пакет слишком короткий. Моё устройство его игнорирует, т.к. его величина 32 бит, а следом за ним идёт сигнал EOP(End-of-Packet)- сигнал конец пакета. При сигнале EOP, обе линии D- и D+ находятся в "0", а при этом условии происходит сброс счётчиков. Я в пояснительной записке это описывал, на второй странице, "Пакеты данных". И заострил внимание на длинах пакетов.
Существуют служебные пакеты данных (общение хоста с устройством) и информационные (передача полезного сигнала, в нашем случае аудио сигнала). Длина служебного пакета как правило не более 32бит, а вот информационного Data намного больше, до 1023*8+32=8216 бит.

По поводу разбалансировки USB. Там на обеих линиях одинаковое сопротивление и на концах одинаковые ёмкости. Для выравнивания ёмкостей даже присутствует «компенсирующий» конденсатор, об этом тоже в пояснительной записке написано. Страница 5.Конденсатор С4 «компенсирующий». Компенсирует разность входных емкостей. По даташиту номинальная ёмкость входа микросхемы у разных производителей 3-3,5 пФ. Вот разницу в два входа мы и компенсируем.

Если память не изменяет, то волновое сопротивление кабеля 90 Ом. Если даже прикинуть ОЧЕНЬ ГРУБО, что сопротивление емкости входов при частоте 6 МГц будет равно "0", то волновое сопротивление будет 90*1000/(90+1000)=82,5 Ом. Отклонение 8,3%. Может я где то и заблуждаюсь, но думаю не настолько. Тем более скорость передачи данных всё же 12Mb/s, а не 480Mb/s.

Реклама

АлексейКр

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

Реклама

YS · Сообщение YS » Пн янв 05, 2015 10:00:04

Назовите мне "событие", "состояние" или "условие", при которых должно произойти ложное срабатывание устройства.

Одно я уже назвал - хост не переводит устройство в спячку, а продолждает обмен, но с другой конечной точкой. Например, с каким-то из Feature Units. И все... Да, пока что вы не встречали такой ситуации. Но стандарт не запрещает ей быть.

Я тут правда должен буду понять, какое напряжение будет во время этого "события" на линиях D- и D+, и продолжительность этого "события".

А напряжение/продолжительность будут ровно такими же, если, например, хост выберет изохронную конечную точку из другого интерфейса. И я подозреваю, что ваше устройство не отличит isochronous transfer от interrupt transfer.

Да, вы там твердите про 32 бита. Так вот, не бита, а байта. Размер пакета контрольной конечной точки может быть 8, 16, 32 или 64 байта, на выбор устройства. Размер пакета данных может быть от 1 до 1023 байт. Все на выбор хоста и устройства. 32 бита - стандартный размер пакета HID report. Все перечисленные цифры, разумеется, не включают служебные биты.

АлексейКр

По первому же объяснил, устройство не уходит в спячку, сигнал Start-of-Frame Packets постоянно присутствует на шине, даже когда воспроизведения нет. Или Вы хотите сказать, что на том же кабеле (или том же гнезде) USB будут присутствовать пакеты Data для другого устройства? Мы же ведём речь о шине, на которой сидит устройство, а не хаб. На шине хаба такое будет, а на шине устройства сомнительно. Там на "Облаке" так же лежит спецификация USB1.1. Судя по рисунку Figure 5-5. USB Physical Bus Topology на странице 45, устройство напрямую подключено к хабу. Зачем тогда хабы нужны, если все устройства можно было бы подключить к одной шине (кабелю)?

По поводу размера пакета Start-of-Frame Packets, посмотрите в той же спецификации на странице 175 пункт 8.4.2. Там БИТЫ, а не байты. И тут тоже биты http://www.softelectro.ru/usb.html пункт 3.5.1 Пакет (Packet), чуть ниже есть пакет Start-of-Frame

Если речь идёт про пакет Data, то страница 176 спецификации USB1.1 или тут же http://www.softelectro.ru/usb.html под пакетом SOF. Там в начале и конце тоже БИТЫ, а вот полезная информация в БАЙТАХ, которую я перевёл в биты умножив на 8.

YS · Сообщение YS » Пн янв 05, 2015 11:23:47

По первому же объяснил

Не объяснили. Вы, судя по всему, не понимаете, что такое конечная точка (endpoint). Это не другое устройство. Это другой поток к тому же устройству. Я уже приводил документы, которые рекомендовал бы вам почитать перед дальнейшей беседой. Судя по всему, вы не уделили им достаточно внимания. Особенно рекомендую ознакомиться с официальной спецификацией аудио-класса, коли уж вы с ним работаете.

Или Вы хотите сказать, что на том же кабеле (или том же гнезде) USB будут присутствовать пакеты Data для другого устройства?

Для другой конечной точки, endpoint. Непосредственно для воспроизведения используется два интерфейса и две конечные точки. Как правило, endpoint 0 в control-режиме для интерфейса AudioControl и endpoint 1 в isochronous-режиме для интерфейса AudioStreaming. Также в последнем может присутствовать дополнительная конечная точка для дополнительной синхронизации.

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

АлексейКр

Ну я совсем не программист. тяжело мне Ваш язык понять. Про второй поток Вы сказали, я понял. Собственно пусть этих потоков хоть сколько будет, хоть к устройству, хоть от устройства. Ведь все эти потоки будут состоять из пакетов? Если длина пакетов в потоках будет меньше длины пакета Data несущего музыку, то устройство не среагирует. Ведь по логике пакет Data, несущий музыку, является самым длинным.

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

YS · Сообщение YS » Пн янв 05, 2015 19:15:39

тяжело мне Ваш язык понять

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

Я все еще настоятельно рекомендую вам сходить по тем ссылкам, что я давал. Особенно насчет спецификации USB Audio. Это не я придумал, это официальный документ.

Если длина пакетов в потоках будет меньше длины пакета Data несущего музыку, то устройство не среагирует.

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

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

Не факт. Кто знает, что в конкретном устройстве программисты завернули? Стандарт USB дает большую свободу в выборе форматов передачи и длин пакетов.

АлексейКр

Чего то мы уже в дебри лезем.

Работа устройства основана:
1. На измерении длин пакетов. Самый длинный пакет, есть пакет звука идущего на наушники. Если примерно прикинуть по счётчику, то длина его будет примерно 1600 бит. Следующий по длине пакет, это пакет звука идущего с микрофона. Его длина примерно 800 бит. Я знаю что длины пакетов не строго одного и того же размера, это видно в программе Advanced USB Port Monitor, разнятся они не на много. Поэтому число, на которое реагирует устройство программируется средним, и равным (1600+800)/2=1200 бит. Это даёт огромный запас от ложного срабатывания. Да даже если и запрограммировать 1600 бит, то там есть специальная задержка на отключение РТТ с диапазоном 0,2 - 2 сек. 0,2 сек это 200 пакетов! Один да точно будет 1600 бит.

2. На анализе количества "0". В пояснительной записке я писал, что в "пустых пакетах" Data, которые идут в течении 2х - 3х секунд после окончания воспроизведения "0" больше чем в пакетах Data, в которых есть звук. . Так вот, если число "0" превысит запрограммированное, то происходит блокировка анализатора длин пакетов.

Я согласен что программисты могут завернуть чего угодно, но звуковая карта она потому и звуковая, что предназначена для передачи звука. Соответственно и львиная доля трафика предназначена для звука. Да и чего там на карте может быть такого, на что необходимо больше информации чем для звука? Тем более что мы говорим о USB1.1 12Mbps.