Комментарии 139
Я недавно закончил магистратуру в CMU, там плотно работал с профессором, который занимается связью, особенно IoT и LoRaWAN. Со многими проблемами, которые вы описываете (низкая скорость, лимиты на размер пакета, загруженность сети) мы тоже сталкивались и пытались решать.
У нас была идея в том, чтобы мультиплексировать доступ к сети через TDMA.
В основе этого решения — синхронизация времени на устройствах, этим я в основном и занимался. Если все пройдет удачно, эту работу могут принять в стандарт LoRaWAN — и может быть всем будет полегче строить поверх этого более нагруженные сети.
А вы прямо связывались с LoRa Альянсом, и предлагали свои разработки?
GPS горели, бывало. Но точно так же случались другие проблемы и я бы не назвал эту проблему прям критичной. Всякое ломалось. Ну сменим раз в месяц одну антеннку из 50, ну и все. Терпимо.
Погубило нас отсутствие развития (Qualcomm как привез в 2000 свой коммутатор и железо, так и забил на проект) и, главное, необходимость освобождать частоты. Мы с трудом абонентов выгоняли на GSM, когда закрывались. Если б не частоты, даже в том виде, без развития и новинок, еще бы долго прожили. Я уж молчу про возможность развиваться.
Скайлинк работал на частотах 450. Там шумновато, но им нормально было. Однако, их купил РТК и быстро свернул лавочку. Там больше политика, а не техника.
Но Скай — это CDMA2000, третье поколение.
Все операторы CDMA работали во втором — CDMAone. И вот они закрылись исключительно из-за частот, которые потом планировали под цифровое ТВ.
Еще вот анализ пропускной способности и поведения сети в реальных условиях со множеством узлов — Understanding the Limits of LoRaWAN — arxiv.org/pdf/1607.08011.pdf
А если все таки нужно батарейное питание? Скажем, бывает ли такой режим у распространенных модулей, чтобы первый пакет разбудил модуль, а второй уже можно было принять?
Есть класс B, нормально описанный только в свежей спецификации 1.1, он включается на послушать эфир по расписанию, без собственной передачи. Получается компромисс по энергопотреблению и доступности между A и C.
Ну и RS485 сам по себе не то чтобы сильно экономичный.
Первыми пакетами можно пренебречь.
Т.е. нужна возможность постоянного вызова, с некоторой оперативностью — расписание не подойдет.
Но если у вас эфир достаточно сильно загружен общением с другими устройствами, это не поможет — будет постоянно просыпаться на чужие пакеты. Кроме того, CAD делается однократно по команде, то есть требует просыпания микроконтроллера, и по очевидной причине периодичность этих просыпаний должна быть такой, чтобы преамбулу точно успеть поймать — а у неё фиксированная длина в символах, т.е. с падением SF и прембула становится всё короче…
P.S. Вообще у Семтека был калькулятор энергопотребления, можно скачать и поиграться.
Ну либо решаемой, но дня за три неспешного скачивания тех архивов маленькими кусочками.
Видимо будущее промышленной телемеханики всё-таки за NB-Iot.
Ну а в общем, где нет LTE придётся по старинке GPRS/EDGE/3G.
Может так получится, что беспроводка вообще не годится, если стоит какая-нибудь электромагнитная плавильная печь.
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 В. И вот это будет печально.
NB-IoT — это та же лора, ну, может, чуть лучше, только с симкой.
Проблемы те же самые + дополнительные с регистрацией/установкой и обслуживанием симок.
Я лично ходил (потому, что даже внедорожник там не проедет) по лесам Псковщины и степям Астраханьщины и осуществлял пуско-наладку систем телеметрии по GSM.
Там, где между объектами телемеханизации десятки км ни Лора, ни тем более Wi-Fi не применимы.
1) Как в голове может умещаться «Просто установи сим карту» напротив «непролазных лесов и степей?» Я постоянно путешествую по местам, где никакиго LTE и даже 3G нет. Для этого достаточно сесть на электричку и проехать километров 30 от города.
2) Мухи отельно, котлеты отдельно. Промышленная автоматизация зданий и объектов и сбор показаний в условиях тундры — это два абсолютно разных сценария с абсолютно разными подходами/используемыми технологиями.
3) Если мы говорим о рынке, то автоматизация объектов, между которыми десятки километров — это жалкие крохи. В качестве контрпримера — ну да, сойдет. Как альтернативный сегмент рынка — нет. В городской и промышленной автоматизации Wi-Fi в большинстве сценариев будет лучшим решением.
В городской и промышленной автоматизации Wi-Fi в большинстве сценариев будет лучшим решением
Рассчитайте систему управления уличным освещением на Wi-Fi. 100 кв. км, 20 тысяч ламп.
Да что там уличное освещение, сделайте смеха ради проект съёма показаний с тех же водосчётчиков по Wi-Fi. Жилой дом, 160 квартир. С радиопланированием, гарантирующим покрытие, и счётчиками с ресурсом работы без смены элемента питания 8 лет.
Вас интересует решение или это был просто вброс «докажи, что ты не балабол»?
Большинство из описанного уже есть
На вайфае?
Ну докажи, что ты не балабол.
Сколько реальных внедрений-то? Со сплошным покрытием ну хотя б вот дома на 160 квартир.
Вы, похоже, не поняли, что в таком варианте нет понятия «покрытие». Это другой подход.
Возьмите план какого-нибудь П-44Т и расскажите нам, сколько вам потребуется роутеров для снятия показаний с водосчётчиков банальных, при выполнении трёх условий:
1) Wi-Fi роутеры стоят вне квартир
2) электропитание роутеров — от общедомовых нужд
3) выход из строя роутера на любом отдельном этаже связность сети не ломает
Ну и ссылку на водосчётчик с Wi-Fi и батарейкой на 8 лет заодно.
1) Роутеры уже стоят в квартирах.
2) Электропитание роутеров уже обеспечивается жильцами квартир.
4) Выход клиентского роутера из строя раз в N лет не является критичным сценарием.
Вот у этих ребят точно были водосчетчики с вайфаем
telecan.ru/telekan-products. Это из отечественных. Импортных тоже много встречал, но с таким тоном беседы с вашей стороны, у меня все меньше желания ее продолжать.
Вы скажите, есть лихоть какая-то призначная надежда перевести наш диалог из разряда «А докажи, а дай, а покажи, а посчитай, у вас ничего нет» в сколь-нибудь конструктивное русло?
1) В квартире стоит мой роутер, а не ваш. Вас я в эту квартиру попросту не пущу.
2) Вы мне предлагаете за счастье обладания вашим роутером там, где он мне даром не нужен, ещё и платить?
3) Ну то есть в типовых домах из монолитного железобетона ваш роутер два перекрытия уверенно просвечивает?
Вы скажите, есть лихоть какая-то призначная надежда перевести наш диалог из разряда «А докажи, а дай, а покажи, а посчитай, у вас ничего нет» в сколь-нибудь конструктивное русло?
Конечно. Я же вам предложил посчитать проект для П-44Т в реальных условиях, а не в сказке «все жильцы пошли и дружно сами себе наши роутеры поставили».
1) В квартирах стоят провайдерские роутеры. Там где стоят роутеры клиента — есть тысяча и один способ идентифицировать устройства за роутером и привязать их к конкретному абоненту.
2) Я предлагаю не платить там, где можно не платить.
3) Мир уже давно пришел к тому, что никто не пробивает железобетонные перекрытия, а наоборот снижают мощность роутеров и делают mesh внутри квартиры, либо соединяют проводами. Размораживайтесь скорее.
А если они не захотят, то вы что сделаете, бесплатные билеты на ваш следующий концерт предложите?
А если в квартире живёт бабулька, которой этот роутер даром не нужен? А если владелец квартиру сдаёт и считает, что подключение интернета — не его проблема? А если владелец в отпуск уехал и интернет на блокировку поставил? А если жилец горячую воду тырит кубометрами, засунув проволочку в крыльчатку счётчика, и все ваши новые технологии, которые помешают ему это делать, в гробу в белых тапках видел? А если стоящий где-то за унитазом счётчик вообще Wi-Fi от стоящего в гостиной через три стены роутера не ловит?
А если он сделал врезку в трубу и забирает воду мимо счетчика? А если клиент носит шапочку из фольги и принципиально не хочет, чтобы в его квартире были излучающие устрйоства? А если клиенту религия не позволяет иметь электронику в доме?
Ну и так далее.
Да, я предлагаю использовать уже готовый интернет канал и готовую инфраструктуру, имеющуюся у провайдеров. Потому что сбор показаний — это обязанность гражданина, закрепленная законодательно. А сделать сбор показаний доступным и удобным — обязанность провайдеров.
Если они (жильцы) не захотят — я предложу им бесплатно сборник ваших язвительных комментариев =)
А вот всё остальное делать он в полном и абсолютном праве.
Потому что сбор показаний — это обязанность гражданина, закрепленная законодательно
А ещё однажды вы узнаете, что гражданину более чем достаточно раз в месяц позвонить в диспетчерскую и продиктовать циферки. Вся остальная же возня с почасовыми архивами и синхронизированным по времени съёмом показаний нужна не гражданину.
Я продолжу заниматься соим делом.
Как гражданин:
Читаю я вот это обсуждение и накладываю на себя:
- показания электричества — один раз в месяц уходят (если уходят, расчеты по среднему меня вот устраивают, последние месяцы уходят регулярно но только потому что у банка который я сейчас для платежей использую ну нельзя оплатить соответствующий счет не указав показания)
- газ — совсем не каждый месяц (спасибо тем личностям кто в интерфейсе гисжкх сделал ввод показаний за газ 3 дня в месяц, а разбиратся где там еще их указывать — желания нет)
WiFi у меня конечно же есть. Но при этом и роутер не провайдерский и конфигурация интересная и еще и меняется периодически (и для то же Яндекс. Станции пришлось специально прописывать настройки чтобы она могла нормально работать, яндекс почему то решил что внешний IP-адрес у домашней сети всегда один и тот же даже когда обращение к разным хостам идет). При этом настройка по большей части по гайдам с хабра (я не сетевой админ).
Обеспечивать работу левого железа которое только жрет канал и электричество а мне даже не дает себе архивы выгрузить — а зачем это мне? Если будет попытка именно принудительно — ну доступ получит это железо, как оно будет работать — их проблемы (или пусть внятно объясняют что не так и отвечают на все мои вопросы), меня вариант с вводом данных руками раз в месяц — устраивает.
1) Роутеры уже стоят в квартирах.
С чего бы это? Вот прямо в каждой квартире у каждой семьи в стране по роутеру.
Вот у этих ребят точно были водосчетчики с вайфаем
Ага. Снимаем установленные застройщиком и заменяем на модные с вай-фаем за свой счёт. Или мы идём к застройщику и говорим — друг, не ставь счётчики за 700 рублей, ставь за 4500. Разницу в стоимости на 200 квартир можете посчитать сами.
По ссылке не счетчики, а модули снятия и передачи показаний.
Но вот идея обеспечение инфраструктуры повесить на жильцов — это однозначно из страны, где единороги бегают по радуге.
Вся обслуживающая передачу показаний инфраструктура должна находиться за пределами квартиры и никак не зависеть от собственника и/или жильцов.
Ладно, чего мелочится, накидываем ещё сервисных данных столько же.
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 тот же.
Например, мы говорим о каком-нибудь парке с толпами гуляющих.
Тут лора в принципе пролетает, у неё совсем другие задачи. NB-Iot тоже не нужен. На каждый фонарь по абоненту через каждые 5 метров — избыточно.
Но изначально тов. Klukonin заявил, что «Будущее промышленной телемеханики за Wi-Fi». Что явно не соответствует действительности.
Это всяко проще, чем городить 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
С уважением, просто практик беспроводных сетей.
В нашем городе стабильно раз в 2-3 года на сайте мэрии и всяких причастных компаний печатаются проекты создания метрополитена. Вот только метро как не было так и нет, и в ближайшие 20-30 лет точно не будет. Хотя даже по официальным данным в городе полтора миллиона человек и наземная транспортная инфраструктура уже давно в коленно-локтевой позе.
Прямо сейчас в Москве в целях телеметрии инфраструктуры защиты газопроводов от коррозии задействовано не менее 2,5 тысяч контроллеров передающих данные по GPRS/3G (из того, что известно мне лично).
есть же 802.15.4 тот же.— ложки нет. Он мертв. И я объяснял почему.
Я буду продолжать утверждать, что 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 рассчитана исключительно на стационарные оконечные устройства? Или есть варианты с редкоподвижными (раз в день/неделю/месяц) переехали в зону действия другой БС? И просто подвижные, когда оконечное устройство может начать передачу в момент движения?
Если брать практику, то я пробовал возить устройство с собой в машине по городу — потери пакетов не наблюдалось. Однако, прям длительных тестов на подвижность не делали и уж точно не тестировали на больших скоростях.
Спасибо за отзыв)
MAC поверх него может быть разный, если это LoRaWAN, то в нём роуминг между БС одного оператора автоматический. Там БС вообще тупая как пробка, её задача — сигнал из эфира принял, в обёртку завернул и по эзернету или 3G в сторону сетевого сервера выплюнул.
Только кажется, что посчитать импульсы и передать их — это достаточно. Это достаточно для курсовой работы первого курса, по факту задачки сбора показаний со счетчиков — посложнее. Сразу оговорюсь, что серебряной пули нет, но:
— при сборе показаний с теплосчетчика желательно видеть все измеряемые величины — обе температуры, расход теплоносителя, код состояния (в рудиментарном случае квартирного теплосчетчика). Если нет импульсов от квартирного теплосчетчика, то может быть целый набор ситуаций (разрешенных и нет) от закрытых кранов до оборванного термометра или застопреной крыльчатки. Через импульсный выход этого не увидеть и одно состояние от другого не отличить. Как и от оборванного импульсного выхода. В случае общедомового (промышленного) теплосчетчика — параметров может быть в разы больше.
Архив на сервере — хорошо, но как только часы LORA-устройства разойдутся с часами теплосчетчика, а это точно произойдет, весь архив на сервере потеряет ценность.
С электросчетчиками — абсолютно аналогичная ситуация, еще более осложненная «двухтарифностью» — часы разойдутся, и показания с LORA — устройства обесценятся.
Если быть правдивым, не совсем обесценятся — они станут тем, что в среде метрологов называют «показометром» — им можно верить «для личного пользования», но их нельзя использовать для коммерческих расчетов.
Вода — тут тоже непросто, но сложности другие. Через импульсный выход нельзя отличить, крутится счетчик вперед или назад, когда крутился вперед-назад (это проблема перетока в смесителях и кривых разводках труб, встречается в каждом доме обязательно), воздействие магнитов и когда провод импульсного выхода оборван. Частично эту проблему решает НАМУР (для детекта оборванности импульсного выхода), остальные можно решить только встраивая интерфейс в счетчик.
И тогда получается, что в многоквартирных домах провод всегда дешевле для электросчетчиков и теплосчетчиков — т.к. они в 95% случаем стоят в местах общего пользования, для водосчетчиков решение импульс+радиопередача — живое, но такие решения есть уже лет 10, и живые и работают и без LORA.
Получается, что сегмент применения, где решение действительно даст что-то, чего не было раньше — это передача на более-менее большие расстояния — коттеджные поселки, деревни, дачи? Тут они конкурируют с NB-IOT и GPRS.
Одиноко стоящие подстанции и промышленные узлы учета всегда проще оборудовать GPRS-модемом. Даже электросчетчики, которые сейчас в загородных поселках выносят группами на улицу проще оборудовать одним GPRS-модемом.
Получатся что сегмент очень ограничен. По крайней мере в ЖКХ.
1) Не следует путать систему телеметрии с системой контроля хитрости) Меня часто спрашивают — может ли LoRa как-то помочь против магнитов или иных уловок на индивидуальных приборах учета. У меня один ответ.
А парень с карандашом и блокнотом, который попадает в одну квартиру из пяти или показания жильцов, которые они вбивают через Интернет смогут помочь выявить магнит?)
Насчет обрыва — у нас есть система мониторинга, что внезапно стали приходить нулевые значения. Само по себе это еще ничего не значит, но повод назначить ремонт на объект.
Кроме того, внешние радиомодули — это все-таки переходный период. Я думаю, что скоро будем иметь устройства с интегрированным радиомодулем. И вот тогда NBIoT потребует куда большей батарейки. Я уж молчу про GPRS, к нему вообще допшкаф понадобится)
2) Я не совсем понял вашу мысль с часами. Ну вот будет у нас рассинхрон c внутренними часами теплосчетчика. Ну или электросчетчика. Почему показания обесценятся? Вы считаете, что этот рассинхрон набежит в полчаса?
Насчет обрыва — вы не сможете отличить — человек уехал в отпуск или у него сломался счетчик. И вы назначаете выезд на ремонт. Вы систему создаете, чтобы этих выездов не было, тем более — ложных.
Что касается GPRS — то вы тоже не правы. Никто не заставляет держать модуль GPRS постоянно включенным. А системы, которые его включат с настраиваемым интервалом для передачи данных я первый раз видел на выставке лет 6 назад. И работают нормально в своих сегментах.
Про часы написал ниже.
Не у всех, кто выходит на этот рынок, хватает широты взгляда чтобы оценить, что до них эту тему качают уже два десятка лет, и люди общаются с заказчиком и под его требования разрабатывают системы. И все это вымучено, выстрадано, многократно пропущено через себя и множество разнообразных кейсов. И многочисленные «невзлеты» новичков на этом поприще — это как раз из-за этого. Когда они это понимают, у них уже кончаются деньги.
Система сбора данных — это не самоцель, это лишь инструмент для решения совсем других проблем. И не надо думать, что кому-то нужна «чистая телеметрия и больше ничего». Как самоцель, по крайней мере в ЖКХ, она не нужна никому.
Собрать в одном корпусе индивидуальный водосчетчик, батарейку и передатчик GPRS не получится. Точнее получится, но долго эта конструкция не проживет. А вот на Лоре это вполне реализуемо.
2) Вы преувеличиваете проблему рассинхрона. Часы радимодуля можно подводить специальной командой. Пока таких проблем нет, но если они возникнут — просто добавим серверу в задачи отправлять команду синхронизации раз в… ну пусть раз в месяц. И все у нас будет актуально.
Что же касается внутренних часов теплосчетчика, был бы у них сертификат, если бы в конце срока эксплуатации там был рассинхрон в десятки минут?
3) Ну и наконец. Мы же можем запрашивать время с теплосчетчика, как один из параметров. И вуаля! У нас данные с первичного источника.
Сразу оговорюсь, что серебряной пули нет
Я писал вам про то, что реализуемо на Лоре — уже 10 лет как есть на рынке, и ничего нового с точки зрения эксплуатации, с точки зрения приближения к этой самой «серебряной пуле» она (Лора) не предлагает.
2) Во всех документах, в ПП354, в правилах учета ТЭ и ТН — везде фигурирует первичный прибор и его архив. Нигде не написано, что его часы должны иметь сертификат. Но он — первичный прибор. И в итоге будут обращаться к его архиву. А если ваша система выдает данные, отличные от его архива, то доверия нет к системе, а не к прибору. Если вы посылаете безграмотного человека снимать показания, и он их неверно переписал — то нет доверия к системе (снятия показаний), а не к прибору. Пока у прибора есть поверка — доверие к нему абсолютное.
3) Ну да, я сам это написал ниже часов пять назад. Я думаю, что это костыль, и на нем далеко не уедешь.
С моей колокольни — это устройства с интегрированными передатчиками. Я могу быть не прав.
2) и 3) А почему вы считаете, что забирать время у прибора учета — это костыль? Получается, что любая система диспетчеризации — это костыль?
2)3) предвижу сложности с разными приборами, разными протоколами, переводом часов и сменой тарифных расписаний, возведенное в степень абсурда происходящего вокруг. Но волков бояться — в лес не ходить, как завещал нам анекдот — «хули думать — прыгать надо»
Ценность собственных часов счётчика в этом случае остаётся значимой постольку, поскольку он хранит архив показаний и является первичным средством измерения. Если, однако, радиоинтерфейс, даже внешний, сертифицирован как средство измерения, то сам счётчик часов может хоть вообще больше не иметь.
Кончено, положа руку на сердце, LORA-устройству можно по своим часам каждый час считывать 5 последних часовых записей или даже синхронизировать свое время со временем прибора. Но это костыли, на которых можно и не взлететь.
Кроме того, если у прибора есть архив показаний — то и выход у него обычно есть не только импульсный, а вариации на тему UART, по которым можно читать и архив, и текущее внутреннее время. И тогда всем пофигу, что там с часами в радиомодеме.
Ценность собственных часов счётчика в этом случае остаётся значимой постольку, поскольку он хранит архив показаний и является первичным средством измерения.
Скорее всего в случае конфликта будут смотреть на первичное средство измерения. И если его архив не совпадет с архивом системы, и суд примет решение, основываясь на архиве первичного прибора (а скорее всего так и будет), и вот тогда доверие к системе будет подорвано. После суда заказчик спросит — «А зачем нам система, если мы с такой системой суды проигрываем?»
Сим-карты кто будет в этих модемах менять? Пушкин, Александр Сергеевич? Или вы работаете в «АО ГЛОНАСС» и эти вопросы вас, как в случае с Эрой-Глонасс, не волнуют?
Все lpwan интеграторы/операторы зачем то идут в ЖКХ. Это алый океан бизнеса, он переполнен акулами, маржинальность минимальна, проблемы максимальны. Зачем оно вам?
Большинство других задач гораздо проще решаются проводом или GSM.
Акулы уже достаточно сильно подняли требования к таким системам. На чем, собственно, «горит» Стриж(Вавиот) — их «модемы» работают от силы полтора года при заявленных 10 годах, в то время как у существующих систем — срок жизни устройств от батарейки 14505 от 4 до 10 лет. Для того, чтобы успешно внедряться, надо рассчитывать на годы испытаний. Товарищи типа Стрижа довольно сильно подрывают доверие к новичкам на этом рынке, и, к сожалению, это случается регулярно. Выживают (пока) те, кто профессионально занимается учетом.
Тут должен сказать, что лора в наших задачах в принципе слабо применима — раз, а во вторых тот-же документ русским по белому говорит, что всем прочим каналам обмена предпочтение должно отдаваться GSM.
Вообще РС-485 умирает потихоньку. Эзернет в промышленности растет быстрее.
Насчет Ethernet и смерти RS-485 вы зря. У Ethernet много ограничений, из-за которого с ним трудно. Скажем, ограничение в 100 м. Оно обходится, но у RS-485 поболее будет.
Полтора км RS-485. Видел своими глазами.Ещё больше, с хорошей скоростью (сколько точно — не помню, 115200 вроде), в условиях электростанции (сильные помехи). Оптика :)
Стандарт оговаривает логические «0» и «1» при разности потенциалов между двумя линиями интерфейса. Т.е. физика стандарта подразумевает как минимум 2 проводника.
Ethernet делает стоимость микроконтроллера счетчика больше в три-четыре раза. Далеко не каждый производитель пойдет на такое.
Витуху есть смысл тащить в систему сбора показаний, чтобы прыгнуть на одного из коммерческих интернет-провайдеров.
РС-485 умирает потихоньку
Он может умирает в промышленной автоматизации, где стоимость железки по 50-100кру за штуку — дешево. Один полупроводниковый разработчик говорил, что у них в китае клондайк на микросхемы интерфейса RS-485, поскольку там идет бурный рост и нужны тысячи, миллионы электросчетчиков, что болтают по этому интерфейсу
РС-485 конечно более быстрый чем ХАРТ, но тоже не молния ведь :). Я сторонник проникновения «офисных» решений в промышленность. В этом случае и специалиста проще найти и замену подобрать.
Коллеги, РС-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.
Чуть-чуть теории. RS-485 (Recommended Standard) – это асинхронный интерфейс физического уровня. Получил огромную популярность в Промышленном ИнтернетеНебольшая поправка от зануды. 485 получил популярность и распространение ещё тогда, когда ни ethernet, ни интернет, ни internet of shit ещё не изобрели. И до моего, и до вашего рождения.
Записки IoT-провайдера. LoRaWAN и RS-485