LusoRobótica - Robótica em Português
Sistemas específicos => Arduino / AVR => Tópico iniciado por: dio123 em 22 de Julho de 2013, 09:34
-
Bom dia,
Acontece que tenho um projecto +/- preparado codigo dos comandos gravados, pcb feitas, e soldadas, e deixei o codigo para a ultima da hora, concluindo lixei-me. E só tenho até sexta feira para resolver o problema.
Acontece que a Biblioteca VirtualWire e IRRemote, entram em conflito porque ambos usam o timer.
Como não consegui resolver este problema fui passar umas horas ao google e descobri uma possivel solução, mas no entanto não como o problema foi resolvido, porque o meu inglês é medíocre e o tradutor não é melhor não percebo o que quer dizer com 4 usec steps. http://forum.arduino.cc/index.php?topic=66430.0 (http://forum.arduino.cc/index.php?topic=66430.0)
Se puderem ajudar agradeço
-
Altera as bibliotecas para funcionarem em conjunto.
Passos de 4us, convinha ao menos fazeres um quote, não vou ler isso só para chegar ou não ao texto que tens duvidas...
Os comandos IR mandam pulsos via IR, possivelmente esse código que falam no tópico só consegue enviar pulsos multiplos de 4us, 4,8,12,16,18, etc..
-
Podes espreitar este projecto meu e ver se te ajuda...
http://sequencedecoder.weebly.com/ (http://sequencedecoder.weebly.com/)
Estas a tentar controlar o quê mesmo?
-
Boa tarde,
Tenho uma box tdt satélite, e na casa de férias passa imagem para 2 televisões. E eu quero mudar de canal sem estar a ir ao piso 1.
Do piso 0 envio o código de um outro comando e no piso 1 recebo o código e faz a equivalência ao comando da box.
O problema está nos timers das bibliotecas, mas nao tenho capacidade de alterar o codigo, porque não percebo grande parte do microcontrolador, e nao tenho estudo para isso
tarquinio Vou exprimentar o site que me deu.
O comentário que não percebo é este.
how do i give delay of 8.8 uS..
the delayMicroseconds() takes only integer values..
And only has resolution of 4 usec steps.
Quote
Returns the number of microseconds since the Arduino board began running the current program. This number will overflow (go back to zero), after approximately 70 minutes. On 16 MHz Arduino boards (e.g. Duemilanove and Nano), this function has a resolution of four microseconds (i.e. the value returned is always a multiple of four).
[/color]
is there any kind of delay around nanoseconds?
None avalible or really possible as basic single instruction timing is around 64 nsec.
-
É basicamente o que disse...
Com delays só fazes delays multiplos de 4us, logo se precisas de um delay que não de 4 us, é simples, meter nops á mão, não é que seja algo ideal, mas funciona garantidamente.
Já agora, para que é que precisas dessa virtualWire e o que é que isso faz?
-
A library que eu fiz tambem não usa os registos directamente (o que significa que poderia ser mais precisa) mas nunca tive problemas por causa disso. Os receptores de infravermelhos parecem ter um range de frequencias maior do que eu estava à espera quando comecei a desenvolver essa library.
Aqui em casa tenho um sistema parecido, com o sinal de uma ZONbox a ir para várias televisões e com vários sensores espalhados pela casa para poder controlar a box de qualquer lado, funciona tudo ok :)
-
Neste caso a biblioteca virualwire e usada para receber o código do comando que vem do piso 0 para o piso 1 por rf 433mhz.
-
Não precisas de essa biblioteca para NADA, se esses módulos falam serial, usa serial nativo, metes um checksum no fim dos dados e está feito.
-
Boa tarde,
Estou aqui na volta disto e não consegui nada de jeito.
Estou enviar uma letra A em cada segundo, mas no receptor recebo montes de coisas, mas não tem nenhum padrão fixo. A mim dá-me a impressão que os numeros e letras são alatórios.
E mesmo sem o receptor ligado ao pino rx o led acende
Mas é +/- isto que o senso sugeriu que eu usa-se?
int led = 13;
#include <LiquidCrystal.h>
int incomingByte = 0;
LiquidCrystal lcd(12, 11, 5, 4, 3, 2);
void setup() {
pinMode(led, OUTPUT);
Serial.begin(1200);
lcd.begin(16, 2);
}
void loop() {
if (Serial.available() > 0) {
incomingByte = Serial.read();
lcd.print(incomingByte, HEX);
if (incomingByte == 'A')
{
digitalWrite(led, HIGH);
dela
}
}
incomingByte = 0;
}
Envia letra
void setup() {
Serial.begin(1200);
}
void loop(){
Serial.print('A', HEX); // send data out tx
delay(1000);
}
-
Ainda não percebi bem exactamente que hardware é que estas a usar para enviar o sinal... É algo deste tipo?
http://www.electan.com/433mhz-link-kit-p-3039-en.html (http://www.electan.com/433mhz-link-kit-p-3039-en.html)
-
Ah e agora que olhei bem para o código... Estás a enviar 'A' em hex, o que significa qhe ele vai enviar "41".
Depois ao ler estas a ler o 4 e o 1 em separado...
Tens de enviar e receber as coisas sempre da mesma forma.
Porque não fazes simplesmente
Serial.print('A');
-
tarquinio - sim, os kits rf são iguais a esses de 433Mhz.
O problema é que sem o transmissor ligado estou sempre a receber dados de algures, ou é intereferencia ou não sei.
-
Eh perfeitamente normal acontecer isso c esses modilos pois nao teem qq forma de tratamento de dados, trabalham em tipo CW AM ou CW FSQ.
A maneira de resover isso eh criar um protocolo de comunicacao. Algo simples tal como enviat e Cabecalho-Dados-CRC.
Assim so passa o q tiver sido enviado pelo transmissor e nao pelo ruido ambiente.
-
Pois eu tb tenho projectos com módulos desses e tive o mesmo problema... É como o asena disse, os receptores apanham ruido de todo o lado. Tens de implementar o teu protocolo de tratamento de comunicação e filtrar as mensagens no receptor... Eu faria algo do tipo um header com 2 bytes fixos + 1 byte para indicar o tamanho da mensagem + n bytes da mensagem + um crc de 2 bytes. Não é algo muito complicado e já deve filtrar o ruido todo.
A minha experiencia com esse tipo de módulos é que apanham realmente muita interferencia mas quando o transmissor está a enviar coisas até se portam bem, pelo menos para velocidades de transmissão baixas.
-
Boa tarde,
Encontrei um projecto onde tem aquilo que preciso. Usar rf nos pinos tx e rx
http://nootropicdesign.com/projectlab/2010/12/26/rf-wireless-temperature-sensor/ (http://nootropicdesign.com/projectlab/2010/12/26/rf-wireless-temperature-sensor/)
Fui exprimentar, mas a transmissão está muito lenta, ou está a falhar muitas recepções.
Estou a usar velocidade 1200. Neste caso adaptei e ficou assim.
Atmega recebe o comando envia o outro atmega recebe e liga e desliga o led. No entanto é preciso clicar no camando muitas das vezes não apaga nem acende o led a primeira.
-
peguei num codigo e adaptei para arduino, e depois de perceber, e estudar o problema continua.
Um simples blink em Rf mas o led não pisca normalmente.
Imagem do código http://cl.ly/image/0Q2a0j1m0d0n/o (http://cl.ly/image/0Q2a0j1m0d0n/o)
Será que tem haver como a forma da onda é criada?
-
Tu tens as antenas montadas?
Já pensaste em simplesmente passar um fio de um andar para o outro?
-
Boas,
Será que isso não tem a ver com o facto de estares constantemente a ler o buffer da porta Serial mesmo quando não há nada para ler?
No código que tens no recetor não há nenhuma condição para que leias o buffer apenas quando estiver lá algo, então ele é lido constantemente e pode acontecer que não seja lido na ordem correcta... Não sei se me fiz entender bem.
Ou seja, os bytes podem estar disponíveis para ler apenas no momento em que estás a atribuir o valor à variável data e se isso acontecer a variável data vai ter o valor que a variável raddress deveria ter e assim sucessivamente.
Edit: Não falta outro delay no código do transmissor? Da forma como está o led vai estar sempre aceso.
-
Pois, falta ai um Serial.available(), mas não precisa de nenhum delay no lado do receptor.
-
O delay que falei era no void loop do lado do trasmissor.
-
Sim do lado do transmissor precisas de ter mais um delay depois de enviares o ledoff, senão o loop inicia logo outra vez e manda logo o ledon de seguida.
Do lado do receptor há mais alguns problemas:
-Como já foi referido, só podes ler coisas quando houver algo para ler (serial.available)
-estas a enviar 4 bytes no emissor mas a ler só 3 no receptor (o SYNC é enviado mas não é lido em lado nenhum)
-não estas a garantir de forma menhuma que os bytes estejam a ser lidos no sitio certo. a idéia é estares sempre a ver se chega o byte que marca o inicio da mensagem (SYNC), e só quando esse for lido é que vais ler os 3 bytes que vem a seguir a esse...
-
http://img607.imageshack.us/img607/6208/9b5r.png
(http://img607.imageshack.us/img607/6208/9b5r.png)
A variavel SYNC é um startbit, se o SerialAvailable detectar SYNC , le os 3 bits seguinte depois faz a verificação e liga ou desliga o led.
É assim a teorica certo? mas não funciona. coloquei as 2 beardboard uma em cada computador e não dá nada nem pisca nem nada.
Exprimentei tambem com if (Serial.available() > 1 ) mas não dá nada.
Mas ainda tenho erros no codigo?
agradeço desde já
-
Boas,
Continua com erros...
Muda para Serial.available()>0.
Parece-me que o byte SYNC não está a ser usado para nada. Tens 2 opções: continuas a enviar esse byte, mas tens que adicionar uma linha no lado do recetor: syc = Serial.read() ou simplesmente Serial.read(); apagas a linha que envia o byte no lado do transmissor visto que não está a ser usado para nada...
Depois deve funcionar.
Hmm, não sei até que ponto podes declarar o pino 1 como output visto que ele vai ser usado pela porta Serial... Essa linha não está lá a fazer nada e não sei até que ponto pode lá estar.
Cumps
-
Credo de onde é que veio aquele Serial.available()>170??? :P
Como o rglove já referiu, o byte SYNC continua a não estar a ser usado para nada (nem sequer a ser lido da parte do receptor)...
Não concordo é com esta parte:
Tens 2 opções: continuas a enviar esse byte, mas tens que adicionar uma linha no lado do recetor: syc = Serial.read() ou simplesmente Serial.read(); apagas a linha que envia o byte no lado do transmissor visto que não está a ser usado para nada...
Enviares o byte e depois ler o valor e não fazer nada com ele não serve de nada... Não enviares o byte tambem não é boa idéia, os headers servem para alguma coisa... Neste caso, a idéia daquele byte é sinalizar o inicio da mensagem, e usá-lo como ponto de referencia para ler o resto da mensagem. O problema aqui é que tu envias 4 bytes... Mas basta haver um bocado de ruido para facilmente haver bytes perdidos pelo caminho, ou então aparecerem bytes do nada...
Daí o formato (header|mensagem|crc). O header indica onde é que cada envio começa, de seguida vem os bytes com a informação que se quer enviar, e por fim o crc para confirmar que não houve erros a meio da transmissão.
Tens aqui uma versão simples da coisa:
while (Serial.available() > 0)
{
int value=Serial.read();
// Se recebe um sync, comeca a ler a mensagem
if (value==SYNC) read_pos=0;
else
{
// Le cada byte para a variável certa
if (read_pos==0) raddress = value;
else if (read_pos==1) data = value;
else if (read_pos==2) chk = value;
read_pos++;
// Se já leu 3 posições, a mensagem já acabou
if (read_pos==3)
{
// Confirma se o CRC bate certo
if (chk==(raddress+data))
{
// Dentro deste IF podes fazer o código que quiseres,
// que sera executado quando chega uma mensagem
}
}
}
}
Este código assume que o SYNC é um byte unico na mensagem (mesmo o crc tem de ser diferente do valor de SYNC). Se fosse para mandar mensagens mais complexas a coisa teria de ser um bocado diferente, mas para a aplicação em causa serve bem...
-
desde já agradeço.
O tempo acabou, e não consegui. Ficará para quando vier.
No entanto tenho uma duvida? Se puxar um fio, a distancia ainda vai ser vai ser considerável 13metros, os impulsos para led IR e a voltagem não se vai perder pelo meio?
-
Penso que devem haver cabos próprios para essas distâncias :)
-
13m não é nada...
-
Acho que comprei uns fios fininhos (tipo daqueles que se usa no arduino) e a resistencia em 100m era inferior a 10ohm. Não me lembro exatamente mas penso que era 1-4Ohm