Комментарии 139
С интересом читаю ваш цикл статей, очень познавательно!
Я недавно закончил магистратуру в CMU, там плотно работал с профессором, который занимается связью, особенно IoT и LoRaWAN. Со многими проблемами, которые вы описываете (низкая скорость, лимиты на размер пакета, загруженность сети) мы тоже сталкивались и пытались решать.
У нас была идея в том, чтобы мультиплексировать доступ к сети через TDMA.
В основе этого решения — синхронизация времени на устройствах, этим я в основном и занимался. Если все пройдет удачно, эту работу могут принять в стандарт LoRaWAN — и может быть всем будет полегче строить поверх этого более нагруженные сети.
Я недавно закончил магистратуру в CMU, там плотно работал с профессором, который занимается связью, особенно IoT и LoRaWAN. Со многими проблемами, которые вы описываете (низкая скорость, лимиты на размер пакета, загруженность сети) мы тоже сталкивались и пытались решать.
У нас была идея в том, чтобы мультиплексировать доступ к сети через TDMA.
В основе этого решения — синхронизация времени на устройствах, этим я в основном и занимался. Если все пройдет удачно, эту работу могут принять в стандарт LoRaWAN — и может быть всем будет полегче строить поверх этого более нагруженные сети.
Кстати, очень много стартапов пилят свой стек, т.к. недовольны LoRaWAN.
А вы прямо связывались с LoRa Альянсом, и предлагали свои разработки?
А вы прямо связывались с LoRa Альянсом, и предлагали свои разработки?
Синхронизация времени на устройствах погубила стандарт CDMA. Где каждая БС синхронизируется по ЖПС или Глонасу. У нас целые кварталы от связи отваливались из-за повреждения ЖПС приемника. В ЖСМ такого нет и все работает.
CDMA погубило не это. Говорю вам как бывший сотрудник коммутатора челябинского CDMA-оператора.
GPS горели, бывало. Но точно так же случались другие проблемы и я бы не назвал эту проблему прям критичной. Всякое ломалось. Ну сменим раз в месяц одну антеннку из 50, ну и все. Терпимо.
Погубило нас отсутствие развития (Qualcomm как привез в 2000 свой коммутатор и железо, так и забил на проект) и, главное, необходимость освобождать частоты. Мы с трудом абонентов выгоняли на GSM, когда закрывались. Если б не частоты, даже в том виде, без развития и новинок, еще бы долго прожили. Я уж молчу про возможность развиваться.
GPS горели, бывало. Но точно так же случались другие проблемы и я бы не назвал эту проблему прям критичной. Всякое ломалось. Ну сменим раз в месяц одну антеннку из 50, ну и все. Терпимо.
Погубило нас отсутствие развития (Qualcomm как привез в 2000 свой коммутатор и железо, так и забил на проект) и, главное, необходимость освобождать частоты. Мы с трудом абонентов выгоняли на GSM, когда закрывались. Если б не частоты, даже в том виде, без развития и новинок, еще бы долго прожили. Я уж молчу про возможность развиваться.
Скайлинк, если не ошибаюсь, больше не существует тоже. В общем нет больше СДМА на территории РФ.
В Крыму, вроде, еще есть.
Скайлинк работал на частотах 450. Там шумновато, но им нормально было. Однако, их купил РТК и быстро свернул лавочку. Там больше политика, а не техника.
Но Скай — это CDMA2000, третье поколение.
Все операторы CDMA работали во втором — CDMAone. И вот они закрылись исключительно из-за частот, которые потом планировали под цифровое ТВ.
Скайлинк работал на частотах 450. Там шумновато, но им нормально было. Однако, их купил РТК и быстро свернул лавочку. Там больше политика, а не техника.
Но Скай — это CDMA2000, третье поколение.
Все операторы CDMA работали во втором — CDMAone. И вот они закрылись исключительно из-за частот, которые потом планировали под цифровое ТВ.
Добрый день, Существуют ли научные статьи по этому вопросу? На магистратуре иногда публикуют :)
Не совсем понял. Вам нужны научные статьи по CDMA?
Да, ближайшее к озвученной теме — о реализации time slot channel hopping в lora ieeexplore.ieee.org/document/7991972 (открытый доступ через sci-hub: sci-hub.tw/https://ieeexplore.ieee.org/document/7991972)
Еще вот анализ пропускной способности и поведения сети в реальных условиях со множеством узлов — Understanding the Limits of LoRaWAN — arxiv.org/pdf/1607.08011.pdf
Еще вот анализ пропускной способности и поведения сети в реальных условиях со множеством узлов — Understanding the Limits of LoRaWAN — arxiv.org/pdf/1607.08011.pdf
> Т.к. RS-485 подразумевает, что мы можем обратиться к устройству в любой момент, радиомодуль LoRa с его поддержкой должен быть класса С. То есть всегда слушать эфир и быть готовым ответить.
А если все таки нужно батарейное питание? Скажем, бывает ли такой режим у распространенных модулей, чтобы первый пакет разбудил модуль, а второй уже можно было принять?
А если все таки нужно батарейное питание? Скажем, бывает ли такой режим у распространенных модулей, чтобы первый пакет разбудил модуль, а второй уже можно было принять?
Нет, приёмник сам по себе слишком много жрёт, 11 мА в SX127x и в районе 5 мА в новых SX126x.
Есть класс B, нормально описанный только в свежей спецификации 1.1, он включается на послушать эфир по расписанию, без собственной передачи. Получается компромисс по энергопотреблению и доступности между A и C.
Ну и RS485 сам по себе не то чтобы сильно экономичный.
Есть класс B, нормально описанный только в свежей спецификации 1.1, он включается на послушать эфир по расписанию, без собственной передачи. Получается компромисс по энергопотреблению и доступности между A и C.
Ну и RS485 сам по себе не то чтобы сильно экономичный.
Спасибо, значит как вариант лишь сетевое + бэкап.
Вы спрашиваете именно про вариант работы «прозрачный канал»? Т.е. опрос модуля в любой момент времени?
Думаю, да. То есть, чтобы слушал, но в экономичном режиме, что-то вроде BLE 4.0.
Первыми пакетами можно пренебречь.
Т.е. нужна возможность постоянного вызова, с некоторой оперативностью — расписание не подойдет.
Первыми пакетами можно пренебречь.
Т.е. нужна возможность постоянного вызова, с некоторой оперативностью — расписание не подойдет.
Есть вариант с периодическим запуском на трансивере лоры режима CAD, Channel Activity Detection — он быстро слушает эфир на предмет наличия в нём преамбулы, и если таковой нет, засыпает.
Но если у вас эфир достаточно сильно загружен общением с другими устройствами, это не поможет — будет постоянно просыпаться на чужие пакеты. Кроме того, CAD делается однократно по команде, то есть требует просыпания микроконтроллера, и по очевидной причине периодичность этих просыпаний должна быть такой, чтобы преамбулу точно успеть поймать — а у неё фиксированная длина в символах, т.е. с падением SF и прембула становится всё короче…
P.S. Вообще у Семтека был калькулятор энергопотребления, можно скачать и поиграться.
Но если у вас эфир достаточно сильно загружен общением с другими устройствами, это не поможет — будет постоянно просыпаться на чужие пакеты. Кроме того, CAD делается однократно по команде, то есть требует просыпания микроконтроллера, и по очевидной причине периодичность этих просыпаний должна быть такой, чтобы преамбулу точно успеть поймать — а у неё фиксированная длина в символах, т.е. с падением SF и прембула становится всё короче…
P.S. Вообще у Семтека был калькулятор энергопотребления, можно скачать и поиграться.
То, что вы описали — на самом деле не проблемы. Проблемы будут, если начнёте подключать ещё более «умные» приборы по интерфейсам. Особенно, имеющими свои архивы. Текущие данные запросить несложно. А вот выкачать с какого-нибудь расходомера часовые архивы за несколько месяцев — вот тут и начнутся танцы с бубнами.
В общем случае такую задачу на LoRaWAN можно считать нерешаемой.
Ну либо решаемой, но дня за три неспешного скачивания тех архивов маленькими кусочками.
Ну либо решаемой, но дня за три неспешного скачивания тех архивов маленькими кусочками.
Вы сейчас очень сильно сузили область применения Лоры. По крайней мере для меня.
Видимо будущее промышленной телемеханики всё-таки за NB-Iot.
Видимо будущее промышленной телемеханики всё-таки за NB-Iot.
Ну, как только сможете найти NB-IoT вне зоны покрытия LTE…
) более правильный вопрос — когда NB-Iot запустится в коммерческую эксплуатацию? В Беларуси/Белоруссии уже вполне себе работает, по словам местных разработчиков.
Ну а в общем, где нет LTE придётся по старинке GPRS/EDGE/3G.
Ну а в общем, где нет LTE придётся по старинке GPRS/EDGE/3G.
Каждую техзадачу нужно решать отдельно. И смотреть, что для нее лучше подходит. Я бы не хоронил Лору прежде времени, однако для определенного круга задач она правда не самое лучшее решение. И если уж мы говорим о промышленном предприятии, то там может и NBIoT окажется не к месту, а самым рациональным решением станет… Ну не знаю? Wireless HART?)
Может так получится, что беспроводка вообще не годится, если стоит какая-нибудь электромагнитная плавильная печь.
Может так получится, что беспроводка вообще не годится, если стоит какая-нибудь электромагнитная плавильная печь.
Не знаете, есть ли на практике разница в энергопотреблении между одним и тем же датчиком на лоре и nb-iot?
NBIoT есть примерно в два раза больше LoRa на передаче и больше, чем в три раза на прием. Их не очень корректно сравнивать в лоб из-за разницы скоростей и общей разницы концепций. Однако, факт остается фактом, у NBIoT есть определенные проблемы с питанием и батареи им требуются хорошие.
Средняя температура по больнице примерно одинакова, но
1) у модулей NB-IoT пиковый ток при передаче на полной мощности — больше 200 мА, у LoRa — 30 мА
2) большая часть имеющихся сейчас в продаже модулей NB-IoT рассчитаны на работу от перезаряжаемого аккумулятора (3,2 — 4,2 В), LoRa — от батарейки (2,0 — 3,6 В)
В результате там, где лора годами живёт на ER14505 (3,6 В, 2400 мА*ч), придётся впихивать или обычный LiMNO2 3,0-вольтовый, или умощнённую ER14505M, которая способна вытянуть пиковое потребление NB-IoT, в обоих случаях с потерей в ёмкости в 20-30 %, а со многими модулями — ещё и с повышайкой до 3,6-3,8 В. И вот это будет печально.
1) у модулей NB-IoT пиковый ток при передаче на полной мощности — больше 200 мА, у LoRa — 30 мА
2) большая часть имеющихся сейчас в продаже модулей NB-IoT рассчитаны на работу от перезаряжаемого аккумулятора (3,2 — 4,2 В), LoRa — от батарейки (2,0 — 3,6 В)
В результате там, где лора годами живёт на ER14505 (3,6 В, 2400 мА*ч), придётся впихивать или обычный LiMNO2 3,0-вольтовый, или умощнённую ER14505M, которая способна вытянуть пиковое потребление NB-IoT, в обоих случаях с потерей в ёмкости в 20-30 %, а со многими модулями — ещё и с повышайкой до 3,6-3,8 В. И вот это будет печально.
За Wi-Fi.
NB-IoT — это та же лора, ну, может, чуть лучше, только с симкой.
Проблемы те же самые + дополнительные с регистрацией/установкой и обслуживанием симок.
NB-IoT — это та же лора, ну, может, чуть лучше, только с симкой.
Проблемы те же самые + дополнительные с регистрацией/установкой и обслуживанием симок.
Не согласен. NB-Iot будет доступен в зоне действия БС с поддержкой LTE. За инфраструктуру сети отвечают операторы сотовой связи. Канальный, транспортный, сетевой, и частично физический уровень OSI — всё на операторе сотовой связи. Для разворачивания требуется только купить и установить SIM-карту оператора, фирменный цвет, которого больше нравится. Причём работать будет, как в центре мегаполиса, так и в поле (не скоро и не точно). Wi-Fi же для этих целей — чуть ли не худший вариант.
Я лично ходил (потому, что даже внедорожник там не проедет) по лесам Псковщины и степям Астраханьщины и осуществлял пуско-наладку систем телеметрии по GSM.
Там, где между объектами телемеханизации десятки км ни Лора, ни тем более Wi-Fi не применимы.
Я лично ходил (потому, что даже внедорожник там не проедет) по лесам Псковщины и степям Астраханьщины и осуществлял пуско-наладку систем телеметрии по GSM.
Там, где между объектами телемеханизации десятки км ни Лора, ни тем более Wi-Fi не применимы.
А давайте еще более жесткий сценарий возьмем — сбор показаний на Луне!
1) Как в голове может умещаться «Просто установи сим карту» напротив «непролазных лесов и степей?» Я постоянно путешествую по местам, где никакиго LTE и даже 3G нет. Для этого достаточно сесть на электричку и проехать километров 30 от города.
2) Мухи отельно, котлеты отдельно. Промышленная автоматизация зданий и объектов и сбор показаний в условиях тундры — это два абсолютно разных сценария с абсолютно разными подходами/используемыми технологиями.
3) Если мы говорим о рынке, то автоматизация объектов, между которыми десятки километров — это жалкие крохи. В качестве контрпримера — ну да, сойдет. Как альтернативный сегмент рынка — нет. В городской и промышленной автоматизации Wi-Fi в большинстве сценариев будет лучшим решением.
1) Как в голове может умещаться «Просто установи сим карту» напротив «непролазных лесов и степей?» Я постоянно путешествую по местам, где никакиго LTE и даже 3G нет. Для этого достаточно сесть на электричку и проехать километров 30 от города.
2) Мухи отельно, котлеты отдельно. Промышленная автоматизация зданий и объектов и сбор показаний в условиях тундры — это два абсолютно разных сценария с абсолютно разными подходами/используемыми технологиями.
3) Если мы говорим о рынке, то автоматизация объектов, между которыми десятки километров — это жалкие крохи. В качестве контрпримера — ну да, сойдет. Как альтернативный сегмент рынка — нет. В городской и промышленной автоматизации Wi-Fi в большинстве сценариев будет лучшим решением.
В городской и промышленной автоматизации Wi-Fi в большинстве сценариев будет лучшим решением
Рассчитайте систему управления уличным освещением на Wi-Fi. 100 кв. км, 20 тысяч ламп.
Да что там уличное освещение, сделайте смеха ради проект съёма показаний с тех же водосчётчиков по Wi-Fi. Жилой дом, 160 квартир. С радиопланированием, гарантирующим покрытие, и счётчиками с ресурсом работы без смены элемента питания 8 лет.
Большинство из описанного уже есть.
Вас интересует решение или это был просто вброс «докажи, что ты не балабол»?
Вас интересует решение или это был просто вброс «докажи, что ты не балабол»?
Большинство из описанного уже есть
На вайфае?
Ну докажи, что ты не балабол.
А, уважаемый оппонент своё творчество пиарит…
Сколько реальных внедрений-то? Со сплошным покрытием ну хотя б вот дома на 160 квартир.
Сколько реальных внедрений-то? Со сплошным покрытием ну хотя б вот дома на 160 квартир.
Я пытаюсь достучаться до людей.
Вы, похоже, не поняли, что в таком варианте нет понятия «покрытие». Это другой подход.
Вы, похоже, не поняли, что в таком варианте нет понятия «покрытие». Это другой подход.
Да нет у вас никакого подхода, у вас только мечты о светлом будущем есть.
Возьмите план какого-нибудь П-44Т и расскажите нам, сколько вам потребуется роутеров для снятия показаний с водосчётчиков банальных, при выполнении трёх условий:
1) Wi-Fi роутеры стоят вне квартир
2) электропитание роутеров — от общедомовых нужд
3) выход из строя роутера на любом отдельном этаже связность сети не ломает
Ну и ссылку на водосчётчик с Wi-Fi и батарейкой на 8 лет заодно.
Возьмите план какого-нибудь П-44Т и расскажите нам, сколько вам потребуется роутеров для снятия показаний с водосчётчиков банальных, при выполнении трёх условий:
1) Wi-Fi роутеры стоят вне квартир
2) электропитание роутеров — от общедомовых нужд
3) выход из строя роутера на любом отдельном этаже связность сети не ломает
Ну и ссылку на водосчётчик с Wi-Fi и батарейкой на 8 лет заодно.
План брать нет никакой небходимости потому что:
1) Роутеры уже стоят в квартирах.
2) Электропитание роутеров уже обеспечивается жильцами квартир.
4) Выход клиентского роутера из строя раз в N лет не является критичным сценарием.
Вот у этих ребят точно были водосчетчики с вайфаем
telecan.ru/telekan-products. Это из отечественных. Импортных тоже много встречал, но с таким тоном беседы с вашей стороны, у меня все меньше желания ее продолжать.
Вы скажите, есть лихоть какая-то призначная надежда перевести наш диалог из разряда «А докажи, а дай, а покажи, а посчитай, у вас ничего нет» в сколь-нибудь конструктивное русло?
1) Роутеры уже стоят в квартирах.
2) Электропитание роутеров уже обеспечивается жильцами квартир.
4) Выход клиентского роутера из строя раз в N лет не является критичным сценарием.
Вот у этих ребят точно были водосчетчики с вайфаем
telecan.ru/telekan-products. Это из отечественных. Импортных тоже много встречал, но с таким тоном беседы с вашей стороны, у меня все меньше желания ее продолжать.
Вы скажите, есть лихоть какая-то призначная надежда перевести наш диалог из разряда «А докажи, а дай, а покажи, а посчитай, у вас ничего нет» в сколь-нибудь конструктивное русло?
facepalm.jpg
1) В квартире стоит мой роутер, а не ваш. Вас я в эту квартиру попросту не пущу.
2) Вы мне предлагаете за счастье обладания вашим роутером там, где он мне даром не нужен, ещё и платить?
3) Ну то есть в типовых домах из монолитного железобетона ваш роутер два перекрытия уверенно просвечивает?
Конечно. Я же вам предложил посчитать проект для П-44Т в реальных условиях, а не в сказке «все жильцы пошли и дружно сами себе наши роутеры поставили».
1) В квартире стоит мой роутер, а не ваш. Вас я в эту квартиру попросту не пущу.
2) Вы мне предлагаете за счастье обладания вашим роутером там, где он мне даром не нужен, ещё и платить?
3) Ну то есть в типовых домах из монолитного железобетона ваш роутер два перекрытия уверенно просвечивает?
Вы скажите, есть лихоть какая-то призначная надежда перевести наш диалог из разряда «А докажи, а дай, а покажи, а посчитай, у вас ничего нет» в сколь-нибудь конструктивное русло?
Конечно. Я же вам предложил посчитать проект для П-44Т в реальных условиях, а не в сказке «все жильцы пошли и дружно сами себе наши роутеры поставили».
Вы предложили посчитать проект не на релаьных условиях, а на ваших. И потом критиковали меня за то что я живу в воображаемом мире. А реальный мир таков, что
1) В квартирах стоят провайдерские роутеры. Там где стоят роутеры клиента — есть тысяча и один способ идентифицировать устройства за роутером и привязать их к конкретному абоненту.
2) Я предлагаю не платить там, где можно не платить.
3) Мир уже давно пришел к тому, что никто не пробивает железобетонные перекрытия, а наоборот снижают мощность роутеров и делают mesh внутри квартиры, либо соединяют проводами. Размораживайтесь скорее.
1) В квартирах стоят провайдерские роутеры. Там где стоят роутеры клиента — есть тысяча и один способ идентифицировать устройства за роутером и привязать их к конкретному абоненту.
2) Я предлагаю не платить там, где можно не платить.
3) Мир уже давно пришел к тому, что никто не пробивает железобетонные перекрытия, а наоборот снижают мощность роутеров и делают mesh внутри квартиры, либо соединяют проводами. Размораживайтесь скорее.
Вы предлагаете жильцам в частном порядке подключать водосчётчики к Wi-Fi собственных роутеров и передавать их показания по собственному интернет-каналу, что ли?
А если они не захотят, то вы что сделаете, бесплатные билеты на ваш следующий концерт предложите?
А если в квартире живёт бабулька, которой этот роутер даром не нужен? А если владелец квартиру сдаёт и считает, что подключение интернета — не его проблема? А если владелец в отпуск уехал и интернет на блокировку поставил? А если жилец горячую воду тырит кубометрами, засунув проволочку в крыльчатку счётчика, и все ваши новые технологии, которые помешают ему это делать, в гробу в белых тапках видел? А если стоящий где-то за унитазом счётчик вообще Wi-Fi от стоящего в гостиной через три стены роутера не ловит?
А если они не захотят, то вы что сделаете, бесплатные билеты на ваш следующий концерт предложите?
А если в квартире живёт бабулька, которой этот роутер даром не нужен? А если владелец квартиру сдаёт и считает, что подключение интернета — не его проблема? А если владелец в отпуск уехал и интернет на блокировку поставил? А если жилец горячую воду тырит кубометрами, засунув проволочку в крыльчатку счётчика, и все ваши новые технологии, которые помешают ему это делать, в гробу в белых тапках видел? А если стоящий где-то за унитазом счётчик вообще Wi-Fi от стоящего в гостиной через три стены роутера не ловит?
Давайте я продолжу
А если он сделал врезку в трубу и забирает воду мимо счетчика? А если клиент носит шапочку из фольги и принципиально не хочет, чтобы в его квартире были излучающие устрйоства? А если клиенту религия не позволяет иметь электронику в доме?
Ну и так далее.
Да, я предлагаю использовать уже готовый интернет канал и готовую инфраструктуру, имеющуюся у провайдеров. Потому что сбор показаний — это обязанность гражданина, закрепленная законодательно. А сделать сбор показаний доступным и удобным — обязанность провайдеров.
Если они (жильцы) не захотят — я предложу им бесплатно сборник ваших язвительных комментариев =)
А если он сделал врезку в трубу и забирает воду мимо счетчика? А если клиент носит шапочку из фольги и принципиально не хочет, чтобы в его квартире были излучающие устрйоства? А если клиенту религия не позволяет иметь электронику в доме?
Ну и так далее.
Да, я предлагаю использовать уже готовый интернет канал и готовую инфраструктуру, имеющуюся у провайдеров. Потому что сбор показаний — это обязанность гражданина, закрепленная законодательно. А сделать сбор показаний доступным и удобным — обязанность провайдеров.
Если они (жильцы) не захотят — я предложу им бесплатно сборник ваших язвительных комментариев =)
Врезку в трубу ему закон не велит.
А вот всё остальное делать он в полном и абсолютном праве.
А ещё однажды вы узнаете, что гражданину более чем достаточно раз в месяц позвонить в диспетчерскую и продиктовать циферки. Вся остальная же возня с почасовыми архивами и синхронизированным по времени съёмом показаний нужна не гражданину.
А вот всё остальное делать он в полном и абсолютном праве.
Потому что сбор показаний — это обязанность гражданина, закрепленная законодательно
А ещё однажды вы узнаете, что гражданину более чем достаточно раз в месяц позвонить в диспетчерскую и продиктовать циферки. Вся остальная же возня с почасовыми архивами и синхронизированным по времени съёмом показаний нужна не гражданину.
Хорошо, продолжайте говорить от имени граждан о том что им нужно, а что нет.
Я продолжу заниматься соим делом.
Я продолжу заниматься соим делом.
Как гражданин:
Читаю я вот это обсуждение и накладываю на себя:
- показания электричества — один раз в месяц уходят (если уходят, расчеты по среднему меня вот устраивают, последние месяцы уходят регулярно но только потому что у банка который я сейчас для платежей использую ну нельзя оплатить соответствующий счет не указав показания)
- газ — совсем не каждый месяц (спасибо тем личностям кто в интерфейсе гисжкх сделал ввод показаний за газ 3 дня в месяц, а разбиратся где там еще их указывать — желания нет)
WiFi у меня конечно же есть. Но при этом и роутер не провайдерский и конфигурация интересная и еще и меняется периодически (и для то же Яндекс. Станции пришлось специально прописывать настройки чтобы она могла нормально работать, яндекс почему то решил что внешний IP-адрес у домашней сети всегда один и тот же даже когда обращение к разным хостам идет). При этом настройка по большей части по гайдам с хабра (я не сетевой админ).
Обеспечивать работу левого железа которое только жрет канал и электричество а мне даже не дает себе архивы выгрузить — а зачем это мне? Если будет попытка именно принудительно — ну доступ получит это железо, как оно будет работать — их проблемы (или пусть внятно объясняют что не так и отвечают на все мои вопросы), меня вариант с вводом данных руками раз в месяц — устраивает.
1) Роутеры уже стоят в квартирах.
С чего бы это? Вот прямо в каждой квартире у каждой семьи в стране по роутеру.
Вот у этих ребят точно были водосчетчики с вайфаем
Ага. Снимаем установленные застройщиком и заменяем на модные с вай-фаем за свой счёт. Или мы идём к застройщику и говорим — друг, не ставь счётчики за 700 рублей, ставь за 4500. Разницу в стоимости на 200 квартир можете посчитать сами.
Потрудитесь сперва читать, а потом писать.
По ссылке не счетчики, а модули снятия и передачи показаний.
По ссылке не счетчики, а модули снятия и передачи показаний.
Проблема не в счётчиках как таковых, со счётчиками в принципе решить можно (можно даже собранием жильцов перевести их в общедомовую собственность, тогда УК может за свои деньги их менять).
Но вот идея обеспечение инфраструктуры повесить на жильцов — это однозначно из страны, где единороги бегают по радуге.
Вся обслуживающая передачу показаний инфраструктура должна находиться за пределами квартиры и никак не зависеть от собственника и/или жильцов.
Но вот идея обеспечение инфраструктуры повесить на жильцов — это однозначно из страны, где единороги бегают по радуге.
Вся обслуживающая передачу показаний инфраструктура должна находиться за пределами квартиры и никак не зависеть от собственника и/или жильцов.
В вашем докладе при сравнении технологий передачи данный для IoT есть одна логическая ошибка. Вы во главу угла ставите пропускную способность канала. Для задач IoT это не принципиальный параметр. Возьмём ЖКХ. Счётчик воды с импульсным выходом. Данные в управляющую передаются 1 (один) раз в месяц. Какой объём данных? Далее на вскидку: количество подсчитанных импульсов — от 4 до 8 байт, UID прибора — 4 байта, контрольная сумма (если у нас NB-IoT и TCP, то не обязательно) — 2 байта. Итого: 14 байт. Усложняем. Добавляем временную метку — от 4 до 8 байт, флаг срабатывания датчика магнитного поля (мы же крутые ребята) — 1 байт. Сумма — 23 байта. Какая-нибудь транспортная обвязка — ещё плюс 4-5 байт. 28 байт в месяц.
Ладно, чего мелочится, накидываем ещё сервисных данных столько же.
56 байт. 56 байт в месяц, Карл!
Хорошо, усложняем задачу. Мы ведём суточные архивы. Что такое архивная запись — время записи + данные. Берём по максимуму 8 байт на время, 8 байт на количество импульсов, 1 байт на магнит. 17 байт. В среднем в месяце 30 дней. 30 * 17 = 510 байт. Плюс всякая транспортная обвязка, грубо 530 байт. Суточные архивы за месяц 530 байт. Один раз в месяц.
Вы будете продолжать утверждать, что это задача для Wi-Fi?
Ладно, чего мелочится, накидываем ещё сервисных данных столько же.
56 байт. 56 байт в месяц, Карл!
Хорошо, усложняем задачу. Мы ведём суточные архивы. Что такое архивная запись — время записи + данные. Берём по максимуму 8 байт на время, 8 байт на количество импульсов, 1 байт на магнит. 17 байт. В среднем в месяце 30 дней. 30 * 17 = 510 байт. Плюс всякая транспортная обвязка, грубо 530 байт. Суточные архивы за месяц 530 байт. Один раз в месяц.
Вы будете продолжать утверждать, что это задача для Wi-Fi?
Данные в управляющую передаются 1 (один) раз в месяц
Это не совсем так, ибо с внедрением автоснятия показаний все начинают хотеть почасовой архив.
Но у докладчика проблема не в этом, а в том, что он живёт в воображаемом мире. Это так бывает со многими стартапами, которые рисуют красивые коттеджные посёлки, оснащённые их уникальной технологией — а потом сталкиваются лбом с типовой многоэтажкой в 22 этажа, где им их красивый роутер разрешают вешать строго внутри электрощитка. Единственного на этаж, закрывающегося стальной крышкой и отделённого от наиболее удалённого водосчётчика пятью бетонными стенами.
Это не совсем так, ибо с внедрением автоснятия показаний все начинают хотеть почасовой архив.
Да хоть так. Многомегабитный канал для этого не нужен. А проблем с созданием инфраструктуры Wi-Fi for IoT даже на первый взгляд достаточно.
Ну да.
У лоры, на самом деле, в городском хозяйстве есть область, где она так себе — АСУНО, уличное освещение, то есть. Если заказчику нужно оперативное управление (т.е. возможность диспетчеру тыкнуть мышкой «зажечь лампы по этой улице прям ща») и/или оперативная реакция устройств (т.е. в течение 3 минут после включения мы получаем рапорт, где чего не загорелось), то лора на это не ложится, при тысяче ламп индивидуальное управление ими тянет на десятки минут.
Но даже здесь Wi-Fi — как рыбе зонтик, есть же 802.15.4 тот же.
У лоры, на самом деле, в городском хозяйстве есть область, где она так себе — АСУНО, уличное освещение, то есть. Если заказчику нужно оперативное управление (т.е. возможность диспетчеру тыкнуть мышкой «зажечь лампы по этой улице прям ща») и/или оперативная реакция устройств (т.е. в течение 3 минут после включения мы получаем рапорт, где чего не загорелось), то лора на это не ложится, при тысяче ламп индивидуальное управление ими тянет на десятки минут.
Но даже здесь Wi-Fi — как рыбе зонтик, есть же 802.15.4 тот же.
Если есть сетевое энергоснабжение, открытое пространство, небольшие расстояния между объектами, необходимость мониторинга нон-стоп, то тут вполне допускаю. А через Wi-Fi роутеры можно и халяву раздавать.
Например, мы говорим о каком-нибудь парке с толпами гуляющих.
Тут лора в принципе пролетает, у неё совсем другие задачи. NB-Iot тоже не нужен. На каждый фонарь по абоненту через каждые 5 метров — избыточно.
Но изначально тов. Klukonin заявил, что «Будущее промышленной телемеханики за Wi-Fi». Что явно не соответствует действительности.
Например, мы говорим о каком-нибудь парке с толпами гуляющих.
Тут лора в принципе пролетает, у неё совсем другие задачи. NB-Iot тоже не нужен. На каждый фонарь по абоненту через каждые 5 метров — избыточно.
Но изначально тов. Klukonin заявил, что «Будущее промышленной телемеханики за Wi-Fi». Что явно не соответствует действительности.
У нас для лоры есть свой MAC-уровень, позволяющий дёшево и просто покрывать одиночные объекты, на сотню-другую абонентов и километр-два радиусом.
Это всяко проще, чем городить Wi-Fi.
Это всяко проще, чем городить Wi-Fi.
Да я в курсе возможностей лоры. У меня знакомые разворачивают сеть. net868.ru
Виталию привет. :)
Виталия не знаю. Вот этого знаю net868.ru/blog/1078
Кстати, популярная тема накрутить на LoRa свой стек. У меня только две знакомые конторы каждый свой разработали. Однако, все они упираются в одно. Если есть крупный заказчик (а не проект под ключ, который более не будет развиваться), ему нужен классический стандарт, чтоб потом не сидеть с неразвивающимся и непонятным другим устройствам стеком.
Это потому что все эти проекты сначала мечтают, что они сделают свой ни с чем не совместимый стек — и всем придётся покупать только их устройства, а потом идут с ними в проекты, где заказчик изначально не планирует покупать только их устройства.
Не надо так. Надо начинать с устройств, которые больше не у кого купить, а потом уже заказчику будет всё равно, какой там стек ;)
Не надо так. Надо начинать с устройств, которые больше не у кого купить, а потом уже заказчику будет всё равно, какой там стек ;)
Если такой разработчик не разбегается через полтора-два года и у него появляется задача интегрироваться в сторонние системы, то нагугливается технология OPC. Большинство промышленных SCADA в неё умеют.
У вас есть расчеты, опровергающие мои, чтобы говорить о несоответствии действительности?
Да какие расчёты? Начнём с вопроса: соответствует ли ваше оборудование температурным требованиям промышленного исполнения? От минус 40 до плюс 70 по Цельсию? Работают ли они при влажности воздуха 98%? Имеется ли взрывобезопасное исполнение? Находится ли оно в реестре средств измерений? Как вы будете организовывать передачу данных с объекта, находящегося в нескольких десятках км от ближайшего населённого пункта, не оснащённого энергоснабжением?
Опять двадцать пять.
Мухи отдельно, котлеты отдельно.
Когда речь идет о технологии передачи данных и конкретном сценарии использования, есть ли смысл переводить разговор в русло обсуждения работы в условиях тундры, взрывозащищенных корпусов, промышленных исполненй итп? Правильно, никакого смысла в этом нет.
Мухи отдельно, котлеты отдельно.
Когда речь идет о технологии передачи данных и конкретном сценарии использования, есть ли смысл переводить разговор в русло обсуждения работы в условиях тундры, взрывозащищенных корпусов, промышленных исполненй итп? Правильно, никакого смысла в этом нет.
Пони бегают по кругу. Я говорил изначально о промышленной телемеханике. Ключевое слово — промышленная.
Лору при желании можно притянуть к некоторым задачам промышленной телеметрии (без механики). Wi-Fi — я вариантов не вижу.
Лору при желании можно притянуть к некоторым задачам промышленной телеметрии (без механики). Wi-Fi — я вариантов не вижу.
" — Видишь суслика?
— Нет…
— А он есть..."
www.omega.de/pptst/WSERIES.html
www.monnit.com/Product/MNS-9-WF-MV-VD
www.icpdas-usa.com/wf_2051.html
— Нет…
— А он есть..."
www.omega.de/pptst/WSERIES.html
www.monnit.com/Product/MNS-9-WF-MV-VD
www.icpdas-usa.com/wf_2051.html
Господа теоретики и программисты. У нас в РФ нефтегазовые месторождения на беспроводке мониторятся. Уже лет 10 все работает, уже лет 10 все взрывозащищено по умолчанию и имеет ТР ТС, уже лет 10 все в реестре СИ. Да, проблемы есть. Да, низкая температура это враг батареи. Но -40 это не самое страшное. -60 вот вызов. Все работает так как надо. Обращайтесь если нужен эксперт.
С уважением, просто практик беспроводных сетей.
С уважением, просто практик беспроводных сетей.
Это проект. Если выстрелит — хорошо, но, на мой взгляд не оптимальный выбор технологии.
В нашем городе стабильно раз в 2-3 года на сайте мэрии и всяких причастных компаний печатаются проекты создания метрополитена. Вот только метро как не было так и нет, и в ближайшие 20-30 лет точно не будет. Хотя даже по официальным данным в городе полтора миллиона человек и наземная транспортная инфраструктура уже давно в коленно-локтевой позе.
В нашем городе стабильно раз в 2-3 года на сайте мэрии и всяких причастных компаний печатаются проекты создания метрополитена. Вот только метро как не было так и нет, и в ближайшие 20-30 лет точно не будет. Хотя даже по официальным данным в городе полтора миллиона человек и наземная транспортная инфраструктура уже давно в коленно-локтевой позе.
Но там уже введено в эксплуатацию (тестовую) как минимум 500 устройств. Значит, стадия обещаний давно пройдена.
есть же 802.15.4 тот же.— ложки нет. Он мертв. И я объяснял почему.
В моем докладе и моих статьях есть четкие обоснования, таблицы и результаты вычислений, объясняющие почему во главу угла ставится пакетный бюджет, напрямую зависящий от канальной скорости. Никакой логической ошибки там нет.
Я буду продолжать утверждать, что 1 раз в месяц — ничтожно мало и нужно ориентироваться на «несколько раз в день».
И каждый раз передавать не UID прибора + данные, а журнал сбора показаний с интервалом в несколько минут. Это и будет приближено к тому что называют интернет вещей. В идеальном мире это должнобыть реалтайм.
Потом я в очередной раз напомню о необходимочти обновления по воздуху и все вернется на круги своя. Ни LoRa, ни NB-IoT такое не вывезут. А вайфай вывезет.
Я буду продолжать утверждать, что 1 раз в месяц — ничтожно мало и нужно ориентироваться на «несколько раз в день».
И каждый раз передавать не UID прибора + данные, а журнал сбора показаний с интервалом в несколько минут. Это и будет приближено к тому что называют интернет вещей. В идеальном мире это должнобыть реалтайм.
Потом я в очередной раз напомню о необходимочти обновления по воздуху и все вернется на круги своя. Ни LoRa, ни NB-IoT такое не вывезут. А вайфай вывезет.
Логической ошибки у вас там действительно нет.
У вас ошибка только в том, что все эти чёткие обоснование приведены для воображаемого мира.
А в реальном вы расшибёте лоб.
У вас ошибка только в том, что все эти чёткие обоснование приведены для воображаемого мира.
А в реальном вы расшибёте лоб.
NB-IoT такое не вывезут
Мы на CSD и GPRS прекрасно вывозим. Вывозилось даже по v.23 на 1200 бит/с (хоть и очень давно). Даже с учётом кривого протокола обновления, который не допускает пакеты более 256 байт (руки не доходят исправить уже много лет) эта процедура занимает 20-30 минут. Да и вообще не так уж и часто приходится это делать. Самое частое на моей памяти — раз в год (а работаю я в текущей сфере уже 8 лет).
1 раз в месяц — ничтожно мало и нужно ориентироваться на «несколько раз в день».
Окей, несколько раз в день передаём по 28 байт текучки. Пусть 24 раза по 28 байт — 672 байта. Смысл такой частоты передачи оставляем на вашей совести ). И для этих 672 байт нужна скорость 65000 кб/с по таблице из вашего доклада?
И каждый раз передавать не UID прибора + данные, а журнал сбора показаний с интервалом в несколько минут.
Попробуйте объяснить зачем управляющей компании поминутный расход воды?
На самом деле, запросы есть. Хотят оперативно мониторить аварии. Но это из разряда будущего, пока раз в час много.
Для оперативного мониторинга нужен не поминутный журнал, а поминутная передача — а это с разумным расходом батарейки по беспроводке невозможно ни на какой технологии.
Реальное время такое же враг батареи, как и низкая температура :).
Хороший цикл статей, спасибо
А LoRa рассчитана исключительно на стационарные оконечные устройства? Или есть варианты с редкоподвижными (раз в день/неделю/месяц) переехали в зону действия другой БС? И просто подвижные, когда оконечное устройство может начать передачу в момент движения?
А LoRa рассчитана исключительно на стационарные оконечные устройства? Или есть варианты с редкоподвижными (раз в день/неделю/месяц) переехали в зону действия другой БС? И просто подвижные, когда оконечное устройство может начать передачу в момент движения?
Устройства могут быть мобильными. Спецификация это предусматривает.
Если брать практику, то я пробовал возить устройство с собой в машине по городу — потери пакетов не наблюдалось. Однако, прям длительных тестов на подвижность не делали и уж точно не тестировали на больших скоростях.
Спасибо за отзыв)
Если брать практику, то я пробовал возить устройство с собой в машине по городу — потери пакетов не наблюдалось. Однако, прям длительных тестов на подвижность не делали и уж точно не тестировали на больших скоростях.
Спасибо за отзыв)
LoRa — это физуровень, канал связи.
MAC поверх него может быть разный, если это LoRaWAN, то в нём роуминг между БС одного оператора автоматический. Там БС вообще тупая как пробка, её задача — сигнал из эфира принял, в обёртку завернул и по эзернету или 3G в сторону сетевого сервера выплюнул.
MAC поверх него может быть разный, если это LoRaWAN, то в нём роуминг между БС одного оператора автоматический. Там БС вообще тупая как пробка, её задача — сигнал из эфира принял, в обёртку завернул и по эзернету или 3G в сторону сетевого сервера выплюнул.
Ну вот и вылезла ограниченность применения.
Только кажется, что посчитать импульсы и передать их — это достаточно. Это достаточно для курсовой работы первого курса, по факту задачки сбора показаний со счетчиков — посложнее. Сразу оговорюсь, что серебряной пули нет, но:
— при сборе показаний с теплосчетчика желательно видеть все измеряемые величины — обе температуры, расход теплоносителя, код состояния (в рудиментарном случае квартирного теплосчетчика). Если нет импульсов от квартирного теплосчетчика, то может быть целый набор ситуаций (разрешенных и нет) от закрытых кранов до оборванного термометра или застопреной крыльчатки. Через импульсный выход этого не увидеть и одно состояние от другого не отличить. Как и от оборванного импульсного выхода. В случае общедомового (промышленного) теплосчетчика — параметров может быть в разы больше.
Архив на сервере — хорошо, но как только часы LORA-устройства разойдутся с часами теплосчетчика, а это точно произойдет, весь архив на сервере потеряет ценность.
С электросчетчиками — абсолютно аналогичная ситуация, еще более осложненная «двухтарифностью» — часы разойдутся, и показания с LORA — устройства обесценятся.
Если быть правдивым, не совсем обесценятся — они станут тем, что в среде метрологов называют «показометром» — им можно верить «для личного пользования», но их нельзя использовать для коммерческих расчетов.
Вода — тут тоже непросто, но сложности другие. Через импульсный выход нельзя отличить, крутится счетчик вперед или назад, когда крутился вперед-назад (это проблема перетока в смесителях и кривых разводках труб, встречается в каждом доме обязательно), воздействие магнитов и когда провод импульсного выхода оборван. Частично эту проблему решает НАМУР (для детекта оборванности импульсного выхода), остальные можно решить только встраивая интерфейс в счетчик.
И тогда получается, что в многоквартирных домах провод всегда дешевле для электросчетчиков и теплосчетчиков — т.к. они в 95% случаем стоят в местах общего пользования, для водосчетчиков решение импульс+радиопередача — живое, но такие решения есть уже лет 10, и живые и работают и без LORA.
Получается, что сегмент применения, где решение действительно даст что-то, чего не было раньше — это передача на более-менее большие расстояния — коттеджные поселки, деревни, дачи? Тут они конкурируют с NB-IOT и GPRS.
Одиноко стоящие подстанции и промышленные узлы учета всегда проще оборудовать GPRS-модемом. Даже электросчетчики, которые сейчас в загородных поселках выносят группами на улицу проще оборудовать одним GPRS-модемом.
Получатся что сегмент очень ограничен. По крайней мере в ЖКХ.
Только кажется, что посчитать импульсы и передать их — это достаточно. Это достаточно для курсовой работы первого курса, по факту задачки сбора показаний со счетчиков — посложнее. Сразу оговорюсь, что серебряной пули нет, но:
— при сборе показаний с теплосчетчика желательно видеть все измеряемые величины — обе температуры, расход теплоносителя, код состояния (в рудиментарном случае квартирного теплосчетчика). Если нет импульсов от квартирного теплосчетчика, то может быть целый набор ситуаций (разрешенных и нет) от закрытых кранов до оборванного термометра или застопреной крыльчатки. Через импульсный выход этого не увидеть и одно состояние от другого не отличить. Как и от оборванного импульсного выхода. В случае общедомового (промышленного) теплосчетчика — параметров может быть в разы больше.
Архив на сервере — хорошо, но как только часы LORA-устройства разойдутся с часами теплосчетчика, а это точно произойдет, весь архив на сервере потеряет ценность.
С электросчетчиками — абсолютно аналогичная ситуация, еще более осложненная «двухтарифностью» — часы разойдутся, и показания с LORA — устройства обесценятся.
Если быть правдивым, не совсем обесценятся — они станут тем, что в среде метрологов называют «показометром» — им можно верить «для личного пользования», но их нельзя использовать для коммерческих расчетов.
Вода — тут тоже непросто, но сложности другие. Через импульсный выход нельзя отличить, крутится счетчик вперед или назад, когда крутился вперед-назад (это проблема перетока в смесителях и кривых разводках труб, встречается в каждом доме обязательно), воздействие магнитов и когда провод импульсного выхода оборван. Частично эту проблему решает НАМУР (для детекта оборванности импульсного выхода), остальные можно решить только встраивая интерфейс в счетчик.
И тогда получается, что в многоквартирных домах провод всегда дешевле для электросчетчиков и теплосчетчиков — т.к. они в 95% случаем стоят в местах общего пользования, для водосчетчиков решение импульс+радиопередача — живое, но такие решения есть уже лет 10, и живые и работают и без LORA.
Получается, что сегмент применения, где решение действительно даст что-то, чего не было раньше — это передача на более-менее большие расстояния — коттеджные поселки, деревни, дачи? Тут они конкурируют с NB-IOT и GPRS.
Одиноко стоящие подстанции и промышленные узлы учета всегда проще оборудовать GPRS-модемом. Даже электросчетчики, которые сейчас в загородных поселках выносят группами на улицу проще оборудовать одним GPRS-модемом.
Получатся что сегмент очень ограничен. По крайней мере в ЖКХ.
Давайте по порядку.
1) Не следует путать систему телеметрии с системой контроля хитрости) Меня часто спрашивают — может ли LoRa как-то помочь против магнитов или иных уловок на индивидуальных приборах учета. У меня один ответ.
А парень с карандашом и блокнотом, который попадает в одну квартиру из пяти или показания жильцов, которые они вбивают через Интернет смогут помочь выявить магнит?)
Насчет обрыва — у нас есть система мониторинга, что внезапно стали приходить нулевые значения. Само по себе это еще ничего не значит, но повод назначить ремонт на объект.
Кроме того, внешние радиомодули — это все-таки переходный период. Я думаю, что скоро будем иметь устройства с интегрированным радиомодулем. И вот тогда NBIoT потребует куда большей батарейки. Я уж молчу про GPRS, к нему вообще допшкаф понадобится)
2) Я не совсем понял вашу мысль с часами. Ну вот будет у нас рассинхрон c внутренними часами теплосчетчика. Ну или электросчетчика. Почему показания обесценятся? Вы считаете, что этот рассинхрон набежит в полчаса?
1) Не следует путать систему телеметрии с системой контроля хитрости) Меня часто спрашивают — может ли LoRa как-то помочь против магнитов или иных уловок на индивидуальных приборах учета. У меня один ответ.
А парень с карандашом и блокнотом, который попадает в одну квартиру из пяти или показания жильцов, которые они вбивают через Интернет смогут помочь выявить магнит?)
Насчет обрыва — у нас есть система мониторинга, что внезапно стали приходить нулевые значения. Само по себе это еще ничего не значит, но повод назначить ремонт на объект.
Кроме того, внешние радиомодули — это все-таки переходный период. Я думаю, что скоро будем иметь устройства с интегрированным радиомодулем. И вот тогда NBIoT потребует куда большей батарейки. Я уж молчу про GPRS, к нему вообще допшкаф понадобится)
2) Я не совсем понял вашу мысль с часами. Ну вот будет у нас рассинхрон c внутренними часами теплосчетчика. Ну или электросчетчика. Почему показания обесценятся? Вы считаете, что этот рассинхрон набежит в полчаса?
1) Я и не путаю. Я знаю реальные требования заказчиков, и они живут не в идеальном мире систем с узким предназначением, им надо решать комплексные проблемы, и данные снимать, и манипуляции отслеживать. И эволюция систем уже давно повернула в эту сторону.
Насчет обрыва — вы не сможете отличить — человек уехал в отпуск или у него сломался счетчик. И вы назначаете выезд на ремонт. Вы систему создаете, чтобы этих выездов не было, тем более — ложных.
Что касается GPRS — то вы тоже не правы. Никто не заставляет держать модуль GPRS постоянно включенным. А системы, которые его включат с настраиваемым интервалом для передачи данных я первый раз видел на выставке лет 6 назад. И работают нормально в своих сегментах.
Про часы написал ниже.
Не у всех, кто выходит на этот рынок, хватает широты взгляда чтобы оценить, что до них эту тему качают уже два десятка лет, и люди общаются с заказчиком и под его требования разрабатывают системы. И все это вымучено, выстрадано, многократно пропущено через себя и множество разнообразных кейсов. И многочисленные «невзлеты» новичков на этом поприще — это как раз из-за этого. Когда они это понимают, у них уже кончаются деньги.
Система сбора данных — это не самоцель, это лишь инструмент для решения совсем других проблем. И не надо думать, что кому-то нужна «чистая телеметрия и больше ничего». Как самоцель, по крайней мере в ЖКХ, она не нужна никому.
Насчет обрыва — вы не сможете отличить — человек уехал в отпуск или у него сломался счетчик. И вы назначаете выезд на ремонт. Вы систему создаете, чтобы этих выездов не было, тем более — ложных.
Что касается GPRS — то вы тоже не правы. Никто не заставляет держать модуль GPRS постоянно включенным. А системы, которые его включат с настраиваемым интервалом для передачи данных я первый раз видел на выставке лет 6 назад. И работают нормально в своих сегментах.
Про часы написал ниже.
Не у всех, кто выходит на этот рынок, хватает широты взгляда чтобы оценить, что до них эту тему качают уже два десятка лет, и люди общаются с заказчиком и под его требования разрабатывают системы. И все это вымучено, выстрадано, многократно пропущено через себя и множество разнообразных кейсов. И многочисленные «невзлеты» новичков на этом поприще — это как раз из-за этого. Когда они это понимают, у них уже кончаются деньги.
Система сбора данных — это не самоцель, это лишь инструмент для решения совсем других проблем. И не надо думать, что кому-то нужна «чистая телеметрия и больше ничего». Как самоцель, по крайней мере в ЖКХ, она не нужна никому.
1) ОК, давайте поговорим про решение проблем воровства. Как вы хотите сделать это с помощью GPRS?
Собрать в одном корпусе индивидуальный водосчетчик, батарейку и передатчик GPRS не получится. Точнее получится, но долго эта конструкция не проживет. А вот на Лоре это вполне реализуемо.
2) Вы преувеличиваете проблему рассинхрона. Часы радимодуля можно подводить специальной командой. Пока таких проблем нет, но если они возникнут — просто добавим серверу в задачи отправлять команду синхронизации раз в… ну пусть раз в месяц. И все у нас будет актуально.
Что же касается внутренних часов теплосчетчика, был бы у них сертификат, если бы в конце срока эксплуатации там был рассинхрон в десятки минут?
3) Ну и наконец. Мы же можем запрашивать время с теплосчетчика, как один из параметров. И вуаля! У нас данные с первичного источника.
Собрать в одном корпусе индивидуальный водосчетчик, батарейку и передатчик GPRS не получится. Точнее получится, но долго эта конструкция не проживет. А вот на Лоре это вполне реализуемо.
2) Вы преувеличиваете проблему рассинхрона. Часы радимодуля можно подводить специальной командой. Пока таких проблем нет, но если они возникнут — просто добавим серверу в задачи отправлять команду синхронизации раз в… ну пусть раз в месяц. И все у нас будет актуально.
Что же касается внутренних часов теплосчетчика, был бы у них сертификат, если бы в конце срока эксплуатации там был рассинхрон в десятки минут?
3) Ну и наконец. Мы же можем запрашивать время с теплосчетчика, как один из параметров. И вуаля! У нас данные с первичного источника.
1) Я не говорил, что «водосчетчик со встроенным GPRS» — это решение. Я сразу написал —
Я писал вам про то, что реализуемо на Лоре — уже 10 лет как есть на рынке, и ничего нового с точки зрения эксплуатации, с точки зрения приближения к этой самой «серебряной пуле» она (Лора) не предлагает.
2) Во всех документах, в ПП354, в правилах учета ТЭ и ТН — везде фигурирует первичный прибор и его архив. Нигде не написано, что его часы должны иметь сертификат. Но он — первичный прибор. И в итоге будут обращаться к его архиву. А если ваша система выдает данные, отличные от его архива, то доверия нет к системе, а не к прибору. Если вы посылаете безграмотного человека снимать показания, и он их неверно переписал — то нет доверия к системе (снятия показаний), а не к прибору. Пока у прибора есть поверка — доверие к нему абсолютное.
3) Ну да, я сам это написал ниже часов пять назад. Я думаю, что это костыль, и на нем далеко не уедешь.
Сразу оговорюсь, что серебряной пули нет
Я писал вам про то, что реализуемо на Лоре — уже 10 лет как есть на рынке, и ничего нового с точки зрения эксплуатации, с точки зрения приближения к этой самой «серебряной пуле» она (Лора) не предлагает.
2) Во всех документах, в ПП354, в правилах учета ТЭ и ТН — везде фигурирует первичный прибор и его архив. Нигде не написано, что его часы должны иметь сертификат. Но он — первичный прибор. И в итоге будут обращаться к его архиву. А если ваша система выдает данные, отличные от его архива, то доверия нет к системе, а не к прибору. Если вы посылаете безграмотного человека снимать показания, и он их неверно переписал — то нет доверия к системе (снятия показаний), а не к прибору. Пока у прибора есть поверка — доверие к нему абсолютное.
3) Ну да, я сам это написал ниже часов пять назад. Я думаю, что это костыль, и на нем далеко не уедешь.
1) Серебряной пули нет, тут вы правы. Но все ищут решение максимально приближенное к идеалу.
С моей колокольни — это устройства с интегрированными передатчиками. Я могу быть не прав.
2) и 3) А почему вы считаете, что забирать время у прибора учета — это костыль? Получается, что любая система диспетчеризации — это костыль?
С моей колокольни — это устройства с интегрированными передатчиками. Я могу быть не прав.
2) и 3) А почему вы считаете, что забирать время у прибора учета — это костыль? Получается, что любая система диспетчеризации — это костыль?
1) Я с вами согласен, устройства с интегрированными передатчиками — это решение.
2)3) предвижу сложности с разными приборами, разными протоколами, переводом часов и сменой тарифных расписаний, возведенное в степень абсурда происходящего вокруг. Но волков бояться — в лес не ходить, как завещал нам анекдот — «хули думать — прыгать надо»
2)3) предвижу сложности с разными приборами, разными протоколами, переводом часов и сменой тарифных расписаний, возведенное в степень абсурда происходящего вокруг. Но волков бояться — в лес не ходить, как завещал нам анекдот — «хули думать — прыгать надо»
Никого не волнует рассинхрон одной железки с другой железкой. Рассинхрона не должно быть с московским временем — и на радиомодуле с двунаправленным каналом это обеспечить с приемлемой точностью (плюс-минус секунды) можно.
Ценность собственных часов счётчика в этом случае остаётся значимой постольку, поскольку он хранит архив показаний и является первичным средством измерения. Если, однако, радиоинтерфейс, даже внешний, сертифицирован как средство измерения, то сам счётчик часов может хоть вообще больше не иметь.
Ценность собственных часов счётчика в этом случае остаётся значимой постольку, поскольку он хранит архив показаний и является первичным средством измерения. Если, однако, радиоинтерфейс, даже внешний, сертифицирован как средство измерения, то сам счётчик часов может хоть вообще больше не иметь.
Ну да, примерно так. Как только у вас в системе произойдет рассинхронизация с собственным архивом прибора, пропадает доверие к системе, т.к. она не способна без искажений передать внутренний архив прибора. А поверка систем измерения (если, конечно, сертификат не «куплен» на том и строится, что доказывается неискажаемость данных и невозможность манипулирования ими.
Кончено, положа руку на сердце, LORA-устройству можно по своим часам каждый час считывать 5 последних часовых записей или даже синхронизировать свое время со временем прибора. Но это костыли, на которых можно и не взлететь.
Кончено, положа руку на сердце, LORA-устройству можно по своим часам каждый час считывать 5 последних часовых записей или даже синхронизировать свое время со временем прибора. Но это костыли, на которых можно и не взлететь.
Если радиомодем сертифицирован как средство измерения, пригодное для ведения коммерческих расчётов, и имеет собственный архив показаний, то всем пофигу, что там в приборе происходит. Истиной в последней инстанции в этом случае является радиомодем.
Кроме того, если у прибора есть архив показаний — то и выход у него обычно есть не только импульсный, а вариации на тему UART, по которым можно читать и архив, и текущее внутреннее время. И тогда всем пофигу, что там с часами в радиомодеме.
Кроме того, если у прибора есть архив показаний — то и выход у него обычно есть не только импульсный, а вариации на тему UART, по которым можно читать и архив, и текущее внутреннее время. И тогда всем пофигу, что там с часами в радиомодеме.
Если только радиомодем корректно передает его внутренний архив. Мы же смотрим на это сквозь призму конфликта, правильно? Как вы написали выше,
Скорее всего в случае конфликта будут смотреть на первичное средство измерения. И если его архив не совпадет с архивом системы, и суд примет решение, основываясь на архиве первичного прибора (а скорее всего так и будет), и вот тогда доверие к системе будет подорвано. После суда заказчик спросит — «А зачем нам система, если мы с такой системой суды проигрываем?»
Ценность собственных часов счётчика в этом случае остаётся значимой постольку, поскольку он хранит архив показаний и является первичным средством измерения.
Скорее всего в случае конфликта будут смотреть на первичное средство измерения. И если его архив не совпадет с архивом системы, и суд примет решение, основываясь на архиве первичного прибора (а скорее всего так и будет), и вот тогда доверие к системе будет подорвано. После суда заказчик спросит — «А зачем нам система, если мы с такой системой суды проигрываем?»
> оборудовать GPRS-модемом
Сим-карты кто будет в этих модемах менять? Пушкин, Александр Сергеевич? Или вы работаете в «АО ГЛОНАСС» и эти вопросы вас, как в случае с Эрой-Глонасс, не волнуют?
Сим-карты кто будет в этих модемах менять? Пушкин, Александр Сергеевич? Или вы работаете в «АО ГЛОНАСС» и эти вопросы вас, как в случае с Эрой-Глонасс, не волнуют?
Я не работаю в ЭРА-ГЛОНАСС. А зачем менять SIM-карты?
Сим-карты имеют обыкновение умирать по самым разным причинам, блокироваться оператором и так далее. Частично проблема решается использованием «специальных» сим-карт и тарифов (это не всегда доступно). «Бытовые» же карты имеют лимит на количество регистраций в сети (несколько тысяч — исчерпывается довольно быстро, если модем большую часть времени спит и при каждом сеансе связи заново регистрируется) — ну и не стоит забывать о приколах наших операторов с подпиской на разные интересные услуги без ведома абонента.
Это всё решается переходом на корпоративные специализированные тарифы.
Про обратную связь…
Все lpwan интеграторы/операторы зачем то идут в ЖКХ. Это алый океан бизнеса, он переполнен акулами, маржинальность минимальна, проблемы максимальны. Зачем оно вам?
Все lpwan интеграторы/операторы зачем то идут в ЖКХ. Это алый океан бизнеса, он переполнен акулами, маржинальность минимальна, проблемы максимальны. Зачем оно вам?
Теоретически ЖКХ — оптимальная задача для Лоры. Большое количество достаточно простых устройств, концентрирующихся на небольшой площади. Трудно представить более подходящие условия.
Большинство других задач гораздо проще решаются проводом или GSM.
Большинство других задач гораздо проще решаются проводом или GSM.
Когда-то то же самое говорили по ZigBee. Что это оптимальная задача для ZigBee и все будет работать.
Акулы уже достаточно сильно подняли требования к таким системам. На чем, собственно, «горит» Стриж(Вавиот) — их «модемы» работают от силы полтора года при заявленных 10 годах, в то время как у существующих систем — срок жизни устройств от батарейки 14505 от 4 до 10 лет. Для того, чтобы успешно внедряться, надо рассчитывать на годы испытаний. Товарищи типа Стрижа довольно сильно подрывают доверие к новичкам на этом рынке, и, к сожалению, это случается регулярно. Выживают (пока) те, кто профессионально занимается учетом.
Акулы уже достаточно сильно подняли требования к таким системам. На чем, собственно, «горит» Стриж(Вавиот) — их «модемы» работают от силы полтора года при заявленных 10 годах, в то время как у существующих систем — срок жизни устройств от батарейки 14505 от 4 до 10 лет. Для того, чтобы успешно внедряться, надо рассчитывать на годы испытаний. Товарищи типа Стрижа довольно сильно подрывают доверие к новичкам на этом рынке, и, к сожалению, это случается регулярно. Выживают (пока) те, кто профессионально занимается учетом.
При таких требованиях, которые выкатывают некоторые заказчики физически невозможно обеспечить длительный срок автономной работы, если не ставить рядом шкаф батарей. Например, есть в нашей отрасли интересное требование, что контроллер телеметрии, даже автономный должен быть доступен для опроса в любой момент времени.
Тут должен сказать, что лора в наших задачах в принципе слабо применима — раз, а во вторых тот-же документ русским по белому говорит, что всем прочим каналам обмена предпочтение должно отдаваться GSM.
Тут должен сказать, что лора в наших задачах в принципе слабо применима — раз, а во вторых тот-же документ русским по белому говорит, что всем прочим каналам обмена предпочтение должно отдаваться GSM.
Не все.
Не туда
РС-485 это не протокол, а интерфейс, т.е. физический уровень. Модбас это протокол.
Вообще РС-485 умирает потихоньку. Эзернет в промышленности растет быстрее.
Вообще РС-485 умирает потихоньку. Эзернет в промышленности растет быстрее.
Все верно и я написал об этом крупными буквами)
Насчет Ethernet и смерти RS-485 вы зря. У Ethernet много ограничений, из-за которого с ним трудно. Скажем, ограничение в 100 м. Оно обходится, но у RS-485 поболее будет.
Насчет Ethernet и смерти RS-485 вы зря. У Ethernet много ограничений, из-за которого с ним трудно. Скажем, ограничение в 100 м. Оно обходится, но у RS-485 поболее будет.
Полтора км RS-485. Видел своими глазами.
Полтора км RS-485. Видел своими глазами.Ещё больше, с хорошей скоростью (сколько точно — не помню, 115200 вроде), в условиях электростанции (сильные помехи). Оптика :)
Оптика и RS-485 это разные физические среды.
Вы имели в виду «Оптика и витая пара это разные физические среды»?
RS-485 (англ. Recommended Standard 485), EIA-485 (англ. Electronic Industries Alliance-485) — стандарт физического уровня для асинхронного интерфейса. (https://ru.wikipedia.org/wiki/RS-485)
Стандарт оговаривает логические «0» и «1» при разности потенциалов между двумя линиями интерфейса. Т.е. физика стандарта подразумевает как минимум 2 проводника.
Стандарт оговаривает логические «0» и «1» при разности потенциалов между двумя линиями интерфейса. Т.е. физика стандарта подразумевает как минимум 2 проводника.
Ethernet делает стоимость микроконтроллера счетчика больше в три-четыре раза. Далеко не каждый производитель пойдет на такое.
Витуху есть смысл тащить в систему сбора показаний, чтобы прыгнуть на одного из коммерческих интернет-провайдеров.
РС-485 умирает потихоньку
Он может умирает в промышленной автоматизации, где стоимость железки по 50-100кру за штуку — дешево. Один полупроводниковый разработчик говорил, что у них в китае клондайк на микросхемы интерфейса RS-485, поскольку там идет бурный рост и нужны тысячи, миллионы электросчетчиков, что болтают по этому интерфейсу
Не знал про Китай. Китайцы копируют все хорошо, а вот с креативом у них проблемы иногда.
РС-485 конечно более быстрый чем ХАРТ, но тоже не молния ведь :). Я сторонник проникновения «офисных» решений в промышленность. В этом случае и специалиста проще найти и замену подобрать.
Коллеги, РС-485 в обычной жизни это старомодно же. Ну согласитесь ?! :) Не припомню ни одного случая, чтобы сталкивался в быту с ним. Витая пара, оптика, беспроводка… вот будущее.
РС-485 конечно более быстрый чем ХАРТ, но тоже не молния ведь :). Я сторонник проникновения «офисных» решений в промышленность. В этом случае и специалиста проще найти и замену подобрать.
Коллеги, РС-485 в обычной жизни это старомодно же. Ну согласитесь ?! :) Не припомню ни одного случая, чтобы сталкивался в быту с ним. Витая пара, оптика, беспроводка… вот будущее.
В промышленном секторе трудно найти что-то лучше RS-485 там, где не нужны огромные объёмы данных гонять. Простой на логическом и физическом уровне, возможность использования, как шины обмена данным на несколько устройств, помехозащищённость, протяжённость. Плюс огромное количество оборудования и дешевизна реализации в конечных устройствах.
В быту же нужна ширина канала, чтобы котиков в 4K разрешении смотреть и удобство подключения. В идеале — лёжа на диване. Отсюда и отсутствие 485 в быту.
В быту же нужна ширина канала, чтобы котиков в 4K разрешении смотреть и удобство подключения. В идеале — лёжа на диване. Отсюда и отсутствие 485 в быту.
Ну вот смотрите: чтобы организовать полноценно общение по RS-485 достаточно любого МК с UART — а это может быть и STM8, и 8051 и AVR. Берем оптоизоляцию на оптронах, цепляем трансивер по цене песка и работаем.
Чтобы полноценно организовать обмен по Ethernet нужно:
- Аппаратный TCP/IP процессор ~3USD за штуку, не считая обвязки еще на столько же
или - МК с аппаратным MAC-модулем, а это уже минимум ARM Cortex M3 или что-то похожее
или - МК уровня Cortex M0/M3/M4 минимум с парой десятков килобайт ОЗУ (непозволительная роскошь для счетчика) + Внешний MAC + Внешний PHY
А потом смотрим на объемы данных от счетчика: 50-100 байт в час, мб чуть больше. И ради этого ставить многожручий контроллер, просто потому, что современный студент не знает про проверенный десятилетиями интерфейс, который проще и надежнее?
Езернету нужен отдельный кабель на каждого абонента, RS-485 — шинный и кидать его можно чуть ли не по бельевым веревкам (с ограничением по скорости, разумеется).
Мне вот больше нравится тема с субгигагерцовым 6lowpan, но там наверное хватает своих подводных камней
Коллеги, РС-485 в обычной жизни это старомодно же. Ну согласитесь ?! :) Не припомню ни одного случая, чтобы сталкивался в быту с ним.Не соглашусь. Если вы с ним не сталкивались — то вы либо слишком молоды, либо далеки от автоматики.
оптика485 прекрасно работает по оптике.
Вообще РС-485 умирает потихоньку.Вы ещё скажите, что капитализм загнивает потихоньку. RS-485 ещё нас с вами переживёт, и до сих пор продолжает внедряться.
Автору — респект и благодарность за цикл статей. Прочитал с интересом.
Только вот поправить надо современные требования ГКРЧ к диапазону 868.
Только вот поправить надо современные требования ГКРЧ к диапазону 868.
Чуть-чуть теории. RS-485 (Recommended Standard) – это асинхронный интерфейс физического уровня. Получил огромную популярность в Промышленном ИнтернетеНебольшая поправка от зануды. 485 получил популярность и распространение ещё тогда, когда ни ethernet, ни интернет, ни internet of shit ещё не изобрели. И до моего, и до вашего рождения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Записки IoT-провайдера. LoRaWAN и RS-485