Enviar 10bits usando RF433

Olá,

Em breve devo anunciar a construção de um veiculo robô autónomo.

Para implementar esse projeto pensei primeiro construir um comando a distância para controlo do veiculo.

A primeira abordagem foi o comando por Infravermelhos (IR ), no entanto percebi que iria ter uma grande dificuldade em controlar o veiculo, devido ao facto do feixe de infravermelhos ser necessário estar directamente direcionado para o recetor, isto obrigava também a deslocar-me juntamente com o veiculo, para direcionar-me para o recetor 🙁

Foi neste sentido que pensei numa alternativa, usar comando por radio frequência, encontrei o emissor FS1000A + recetor MX-RV-5V, conforme figura, as ligações dos dispositivos conforme imagem anexa, é perfeitamente pacifica:

Esquema de ligações do RF433 e do Joystick

Esquema de ligações ao Atmega8 (emissor) e Atmega128 (receptor)

A pretensão é comandar o veiculo com um joystick, aqui tive de escolher outro dispositivo. Encontrei uma vez mais para Arduino, como sempre nada é perfeito 🙂

Só depois do rececionar e o colocar em funcionamento percebi que o estado de repouso do Joystick, envia ambos metade dos 10bits do AD, mais uma limitação, mas que é perfeitamente ultrapassável.

O funcionamento do emissor RF433 envia os dados pela porta UART/USART do microcontrolador na primeira abordagem achei que seria uma vantagem, pois bastava construir uma trama de dados e enviar pela USART, mas na implementação comecei a perceber algumas das limitações, ex: baud rate, tempo de codificação/descodificação, dessincroniza a respetiva trama, distancia dos dispositivos, etc…

Como o RF433 envia pela USART teria de construir uma Trama de dados onde nessa trama  fosse possível enviar [bit de início da trama], [valor do estado do Switch], [1ºvalor 10bits do AD], [verificação de erros de 16bits], [2ºvalor 10bits do AD], [fim da trama].

Antes da receção destes dispositivos fiz a simulação em proteus com módulos iguais (Projeto Proteus), tudo pareceu funcionar bem, o certo é que quando implementei o circuito na pratica os dispositivos não se comportam tão bem. Isto deve-se ao facto do tempo de processamento ser mais rápido do que no simulador e dai alguns erros que não encontrava no simulador, foram aparecendo.

Neste video podemos verificar a trama de dados enviada pelo emissor FS1000A igual a Trama de dados recebida pelo MX-RM-5V, quando se clica no botão que esta ligado ao PD3 do Atmega8, envia a trama de dados e faz a comutação do led do receptor.

Também poderemos verificar que é enviado o valor que o ADC ( conversor analógico/ digital ) do Atmega8 esta a ler, quer o valor de um potenciómetro quer o valor de outro potenciómetro, ambos ligados AD0 e AD1 de 10bits do atmega8.

 

 

Se não consegue visualizar em fullscreen seleccione aqui Youtube

Vamos agora ao código, que podem fazer download : no link https://github.com/norlinux1/RF-433-FS1000A—MX-RM-5V-

como poderemos observar existe código do emissor, o MCU usado Atmega8,

/*
 * MyLib_RF433_TX.c
 * Created: 07-04-2017
 * Author: Norlinux
 *http://maquina.96.lt
 *http://www.microelectronic.pt
 *https://www.facebook.com/MundoDosMicrocontroladores/
 *Released under GPLv3.
 *Please refer to LICENSE file for licensing information.
 *which can be found at http://www.gnu.org/licenses/gpl.txt
 */

/*MCU ATmega8 - 8 Mhz*/

#include <avr/io.h>
#include <util/delay.h>
#include <avr/sfr_defs.h>
#include <stdint.h>
#include "public_global.h"
#include "hardware.h"
#include "tarefas.h"
#define ESPERA() _delay_ms(180)
int main(void)
{
	HW_Init();
	USART_Init(USART_BAUD_RATE);
	ADC_Init();

	while(1)
    {	
	CheckBotao();
    }
}

 

como poderemos observar existe código do receptor, o MCU usado Atmega128

/*
 * MyLib_RF433_RX.c
 * Created: 08-04-2017
 *Author: Norlinux
 *http://maquina.96.lt
 *http://www.microelectronic.pt
 *https://www.facebook.com/MundoDosMicrocontroladores/
 *Released under GPLv3.
 *Please refer to LICENSE file for licensing information.
 *which can be found at http://www.gnu.org/licenses/gpl.txt
 */

/*MCU ATmega128 - 8 Mhz*/

#include <avr/io.h>
#include <avr/interrupt.h>
#include "hardware.h"
#include "Tarefas.h"
#include "lcd/lcd_lib.h"

int main(void)
{
    HW_Init();
    USART_Init(USART_BAUD_RATE);
	LCDinit();
	while(1)
    {

    }
}

Uma breve explicação do código.

O projeto é composto por uma fundamental biblioteca “ tarefas.c”, nesta biblioteca está construída a base do funcionamento da comunicação pela USART. A função ucTramaEncoder é constituída pela construção de toda a trama que pretendemos enviar, do seguinte modo:

Foi criada uma estrutura de dados, responsável por coletar e transladar a informação entre as diversas funções:

typedef struct{

unsigned char   ucSwitch;      // (inteiro switch 0-1)

unsigned char*  pucVRx;        // ponteiro ADCx buffer

unsigned char   ucVRxTam;      // Tamanho ponteiro ADCx

unsigned int    uiCrc16;       // CRC16  (16-bit)

unsigned char*  pucVRy;        // ponteiro ADC y buffer

unsigned char   ucVRyTam;      // Tamanho ponteiro ADCx

}STRUCT_TRAMA;

Para envio desta informação precisamos de delimitadores de informação, identificadores de inicio e fim, esta ideia foi elaborada num outro trabalho do Autor: Tomasz Jokie.

#define INICIO_SEQ                      “*:”            // String inicio sequencia “*:”

#define FIM_SEQ                          “:#”            // String fim sequencia “:#”

#define CONCATENAR_SEQ         “#”             // delimitador da sequencia “#”

Ficando a trama do seguinte modo->*:s#VRx#LM#VRy:# sendo ‘s’ valor do switch ‘0’ ou ‘1’, VRx assume o valor de 4 digitos ex: ‘0512’ o mesmo sucedo o VRy ‘1023’, os 10 bits que pretendemos enviar estão no formato unsigned char*  que posteriormente pode ser convertido para um inteiro com comando atoi(). No meio da Trama temos LM, sendo L o bit menos significativo LSB da verificação de erros CRC16, imediatamente a seguir temos o bit mais significativo MSB da CRC16, estes bites são codificados e descodificados no recetor para verificar e validar credibilidade dos dados enviados e recebidos.

A função ucTramaEncoder coleta toda esta informação numa trama, no recetor será descodificada pela função stDescoderTrama. Considerei este projeto bastante útil, abrindo assim as portas para outros trabalhos, em que é necessário enviar informação de valores analógicos e digitais através da USART.

Agora vamos abrir o livro, se chegaram ate esta parte do texto vão ficar um pouco desiludidos (tal como fiquei), isto porquê? Porque a transmissão usada foi de 1200bps o que é baixa, mesmo assim como na rotina de interrupção ISR(USART0_RX_vect) existe uma imensidão de tarefas que tem de executar enquanto o buffer esta a rececionar os dados, isto faz com que alguma informação fica “desprendida” da estrutura inicial, ou então faz com o micro trave, talvez por não conseguir o sincronismo em tempo real. Pelo menos foi o que constatei, não usei ferramentas de diagnostico nesta fase, terei de polir melhor o código tornando-o mais light e mais rápido. A ideia de ter um joystick a comandar um veiculo robot, foi pela agua a baixo, infelizmente o dispositivo não esta preparado para algo tão elaborado, a USART também não ajuda muito, o que fiz foi sincronizar a informação com o switch cada vez que faço um clique envia uma trama, assim como é mais pausado já funciona relativamente bem, o que na pratica não serve de muito pois não vamos estar sempre a clicar no switch quando pretendemos direcionar um veiculo. Resumindo o FS1000A tem a natural limitação que vou ter de diagnosticar, fica para um próximo tema as respectivas conclusões.

Para saberem das novidades façam SEGUIR na pagina do Facebook: https://www.facebook.com/MundoDosMicrocontroladores/

Trabalho final:

ver video em fullscreen: Youtube

Deixe uma resposta

Your email address will not be published.

www.000webhost.com