Как стать автором
Обновить

Комментарии 75

Можно посмотреть на карту покрытия LORA (TTN) в Голландии (например) и в России.
Становится очень грустно.
В России широкомасштабные сети LoRaWAN (не LoRa, LoRa — это лишь тип модуляции сигнала) начнут разворачиваться где-то в конце текущего года.

Пока что ни по одной из вышеупомянутых технологий внедрений масштаба города нет — если, конечно, не считать за таковые бравурные пресс-релизы о «100 % покрытии» городков в несколько километров в поперечнике после установки единственной БС и подключения к ней трёх десятков счётчиков воды.
Счетчики воды мне совсем не интересны, но устройства слежения работают гораздо дольше через LORA, чем через GPRS. Хотя рынок счетчиков может и больше. Будет развернут — это хорошо. Но как бы всё опять не уперлось в заоблачные цены на передачу и в несовместимую ни с чем платформу. Посмотрим — осталось не долго.
Цены в таких сетях будут вполне разумные — радикально ниже, чем в обычных сотовых.

Несовместимая платформа — а с чем ей быть несовместимой? Уровень LoRaWAN — стандартный, а вся инфраструктура сети — просто транспорт для бинарных данных, пришедших с абонентского устройства.

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

Вопросы переключения между БС решает сетевой сервер LoRaWAN. БС в LoRaWAN сами по себе довольно тупые, они просто транслируют полученное от абонентов на сервер — а тот уже указывает, какой БС с ним общаться. Так как связь двусторонняя, то мобильное устройство обязано периодически что-нибудь отсылать на сервер, чтобы тот знал, через какую БС с ним связаться — это может быть любое сообщение, можно с пустым содержимым.

С разделением абонентов — в LoRa есть два варианта, CDMA (кодовое) и TDMA (временное). Для первого в LoRaWAN есть механизм ADR — adaptive data rate, фактически это просто команда от БС к абоненту установить определённую модуляцию и мощность выхлопа в эфир. Модуляция при этом косвенно влияет и на TDMA — она определяет скорость связи, так что близкие к БС абоненты с хорошим уровнем сигнала могут уйти на более высокие скорости и быстрее освобождать эфир (а также меньше жрать батарейку).

TDMA — вещь в случае с кучей совершенно разнотипных абонентов неочевидная, но БС может указывать абоненту, сколько времени он имеет право проводить в эфире (включая полное радиомолчание). Абонент обязан подстроиться.

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

FDMA не используется, хотя у БС есть возможность разослать абонентам команду смены рабочей частоты. Но на неё переедет вся сеть — по частотке стандартные БС одноканальные.

********

В локальных сетях LoRa (без полной поддержки LoRaWAN) всё проще. Как правило, в них нет CDMA — простейшие БС (типа той, что на фото) одноканальные, хотя в принципе можно сделать и БС на несколько каналов на дешёвых чипах, она всё ещё будет радикально дешевле полформатной БС LoRaWAN. Зато сеть закрыта, случайные абоненты в ней не появляются, поэтому TDMA можно хорошо реализовать на уровне БС: передав порцию данных, устройство в ответе от БС получает время до следующего слота передачи.

А как проще всего включать устройство в сеть с TDMA, чтобы не было коллизий с другими говорящими абонетами? Понятно, что можно выделить пять секунд в минуту для новых, или посылать с БС широкополосный запрос "кто на новенького?", или забить и ребутнуть абонента, если с первого раза не получилось. Но как обычно делают?


И про пропавших абонентов: есть ли возможность контроля тех, кто не вышел на связь в нужное время?

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

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

И про пропавших абонентов: есть ли возможность контроля тех, кто не вышел на связь в нужное время?


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

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

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

Не поделитесь контактами?))
Под честное слово, что для проекта буду использовать, в случае чего, ваши модули на атеросе?))

У меня же работа на низких мощностях (0-2 дБм) и несколько нод на расстоянии 10-20м — точто доктор прописал.

Про N раз вы не правы. С использованием NC это примерно N/2, а если учитывать такие фичи как мультикаст через бродкаст, Распеределенную ARP таблицу и возможность использовать несколько шлюзов то и все N/4 — вполне себе торт!
И роуминг абонентов занимает около 100-300мс без оптимизации. для потока телеметрии не заметно даже. То есть, полноценный динамический меш.

Глядишь, и тема для кандидатской нарисуется =))))
При чём тут атерос? Людям нужна LoRa и строго LoRa, там речь о сети с несколькими километрами между узлами идёт.
Пардон, прочиталось, как будто речь шла об освещении.
Не, килоетры — это не мое =))
Олег, не подскажите… читал даташиты чипов типа SX1276 — не очень понимаю, откуда там кодовое разделение каналов. Ну можно использовать разный Spreading factor, но их немного разных и битрейт на каждом факторе иной. Как вообще конфликтов избегают в таких сетях? Почему все что читал на эту тему не особо вдаются в этот вопрос. Спасибо.
Spreading factor — это и есть CDMA, он просто преследует в LoRa сразу две цели — как разделение абонентов, так и механизм адаптивной скорости. Делать их много не имеет смысла, если одновременно работающих устройств в эфире будет больше десятка, они просто забьют друг друга в канале приёмника БС.

Конфликтов во всех подобных сетях в общем и целом избегают так же, как в банальном эзернете — если не получили подтверждение в ответ на свой пакет, то ждём случайное количество секунд и пробуем снова. Ну или, в некритичных системах типа счётчиков в ЖКХ, никак вообще не избегают — не сбросил показания сегодня, подождём до завтра (тем более, что у того же Sigfox вообще с обратной связью с подтверждением доставки дела не очень).

При желании на уровне конечного устройства можно разбавить это схемой listen-before-talk — если оно видит в эфире какой-то сигнал, то задерживает передачу. Но тут главное не переборщить, а то постоянная помеха достаточного уровня заткнёт устройство на всё время своего присутствия, т.е. LBT должна быть ограничена по времени, например, несколькими секундами.

При этом собственно разделение устройств не является наиболее критичной проблемой — чаще случается банальная плохая связь, например, из-за неудачного расположения антенны абонентского устройства.
Существует метод синхронизированного разделения кодовых каналов. Т.е. если у всех есть точное время (базовая станция раздала), то можно излучать ортогональными друг другу кодами. В LORA этого нет, поэтому кодовое разделение может строится на том принципе, что два сообщения не случаются строго одновременно. А несколько ЛЧМ при смещении по времени становятся разделимы, даже при использовании одного и того же «кода». По-этому, если преамбулы разошлись во времени, то приемник в теории может разделить несколько пакетов. Честно говоря, я не знаю, Как это сделано на практике в базовых станциях LORA. SX1276 на прием срабатывает по первой преамбуле. А значит, что никакое другое сообщение принято не будет. Т.е. в теории разделить можно два сообщения, наехавших друг на друга, даже с одинаковыми параметрами ЛЧМ. Но правда и тут есть ограничение. Два сигнала ЛЧМ смещенные по времени на самом деле можно разделить только при условии, что они не сильно отличаются по мощности (20-30дБ). А это в системах с динамическим диапазоном приема в реальных условиях около 60-80дБ станет принципиально непреодолимой проблемой.

П.С.: да, чтобы разделить с SX1276 все это подойдет: разделение по частотным каналам, различный битрейт,SF. Но опять же, если появится в эфире мощный сигнал LORA в той же часоте, но пусть другим SF, то он будет маскировать значительно более слабый.
Честно говоря, я не знаю, Как это сделано на практике в базовых станциях LORA. SX1276 на прием срабатывает по первой преамбуле


В SX127x — один цифровой демодулятор, в чипе для БС SX1301 — 49 параллельных демодуляторов.
Во… А я тоже «велосипед изобрел»:)
open-plc.com
Как то сыровато выглядит. Побольше бы информации, или уже довести до ума, а не спешить выкладывать.
Согласен, описание — сыровато, вернее «в процессе». На самом деле уже сделано намного больше, чем описано. Выкладывается по мере появления свободного времени. Есть Linux-based контроллеры. Фото одного из реальных шкафов автоматики на первой странице.
Ну и… я не особо писака WEB ( сам сайт сделан тупо с помощью OpenOffice ).
На сайте есть черновик одной из статей про программную архитектуру системы:
leocat3.com.fozzyhost.com/article.doc ( на русском )
Если интересно, можете почитать…
Да, к линукс-контроллерам можно цеплять тачпанели ( монтаж в шкаф ). Фото там же:
http://leocat3.com.fozzyhost.com/pictures/DSC00966.JPG
http://leocat3.com.fozzyhost.com/pictures/DSC00967.JPG
http://leocat3.com.fozzyhost.com/pictures/DSC00968.JPG
Если это PLC, то какая среда программирования, какие языки МЭК поддерживает? Как реализована трансляция языков в самом МК?
Ответы в статье и на сайте…
Это не только PLC ( ПЛК ) но и архитектура системы. От одного контроллера ( STM32f10x ) до распределенной системы. В роли контроллера может быть одна плата ( с чего начал описание на сайте ) до картинок, там же, на сайте.
Среда программирования — на ваш выбор.
Языки программирования:
ISO/IEC 14882:1998 ( ”C” ), ISO/IEC 14882:2003 ( ”C++” )
Пытаюсь подключить студентов, для разработки/адаптации IEC 61131-3 ( ”FDB, ST” ), правда процесс идет пока не очень быстро.
Причем все означенные языки программирования могут быть реализованы как интерпретаторы ( на линукс-ПЛК ). С интерпретаторами С/С++ баловался — CINT ( https://root.cern.ch/cint ), до FDB, ST дело пока не дошло…
Пока нет поддержки хотя бы одного языка МЭК — это не может называться PLC.
ISO/IEC 14882:1998 ( ”C” ), ISO/IEC 14882:2003 ( ”C++” )
IEC == МЭК
Википедия говорит:
Для программирования ПЛК используются стандартизированные языки МЭК (IEC) стандарта IEC61131-3

Языки программирования (графические)

LD (Ladder Diagram) — Язык релейных схем — самый распространённый язык для PLC
FBD (Function Block Diagram) — Язык функциональных блоков — 2-й по распространённости язык для PLC
SFC (Sequential Function Chart) — Язык диаграмм состояний — используется для программирования автоматов
CFC (Continuous Function Chart) — Не сертифицирован IEC61131-3, дальнейшее развитие FBD

Языки программирования (текстовые)

IL (Instruction List) — Ассемблеро-подобный язык
ST (Structured Text) — Паскале-подобный язык

О С/С++ речи нет.
Вообще МЭК стандарты не ограничиваются 61131, хотя и спецификацию 61131 я прочитал не раз…
Мало того, при разработке архитектуры РИУС использовал именно этот стандарт как основной. Он описывает не только языки программирования, но и архитектуру ПЛК.
Если ссылаться на вики, то:
https://ru.wikipedia.org/wiki/ISO/IEC_14882 ( МЭК, однако )

Все ограничивается что есть пользователи ПЛК, у них например есть Codesys. Программируется ли ваш ПЛК из Codesys? Нет? Значит есть своя среда с поддержкой одного из популярных языков? Нет? Аа, можно в IAR на С++ запрограммировать? Чудесно.
C / C++ это не популярные языки?
На них не программируют большинство пользователей ПЛК.
Как писал выше — все «скушать» просто невозможно. Пока вся реализация сделана только двумя руками и одной головой… Если интересно — можете подключиться к проекту.
Из открытых решений пока нашел только это: http://www.beremiz.org/doc
( Compiles ST/IL/SFC code into ANSI-C code. )
Если встречали FBD code into ANSI-C code, то буду благодарен за ссылку. Ускорит разработку ПО.
Вы не первый, кто говорит: где реализация 61131? :)
Для меня это до сих пор загадка, как например тот же Овен это делает. Они делают ПЛК под среду Codesys, вероятно и рантайм (транслятор с языков МЭК) предосавляет тот же Codesys. И видимо совсем не бесплатно.

Да и транслятор это одно, а пошаговая внутрисхемная отладка языков МЭК из среды — это отдельная тема, как она реализуется, мне тоже непонятно.

А то сейчас много «ПЛК», вон на ардуине несколько «ПЛК» есть в инете, только на поверку оказывается что никакой это не ПЛК.
Отсюда:
С++ прекрасный сильнейший язык программирования. На нем можно запрограммировать любые задачи. Но, это компьютерный язык, а не язык спроектированный специально для ПЛК. Тут есть определенные особенности.

1) Для ПЛК важно иметь интегрированные отладочные средства,
заточенные под специфику автоматизации. Они должны позволять производить технологические операции с оборудованием. Например, при ремонте/наладке некой машины, техник/электрик/механик может машину остановить, вручную поуправлять выходами, проверить входы, зафиксировать выходы и т.п.

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

2) Для ПЛК практически наплевать на эффективность кода, размер программы, экономию памяти, без которых не обойтись, например в базах данных, играх, при запуске непредсказуемо разных приложений пользователя и др. и пр.
Для ПЛК генератор кода должен давать простой дубово-надежный машинный код. Огромные массивы данных тут гонять не нужно. Рядом с ПЛК нет человека-контролера, который бы его перезагрузил при зависании. Да и сам подобный факт может быть фатальным. Поэтому из языков ПЛК намеренно выброшены все потенциально опасные штуки, типа new. В мире широко известны несколько громких аварий по причине примитивных программных ошибок в Си. В МЭК подобные ошибки сделать просто нельзя.

3) ПЛК всегда работает в реальном времени. В МЭК системы встроены свои переносимые средства многозадачности, обеспечения времени цикла, вызова задач по фронтам и т.п. Программисту МЭК нет дела какая ОС сидит внутри ПЛК. Изучать ее функции не надою. В С++ без этого никуда. Своих подобных средств в нем нет, он опирается на ОС. Ее надо изучать.
Ее качество влияет на программу непосредственно. Перенос программы из одной ОС в другую (если сразу не приняты специальные меры) представляет сложность.

4) Языки МЭК значительно проще в освоении. Это не декларация, а факт. Мы не раз сталкивались с обучением техников/наладчиков на заводах. Максимум полдня и электрик уже может выполнить минимально необходимые ему действия сам. Шансов его обучить С++ за полдня ноль. С++ язык для программистов профи. Он позволяет залезать на низкий
уровень и эффективно программировать на уровне железа. Ест-но такие программы требуют знаний, тестирования, по специальным методикам и пр.

5) Часто для некоего электронного устройства 1 программист пишет все от формирования времянок микросхем, до прикладных вещей на С++. Программа выглядит одним большим винегретом. Никто, кроме автора в этом разобраться не может. Он незаменим и обязан сопровождать свою программу, даже если это ему совсем уже не хочется. Руководитель не может отдать это сопровождение молодому специалисту, а этого квалифицированного человека перевести на более выгодную работу. Ни в от отпуск, никуда… У нас это классическая судьба С++ программиста.

Теперь делим софт на системный уровень и прикладной. Между ними простой, четко описанный интерфейс. Это переменные ввода/вывода и системные биб-ки. Системный софт четко разграничен и понятен. Его может писать любой программист, даже наемный. Его легко заменить. Аналогично с прикладным.
Это широко известная старая концепция разделяй и властвуй, но верная и ныне. Подробнее тут.

Для системного уровня С++ прекрасно подходит. Для прикладных задач МЭК языки прекрасно подходят.
Пока сделаны «шаблоны» на «С» для STM32F100/103 под конечный класс устройств. Напр: блоки: 3 реле 220V, 10A, датчики тока по каждой реле, блок 8 входов 0-20mA, блок 2 выхода 4-20mA,…
Управление CAN пакетами, в том числе и нестандартными решениями: радио, IP, PLC ( в тестировании собственная реализация Power Line Cjmmunication протокола 19200 бит/с, а-ля CAN формат ). Есть USB<->CAN шлюз ( проект лежит на сайте ). Можно строить системы с управляющей например win-машиной. Общение с устройствами через COM порт текстовыми данными.
Нужен ли в этом случае 61131?
Я повторюсь, что спроектирована именно архитектура. Да, нестандартная, но на основе 61131 описания архитектуры ПЛК.
Можете для тех кто на бронетранспортере привести преимущества вашего решения?
Общаться через COM порт многие могут.
Спасибо за вопросы. Именно вопросы помогают понять, как же писать буквари.

COM — частный случай. Можно использовать например Siemens контроллер с CAN интерфейсом. Но задача стояла несколько иная. Создать масштабируемую РИУС. Надежную ( пром стандарт ) с предельно низкой стоимостью. Строится из простых блоков на основе STM32F100/103. Блоки понимают простые команды: запиши данные ( управление реле, передачи сигналов и пр ) / дай данные ( состояние входов, состояние реле и пр. ) Потому и начал описание с самих блоков. Но, блок на такой же плате может быть управляющим ( в случае простых систем или старта). На этом же блоке сделан шлюз CAN <-> USB. Т.е. сделана унификация по железу, одна плата — много блоков. Общение между блоками CAN или а-ля CAN пакетами. Математика платы/блока как шаблон на «С» ( что-то не нравится — меняй по своему усмотрению )
Архитектура ПО, начиная с простого ( STM ) построена по одному принципу: работа через разделяемую память. В случае простого блока ( датчиков, управления,… ) в качестве разделяемой памяти — глобальная память ( heap ). Потоки в этом случае вырождаются до функций с приоритетами ( работа напр прерывания по устройству, прерывания по таймеру и т.д.) Пользовательский поток — основной цикл. В нем можно поменять-посмотреть глобальные переменные ( реальные сигналы ). По запросу CAN интерфейса блок получает/отдает данные. CAN обслуживает отдельная функция / а-ля поток.

В случае контроллера/ПЛК отдельные потоки обслуживают свои классы устройств. Все это маппируется на NAMED shared memory. Это память выглядит как отображение на файловую систему. Т.е. мы видим данные как файл, строки с фиксированной структурой. Почему именно так? Реализация NAMED shared memory есть практически во всех ОС, win не исключение. Процессы пользователя работают с сигналами — отображаемые на эту память. На чем будет выполнена реализация сценария ( язык программирования ) в этом случае совершенно все равно. Хоть интерпретатор бэйсика. Что знаем на том и пишем. Вот только интерпретатора 61131 готового я не нашел…
Это вы привели какой-то поток сознания по теме философии разработки, а хотелось бы услышать конкретные преимущества для простого автоматизатора, не для разработчика ПО.
Простота использования, масштабируемость, низкая цена, надежность, пром диапазон.
Это слишком обобщенно, отсюда непонятна конкретная выгода.
Так можно сказать про любое устройство.

Можете привести КОНКРЕТНЫЙ пример где существующая система хуже, чем ваша и чем КОНКРЕТНО хуже?
Ну что-ж, я во всяком случае попытался обхяснить архитектуру…
кстати, а есть ли решения под STM32 для работы с Ladder Diagram?
В аппаратной части ПЛК ничего сложного нет. Вся суть в трансляторе языков.
Вынужден не согласиться. Реализовать работу в пром условиях не так просто.
Да, над надежностью надо хорошо посидеть.
Ничего сложного при грамотном проектировании электроники. Собственно, по вашему же сайту и видно — схемотехника у вас там банальна на 100,0 %, более того, в sens_b1:

1) C2 надо поставить после VD1, прямо перед DC/DC, в текущем положении у него нет смысла
2) VD3 срабатывает в районе 40 В, MC34063A отбрасывает копыта при 40 В — т.е. запаса прочности у защиты от перенапряжения нет

А вот отсутствие МЭКовских языков — это сразу бетонный блок поперёк дороги для 9 из 10 проектов. У эксплуатантов толпы инженеров, не умеющих ничего, кроме МЭК — и либо вы предлагаете им радикально лучшую альтернативу, освоение которой окупится, либо идёте лесом. С C/C++ вы, очевидно, идёте лесом.
Не правильные советы…
С2 именно там, где должен ( фильтр вч говна по питанию )
VD3 — SMBJ26A, срабатывание min 28.9V, max 31.9V
Предельно может выдержать ( долговременно ) до 42.1V, но для защиты самого диода стоит F1 ( самовостонавливающийся ) В схеме использован SMBJ26A с маркировкой LE ( unidirectional ) Делает «козу» в случае переполюсовки, заставляя работать F1.
Плата датчиков — универсальная. Сделана для поддержки «кучи» разных датчиков.
С2 именно там, где должен ( фильтр вч говна по питанию )


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

Если же вы зачем-то хотите фильтровать входящее питание по ВЧ (но зачем?), то надо ставить LC-фильтр нормальный.

У вас же в схеме C2 выполняет чисто декоративные функции.

VD3 — SMBJ26A, срабатывание min 28.9V, max 31.9V


Вы в даташите не на ту колонку смотрите.

Срабатывание даётся при прямом токе 1 мА, которого ваш предохранитель даже не заметит. Гарантированное срабатывание с токами, на которые предохранитель отреагирует, у SMBJ26A случается при 42,1 В.

Предельно может выдержать ( долговременно ) до 42.1V


У него вообще такого понятия «выдерживаемое напряжение» нет. У него есть выдерживаемая рассеиваемая мощность, в данном случае 600 Вт при продолжительности не более 1 мс.

В схеме использован SMBJ26A с маркировкой LE ( unidirectional )


Ваще если у него на корпусе написано «LE», то это SMBJ12A, с чем я вас и поздравляю.

SMBJxxA — униполярные по определению, потому что биполярные — это SMBJxxCA.

Делает «козу» в случае переполюсовки, заставляя работать F1


И VD1 тоже не нужен.
И DA1 — тоже не нужен. Можно сразу запитать сразу 5V. инвертор 24-5 только для запитки по проводу CAN ( БП один на много блоков. ) SMBJ — ну поставте, какой нравится! Сильно принципиально? Опечатался. Просто есть реализации на 12V… SMBJ26A есть как ME, так и CE ( в этом случае см. маркировку на корпусе ). По SMBJ26, не поленитесь, попробуйте вольтметром. Разброс срабатывания большой, но больше 35V мне не попались. Пробовал, как долго выдержит превышение напряжения. Диоды суровые. Отваливается от платы ( перегрев и олово жидкое ), но остаются живы.
Да, «тренируюсь» на диодах от ST.

Цитаты:
U проб. (В) – значение напряжения пробоя. В зарубежной технической документации этот параметр обозначается как VBR (Breakdown Voltage). Это значение напряжения, при котором диод резко открывается и отводит опасный импульс тока на общий провод («на землю»).

U огр. имп. (В) – максимальное импульсное напряжение ограничения. В даташитах обозначается как VCL или VC – Max. Clamping Voltage или просто Clamping Voltage.

Для гашения отдельных импульсов и есть цепь VD1-C3.

Да, схема действительно тривиальна:)
Я просто зафиксирую, что вы начали с «промышленную электронику надо уметь проектировать», а закончили на «даташит мне не указ, я вольтметром пробовал, у меня работает».

Причём даташит вам настолько не указ, что вы его даже не читали.

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

SMBJ26A есть как ME, так и CE


Чушь. SMBJ26A маркируется буквами «ME». Буквами «CE» маркируется SMBJ26CA.

U проб. (В) – значение напряжения пробоя. В зарубежной технической документации этот параметр обозначается как VBR (Breakdown Voltage). Это значение напряжения, при котором диод резко открывается и отводит опасный импульс тока на общий провод («на землю»).


Это, простите, цитата из кого — из вас? Потому что цитата из даташита выглядит иначе: «VBR Breakdown Voltage — Maximum voltage that flows though the TVS at a specified test current (IT)». IT указан ровно в следующей колонке таблицы и равен 1 мА.

Как вы думаете, если в даташите написано «1 мА», а вы разводите ля-ля про «резко открывается», я кому поверяю, вам или даташиту?

Для гашения отдельных импульсов и есть цепь VD1-C3


Я даже не буду спрашивать, как у вас конденсатор какие-то импульсы гасит, а то мы так быстро до проверки знания вами школьного курса физики дойдём, причём с заранее понятным результатом.
Гы. См. время зарядки конденсатора…
Есть мнение, что t=RC, причём и R, и C у вас очень маленькие, а также непонятно, какое вообще оно имеет значение.
Да, сплю почти…
Посмотрел, что у меня впаяно… SMBJ26A-TR BUK
С Vishay экспериментировал, но они мне почему то не понравились…
Смотрим на время импульса:
Peak pulse power:
– 600 W (10/1000 μs)
– 4 kW (8/20 µs)
( это для чего диод+емкость )
tp = 10ms Tj initial = Tamb 100 A
При постоянном напряжении ( см выше, что я писал ) может рассеять 5W, после чего нагревается и отваливается. Реально — не успевает ибо есть предохранитель.
По схеме: Вч импульсы часть гасит C2, что не смог — VD3. Более длительные фильтруется VD1+С3.
Вы вообще понимаете, что напряжение на конденсаторе тупо пропорционально его заряду, поэтому никакие импульсы он не гасит? А что постоянная времени при 0,1 мкФ у вас вообще в наносекундном диапазоне, вам калькулятор не подсказывает?
А я что выше написал? Вроде даже по-русски…
Выше вы написали грамматически корректный, но совершенно бессмысленный набор слов.
Уф-ты… А мужики то и не знают…
И — да. Стремился делать как можно проще и понятнее…
Сама по себе плата датчиков — только для датчиков и ничего более. Там какой то логики ( МК ) нет вообще. И инвертор DC-DC делался по принципу минимальной стоимости. Мог бы вполне сделать более компактное решение на мегагерцовых чипах, но цена буде в 4-6 раз выше.
Язык программирования для тех же датчиков… Пользователь работает с этими устройствами пакетами а-ля CAN. Устройство понимает установи сигналы — дай сигналы. Никто не мешает использовать стандартные PLC например от Siemens. Или ПК в качестве управляющего.
И инвертор DC-DC делался по принципу минимальной стоимости. Мог бы вполне сделать более компактное решение на мегагерцовых чипах, но цена буде в 4-6 раз выше


Давайте в абсолютных единицах? Ваш MC34063 стоит в пределах полудоллара в розницу, нормальный современный чип на 60 В входного напряжения — от силы $2,5-3,5. Трудно считать это гигантской разницей для промышленного оборудования.
Я покупаю по 25 р. за штуку. На алиэкпресс можно приобрести по 6-10 р. за штуку.
Напр:
http://ru.aliexpress.com/item/Free-shipping-40pcs-lot-SMBJ26A-ME-screen-TVS-transient-diode-DO-214AA-SMB-type-new-original/32518957153.html?spm=2114.03010208.3.55.PzBAcC&ws_ab_test=searchweb201556_7,searchweb201602_4_10039_10057_10065_10056_10055_10054_10069_10059_10058_10017_10070_10060_10061_10052_10062_10053_10050_10051,searchweb201603_1&btsid=5a055fac-0e61-4b28-94f6-4a70ad6d044b
Реализовать работу в пром условиях не так просто


На алиэкпресс можно приобрести по 6-10 р. за штуку


А когда у счастливого заказчика ваших контроллеров производственный процесс на денёк-другой остановится из-за того, что вам с алиэкспресса прислали отбраковку, зато по 6 рублей, вы ему какую сумму будете готовы компенсировать, если не секрет?
Ну да, на http://ru.mouser.com ( это не самый дешевый поставщик )
1шт: $0.611; 100шт: $0.455 но даже это не $2.5 В общем то я и писал, что разница минимум в 4 — 6 раз…
25 р. от 1 шт. — нормально? 20шт — 20р. 100шт — 17р.… ( с европейских складов )
Вы покупателям промышленных ПЛК как-нибудь расскажите, что вы на них два доллара экономите, реакция будет забавная.
На сайте что-то про идею написано… Читали?
Что за идею вы философски вещать можете бесконечно, мы уже все поняли, спасибо.
Да не за что… Ну я во всяком случае попытался…
Про защитные диоды: http://go-radio.ru/supressor.html
Может понятно станет схемотехническое решение, и почему именно так.
Может понятно станет схемотехническое решение, и почему именно так


Фейспалм, бесконечный фейспалм. Вы знаете, я вообще-то немного разрабатываю электронику посложнее вашей. И ещё немного руковожу другими разработчиками.

В ваших решениях понимать нечего. Они тупо неправильные. Вы не умеет грамотно разрабатывать электронику.

При этом вместо того, чтобы исправить эти в общем-то мелкие огрехи, которые можно хотя бы на банальную невнимательность списать, вы встали в позу и доказываете мне, что так и надо. Что как бы говорит нам, что не дай бог вы что-то серьёзнее решите разработать — там у вас будет шанс налажать куда масштабнее.
Трезвая самооценка:)
Опыт работы? Когда ЕГЭ сдали?
Данные решения появились не за 5 минут. Что-то объяснять вам далее — бессмысленно. Нести не аргументированную ахинею легче всего.
Вы сами что сделали для сообщества opensource?
А таких картинок я могу десятками генерить, они же ни к чему не обязывают. Вы реализуйте хотя бы одну.
Все, что нарисовано — от реализации:) Т.е. такие системы уже работают, причем не один год и некоторые в очень суровых условиях ( металлургия ). Как уже писал, начал делать и публиковать как open source то, что уже сделано и работает не один год. Да, нет списка готовых изделий. Начал «с конца», т.е. с периферийных устройств. Но и систему можно строить начиная с одной предельно низкой по цене платы.
Как-то все сложно написано имхо.

Если по-простому: я хочу попробовать lorawan, какой девайс я должен купить? В качестве оконечного устройства будет Raspberry Pi.

Небольшое гугление показало, что надо что-то типа такого?
https://www.cooking-hacks.com/lorawan-shield-for-raspberry-pi-868-mhz-xbee-socket

Если допустим, я решу создать свой gateway, тогда что нужно? И раз это wan, то где-то регистрироваться надо и все эти адреса прописывать?
Если по-простому: я хочу попробовать lorawan, какой девайс я должен купить?


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

С модулем же для ардуины самим по себе можно попробовать связь точка-точка или «звезду» на каком-нибудь собственном протоколе.

Если допустим, я решу создать свой gateway, тогда что нужно?


GW именно для LoRaWAN, с его полноценной поддержкой? Как минимум, нужна система на 4-8 чипах SX127x, как максимум — на одном SX1301. Диапазон тут широк, от голых модемов на SX1301 ($180-220), вешаемых на Raspberry Pi, до Kerlink и Cisco IR 910.

И раз это wan, то где-то регистрироваться надо и все эти адреса прописывать?


Если вы хотите делать конечные устройства для подключения к чужим LoRaWAN-сетям, им будут нужны официальные адреса EUI-64 — DevEUI для идентификации устройства и AppEUI для идентификации выполняемого на нём приложения. Адреса получаются как обычно — покупаются блоками у IEEE или поштучно в составе каких-либо чипов (например, DS2502-E64).
А будет опубликована информации по российской части LORAWAN?
Какой-нибудь аналог TTN.ru
Будет поддерживаться beacon?
Можно свой шлюз зарегистрировать (приватный/публичный) и использовать сервер для передаче?
Может пропустил эту информацию.
Это вопросы к операторам сетей. Мы с ними сотрудничаем и делаем для них железки, но мы — не оператор.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий