Форум: Техническая поддержка

Здравствуйте!
1. Насколько я понимаю, конструкция крейтов (8 и 16) штатно предполагает возможность многократного "втыкания/вытыкания" LTR-модулей. Отсюда вопрос: каков ресурс разъёмов, подвергающихся такому воздействию?
2. Проводились ли какие-либо испытания крейтов на предмет вибраций, ударных нагрузок?
3. Возможно ли использование опциональной flash-памяти (2Гб) для буферизации потока данных? Мотивация - нестабильный канал передачи данных (Wi-Fi) и, соответственно, возможность организации некого буфера FIFO, чтобы избежать потери данных в процессе измерений из-за кратковременных просадок канала передачи.

Здравствуйте.
1. Порядка 100 циклов соединений.
2. Нет.
3. Уточните необходимую скорость записи данных.

По п.1: Можем рассмотреть возможность комплектации разъемными парами семейства DSUB с повышенным ресурсом надежности. Это разъёмы - на панелях большинства модулей. Необходимые данные - это объём Вашего заказа.

1. А сколько циклов у DSUB?
3.
2 x LTR24-1
5 x LTR22
1 x LTR212M-1

(2*4*117100+5*4*78125+1*4*7600)*32/1024/1024=77,2Мбит/с

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

Сериальный интерфейс SPI мicro-SD не позволит записывать с такой скоростью. Там пропускная способность значительно меньше.

Забыл уточнить... речь в данном случае про 4 2-местных крейта на 1 точку доступа 802.11n/ac (по 2 канала)

Тогда распишите необходимую конфигурацию каждого крейта LTR-EU-2-5, и необходимые скорости записи каждого крейта.  А также:  можно ли эти данные сильно сжать, превратив их в компактные результаты измерений Вашей специфической задачи измерения?
Такие вопросы задаю потому, что в LTR-EU-2-5 имеется неплохой свободный вычислительный ресурс у процессора Blackfin (если этим ресурсом  воспользоваться, конечно, занявшись низкоуровневым программированием).

LTR-EU-2-5 (LTR22, LTR22) - 2 шт
LTR-EU-2-5 (LTR212M-1, LTR22) - 1 шт
LTR-EU-2-5 (LTR24-1, LTR24-1) - 1 шт

2*4*78125*32/1024/1024=19,073
2*4*78125*32/1024/1024=19,073
(4*78125+4*7600)*32/1024/1024=10,464
2*4*117100*32/1024/1024=28,589
Итого 77,2 Мбит/с

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

Насчет канала, если я правильно понял у Вас 2 антены по 150 МБит/c на все крейты? Тогда даже теоретическая скорость самого интерфейса меньше чем в 4 раза превышает требуемый поток, что сложно назвать "многократно", при том что есть накладные расходы на служебную информацию и реальная скорость WiFi зависит от наличия других беспроводных устройств и прочих факторов. Но при свободном канале должно хватить, хотя все же без многократного запаса... Но тут можно проверить запас скорости конкретного канала просто передавая большой файл по этому каналу.

По поводу SD карты следует учесть, что в штатной прошивке она не используется, для такой работы нужно создание специализированной прошивки крейта.

Во вторых со скоростями, я так понимаю это скорость самого потока. Но в Вашем случае потребуется насколько я понимаю еще и одновременно писать и читать данные, т.е. пропускная скорость интерфейса требуется в 2 раза больше (плюс в скорости вроде используются десятичные приставки, т.е. деление на 1000, а не 1024 - хотя и не большая прибавка).

Как указывалось, SD карта подключена в крейте по SPI интерфейсу. Штатная частота SD карты в этом режиме всего 25 МГц и биты передаются последовательно. Есть и карты, которые могут поддерживать 50МГц, хотя их работу не проверяли, но при этом скорость SPI в Blackfin в любом случае не может быть больше 133/4 или 125/4  МГц (в зависимости от частоты процессора), т.е. в лучшем случае максимальная частота интерфейса с картой 31 или 33 с небольшим MHz.

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

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

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

Отредактировано Алексей L Card (20.09.2018 16:16:56)

В дополнение того, что написал Алексей: важно учитывать, что SPI, к которому подключена SD-карта, подключена к  "управляющему интерфейсу SPI между Blackfin и FPGA"  ( см. http://www.lcard.ru/download/ltr.pdf    "Табл. 21-2. Периферийные функции интерфейсов (портов)" на стр. 336  ). Этот SPI используется как "разделяемый ресурс" между интерфейсами:
- Blackfin - регистры FPGA (SPISSEL5).
- Blackfin - термодатчик (SPISSEL6).
- Blackfin - SD-карта (PF6 - SPISSEL4).
Трафик у обращений к регистрам FPGA и термодатчику наверное небольшой, но, всё равно, это добавляет логические накладные расходы на переключение задач.
Таким образом, данная SD-карта, по всей видимости, в данной задаче может быть использована для накопления обработанных и сжатых результатов измерений, а не для буферизации необработанного потока данных со скоростями, рассчитанными выше.

Не правильно: 2х150+2х433,5=1167 Мбит/с. Спор о понятии "многократно" бессмысленен, как, впрочем, и эти 1167 Мбит/с ближе к "сферическому коню в вакууме", нежели к реалиям. Погонять канал iperf'ом конечно же можно, но пути радиоволн "неисповедимы" в реальных условиях).

Это совсем не обязательно: вполне допустимо сначала "забить" карту данными, а потом всё скачать, т.е. в режиме разделения времени.

Это очевидный путь, и мы его уже проходили лет 7 назад, правда тогда это было вынужденно, так как нужные измерительные модули были с интерфейсом USB (не было ещё LTR210). Ставили pico-ITX с E20-10 и всё работало. Сейчас же с крейтами такое решение выглядит несколько громоздким.
После всех объяснений становится понятно, что реализация буферизации данных на карте малоперспективна и браться за неё не имеет смысла. А, в принципе, какая-то буферизация в ОЗУ в штатной прошивке сейчас реализована?

На аппаратном уровне возможности буферизации ограничены объемом ОЗУ 32 MB. Можем рассмотреть вопрос о наращивании до 64 MB.

Даже 32 MB не так и мало (несколько секунд). Вопрос в том, реализована ли штатно какая-то буферизация? Заниматься переписыванием прошивки, как я уже понял, экономически не целесообразно, так как реализация плана "Б" будет явно дешевле.

Конечно, реализована. Например, практически та же прошивка (за исключением мелочей) и в той же архитектуре (с тем же ресурсами)  работает на 8/16-местном крейте на USB и Ethernet (TCP/IP). Без буферизации были бы потери данных. Какой объём ОЗУ под буферизацию отведён? - надеюсь кто-то из наших программистов ответит. Причем, в Вашем случае (без ЦАП) важна, главным образом, буферизация "на ввод".

Потребуется просто физическая замена 256-мегабитного на 512-мегабитный TSOP-54 ?

С моей точки зрения, потребуется:
- Замена на 512-мегабитную память.
- Изменение режима SDRAM-контроллера Blackfin в прошивке.
- Решение программных вопросов совместимости разных прошивок Blackfin с разным объёмом ОЗУ на борту (с точки зрения дальнейшей поддержки этого "хозяйства" со стороны L-Card).
- Тестирование прошивки в термокамере для проверки отсутствия проблем в рабочем температурном диапазоне на нескольких экземплярах "железа".   
- Решение вопроса оптимальной настройки размера буферов под имеющийся объём ОЗУ в штатной прошивке.
- Тестирование совместно с ПО верхнего уровня для проверки ситуаций использования глубокой буферизации (как это тестировать? - это отдельный вопрос).   

Но, если потребность в значительно большем наращивании ОЗУ является актуальной (с точки зрения, использования LTR-EU-2-5 совместно с Wi-Fi), то, например, процессор ADSP-BF537 позволяет нарастить ОЗУ (до 128 МВ, но сколько практически возможно в рамках данного дизайна - это предмет для изучения). Но это уже более дорогой путь, требующий проектирования другой печатной платы, хотя программная часть работы и испытания там примерно те же самые.

Александр, всё понятно, спасибо. Это не наш метод).  Будем ждать ответа от программистов по поводу текущей буферизации в рамках 32 МБ.

1. Программист,  поддерживающий blackfin, выйдет из отпуска 01 октября.

2.  Мне кажется, вариант с промежуточной платой - выглядит очень простым и бюджетным (например, Raspberry Pi3 B стоит в районе 3000 рублей, в ней есть WiFi с антенной, 4-ядерный процессор на 1.4 Гц, USB, Ethernet, HDMI, к ней есть готовые корпусные решения).

Добрый день!
Внутренний буфер принимаемых от модулей данных в крейтах LTR-EU имеет размер 8 Мбайт. Единицей обмена по внутренней шине крейта являются 4-х байтные слова (т.е., например, один 12-битный отсчет АЦП - вместе со служебной информацией - займет в буфере 4 байта). Таким образом буфер приема крейта может вместить до 2 Мслов данных от модулей.

При изучении документа lgraph2_help.pdf наткнулся на такую фразу (с.32):
"При работе с модулями крейта по TCP/IP необходимо учитывать максимальную пропускную способность крейта. На данный момент она составляет около 1,4 МБайт/с на передачу из крейта в компьютер и 500 КБайт/с на прием из компьютера в крейт".
Это действительно так или всё-таки опечатка?

Получается, что для самого нагруженного крейта (28 Мбит/с) будет буферизация порядка 2с ? А что будет дальше с данными, если связь не восстановилась (каков алгоритм буферизации)?

Я склоняюсь к этому варианту конфигурации, но есть большие сомнения, что даже 3я малина справится с общим потоком 71 Мбит/с. Тем более её 802.11n без MIMO тоже может стать ограничением. Не столь бюджетно, но более внушающими оптимизм выглядят такие платы: http://www.5sgroup.ru/catalog/10110/?lord=price_up c miniPCI-E 802.11ac. Буду благодарен, если посоветуете, какой минимальной "мощности" такая плата нужна под описанную выше конфигурацию из 4х 2-местных крейтов.
На этой плате запускаем ltrd (LTRserver) и к нему "стучимся" по Wi-Fi с помощью LGraph2 ? Здесь возникает тот же вопрос: как поведёт себя ltrd (LTRserver) при разрыве связи (есть ли у него буферизация)?

Это ограничение было давно, в версии прошивки крейта 1.0.0.1, в прошивке 2.0.0.0 максимальная скорость передачи 10 МБайт/с, как указано в характеристиках крейта http://www.lcard.ru/products/ltr/ltr-eu … =1#qt-ltab (но это конечно при отсутствии потерь пакетов и не загруженном канале). Видимо в том руководстве осталась старая информация.

Да, все так.

Если не ошибаюсь, то буфер в самом крейте циклический. При его переполнении новые данные будут перезатирать старые. В общем в случае переполнения Вы потеряете непрерывность данных, так что лучше его не допускать.
Про "связь не восстановилась" не совсем понял, если она не восстановилась, то вряд ли Вы что-то из него уже прочитаете.
Я с WI-FI точками для этих целей не работал, тут еще вопрос, что делает сама точка, при "просадке канала". Есть ли в ней буферезация, задерживает ли она пакеты или пакеты будут теряться. Если последнее, то при потере большого кол-ва пакетов повторные передачи и восстановление скорости может занять достаточное время.

Буферизация в ltrd есть, но штатно тоже не очень большая.  Сейчас в ltrd есть буфер для каждого модуля (он именно на модуль, а не на крейт, т.к. ltrd сразу принятый поток анализирует на номер слота и кладет слова в буфер слота) на 1 МСлово (т.е. те же 2 секунды с небольшим) + какой-то буфер в сокете на передачу данных клиенту. Другой вопрос, что если потребность будет, то можно будет сделать этот буфер настраиваемым, это в принципе не такая сложная задача. Буферизация там при этом работает по другому, если буфер заполнится, то новые слова, принятые от модуля будут отбрасываться, пока не появится место в буфере. Т.е. данные в буфере сохраняются пока не будут вычитаны и разрыв будет только в конце данных из буфера на момент переполнения при вычитывании.
Единственно, что TCP соединение между клиентской программой (LGraph2) и ltrd должно при этом сохраняться (оно может жить и при пропадании физического канала), т.к. новое TCP-соединение как  правило подразумевает новую настройку модуля со сбросом старых данных.

Какого-то сохранения на диск в ltrd понятно нет, такой цели в нем не было. Для полного использования возможности промежуточного ПК нужна программа на нем, буферизирующая данные, но тогда и приемная сторона должна быть не LGraph.
Но в принципе, если сделать настройку размеров буферов в ltrd, то можно обойтись и штатным ПО, как Вы хотели.

С самими платами честно говоря не подскажу, но тут основной вопрос в Wi-Fi. В принципе, если та точка, что Вы хотели изначально использовать, имеет гигабитный Ethernet, то можно использовать и ее как внешнюю для платы, если есть сомнение в модуле Wi-Fi на самой плате (или, если условия позволяют, крейты могут быть подключены к плате по USB и канал "плата - точка" останется 100 Мбит/c).

Это было бы очень здорово!

А в этом нет смысла: ОЗУ можно поставить несколько гигов.

В том то и дело, что LGraph'a для решаемой задачи мне вполне достаточно, поэтому и не хочется его переписывать.

Сомнения в точке доступа на малине. А для miniPCIe можно выбрать даже 2хдиапазонник с MIMO.

Ну в последней Respberry 3 B+ все же двухдиапазонник   IEEE 802.11 ac, а не 802.11n (https://www.raspberrypi.org/products/ra … el-b-plus/), но насколько я понял действительно только одна антенна без MIMO и вроде бегло просмотрев на WiFi там скорость на самом деле не очень (например https://www.raspberrypi.org/forums/view … p?t=207940 и с ссылкой на https://www.raspberrypi.org/forums/view … #p1285923). Ну в принципе в Pi все сделано как можно более бюджетно, а не макс. скорости.
На Pi в идеальных условиях реальная скорость самих данных получается 100 Мбит/с (https://www.raspberrypi.org/blog/raspbe … le-now-35/), а в реальных условиях, если полоса не свободна, то может и на постоянной основе не хватить.

Думаю в Вашем случае так как поток постоянный и не маленький лучше иметь запас скорости и точку взять получше с MIMO, т.к. как Вы написали "пути радиоволн "неисповедимы" в реальных условиях".

К тому же на приведенном Вами сайте есть ПК и на x86/x64, думаю проще софт ставить, можно даже не собирать, хотя в принципе и под ARM собрать проблем больших быть не должно.

Отредактировано Алексей L Card (03.10.2018 18:39:08)

Алексей, спасибо. Вроде бы всё встало на свои места. Осталось только сделать буфер настраиваемым в ltrd. Как это можно осуществить?