Arduino.ru

Зависит от выбранной скорости, длины пакета, а так же параметров и числа повторных посылок, если пакет с первого раза не проходит. Для расстояния 200-300 метров задача может оказаться невыполнимой.

Так как хочется получить точность синхронизации 2-3 мс, то скорость передачи хотелось бы сделать как можно выше. С другой стороны для снижения риска потери пакетов и пока теоретического размера пакета - 16 байт думаю, что скорости 256кбит/с будет достаточно.

Допускаю потерю пакетов, бороться за повторную отправку необходиомсти нет. Т.е. каждый синхроимпульс от ведущего устройства будет иметь свой номер. И к конечному анализу будут приниматься только те данные, которые получены от ведомых устройст, запущенных одним и тем же синхроипульсом. Вся система очень медленная и будет достачно получать данные раз в 5-10 секунд.

Можно ли считать, значение оператора  if (radio.available()){}  (при использовании nRF24) будет TRUE при поступлении первого байта посылки? Т.е., что как только что-то пришло в буфер секундомер стартанул, а дальше приняли всю поcылку, разобрали, поняли что фальш старт, остановили секундомер и ждем следующую посылку.

1. Непонятно, зачем отправлять синхроимпульсы по разным каналам. Судя по условиям задачи, оптимальное решение - на все устройства по единственному каналу.

2. Не обязательно запускать или не запускать внутренние часы по получении сигнала. Достаточно, чтобы внутренние часы просто всегда шли. Тогда, получив два любых сигнала (разумеется, с сметками времени), ведомое устройство одновременно сможет и вычислить разность хода таймеров у себя и на ведущем устройства, и точку начала отсчета. Соответственно, сможет перевести время прихода на него импульсов от внешних устройств в систему отсчета ведущего устройства. Даже если синхроимпульсы получены после прихода импульсов с внешних устройств.

Вот тут похожую задачу решали.

Если у Вас канал двухсторонний, а скорее всего так оно и есть, то можете попробовать сделать синхронизацию по образцу 1588 ptp.

Я как-то экспериментировал с энергоэффективой работой на прием. Суть в следующем: если держать модуль на приеме всю дорогу, то он жрет 15ма и на него никаких батарей не напасешься. Чтобы как-то поберечь батарейки, в голову пришла очевидная мысль -- не держать приемник включенным все время, а включать его непосредственно перед началом работы передатчика с той стороны. Период включения передатчика известен и если аккуратно засечь время первой передачи, то потом следующий сеанс можно вычислить относительно точно.

Если бы время начала сеанса передачи в моем случае не зависело от периода измерений перед этим, то можно было бы добиться суб-миллисекундной точности. С учетом же, что процесс измерений немного "гуляет", устойчивая передача данных оказалась возможной при включении приемника за 2-5 миллисекунд до ожидаемого сеанса связи. Другими словами, за 2-5мс возможно успеть включить приеменик, дождаться передачи и благополучно получить пакет данных. Все это в условиях, когда передача данных происходит с интервалом в одну минуту.

Описанное не является доказательством того, что ваша задача точной синхронизации решается без проблем, но косвенно свидетельствует, что требуемая вам точность скорее всего  достижима.

У NRF24L01 есть выход IRQ, который меняет состояние с высокого на низкое в тот момент, когда модулем принят пакет данных. Используя его, можно даже совсем не вызывать radio.available(), чтобы узнать, что данные поступили. Точность у него нано-секундная.

нда... А включить приемник через 59 сек а передатчик через 60 сек не является достаточным решением? Зачем в милисекунды то лезть? Прикиньте срок службы батареи при таком раскладе и при милисекундной синхронизации. Выиграш будет значим?

a5021, спасибо за подсказку с irq, сегодня нашел пару примеров, наверное именно так и попробую сделать.

Тут у всех могут быть свои мерки, но для сценариев работы приемника 1сек против 2мсек, энергопотребление будет отличаться в пятьсот раз.  Для наглядности, приемник сожрет батарейку CR2032 за 33 дня в первом случае и за 45 лет во втором.

Считайте точней, надо учитывать все потребления и в слипе тоже. Тогда цифры не будут отличатся так сильно.  Например вспомнить что у CR2032 есть саморазряд, она больше 10 лет никак. Если есть IRQ, то чего бы и нет, правда приемник запитать всеравно надо, чтоб с него пришел сигнал что он чтото принял. 

Вы спросили про разницу, я вам показал разницу. Если бы вопрос был про суммарное потребление, тогда и ответ был бы другим. Незименным же остается одно, что за 33 дня, которые потребуются для исчерпания источника модулем работающим 1с в течении минуты, модуль, работающий 2мс в тот же период "съест" лишь очень малую часть, даже если сюда приплести потребление МК в режиме сна и еще чего-нибудь.

Ничего Вы не показали.  Вы посчитали так 1сек/0,002сек=500 и 33дня*500=16500=45лет. Как получено 33дня тоже понятно ;) Это неверный расчет, не учтено время приема и обработки принятого, ток в слипе, саморазряд и т.д. Все факторы будут сближать значения. Если время приема принять всего 10мсек, то вместо 45 лет получим 7,5года. Если учесть саморозряд то около 3 лет и т.д. Здесь важен аккуратный точный подсчет и окажется что снижать время "предвключения" ниже некоторой цифры уже не дает значимого роста срока службы батареи.

Виноват. Заблуждался насчет того, что все здесь присутствующие способны выполнять простейшие арфиметические действия. Исправляюсь: 0,015а (ток потребления приемника) * 1 / 60 = 250мка * ч. Емкость CR2032 ~= 200ма * ч. При нагрузке 250мка ее хватит на 200/0,25 = 800 часов или 33,3 дня.

Еще рез вынужден повторить, что изначально речь о совокупном потреблении не шла. Если вам нужны эти цифры, то извольте взглянуть: саморазряд CR2032 приблизительно равен 1% в год или 2,28мка * ч. Ток NRF24L01 в слипе равен 0.9мка. Время приема пакета, состоящего из преамбулы (1 байт), адреса (5 байт), контрольного битового поля (9 бит) пакета данных (32 байта) и контрольной суммы (2 байта), все вместе 315 байт, на скорости 2мбит составляет 315/2м = 156мкс. Время "обработки принятого" и того меньше, т.к. SPI на атмеге работает на скоростях до 8мгц. С учетом оверхеда это составит ((2 + 32) * 8) /8м = 34мкс. На все про все берем грубо 200мкс и они входят в те самые 2мс, о которых я говорил изначально. Я тут даже не заостряю внимание, что "обработка принятого" по уму делается уже после выключения радио-блока, а пакет обычно меньше максимальных 32 байт. По любому, десяти миллисекундам тут взяться просто неоткуда. Не стоит придумывать того, чего не может быть.

С учетом всего вышеизложенного, считаем энергозатраты и прикидываем ресурс батареи, если нагрузка потребляет: 2,28 мка * ч + 0,9мка + 0,5мка = 2,42мка/ч. Для убедительности считаем, что в пригодном для использования виде от батареи удастся получить 80% находящейся в ней энергии или 160ма * ч. Тогда 160 / 0,00242 = 66115ч или 7,5 лет автономной работы.

Семь с половиной лет -- это, разумеется, не в пятьсот раз больше, чем 33 дня, но и этих цифр достаточно, чтобы понять, что смысл заморачиваться с миллисекундами очевиден.

Видите -  уже лучше ))

Теперь идем дальше, учитываем что иногда будут сбои синхронизации (помеха, передатчик ребутнулся или питание пропадало и синхронизация потеряна) и прийдется минуту держать приемник включеным, для восстановления, один сбой - 15ма/мин=250мка/ч и если это хоть раз в сутки (а это надежность приема 99,93%, что просто дофига!) - 250/24=10мка/ч. Еще в копилку к 2,42, получим ток в 5 раз выше и время службы в 5 раз снижаем. Все считать - значить все! ))

Кстати за 1 сек можно передать сообщение пару раз и сбоев будет сильно меньше,  и если не удалось принять первое - приймем второе или третье.. Это так, мысли вслух ;) Кстати на именно 1 сек я не настаиваю, оптимум может быть и на 100мсек или 10 мсек или гдето между этими тремя (а вот на 0,1мксек - чую что оптимума не будет), но все нада считать и очень внимательно!!!. Просто тут ситуация не такая однозначная, как в теме трактуется  т.е. чем менше время "предвключения" - тем лучше. Все хитрей.

ПС. Про саморазряд не так все просто, там температура очень сильно влияет растет при нагреве а приводят значения при 25С обычно, электрохимия однако. И на морозе тоже плохо, подсевший элемент может и не выдать 15ма в короткий импульс. И вобще - Ваш проект чего я должен гадости выдумывать, сами должны ;) На самом деле это очень полезное занятие, ну для проекта разумеется.

И насколько лучше? 33 дня автономной работы пежду заменами батарей стали лучше 7,5 лет в том же качестве? Как-то я ваш оптимизм не разделяю.

Из всех фантазий вида "передатчик ребутнулся, питание пропадало" опыт реальной эксплуатации устройства с апреля месяца подтверждает только потерю пакетов при передаче на уровне 0.1-0.3%. Из тысячи переданных пакетов не доходят до приемника не более трех или с учетом регулярности сеансов раз в минуту, от одного до трех пакетов теряются на протяжении почти семнадцати часов. В среднем можно говорить о потерях на уровне примерно 2-4 пакетов в сутки.

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

Что такое "синхронизация потеряна" я вообще плохо понял, т.к. сам факт приема является заодно и событием синхронизации.

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

Но это не означает, что нужно заниматься приписками и придумывание несуществующих статей расходов.

Не нужно, чтобы "мысли вслух" подменяли документацию. В мануале на NRF24L01 хорошо описан встроенный механизм доставки с подтверждением и настраиваемый порядок повторных передач (величина паузы между повторами, число самих повторов) в случае неудачи с первой попытки.

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

А ведь еще вчера вы совсем без энтузиазма относились к идее считать миллисекнуды.

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

Не знаю, что там у вас хитрей, т.к. у меня все довольно просто и уже отработано.

Не пытайтесь напустить туману. Среднегодовая температура для центральной России +5..+6 градусов. Саморазряд тут будет ниже обещанного по даташиту.

Это по этой причине вы за потребление 15ма в течении целой секунды? Вообще для 2032 рекомендованный средний ток нагрузки должен быть не выше 200мка. В противном случае, показатели емкости могут существенно деградировать. Это еще один аргумент за то, чтобы держать радио-модуль включенным, как можно меньше. Миллисекунды считать полезно.

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

Я на радиокоте довольно подробно описывал суть своих экспериментов и делился полученными таким образом данными. По части батарейного питания устройств на МК, я давал там информацию, которую собирал из различных источников, а когда не мог найти, то выяснял экспериментально.

Ну видите ж сами, я в расчете прикидывал 1 потеряный в сутки.  те на 1440 шт или 0,07%. Реально У Вас хуже.

Вы действительно не поняли. Передатчик ребутнулся, в заданые 2 мс не пришел пакет, когда ждать следующего?

Работа 45 лет от батарейки?! Действительно проще некуда )))

Это вы это к чему говорите?

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

Это сегодня. А вчера меньше, чем о секунде и думать не хотели. Так что прогресс медленно, но идет.

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

На сколько хватит передатчику аккумулятора при пропаже питания? Как реализована грозозащита? Как осуществляется перепрошивка передатчика? А как замена? Как при этом осуществляется синхронизация таймера передатчика с таймером, который уже не работает?

На какой элементной базе выполнен передатчик, что Вы так уверены в его надежности? Как удалось получить такую надежность без watch dog?

Зачем было изобретать велосипед и делать систему без RTC и без внешней синхронизации, например, по NTP? А с RTC не имеет никакого значения, перезагружается передатчик, или выключается, или перепрошивается - в согласованное время он появится рано или поздно.

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

Как у вас в мобильном телефоне реализована грозозащита? Вот здесь так же, т.е. никак, ибо для устройства с такими размерами в этом нет никакой необходимости.

Это вы мне наказание такое придумали -- отвечать на дурацкие вопросы? Передатчик ни с чем не синхронизируется. Он тупо раз в минуту производит цикл измерений и выплевывает данные в эфир. Ему вообще по брабану, кто и как эти данные будет принимать.

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

А как вы определили, что ватчдог там не используется? Что позволяет вам говорить об этом с уверенностью? Кроме того, ватчдог сам по себе не является средством повышения надежности. Это скорее инструмент аварийного восстановления работоспособности.

Зачем было бредить и придумывать всякую околесицу насчет того, о чем вы не имеете ни малейшего представления? Насчет "велосипедов", довожу до вашего сведения, что, например, в стандарте BLE есть целый класс устройств, работающих на похожих приципах, без всяких RTC и синхронизаций по NTP. Это так называемые маячки. Если вы настаиваете на своих "велосипедных" оценках, можете обратиться в консоциум с решительным требованием немедленно прекратить самодеятельность на том основании, что это противоречит вашим личным представлениям о том, каким образом должны функционировать подобные устройства. Уверен, в консорциуме вашу хохму оценят.

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

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

Не вижу смысла продолжать дискуссию...

И я не вижу. К сожалению a5021 продемонстрировал довольно типичную манеру поведения некоторых людей на форуме. Дискуссия начинается как конструктивный разговор о подходе к решению некоторой проблемы. В какойто момент товарищ начинает изображать всеведенье с легкой долей снисходительного хамства (какже, он умеет разделить емкость батареи на средний ток, кому такое посилам?!). Однако в всеведеньи обнаружываются ляпы, (типа 45 лет от одной батарейки ))). После указания на них, следующий этам, условно "у меня там столько сделано и работает" и тут выясняется, что хоть сделано много, а продумано не все. Далее следует обычно - "читайте мои труды", что не иначе как гнилая отмазка от вопроса.

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

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

По тексту Ф-Г - покойный Фобос-Грунт. (Сколько там народу думало и проверяло?)

"На этапе построения солнечной ориентации это было. На Ф-Г были 2 солнечных датчика, рядышком. Были неправильно заложенные матрицы пересчета данных от приборных осей датчиков в связанные, где осуществлялось управление. Не с того краю угол в 30 градусов отсчитали. :-) Соответственно, когда оба датчика видели Солнце - то ошибка взаимокомпенсировалась. В момент входа в тень один датчик переставал видеть Солнце первым, в результате чего ошибка знания расположения второго, который еще видел Солнце, проявлялась и СУ отрабатывала разворот на 30 градусов. А потом в тени героически держала эту ориентацию на БИНС."

http://novosti-kosmonavtiki.ru/forum/messages/forum11/topic15295/message...

Logik, вы уже продемонстрировали как свое хамство и невежество, так и не умение разбираться в чужом коде, вот только что, прямо тут в соседней теме .. Вы ещё что-то хотите сказать? Гы.. повеселили. Ваши посты можно уже просто пропускать не читая, как эсесовца.

Arhat109-2 - не уподобляйтесь.

a5021 тут реально перл выдал, утверждая что синхронизировать по времени можно базируясь только на времени передатчика, а не по эталонному времени, не зависящему от техники (пока Земля вертится). Потому что передатчик у него выполнен по космическим технологиям, сверх надежен, никогда не ломается, не перезагружается и не выключается )))

Потому Logik и прикалывался, что даже сверх надежные космические станции и те не имеют 100% надежности. Просто потому, что абсолютная надежность достижима исключительно, когда прибор делает a5021. Причем, как он сам утверждает, ему удается повысить надежность серийных МК до 100% )))

Научитесь когда-нибудь говорить за себя, а не за "весь форум".

С такими аргументами не стоило и начинать. А вообще, хорошо, что вы меня освободили от необходимости обсуждать ваши глупости.

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

ptr, Тут сложно "уподобиться", случай - запущенный. Но и Вы не правы. A5021 указал надежность в 99.93%, а никак не 100% и ваше с логиком "прикалывание" достаточно глупо выглядет, типа "чукча - не читатель".

А вот заявленные 33 дня постепенно "рассасываются" у "приколиста", что выглядит ещё глупее. :)

Глупее ваших недавних блокировочно-блокирующих высказываний уже ничего быть не может. Сидели бы уже молча и обтекали, а то ещё и глупые советы решили раздать нахаляву. ))))))))))))))

Ну да! Твои аргументы ваще так самые аргументированные в мире! ))))))))))))))))))))

Ты ваще мастер чужие мысли за свои выдавать. Ты типа бот? )))))))))))))

Достаточно почитать ту тему на коте, где ты извивался и кипел, а тебя тыкали, тыкали, пока не поняли что это безнадёжно. ))))))))

Не сходится. Раз он утверждает, что синхронизация таймера в передатчике не требуется, так как он эталон. А для эталона и пяти девяток мало )

А когда я сказал, что для того, чтобы работать строго по расписанию, необходима синхронизация с эталонным временем (RTC), у него такая истерика приключилась, что я уж даже не знал, то ли смеятся, то ли соболезновать.

Если эталон у нас внешний, то в любом случае, меняем мы приемник или меняем передатчик, синхронизируясь с этим эталоном мы синхронизируемся и со всей системой. А когда эталоном времени является передатчик, то как его синхронизировать в случае выхода из строя - известно только a5021. Эталон то гикнулся.

Бедняга еще решил опозориться, BLE приведя в качестве примера, совсем забыв, что в BLE синхронизация возможна только между приемопередатчиками и не может быть осуществлена, если есть только один передатчик (слабое звено), а все остальные приемники )

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

Это постановление правительства такое было или вы лично устанавливаете, где чего будет мало, а где много, своим решением?

Расписание: раз в минуту. Теперь давайте, объясняйте, зачем здесь RTC.

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

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

Всё, a5021 спёкся! И понёс свой любимый набор ничего не значащих фраз. )))))))))))))

Мозги включи, словопоносец! )))))))))))

Цитатки, стало быть, нет. Разговаривать с человеком (если можно так выразиться), который не в состоянии отвечать за свои слова, не вижу никакого смысла.

А в твоём звездобольстве и так нет никакого смысла. )))))))))

Ты звездоболишь лишь бы порисоваться. За что тебя и пинают, на данный момент, на двух форумах одновременно. Ты мазохист? )))))))))))))

Ты тут не один, кто врет и не краснеет. Я там выложил перепроверку этого теста, можешь зайти и почитать.

Читать твой бред, достойный башорга и лурка одновременно? Пусть a5021 читает, он всё же спец по мазохизму. )))))))))))

Но ради смеха загляну в ту тему, для поддержки общего веселья. ))))))))))

Зачем вы тратите силы на придание некой формы своим словам? Писалили бы сразу: "Гав-гав, уа-уа, ыыыыы!". По смыслу ведь это тоже самое.

Молодец! В будку! )))))))))))))

Переводить что-ли пытаетесь? Офигеть!