[syoma 1]

Привет вот такой теоретический вопрос.

В общем есть аналоговый сигнал - например ток инвертора, который оцифровывается АЦП с частотой 96кГц. Далее эти семплы в виде пакетов данных передаются через общую сеть на основной вычислитель, который уже выполняет их обработку и управляет системой в реальном времени. Например, в нем крутятся алгоритмы защиты, которые должны отключить инвертор как при превышении мгновенного значения тока, так и по перегрузке, если действующее значение выше определенной величины определенное время.  Таких АЦП в системе несколько - на каждой из трех фаз, на сетевых напряжениях, а вычислитель один. 

Вопрос в том, что передающая сеть от АЦП к вычислителю построена по типу Ethernet сети - т.е. каждый АЦП подключен к свичу через свой канал 100Мбит, а от свича к вычислителю идет один линк 1Гб или 10Гб в зависимости от необходимой общей пропускной способности. Свич вносит задержку и джиттер, так как пакеты от разных АЦП сталкиваются в свиче и затем передаются через одну общую линию связи на вычислитель. Т.е. их порядок в очереди приема может быть разный, а сами пакеты достаточно большие, чтобы коллизии имели место. Измеренная итоговая задержка любого конкретного сигнала - от 10 до 18мкс. При этом все устройства - и АЦП и вычислитель четко синхронизированы по времени и каждый семпл имеет свою метку времени и поэтому восстановить сигнал без джиттера в вычислителе можно сравнительно легко и он тогда просто будет всегда иметь максимально возможную задержку.

Но тут возникает вопрос - а надо ли?

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

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

Наверное, самый простой вопрос, нужно ли бороться с джиттером - это 3-х фазные измерения токов, напряжений и мощности. В этом случае стоит иметь полностью синхронизированные семплы от разных фаз. Но эти измерения имеют очень низкую скорость, что похоже им тот джиттер должен быть пофиг. Да и итоговая рассинхронизация между разными АЦП никогда не превышает 1 семпл. Так надо ли?

Какое ваше мнение? Может из аудио кто посоветует?

 

 

[Lmx2315 2]

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

[V_G 8]

Разве это называется джиттер? У меня были другие представления о природе джиттера и соотв. об областях, где он критичен.

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

[syoma 1]

1 hour ago, V_G said:

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

Ну а что это? Пакеты от одного конкретного источника не переставляются и идут в строгом порядке. Т.е. пакет с током, измеренным в момент t, обязательно примется ранее, чем пакет с током, измеренным в момент t+10,4мкс. Наоборот точно невозможно.  Просто из-за коллизий в свиче конкретный пакет может прийти раньше или позже нужного времени.

2 hours ago, Lmx2315 said:

для DSP собирайте по времени.

Так вопрос в том - какие негативные последствия можно ожидать, если так не делать? Хоть в теории? Пока только наблюдаю, что DSP в конкретном цикле может тупо схавать слегка устаревшие данные, если новые не успевают поступить до определенного момента времени. Но чем это грозит с точки зрения алгоритма, прикинуть не могу. Может промоделировать как-то?

[Lmx2315 2]

18 минут назад, syoma сказал:

Так вопрос в том - какие негативные последствия можно ожидать, если так не делать? Хоть в теории? Пока только наблюдаю, что DSP в конкретном цикле может тупо схавать слегка устаревшие данные, если новые не успевают поступить до определенного момента времени. Но чем это грозит с точки зрения алгоритма, прикинуть не могу. Может промоделировать как-то?

Уточните о какой полосе сигнала идёт речь. Если ваш полезный сигнал 48 кГц - то 10 мкс , это 180 градусов изменения фазы для него, а это порождение кучи гармоник в спектре, посмотрите фазовую модуляцию. А если полоса вашего сигнала 100 гц , то 10 мкс это менее 0.1 процента.

Это даст Динамический диапазон более 60 Дб.

[jcxz 184]

3 часа назад, syoma сказал:

Вопрос в том, что передающая сеть от АЦП к вычислителю построена по типу Ethernet сети - т.е. каждый АЦП подключен к свичу через свой канал 100Мбит, а от свича к вычислителю идет один линк 1Гб или 10Гб в зависимости от необходимой общей пропускной способности.

Тут вопрос скорее в том - почему сбор данных с АЦП построен таким странным образом?    Имхо - сами себе создали проблему, теперь пытаетесь её решать.

3 часа назад, syoma сказал:

Свич вносит задержку и джиттер, так как пакеты от разных АЦП сталкиваются в свиче и затем передаются через одну общую линию связи на вычислитель. Т.е. их порядок в очереди приема может быть разный, а сами пакеты достаточно большие, чтобы коллизии имели место. Измеренная итоговая задержка любого конкретного сигнала - от 10 до 18мкс. При этом все устройства - и АЦП и вычислитель четко синхронизированы по времени

Так если все АЦП синхронизированы между собой, то кто мешает разнести передачи от них по времени? так чтобы они не перекрывались. Это конечно если по этой самой Ethernet не передаётся каких-то других данных, кроме АЦП-шных. Это гораздо проще (имхо) чем потом "восстановить сигнал без джиттера в вычислителе". Всегда проще не ломать, чем восстанавливать сломатое.  

49 минут назад, syoma сказал:

Просто из-за коллизий в свиче конкретный пакет может прийти раньше или позже нужного времени.

А ещё он может просто не прийти (потеряться).

[syoma 1]

2 hours ago, jcxz said:

Тут вопрос скорее в том - почему сбор данных с АЦП построен таким странным образом?    Имхо - сами себе создали проблему, теперь пытаетесь её решать.

Ну это не странно, это IEC 61850-9-2. Уменьшает количество проводов, обеспечивает гальваническую развязку, позволяет передавать аналоговые сигналы с большой скоростью на большие расстояния от большого количества узлов в реальном времени, используя стандартное Ethernet оборудование. Возможность простого полного дублирования передающей сети. По проблеме пока нечего решать, надо сначала разобраться есть проблема или ее нет.

2 hours ago, jcxz said:

Так если все АЦП синхронизированы между собой, то кто мешает разнести передачи от них по времени? так чтобы они не перекрывались. Это конечно если по этой самой Ethernet не передаётся каких-то других данных, кроме АЦП-шных. Это гораздо проще (имхо) чем потом "восстановить сигнал без джиттера в вычислителе". Всегда проще не ломать, чем восстанавливать сломатое. 

Во первых в стандарте это не специфицировано. Там описано так, что "измерил - сразу передавай". И разнесение по времени как-то не работает с Ethernet. Я пока не понимаю почему. Вот просто берем один АЦП, цепляем его к свичу и с другой стороны ставим ПЛИС на прием. Других пакетов в сети нет. Все отключено. АЦП шлет один фрейм каждые 10.4мкс. Но почему-то на ПЛИС все равно пакеты приходят с разными задержками. Какая-то странная логика у свича - то ли он их там в буфер засовывает, то ли еще что-то.

2 hours ago, jcxz said:

А ещё он может просто не прийти (потеряться).

Конечно, но это отслеживается. А еще в Ethernet есть удобное решение для этого - Parallel Redundancy Protocol.

 

3 hours ago, Lmx2315 said:

Уточните о какой полосе сигнала идёт речь. Если ваш полезный сигнал 48 кГц - то 10 мкс , это 180 градусов изменения фазы для него, а это порождение кучи гармоник в спектре, посмотрите фазовую модуляцию. А если полоса вашего сигнала 100 гц , то 10 мкс это менее 0.1 процента.

Это даст Динамический диапазон более 60 Дб.

До высших гармоник, то есть 2500 Гц.

[blackfin 14]

3 minutes ago, syoma said:

Какая-то странная логика у свича - то ли он их там в буфер засовывает, то ли еще что-то.

Значит, пора переходить на TSN. ;)

[jcxz 184]

7 минут назад, syoma сказал:

Во первых в стандарте это не специфицировано. Там описано так, что "измерил - сразу передавай".

Так у Вас по любому это не возможно, ведь при наложении 2-х пакетов по времени, один всё равно будет задержан.

А вот то, что даже при наличии только одного передатчика, задержка приёма недетерминирована - с этим стоит разбираться отдельно. Может свич поменять на другой. Или в чём-то другом проблема.

[haker_fox 60]

4 hours ago, syoma said:

построена по типу Ethernet сети

Извините, не совсем по теме. Но.. вы используете протокол TCP/IP или голые Ethernet-фреймы? Или что-нибудь индустриальное?

[AlexandrY 2]

45 minutes ago, syoma said:

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

А как вы умудряетесь с таким свичером добиться синхронизации времени с точностью 1 мкс? 

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

[syoma 1]

2 hours ago, blackfin said:

Значит, пора переходить на TSN. ;)

TSN вроде как организует трафик внутри сети, так что все что надо, доставляется куда надо с гарантированной максимальной задержкой. Но дальше возникает тот же вопрос - что делать с фреймами, которые пришли раньше времени?

2 hours ago, jcxz said:

А вот то, что даже при наличии только одного передатчика, задержка приёма недетерминирована - с этим стоит разбираться отдельно. Может свич поменять на другой. Или в чём-то другом проблема.

Я думаю, что что-то в свиче. Может быть особенность перевода из 100мБит в 1Гбит.  Но на самом деле это не так важно, так как когда передатчиков (и фреймов) будет много, недетерминированные задержки все равно возникнут. Насколько я понимаю тут будут играть даже скорости распространения света по оптике на расстояниях 50-200м. Ну и как ниже описано, точность синхронизации +-500нс, то есть обязательно кто-то будет слать чуть раньше, а кто-то чуть позже.

1 hour ago, haker_fox said:

Извините, не совсем по теме. Но.. вы используете протокол TCP/IP или голые Ethernet-фреймы? Или что-нибудь индустриальное?

IEC61850-9-2 - Sampled Values.  Это layer 2 protocol - голые MAC фреймы. Модель publisher-subscriber. Wireshark его легко понимает.

1 hour ago, AlexandrY said:

А как вы умудряетесь с таким свичером добиться синхронизации времени с точностью 1 мкс? 

Не знаю, но IEEE 1588 v2 PTP прекрасно справляется с такими свичами. Точнее не так. Свич-то как раз с точки зрения IEEE 1588 является "transparent clock" и поэтому компенсирует там у себя что-то. Но реально синхронизация с точностью менее 1мкс есть и работает - мы проверяли.

1 hour ago, AlexandrY said:

Не хватает рассказа как DSP алгоритм выводит свои результаты. Небось опять через тот же свичер.
И насколько эти алгоритмы сами детерминированы.
А не окажется ли что джитер вывода гораздо больше джитера ввода. 

Тут чистая внутренняя ПЛИСоводчина и синхронизированная проприетарщина. Поэтому джиттер пока там не ищем.

[nice_vladi 1]

18 minutes ago, syoma said:

Тут чистая внутренняя ПЛИСоводчина и синхронизированная проприетарщина. Поэтому джиттер пока там не ищем.

Позволю себе глупый вопрос: а почему АЦП напрямую к ПЛИС не подключить? И будет полная синхронность.

 

ЗЫ. В любом случае свитч собирает несколько портов в один - задержки неизбежны. Чудес не бывает)

 

ЗЗЫ. Недетерменированность откликов - свитч перебирает буферы портов по порядку. Пакеты приходят в него случайно относительно этого процесса. Поэтому возможна ситуация, когда задержки между пакетами плавают. Более того, порядок передачи пакетов из нескольких портов в один так же не гарантируется (в зависимости от свитча, конечно).
 

[AlexandrY 2]

24 minutes ago, syoma said:

Тут чистая внутренняя ПЛИСоводчина и синхронизированная проприетарщина. Поэтому джиттер пока там не ищем.

Ну тогда этим плисоводам и карты в руки. 
Джитер в сигнале будет превращаться в шум. Но шум можно фильтровать.
Если используют Калмана то чем точнее модель планта и объекта управления тем лучше фильтрация и тем большие шумы(джитер) можно позволить от сенсоров.  

[Pengozoid 0]

ТС, вы бы для понимания сути проблемы рассказали, что у вас не просто АЦП, а что-то типа 61850 MU на подстанции (?), где там ваша аппаратура стоит, process/station, может быть по делу чего посоветовали, а не спрашивали, почему нельзя напрямую АЦП подключить.