Например TDA7294

Форум РадиоКот :: Просмотр темы - Автомобильный GSM-оповещатель с дополнительными функциями
Форум РадиоКот
https://radiokot.ru/forum/

Автомобильный GSM-оповещатель с дополнительными функциями
https://radiokot.ru/forum/viewtopic.php?f=25&t=143879
Страница 1 из 1

Автор:  r0c [ Вс апр 02, 2017 09:36:01 ]
Заголовок сообщения:  Автомобильный GSM-оповещатель с дополнительными функциями

Давно читаю сайт, но только сейчас решил зарегистрироваться. Создал тему для общения с автором и всеми, кто решил повторить конструкцию http://radiokot.ru/circuit/digital/security/56/#.
Вопрос автору. Как активируется режим охраны? Пока, лежа на столе, удалось добиться только срабатывания от подачи напря;ения на вход ALARM

Автор:  savage [ Вс апр 02, 2017 21:15:33 ]
Заголовок сообщения:  Re: Автомобильный GSM-оповещатель с дополнительными функциям

Доброе время суток!
Не сразу увидел сообщение. Прошу простить. Сегодня подробно уже не успею ответить.
Кратко. У устройства нет режима охраны как такового. Это приставка к сигнализации. Пейджер. Срабатывает по сигналу на входе ALARM. При этом проверяет состояние входов DOOR и IGN. ЦЗ это допфункция на случай забывания ключей или необходимости закрыть машину без постановки на охрану. Так-же у некоторых сигнализаций, постановка на охрану происходит при запирании ЦЗ (попалась такая вместе с машиной). Первый вариант прошивки у меня и был под такую сигналку. Какая-то очень древняя но-нейм. Ни разу такая не попадалась. Сигнализация благополучно сдохла на второй год. Пейджер к ней не успел. Это уже второй вариант прошивки. Сигнализация поменялась, а функция осталась. Если делать полноценное запирание-отпирание, то с готовой сигнализацией это не поженить. Проще сделать полностью свою.

Автор:  r0c [ Пн апр 03, 2017 09:23:33 ]
Заголовок сообщения:  Re: Автомобильный GSM-оповещатель с дополнительными функциям

Спасибо,что появились в теме!
Проводил измерения- при бездействии микроконтроллер не засыпает что ли? Постоянное потребление 10 мА.
Насчет радиомодуля- у него постоянные скачки потребления тока. от 3 до 20 мА.
Еще вопрос-где в проекте поправить строки, что бы после входящей смс поочередно, на 1 секунду, шел сигнал управления на транзисторы HEAT и CAM?

Автор:  savage [ Пн апр 03, 2017 16:23:39 ]
Заголовок сообщения:  Re: Автомобильный GSM-оповещатель с дополнительными функциям

Контроллер уходит в IDLE.
if (rx_counter0==0) idle();
Но все равно набегает. Например всегда подтянут к 1 M590_POWERPIN. Опять же таймер, который отрабатывает 5Гц.
Радиомодуль постоянно общается с сетью даже в режиме сна, в который переходит сразу после инициализации.

m590command("AT+ENPWRSAVE=1"); //enable savemode
M590_SLEEPPIN=0;
Что касается перенастройки алгоритма работы выходов, то это в процедуре parseSMS()
Строки для времени из СМС:
}else if(strstr(comand,reley1command)!=NULL){
Строки для времени из EEPROM
if(strstr(ptr_to_ram,reley1command)!=NULL){
Соответственно reley1command это первая команда из EEPROM, reley2command вторая и т.д. Внутри тела ветвления if нужной вам команды можно что-то менять.
Если речь только про 1 секунду и выходы HEAT и CAM, то можно
Строки
}else if(strstr(ptr_to_ram,reley3command)!=NULL){
#asm("cli")
reley3counter=reley3delay;
#asm("sei")
Поменять на

}else if(strstr(ptr_to_ram,reley3command)!=NULL){
RELEY3PIN =1;
delay_ms(200);
#asm("wdr")
delay_ms(200);
#asm("wdr")
delay_ms(200);
#asm("wdr")
delay_ms(200);
#asm("wdr")
delay_ms(200);
#asm("wdr")
RELEY4PIN =1;
RELEY3PIN =0;
delay_ms(200);
#asm("wdr")
delay_ms(200);
#asm("wdr")
delay_ms(200);
#asm("wdr")
delay_ms(200);
#asm("wdr")
delay_ms(200);
#asm("wdr")
RELEY4PIN =0;
Именно то что вам нужно. Нужно только убрать в main()
if (reley3counter>0){reley3counter--; RELEY3PIN =1;} else RELEY3PIN =0;
if (reley4counter>0){reley4counter--; RELEY4PIN =1;} else RELEY4PIN =0;
Ну и опять же лишние if в parseSMS()

Добавлено after 11 minutes 40 seconds:
Re: Автомобильный GSM-оповещатель с дополнительными функциями
Да. Забыл добавить, что при такой переделке на эти 2 секунды модуль перестанет реагировать на внешний мир. По этому более изящно было бы выставлять какой то флаг, а уже в main() при наличие этого флага запускать счетчики. Те самые
if (reley3counter>0){reley3counter--; RELEY3PIN =1;} else RELEY3PIN =0;
if (reley4counter>0){reley4counter--; RELEY4PIN =1;} else RELEY4PIN =0;

Автор:  vitalyadm [ Пн апр 10, 2017 13:06:59 ]
Заголовок сообщения:  Re: Автомобильный GSM-оповещатель с дополнительными функциям

Приветствую коллега, заглянул с соседней ветки (viewtopic.php?f=25&t=127128&start=440), увидел GSM…. Думаю, о дай ка гляну, что за зверь такой на всеобщее обозрение выставлен.
В общем…. Сначала критика. Когда- то давно, что- то вдруг не с того ни с сего решил слепить gsm оповещалку, так тема gsm до сих пор и не отпускает :))) И вот читаю Вашу статью и прям, ухты- те же юзабилити ляпы, те же косяки, но только чуть с другого ракурса. Но, мы же здесь зачем, правильно, помогать друг другу. Лично по моему мнению, сейчас!!!!, с точки зрения эксплуатационной и программной устройство никуда не годится, от слова совсем. Программная часть вызывает больше вопросов и недоумений - нежели ответов. Только ещё раз обращаю внимание, я критикую не для того что бы гадость сказать, а для того, что бы поделиться опытом и помочь.
Теперь давайте по порядку. Вводное – хотите верьте, хотите нет, но если устройство является не закоченей конструкцией, а скажем так «полуфабрикатом», то годится оно только лишь для индивидуального исполнения/повторения, но с другой стороны, тогда какой смысл публиковать статью?! Вы скажите, ну так это же не сайт «мамочек», а сайт технический и всё такое… Нееее, всё не так, на самом деле человек может быть хорошим схемотехником- но совсем не быть программистом, да и вообще продукт должен быть логически закончен и не важно как он позиционируется. Короче, смысл прост, есть железка, есть прошивка, дальнейшее управление и настройка должна осуществляться без допиливания пользователем прошивки под себя и последующим дебагом, вообще исходников может и не быть (только если Вы просто желаете поделиться знаниями, не более), в ином случае – это «полуфабрикат», который не имеет шансов на выживание или же хоть какое- то повторение.
Вводные бросания фекалиями я закончил :))) теперь давайте к делу.
Что я предлагаю:
Никаких допилов пришивки юзером!

Варианты решений:

1. Настройка осуществляется через терминал т.е. скидываем GSM модуль, вместо модуля подключаем USB-UART модуль и уже по средствам терминала запиндориваем в еепром те системные настройки- которые потом, в последствии будут использованы. При чём проц сам будет последовательно спрашивать, ну типа того: 1. MASTER PASS? – ввели мастер пасс, нажали ентер и т.д. 2. MASTER PHONE NUMBER? И т.д.
Технически всё просто, на плате девайса появляется перемычка- обучение, накидываем перемычку, подключаем юарт, включаем проц в розетку))) Проц стартует- смотрит, оп а там перемычка стоит, значит мне нельзя работать, я буду обучаться….

2. Настройка осуществляется по средствам SMS. При этом мастер пассом является не статичное «12345», а например, последние 4 – 6 цифр имей модуля (вариантов может быть много, но с имеем самый лучший вариант, он никуда не потеряется и не забудется, он всегда у всех разный и т.д.). При этом мастер пасс служит только лишь для того, что бы можно было поменять юзерпас и не более! Ну, а дальше всё просто….

3. Настройка и управление осуществляется по средствам SMS, но только с мастерномера, т.е. как и в предыдущем варианте, только полностью отсутствует понятие «пароля», паролем является номер с которого была отправлена SMS. Тоже всё просто, всё та же перемычка (как в пункте выше) накидываем перемычку, включаем проц, проц видит что есть перемычка, значит начинает ждать входящего вызова, первый входящий вызов на модуль и будет запомнен как мастерномер. Это только лишь первые мысли которые пришли в голову, можно ещё кучу вариантов придумать…
Что сейчас? В текущем виде прошивка не позволяет настраивать девайс под свои нужды, кроме как перепилом прошивки, все настройки будут уничтожены при следующем включении- это плохо!

unsigned char eeprom eemasterpass[5] ="WE32";
unsigned char eeprom eeuserpass[5] ="1234";
unsigned char eeprom eealarmphone[13] ="+70000000000" ;
.
.
.


Т.е. что Вы делаете, Вы из еепром переменной делаете еепром константу, ибо у Вас определение этих переменных в заголовке программы, но большой вопрос зачем? Ладно, дальше хуже, юзер меняет, например значение пароля, значение падает в еепром переменную, потом бац- питание проца пропало, старт иииии- снова все переменные вернулись на свои ранее заданные значения. Коль пошла такая пьянка, то делать нужно было хотя бы так:

Объявляем переменные еепрома:
unsigned char eeprom eemasterpass[5];
unsigned char eeprom eemasterpass[5];
unsigned char eeprom eeuserpass[5];
unsigned char eeprom eealarmphone[13];
……..
unsigned char eeprom eefirststart;


перед майном:
void check_first_start( void ) {

if ( eefirststart != 0xAA ) {
eemasterpass[5] ="WE32";
eeuserpass[5] ="1234";
…….
eefirststart = 0xAA
}
eeprom2var();
}


Ну и перед главным вайл( 1 ) пишем уже check_first_start();

Смысл понятен, да, т.е. мы перед тем как уйти в майн цикл, смотрим- это первый запуск МК после прошивки или нет, определяем по переменной eefirststart, которая хранится в еепром. Если она не равна условным 0хАА, значит после прошивки МК это первое включение, значит надо заполнить еепром переменные каким- то значениями стартовыми, соответственно при следующем включении питания eefirststart уже будет равна 0хАА и в оперативку просто будут изыматься значения из еепрома, а не перезаписываться одними и теми же константами.
При чём, скажу больше, в этом исполнении вообще еепром нахрен не нужен, можно было бы с таким же успехом объявить глобальные массивы и переменные со стартовыми значениями и всё.
Грубо говоря сейчас unsigned char eeprom eemasterpass[5] ="WE32"; имеет такой же смысл как и unsigned char masterpass[5] ="WE32";

Дальше, это вообще трешак)))))
float eeprom voltdev =0.02685546875; // 1/25-devider(1k+24k) 1.1V/1024*25=0.02685546875

Может так?
#define voltdev 0.02685546875

Короче я вообще не понял нафига хранить конкретную константу в еепроме.

Ладно, едем дальше.
Функция eeprom2var. Это короче тоже круто.
Во первых, если уж изобретать лисапед, то лисапед должен быть как минимум собран правильно, у Вас в принципе по коду везде капут такой творится, но вот первое на что упал взгляд, если Вы собираете массив, то он обязательно должен быть закрыт всегда нулём, это первое правило, которое должно стоять на вершине всего остального!

Короче так не правильно:
while (eemasterpass[counter]) {
masterpass[counter] = eemasterpass[counter];
counter++;
#asm("wdr")
}


Правильно:
while ( eemasterpass[ counter ] ) {
masterpass[ counter ] = eemasterpass[counter];
masterpass[ counter + 1 ] = 0;
counter++;
#asm("wdr")
}


А Вообще я так и не понял зачем это было сделано, но вот как бы лисапед заводского производства в компиляторе уже имеется и выглядит он так:
memcpy(masterpass, eemasterpass, strlen(eemasterpass ) );

Штатная функция приёма строки от модуля- в топку и на свалку! Ну в каких- то (может) решениях и такая сгодится, но в нашем случае – это КОСЯЧИЩЩЩЩЕ!!!!

Вот это неправильно:
// USART Receiver interrupt service routine
interrupt [USART_RXC] void usart_rx_isr(void)
{
char status,data;
status=UCSR0A;
data=UDR0;
if ((status & (FRAMING_ERROR | PARITY_ERROR | DATA_OVERRUN))==0){
rx_buffer0[rx_wr_index0]=data;
if (++rx_wr_index0 == RXFIFO_BUFFER_SIZE0) rx_wr_index0=0;
if (++rx_counter0 == RXFIFO_BUFFER_SIZE0){
rx_counter0=0;
rx_buffer_overflow0=1;
};
};
}


Правильная функция приёма строки от модуля:

Используемые переменные для работы с юартом:

// размер буфера приёма строки
#define RX_BUFFER_SIZE 255
// USART буфер
unsigned char rx_buffer[ RX_BUFFER_SIZE ];
// индекс записи в массив
unsigned char rx_wr_index = 0;
// бит указывающий на "полный" приём данных
bit rx_buffer_complete;


Функция очистки:
// Очистка приёмного буфера UART
void rx_clear( void ) {
rx_wr_index = 0;
rx_buffer_complete = 0;
rx_buffer[ 0 ] = 0;
}


// Сама функция по приёму строки от модуля
interrupt [USART_RXC] void usart_rx_isr(void) {
char status,data;
status=UCSR0A;
data=UDR0;

// проверка была ли обработана предыдущая строка
// игнорируем новые входящие данные пока юзер не обработал последнюю принятую строку
if ( rx_buffer_complete ) return;
// смотрим ошибки
if ( status & (FRAMING_ERROR | PARITY_ERROR | DATA_OVERRUN) ) return;
// всегда игнорируем 0x0A, чтобы реагировать только на 0x0D
if ( data == 0x0A ) return;
// проверяем 0x0D - конец строки, а модуль всегда будет закрывать отправленную строку символом 0D
if ( data == 0x0D ) {
// если длинна принемаемых данных составила менее двух символов, значит обнуляем результаты приёма, обязательный КОСТЫЛЬ, модули шлют двойной ентер, нулевые строки нам никчему!!!
if ( strlen(rx_buffer) < 2 ) {
// чистим буфер приёма
rx_clear();
// выходим
return;
}
}
else {
// записываем принятый байт
rx_buffer[ rx_wr_index ] = data;
// всегда записываем 0 после принятого байта
rx_buffer[ rx_wr_index + 1 ] = 0;
// увеличиваем индекс для следующего байта
rx_wr_index++;
// проверяем переполнение
if ( rx_wr_index > RX_BUFFER_SIZE - 2 ) rx_wr_index = RX_BUFFER_SIZE - 2;
// выходим
return;
}
}


Вот теперь есть фалг полностью принятой строки, есть буфер приёма, делайте с ним что хотите и главное когда хотите…..

«Модуль не умеет кириллицу….» Разочарую, ни один модуль не умеет кириллицу, но это не значит, что не получиться слать смс на человечем, а не на буржуйском языке, просто слать надо не в формате AT+CSCS="GSM", а в формате AT+CSCS="UCS".

Ну тут совсем всё просто, делаете например так:
#define DOOR_OPEN 0414043204350440044C0020043E0442043A0440044B044204300021 // что в свою очередь на великом и могучем = Дверь открыта!

А дальше пишите свой printf( DOOR_OPEN );
Номер получателя вроде тоже в юцсе должен быть, но и это не проблема

// нам поможет цикл)))))
for ( i = 0; i < strlen( alarmphone ); i++ ) printf( "%04X", alarmphone[ i ] );

Соответственно на выходе, например +79101231212 превратится в 002B00370039003100300031003200330031003200310032

Фух….
Всё, что- то я уже подзаморился мануалы писать, а по хорошему вся прошивка требует перепила.
В общем, ещё раз, я всё выше написанное изложил только лишь для того, что бы указать на то, что такое хорошо и что такое плохо и только лишь потому, что сам лично набил в своё время огромное колл- во шишек, просто мне повезло, у меня были и есть люди, которые могут подсказать и указать, ну и образование программиста чуть чуть ;)
Ну, а дальше смотрите, захотите общения- велком, всегда помогу чем смогу, а если надо будет и прошивку вместе свояем)
Ах да, я приложил ещё програмульку юцс калькулятор, для себя писал, чтоб голову не ломать когда требуется кодировки туда сюда гонять, может и Вам пригодится.

Вложения:
Комментарий к файлу: UCS калькулятор
UCS.zip [244.34 KiB]
Скачиваний: 440

Автор:  r0c [ Вт апр 11, 2017 06:05:10 ]
Заголовок сообщения:  Re: Автомобильный GSM-оповещатель с дополнительными функциям

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

Автор:  savage [ Вт апр 11, 2017 18:48:28 ]
Заголовок сообщения:  Re: Автомобильный GSM-оповещатель с дополнительными функциям

Добрый день!
Спасибо коллега vitalyadm за конструктивную критику. В свое оправдание хочу сказать две вещи. Во-первых все это было опубликовано только из принципа "не пропадать же добру". Вдруг кому-то пригодится. Я только слегка причесал, чтобы уж совсем страшно не было. Ни о какой коммерциализации речи вообще не идет. Во-вторых, я сейчас ООООчень редко программирую. То, что представлено здесь, это единственная программа написанная мною за последние 2 года. Я иногда еще на Шеле пописываю, по 5 строчек (скопировать туда, удалить там). :(

Теперь, что касается замечаний.

По настройкам и мастерпаролю (или мастерномеру). Все что Вы предлагаете это можно реализовать, но опять же это все хорошо для массового устройства, которое будет делаться сотнями. При единичных экземплярах, можно и EEPROM поперешивать. Опять же можно оставить мастерпароль только для настроек пароля и номера.
Есть там закоментированная строчка
//}else if((strcmp(password,masterpass)==0)&&(strcmpf(comand,"SETPHONE")==0)){ //masrerpassword only
В этом случае номер можно будет поменять только с мастерпаролем. Собственно больше там нет никаких критичных настроек. Ну можно еще сделать настройку пароля только с использованием мастерпароля. Но зачем? Иногда самому пользователю нужно сменить пароль.
В перемычке и уарт или привязке к имей тоже не вижу необходимости. Про перемычку и уарт у меня мысль была кстати. Да, защищенность лучше. Да, постороннее вмешательство исключено. Но это всего лишь пейджер. Самое страшное что с ним можно сделать это разблокировать замок или запустить вебасту (как в моем случае). Ну вот разве что настройку номера оповещения получше можно защитить. Еще можно сделать список телефонов с которых можно менять настройки или управлять нагрузками. Тогда вообще можно без пользоватльских паролей обойтись. Собственно все.
Вы очевидно делали систему охранной сигнализации. В Вашем случае действительно без всего этого нельзя.

Что касается EEPROM.
Вообще при первом старте можно проверять наличие FF в еепром. т.е что еепром чистый. Например так приходится делать для программ отлаживаемых в протеусе (моем). Он иногда у меня не позволяет сразу загрузить в него готовый еепром. Но в данном случае как-то было без надобности. Тем более cvavr все равно сразу предлагает перешить еепром.
float eeprom voltdev =0.02685546875; // 1/25-devider(1k+24k) 1.1V/1024*25=0.02685546875
Опаньки . Забыл это перекочевало с другого проекта, где оно настраивалось и запоминалось. Но уже не важно. Хотя можно было выкинуть десаток строк из программы. :oops:

По поводу memcpy, Собственно я уже не помню почему я ее забраковал. Толи что-то у меня еще обрабатывалось одновременно, толи глючило что-то. Не помню уже. Но какие-то причины были. Сейчас можно и с ней сделать.

Функция приема уарт. Я уже писал в статье, можно было парсить строку прямо в прерывании на лету без ФИФО и лишних пятисот байт ОЗУ. Мне показалось удобнее так. Независимый прием данных и независимая их обработка. С самого начала уменя какие-то заморочки были при отделении от смс ее тела и ОДНОВРЕМЕННОМ (случайном) приеме звонка. Даже были мысли сделать массив строк, а уже потом их разбирать. Собственно можно реализовать и по вашему предложению.

По поводу кириллицы. Речь не о СМСках. Попробуйте запросите баланс у провайдера и посмотрите что выдает модуль. С СМСками как раз проблем нет никаких. У меня даже есть готовая библиотека. А вот сообщения провайдера например в ответ на *100#. Я был бы очень рад если бы мне кто нибудь предложил решение.

В общем вот такие оправдания моего невежества. Еще раз ОГРОМНОЕ СПАСИБО за конструктивную критику. Если буду дорабатывать обязательно воспользуюсь советами. :beer:

Добавлено after 1 hour 18 minutes 39 seconds:
vitalyadm писал(а):
// размер буфера приёма строки
#define RX_BUFFER_SIZE 255
// USART буфер
unsigned char rx_buffer[ RX_BUFFER_SIZE ];
// индекс записи в массив
unsigned char rx_wr_index = 0;
// бит указывающий на "полный" приём данных
bit rx_buffer_complete;


Функция очистки:
// Очистка приёмного буфера UART
void rx_clear( void ) {
rx_wr_index = 0;
rx_buffer_complete = 0;
rx_buffer[ 0 ] = 0;
}


// Сама функция по приёму строки от модуля
interrupt [USART_RXC] void usart_rx_isr(void) {
char status,data;
status=UCSR0A;
data=UDR0;

// проверка была ли обработана предыдущая строка
// игнорируем новые входящие данные пока юзер не обработал последнюю принятую строку
if ( rx_buffer_complete ) return;
// смотрим ошибки
if ( status & (FRAMING_ERROR | PARITY_ERROR | DATA_OVERRUN) ) return;
// всегда игнорируем 0x0A, чтобы реагировать только на 0x0D
if ( data == 0x0A ) return;
// проверяем 0x0D - конец строки, а модуль всегда будет закрывать отправленную строку символом 0D
if ( data == 0x0D ) {
// если длинна принемаемых данных составила менее двух символов, значит обнуляем результаты приёма, обязательный КОСТЫЛЬ, модули шлют двойной ентер, нулевые строки нам никчему!!!
if ( strlen(rx_buffer) < 2 ) {
// чистим буфер приёма
rx_clear();
// выходим
return;
}
}
else {
// записываем принятый байт
rx_buffer[ rx_wr_index ] = data;
// всегда записываем 0 после принятого байта
rx_buffer[ rx_wr_index + 1 ] = 0;
// увеличиваем индекс для следующего байта
rx_wr_index++;
// проверяем переполнение
if ( rx_wr_index > RX_BUFFER_SIZE - 2 ) rx_wr_index = RX_BUFFER_SIZE - 2;
// выходим
return;
}
}



В этом алгоритме есть один существенный недостаток. Если "юзер" слегка проспал, то модем будет гнать данные, а они будут теряться. Это важно при управлении по СМС. Либо СМСка будет принята не вся, либо не правильно расшифрована.
Опять же есть проблема. Узер занят обработкой текста, а тут модем выдал очередную порцию. Программа закончила обработку текста, сбросила rx_buffer_complete. Начался прием данных, но получен только хвост.
Короче не самое мудрое решение.
По хорошему нужно ждать 0A,0D, а уже потом обрабатывать ВСЁ сообщение, причем в зависимости от типа это будет одна или несколько строк. Это нужно сразу учитывать по сигнатуре в начале. Но я, честно сказать, тоже слегка мухлюю.

Добавлено after 40 minutes 32 seconds:
vitalyadm писал(а):
Т.е. что Вы делаете, Вы из еепром переменной делаете еепром константу, ибо у Вас определение этих переменных в заголовке программы, но большой вопрос зачем? Ладно, дальше хуже, юзер меняет, например значение пароля, значение падает в еепром переменную, потом бац- питание проца пропало, старт иииии- снова все переменные вернулись на свои ранее заданные значения.

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

Автор:  r0c [ Вс апр 16, 2017 02:47:27 ]
Заголовок сообщения:  Re: Автомобильный GSM-оповещатель с дополнительными функциям

Спаял, подключил. Машину открывает-закрывает-заводит-глушит двигатель. :))
savage писал(а):
Ну тут совсем всё просто, делаете например так:
#define DOOR_OPEN 0414043204350440044C0020043E0442043A0440044B044204300021 // что в свою очередь на великом и могучем = Дверь открыта!

Не смог разобраться с кириллицей.
С переводом с латиницы в кириллицу все понятно, спасибо за утилиту. А как это дело отправить ?

Автор:  savage [ Вс апр 16, 2017 14:39:11 ]
Заголовок сообщения:  Re: Автомобильный GSM-оповещатель с дополнительными функциям

Для работы с кириллицей я использовал в свое время (для другого проекта) декодер из стандартного примера AVR323 (там файлики AVRSMS_zip называются) Подробностей уже не помню. Но помоему ничего сложного.
Как конкретно работать с PDU можно прочитать например http://radiolaba.ru/microcotrollers/gsm-modul-neoway-m590-opisanie-i-komandyi-upravleniya.html
Не знаю кто автор, но статья хорошая.

П.С. Я в статье забыл рассказать для чего светодиоды. LED1 я думаю понятно. Индикатор состояния модема. Правда толку от него мало. Он в режиме сна всеравно не горит. LED2 показывает состояние устройства. Горит когда устройство просыпается. Мигает с частотой 1Гц, при поиске сети. Мигает с частотой 4Гц, когда ненайдена симкарта или не ответил модем.

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

Добавлено after 6 minutes 5 seconds:
Re: Автомобильный GSM-оповещатель с дополнительными функциями
П.П.П.С Вспомнил вопрос про потребляемый ток. На плате ардуино еще есть светодиод индикатора питания. На моих платках он кушает 5мА

Вложения:
AVR323.zip [617.97 KiB]
Скачиваний: 409

Автор:  r0c [ Вс апр 16, 2017 15:13:44 ]
Заголовок сообщения:  Re: Автомобильный GSM-оповещатель с дополнительными функциям

Спасибо, попробую русский язык добавить. А светодиод я сдул, на него уходило половина потребляемого тока.
9-10 мА потребляет микроконтроллер и около 20мА целиком все устройство. Амперметр стрелочный, инерционный, стрелка слега колеблется 18-20мА. Ну и в пиках- радиомодуль периодически включается.
И еще вопрос- зачем в схеме соединены выводы 6 и 10(правые)?

Автор:  vitalyadm [ Ср апр 19, 2017 08:40:20 ]
Заголовок сообщения:  Re: Автомобильный GSM-оповещатель с дополнительными функциям

savage писал(а):

По поводу кириллицы. Речь не о СМСках. Попробуйте запросите баланс у провайдера и посмотрите что выдает модуль. С СМСками как раз проблем нет никаких. У меня даже есть готовая библиотека. А вот сообщения провайдера например в ответ на *100#. Я был бы очень рад если бы мне кто нибудь предложил решение.
.
.
.
В этом алгоритме есть один существенный недостаток. Если "юзер" слегка проспал, то модем будет гнать данные, а они будут теряться. Это важно при управлении по СМС. Либо СМСка будет принята не вся, либо не правильно расшифрована.
Опять же есть проблема. Узер занят обработкой текста, а тут модем выдал очередную порцию. Программа закончила обработку текста, сбросила rx_buffer_complete. Начался прием данных, но получен только хвост.
Короче не самое мудрое решение.
По хорошему нужно ждать 0A,0D, а уже потом обрабатывать ВСЁ сообщение, причем в зависимости от типа это будет одна или несколько строк. Это нужно сразу учитывать по сигнатуре в начале. Но я, честно сказать, тоже слегка мухлюю.

Вот вообще Вы меня не поняли.
По балансу- ну я же всё объяснил.
Всё просто:
1. Вы задаёте команду модулю AT+CUSD=1,"*102#"
2. Модуль отвечает:
Вариант 1: +CUSD: 0, "OCTATOK 96.34 p.", (в латинице)
Вариант 2: +CUSD: 0, "041E0441044204300442043E043A002000390036002E003300340440002E" (Остаток 96.34р. в кириллице)
3. Дальше нужно добавить в прошивку алгоритм, который проверяет в какой кодировке был принят ответ на запрос баланса, если в формате UCS, значит шлём обратную СМС в формате UCS (AT+CSCS="UCS"), если строка в латинице, то (AT+CSCS="GSM")

Как это проще всего сделать, самый простой вариант- это посчитать количество символов "0" в буфере приёма, если их, скажем больше 10, значит это UCS, если нет, то....

Ну всёж просто.

Дальше.

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

Автор:  savage [ Ср апр 19, 2017 15:29:20 ]
Заголовок сообщения:  Re: Автомобильный GSM-оповещатель с дополнительными функциям

vitalyadm писал(а):
Всё просто:
1. Вы задаёте команду модулю AT+CUSD=1,"*102#"
Ну всёж просто.

Опаньки. А вот тут я похоже ступил. Я запрашиваю баланс дедовским способом printf("ATD%s;\r",ballanscomand);
Почему-то я пропустил в документации AT+CUSD. Старею.
Надо будет попробовать. Спасибо за наводку.


vitalyadm писал(а):
Дальше.
Про алгоритм RX, "юзер" в комментариях- есть проц, юзер тот что с ногами и руками вообще ничего просыпать не должен. Как бы разжевать- то. Есть принятая строка по символу каретки, всё, эта строка полная и полностью принятая, дальше её деваете куда хотите.

Если строка будет приниматься не сначала, то у нее тоже будет символ возврата каретки. И что с ней делать?
СМСка это не данные с GPS. Получил неправильные - подожди, следующие придут корректные. СМСки шлет человек и он не знает дошла она или нет до тех пор пока результат не получит.

По поводу "юзера" это ваши слова.
vitalyadm писал(а):
// игнорируем новые входящие данные пока юзер не обработал последнюю принятую строку

Теперь что касается юзера с руками и ногами. Представьте ситуацию. Этот самый юзер приплясывает возле машины пытаясь ее открыть. А тут программа занята обработкой спама от провайдера или случайного входящего звонка, или пытается отправить СМСку о срабатывании. Всё, по вашему алгоритму СМС от пользователя пропала. Вы может не заметили у меня в программе "AT+CNMI=2,2". Это значит что СМС не пишутся в СИМ, а сразу идут на консоль. Иначе пришлось бы либо постоянно, неостанавливаясь опрашивать модем (без какого либо энергосбережения) на предмет пришедшей СМС или смириться с какой-то периодичностью. Секунд в 10 например. Предвидя возражение, что можно было опрос сделать по прерыванию от выхода модема RING, скажу что мой модем его формирует только по входящему звонку, и не дает, как написано в документации, однократного импульса длительностью 25-35 мс при получении СМС. Я как раз и пытался сначала это реализовать. Не прошло. А так было бы очень здорово, запросил список СМС, обработал непрочитанные. Потом удалил прочитанные. Красота. Но увы и ах.
vitalyadm писал(а):
Или анализируете сразу в прерывании или кидаете во временный буфер, а основной буфер приёма чистите сразу для приёма следующей строки, короче как удобней.

А об этом я даже в самой статье написал. Вот только по факту и реализован вариант с буферами. Большой ФИФО с двухкратным запасоми и непосредственно буфера для тела СМС и ее параметров.

Автор:  savage [ Чт апр 20, 2017 08:30:08 ]
Заголовок сообщения:  Re: Автомобильный GSM-оповещатель с дополнительными функциям

А хотите прикол? А не работает UCS на моем модуле для CUSD. Как понимаю у Мегафона не работет.

PDU и UCS:

AT+CMGF=0
OK
AT+CSCS="UCS2"
OK
AT+CUSD=1,"*100#",15
OK
ПУСТО!!!!

ASCII и текст:

AT+CMGF=1
OK
AT+CSCS="GSM"
OK
AT+CUSD=1,"*100#",15
+CUSD: 0,"-282844.77?.0???.?????? "???? ????" ?? ?????! 07774 (???? 0?)",72

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

Автор:  savage [ Пт апр 21, 2017 19:06:35 ]
Заголовок сообщения:  Re: Автомобильный GSM-оповещатель с дополнительными функциям

Ну в общем это Мегафона глюк. Возможно даже местного.
после atd*105*1250# и atd2 (русский )или atd1 (транслит) начинает работать правильно. До холодного перезапуска модема. Если его выключить, минуты 3 подождать, то после включения и поиска сети он снова не работает с UCS2. Возможно не правильно регистрируется как-то. Я не знаю этой кухни.
AT+CSCS="UCS2"
OK
AT+CUSD=1,"*100#",15
OK

пусто

atd*105*1250#
+CUSD: 1,"0056007900620065007200690074006500200061006C00660061007600690074003A00
0A0031002E004C006100740069006E0073006B0069006A000A0032002E0052007500730073006B00
69006A",15
OK
Сразу принял UCS без изменений настройки.
atd1
OK
+CUSD: 0,"0055007300740061006E006F0076006C0065006E0020006C006100740069006E007300
6B0069006A00200061006C0066006100760069007400200070007200690020006F0074006F006200
720061007A00680065006E0069006900200055005300530044002D00730065007200760069007300
6F0076",15
Теперь работает. До перезагрузки....
Так что экспериментировать просто не хочется.

Ну и раз уж я все равно снял блок с машины, то небольшое обновление.
Небольшие косметические изменения кода. Исправлена пара мелких ошибок. Улучшена защита от дурака при настройке номера телефона оповещения Еще номер телефона можно поменять теперь только с мастерпаролем.
Поменяна строка float eeprom voltdev =0.02685546875; на const float voltdev =0.02685546875; :)
Добавлена команда SETBALANSCOM теперь можно без перепрошивки еепром поменять команду запроса баланса. Тоже с мастерпаролем. (пример *pasw#SETBALANSCOM:*102#)
Еще добавил вариант прошивки где есть возможность проконтролировать закрыт ли ЦЗ (gsm-alarmprj-key.hex). Для этого задействован вывод меги PC1. При 0 на этом входе СМС со статусом будет сообщать, что дверь не заблокирована.
Подключение следующие. Вывод подтянут к 5В резистором 24к. К ЦЗ подключен через диод (анодом к PC1).
Русификуцию не делал из-за проблем с UCS. Собственно меня интересовало только чтобы безглючно приходил баланс. При обвесе всего этого UCS я баланс скорее всего перестану получать вообще. Отсылать после каждой перезагрузки atd*105*1250# это помоему извращение.

Добавлено after 7 hours 32 minutes 47 seconds:
Re: Автомобильный GSM-оповещатель с дополнительными функциями
И схема доработки.

Вложения:
shem-conect2.png [4.76 KiB]
Скачиваний: 737
gsm-alarm-prog21.zip [130.78 KiB]
Скачиваний: 434

Автор:  sergho [ Пн май 01, 2017 08:03:50 ]
Заголовок сообщения:  Re: Автомобильный GSM-оповещатель с дополнительными функциям

Уважаемый автор! Можно комментарии к последней прошивке? на какой проц и частоту скомпилировано? и чем отличаются 2 hex в архиве?

Автор:  savage [ Вт май 02, 2017 19:48:35 ]
Заголовок сообщения:  Re: Автомобильный GSM-оповещатель с дополнительными функциям

Все скомпилировано под ATmega328P под 16Мгц.
gsm-alarmprj-key.hex под доработанную схему для контроля ЦЗ.
gsm-alarmprj.hex без доработки схемы.

Автор:  r0c [ Чт май 04, 2017 09:15:53 ]
Заголовок сообщения:  Re: Автомобильный GSM-оповещатель с дополнительными функциям

Пришел gsm модуль А6. Не пробовали такой использовать? Он по экономичнее будет. В моем варианте маячок имеет автономное питание.

Автор:  savage [ Чт май 04, 2017 14:38:42 ]
Заголовок сообщения:  Re: Автомобильный GSM-оповещатель с дополнительными функциям

SIM800 пробовал. Разницы особой нет. Команды АТ одни и те-же. А до энергосбережения я не добрался. Я с ним экспериментировал для GPS трекера. SIM800+NEO6M+STM32. Но дальше экспериментов не продвинулся. Некогда заниматься.
По моему с экономичностью вряд ли будет большой прогресс. От опроса сети не убежишь.

Автор:  r0c [ Ср июл 26, 2017 13:20:30 ]
Заголовок сообщения:  Re: Автомобильный GSM-оповещатель с дополнительными функциям

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

Автор:  savage [ Вт авг 01, 2017 09:22:05 ]
Заголовок сообщения:  Re: Автомобильный GSM-оповещатель с дополнительными функциям

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


Извините за задержку с ответом

В основном цикле программы есть кусок следующего содержания:

if (alarmflag){

LEDPIN=1;
#asm("cli")
alarmflag=0;
alarmimeout=2; //3 sec
#asm("sei")
while (alarmimeout!=0){
#asm("wdr")
};


Значение alarmimeout=2; это задержка в секундах +1.
Если поставить вместо 2 например 4, то задержка будет 5 сек.

Страница 1 из 1 Часовой пояс: UTC + 3 часа
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/