Перейти к содержанию
Поиск
    

IvanPletnev

Участник
 Профиль  Обзор контента

  • Постов

    68

  • Зарегистрирован

  • Посещение

 Тип контента 

Сообщения, опубликованные IvanPletnev

  1. Опубликовано · Изменено пользователем Иван Плетнев · Пожаловаться

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

     

    Ну, зачем язвить. Я имел ввиду два полумоста. Тогда нижние транзисторы имеют смысл. Попробовал с одним транзистором, субъективно показалось, что стартует мотор на малом значении заполнения ШИМ хуже, чем с полумостом.

     

    Регулировка ШИМ у меня получилась ограниченной примерно 95%. Дальше, видимо, бутстрепная емкость в паузах ШИМ не успевает заряжаться.

  2. Опубликовано · Пожаловаться

    То есть, в паузах ШИМа мотор будет тормозиться, наверное? Так задумано?

    Если мотор можно отсоединить от земляной шины и перенести на сторону плюса питания, то оставьте один транзистор, выбросьте ненужный драйвер и вместе с ним лишние проблемы.

     

    Кстати, схема заработала. Отлично крутит мотор 60Вт. Но Вы правы, получается, что в паузах ШИМ мотор подтормаживается! А для чего тогда придуман полумост? Только для случая, когда требуется менять направление вращения?

  3. Опубликовано · Пожаловаться

    а зачем вам Q2?

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

  4. Опубликовано · Изменено пользователем Иван Плетнев · Пожаловаться

    можетбытьпоэтому?

     

    Ну вообще в даташите написано "3.3V, 5V and 15V input logic compatible". и еще "The logic input is compatible with standard CMOS or LSTTL output, down to 3.3V logic."

     

    А светодиод - не слишком ли малая нагруза? Посмотрите осциллографом выходы, благо напряжение низкое. PWM у Вас задается независимо от выходной цепи, или с ОС?

     

     

    Да, возможно. Попробую лампу на 12В. Нет, PWM без обратной связи.

     

    Update:

     

    Если подаешь статически 3,3В на вход IN, то микросхема отрабатывает правильно, уровни выходов переключаются, верхний транзистор открывается, нижний закрывается, на нагрузке появляется напряжение. Но! Напряжение на нагрузке всего лишь 7,8В. Куда еще четыре вольта пропали?

     

    Ну а когда подключаешь ШИМ, схема не работает.

  5. Опубликовано · Пожаловаться

    Здравствуйте!

     

     

    Требуется сделать управление скоростью вращения двигателя. Собрал схему, рассчитал емкость бутстрепного конденсатора по Design Tip DT 98-2a, частота 4000 Гц, получилось 0,34мкФ, использую 0,47. Подключил светодиод с резистором как нагрузку. На вход IN IR2104 подаю ШИМ с уровенем 3,3В. Не работает. В чем может быть проблема?

    Картинка вот.

  6. Опубликовано · Пожаловаться

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

     

    Вот - http://www.delphisources.ru/forum/showthread.php?t=6547 Обратите внимание, что case намного прозрачнее if. Но это его удобство, проще читать код, все видно хорошо.

    А ссылку на статью давал, там есть рисунки с кодами автомата. Для возвртата в исходное состояние используется оператор goto. И под каждым case устанавливается следующее состояние.

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

    Да я ж говорю, что тоже на автоматах всё у меня

                case 0:
                ExtraBufferCopyFlag = 1; //флаг копирования нужного фрагмента буфера (со смещением)
                send_command0(CIPSTATUS);                
                gprsstate++;
                response_timeout=2000;
                break;
            case 1:
                if (!response_wait) { //если дождались ответа
                    switch (response_code) {
                        case 15: // INITIAL STATE
                            gprsstate++;
                            ready_to_send=0;
                            break;
                        case 17: // PDP DEACT STATE (Отключен сетью)
                            gprsstate = 100; //закрываем все подключения
                            ready_to_send=0;
                            break;
                        case 16: //TCP CLOSED
                            gprsstate = 12;
//                            gsm_delay=300;
                            ready_to_send=0;
                            break;
                        case 18: //CONNECT OK
                            gprsstate = 20;
                            send_flag=1;
                            break;
                        case 20: //CONNECTING
                            gprsstate = 30;
                            break;
                        case 3:
                            gprsstate=30;
                            break;
                    }
                }

    Ну и так далее.

     

    Тоже определял конец строки по таймауту. Работало.

    Потом перешел по \r\n. По \r\n оказалось более работоспособно, и нет никакой необходимости в знании сколько их будет в ответе. К примеру посмотрим на строку \r\nOK\r\nблаблабла\r\n, по первому \n мы видим что это начало строки (так как количество принятых байтов равно 2). По второму получаем ответ OK. По третьему получаем ответ блаблабла. Поэтому при разборе ответов, задача сводится к проверке "наборов байтов находящихся между \r\n". Единственное что портит всю картину это приглашение к вводу данных "> ", но и это обходится очень просто.

     

    Это Вы в прерывании всё делаете? Если так, то приличный такой обработчик в прерывании будет крутиться. А если нет, тогда опять не ясно, как конец сообщения определить?

  7. Опубликовано · Пожаловаться

    Большое спасибо CADiLO за ответ!

    Помогите ещё пожалуйста разобраться с балансом, вот такие проблемы: я пишуAT+CSCS="GSM" ответ OK, зачем AT+CUSD=1,"*100#" и когда отправляю он почему то отправляет post-79077-1398510900.jpg и пишет ERROR. Как будто он не воспринимает символ # вообще. Из за чего это может быть?

    Через ATD*100# такая же фигня(

    Что касается ATD*100#, по-моему, строку нужно завершать символом ";". Т.е. ATD*100#;. Кстати, если оператор поддерживает транслит, то лучше отправлять запрос #100#, иначе ответ будет совершенно нечитаем.

  8. Опубликовано · Пожаловаться

    Однозначно! Все прочее (кроме автомата) - просто мертвому припарки. Выкрутиться не получится.

    Кстати, у оператора case в любом "языковом исполнении" всегда имеется свой else, позволяющий пропустить что-угодно как с распознаванием, так и без, если со стороны пришел некий "невнятный" и не вписывающийся в рамки протокола ответ - команда вместо данных и в таком духе.

    Немного не понял про else. Что Вы имеете ввиду?

     

    Тоже сначала делал обработку по таймауту.

    Все было очень плохо.

     

    Потом перешел на обработку по концу строки.

    По приходу строки выставляю сигнал ртс, в основном цикле обрабатываю строку, убираю ртс когда процессор готов к приему.

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

    В этом случае обрабатываю второую строку и проверяю что-бы ее длинна была 14 символов.

    При этом эхо включено, и оно не мешает процессору вылавливать необходимые ответы.

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

     

    Самое первое правило - обрабатывать ВСЕ!!! последовательности от модема.

     

    Второе - последовательность AT команд четко регламетирована (см GSM 07.07 раздел 4).

    Заметьте, у всех команд стандарта есть final result code (чего не скажешь творчестве собственных расширений производителей модемов)

    Все что между - результат выполения команды.

     

    И еще есть ансинхронные ответы. Могут влезть куда угодно. либо пропускайте их, либо применяйте. НО РАСПОЗНАТЬ их надо!!

    Я всё понимаю, и стараюсь учесть все возможные ответы от модема. Но если пытаться определять конец посылки по CR/LF, учитывая то, что CR/LF может быть несколько, например \r\nOK\r\nблаблабла\r\n, то нам как минимум нужно знать, сколько \r\n будет в ответе от модема. Посчитать их, конечно, легко, но если асинхронное сообщение появилось, с ним как быть? Направьте меня в нужную сторону. Вообще, конечно, то, что форматы ответов так разнятся от команды к команде, сильно осложняет их обработку и даже немного раздражает.

     

    Что до меня, то пока особых трудностей с определением конца посылки по таймауту не возникало. Работает достаточно надежно. Кстати, снизил длительность таймаута до 1мс., пока полет нормальный.

     

    Кстати, по поводу собственно сабжа. У меня трудности, описанные в первом посте этой темы возникали в основном из-за ошибки переполнения буфера UART, связанной с отключением прерываний в другом, параллельном процессе. Так что проблема, можно сказать, почти решена. Сейчас тестирую прозрачный режим, обсуждение в соседней теме . Буду рад выслушать Ваши мнения.

     

    Это как раз не страшно. У меня идет работа с голосом (прием звонка, дозвон), SMS (прием и отправка) и GPRS (клиент) , плюс полный набор обслуживающих команд и всего в сумме получается не более 60 вариантов заголовков команд/ответов. Если делать не побуквенное сравнение, а более оптимизированный парсер, то получается быстрое автоматическое определение что пришло. Но с GPRS, да, в непрозрачном режиме приходится выкручиваться, а в прозрачном нет мультисокетов. Как вариант - реализовать режим мультиплексирования (CMUX).

    Было бы очень удобно, если бы китайцы добавили аналог +CIPRXGET, но не по незапрашиваемому ответу, а по запросу.

    Мне как раз мультисокет и не нужен, мне достаточно одного соединения. Значит ли это, что мне лучше воспользоваться прозрачным режимом?

    И второе. Намекните, если можно, про устройство Вашего оптимизированного парсера. Как он работает?

     

  9. Опубликовано · Изменено пользователем Иван Плетнев · Пожаловаться

    На сколько я знаю, еще не значит, что команда дошла до сервера.

    После отправки сообщения серверу жду от него подтверждения приема.

    Если после трех попыток передачи его нет, делаю реконнект.

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

    В прозрачном режиме надо мониторить пин ри, думаю это неудобно.

     

    Если мы говорим про TCP (не UDP) то SEND OK как раз значит, что команда дошла до сервера, потому что это на самом деле - подтверждение ACK (Acknowledge), формируемое на сервере средствами TCP протокола. Бывает, что команда до сервера дошла, а SEND OK нет. Но наоборот быть не может. Если UDP, то действительно, SEND OK просто говорит о факте отправки, потому что в UDP подтверждение не предусмотрено.

  10. Опубликовано · Пожаловаться

    Господа!

    При разработке устройства с SIM900, которое должно уметь отправлять данные на сервер и получать команды с сервера, опробовал два режима работы:

    1. Посылка данных в АТ режиме, командой CIPSEND - приглашение> - данные. В этом режиме при отправке команды с сервера легко нарваться на ситуацию, когда МК ждет ответ от SIM900, а приходит команда с сервера. Но это, в принципе, проблема решаемая.

    2. Начал пробовать работу в Transparent mode.

     

    Возник вопрос: Какой режим надежней? Поясню. Если, например в командном режиме ты послал данные, а в ответ не пришел ответ SEND OK, выдерживаешь таймаут и делаешь реконнект. А как в прозрачном режиме получить подтверждение? Только средствами сервера?

     

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

  11. Опубликовано · Пожаловаться

    И почему конец сообщения определяется таймаутом?

    Почему не использовать последовательность CR LF?

    Потому что встречаются ответы модема, в которых есть и две последовательности CR LF, и три.

  13. Опубликовано · Пожаловаться

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

     

    Не принимает ваш ящик личку. См. здесь - http://tdocs.su/4199

     

    Спасибо, почитаю.

     

    Проблема-то как раз в том, что жду одно, а приходит другое ))

  14. Опубликовано · Пожаловаться

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

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

  15. Опубликовано · Пожаловаться

    Так понимаю, что процессор ожидает ответ от сима на какую-либо АТ команду?

     

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

    Выполнить ее, и дальше ждать ответа на АТ?

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

  16. Опубликовано · Пожаловаться

    Здравствуйте!

     

    Разрабатываю устройство, которое собирает различные данные с датчиков и с периодичностью в одну минуту отправляет их на сервер посредством SIM900. Использую обычный режим AT-команд, не transparent, то есть команда AT+CIPSEND, приходит приглашение ">", отсылаю в порт строку, дожидаюсь SEND OK, всё. В данный момент добился надежной отсылки данных. Встал вопрос приёма команд от сервера. Все в общем, работает, за исключением случая, когда микроконтроллер ждет ответа от SIM900 и в этот момент приходит команда от сервера. Аппаратное управление потоком в этом случае вряд ли подойдет..

    Подскажите, пожалуйста, кто как справился с этой проблемой?

  17. Опубликовано · Пожаловаться

    Когда происходит TCP-подключение к серверу устанавливается соединение под которое выделяется сокет.

    Для каждого соединения свой собственный сокет.

    Отправляя данные в нужный сокет, можно передать данные конкретному клиенту.

    Узнать какое именно устройство установило соединение с сервером можно при установке связи путем передачи

    информации об идентификаторе устройства серверу.

    Я использую стандартный HTTP-протокол, идентификатор устройства передаю как часть URL (в параметрах).

    Например, "http://мой_сайт.ru/cgi-bin/device.php?id=идентификатор_устройства".

    Спасибо, действительно, на сервере будет создаваться таблица соответствия сокета определенному ID устройства. По мере реконнектов таблица будет обновляться.

  18. Опубликовано · Пожаловаться

    Здравствуйте! Разрабатываю сейчас систему, в которой множество устройств, оборудованных GSM модулями SIM900 будут общаться с TCP сервером. Добился сейчас того, что один модуль надежно отправляет данные на сервер и получает с сервера команды. Возникла необходимость в разработке протокола обмена, обеспечивающего функционирование нескольких устройств. В связи с этим, возник вопрос. Как в таких системах обычно реализуется идентификация клиентов? То есть, например, нужно передать с сервера на определенное устройство, зарегистрированное на сервере, команду. Как легче всего поступить в этом случае? По MAC адресу? Либо какие-то еще механизмы имеются?

×
×
  • Создать...