Детектор поля Опции

[Oleg_IT]

Сделал интерфейс между двумя МК по радио. Ток потребления при приёме достаточно большой, даже при условии «засыпания» МК в промежутках между прослушиванием эфира, система работает в импульсном режиме. Прибор должен работать на аккумуляторах достаточно долго. Есть мысль сделать детектор поля. При обнаружении радио сигнала, он «разбудит» МК и начнётся штатная работа. Я не специалист в этих вопросах, можно ли вообще сделать микро потребляющий детектор поля? Если да, то где можно об этом почитать? Или может, кто поделится опытом.

[Oleg_IT]

На промежуточной не могу, трансивер это микруха с цифровым выходом.
Дайте хоть какие-нибудь ссылки по теме "RFID-системе, где схема "приемника-идентификационной карточки""

[M_Z]

На промежуточной не могу, трансивер это микруха с цифровым выходом.
Дайте хоть какие-нибудь ссылки по теме "RFID-системе, где схема "приемника-идентификационной карточки""

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

[Oleg_IT]

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

У производителя микросхемы в примере примерно так и сделано. Но это опять постоянная работа на передачу. И на приём, кстати, тоже, ведь он должен как-то узнать, что с ним пообщаться хотят.

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

[M_Z]

У производителя микросхемы в примере примерно так и сделано. Но это опять постоянная работа на передачу. И на приём, кстати, тоже, ведь он должен как-то узнать, что с ним пообщаться хотят.

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

ДА Вы нифига не поняли
Ну и ладно

[Oleg_IT]

ДА Вы нифига не поняли
Ну и ладно

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

[M_Z]

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

вслучае болезни оператора вылечить его вратли получится.
А вобщето надо точно понимать задачу.
говоря о времени выхолда на связь имеется ввиду не время суток а время в милисекундах.
обмен пачками готовности или наличия информации может занимать 1мсек. а дальше ожидание которое в зависимости от задачи может быть на уровне 1сек. в итоге потребление падает в 1000 раз.
и т. д.
не зная задачи сложно предлагать.

[Oleg_IT]

вслучае болезни оператора вылечить его вратли получится.
А вобщето надо точно понимать задачу.
говоря о времени выхолда на связь имеется ввиду не время суток а время в милисекундах.
обмен пачками готовности или наличия информации может занимать 1мсек. а дальше ожидание которое в зависимости от задачи может быть на уровне 1сек. в итоге потребление падает в 1000 раз.
и т. д.
не зная задачи сложно предлагать.

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

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

[rx3apf]

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

При запросе непрерывно передаешь пакеты, в которых тикает время до начала сеанса приема. Абонент, обнаружив пакет, отвечает в положенное время. Я это решал именно таким образом.

С детектором поля ни каких идей похоже нет.

Тупиковый путь. Это вообще неправильное решение.