Projeto DASHBOARD Telemetria para RC usando FRSKY

aphawk · 22 de abril de 2015

Tenho um radiocontrole Turnigy 9X no qual instalei um sistema de telemetria da FRSKY, o modelo mais comum, que é o antigo, que não usa a maldita S-PORT, e que envolve um módulo transmissor e um receptor. Uso em um aeromodelo tipo glider, o Bixler3.

Esse sistema mais antigo tem um preço muito atrativo, e os componentes como Hub e sensores ainda são disponíveis, e mesmo assim existem vários projetos open-source de sensores criados por vários usuários e bem documentados na internet.

Existem módulos da FRSKY para serem usados também nos rádios da JR e da FUTABA. Todos eles possuem a mesma conexão para um display LCD serial, a qual disponibiliza todo os dados do protocolo.

Eu tinha em casa todos os sensores e hub, e resolví colocar tudo no avião. Só não tinha o GPS , mas consegui comprar um modelo atual baratinho e funcionou direitinho.

Esse sistema permite o envio automático de informações dos sensores , e como eu tinha também o visualizador LCD da FRSKY para visualização e alarmes, liguei tudo no rádio, e fiz algumas experiências.

No geral, funciona muito bem, já passei de 600 metros sem nenhum problema, com bom nivel de sinal, e a telemetria funciona direitinho. É muito legal ver na tela qual o nivel de sinal que o transmissor e o receptor estão recebendo, assim se ficar muito baixo trago o avião para mais perto.

Mas , existem várias limitacões no sistema do LCD da FRSKY :

1 - O display é pequeno, e temos de trocar manualmente as telas para podermos ler todas as informações, as quais estão espalhadas por 4 telas...

2 - Existem alguns tipos de alarmes que podem ser configurados, que são estes aqui : Sinal no transmissor, sinal no receptor, e tensão nos dois sensores de tensão analógica, que podem ser ligados para medir a bateria do aeromodelo.

Porém, eu acho que tem muitas informações que são transmitidas pela Telemetria, e o display não permite nenhum tipo de controle, apenas a visualização.

Imaginem o trampo de você querer apenas planar com um Glider, procurando as correntes de ar quente, e ter de ficar toda hora olhando na telemetria se a tensão da bateria está ok , ver no display qual foi o consumo da bateria em mAh, e ter de ficar mudando telas toda hora para isso.

Resumindo, seria muito bom se fosse possível ter outros tipos de alarme, por exemplo :

- Consumo em mAh da bateria : se eu tenho uma bateria que fornece 2100 mAh eu posso configurar um alarme para me avisar quando consumí, por exemplo, 1800 mAh. Assim, posso descer o avião sem nenhum risco.

- Nivel de tensão DE CADA CÉLULA da bateria ! Baterias que não estão muito boas acusam queda de tensão excessiva em alguma célula.

- Aviso tonal para ganho ou perda de altura excessivo em uma certa unidade de tempo. Quando o Glider está longe, fica difícil saber se estamos conseguindo ganhar altura.

- Aviso de distância excessiva - como temos um GPS no avião, posso calcular a distância entre o avião e o rádio.

- Log do ultimo minuto do GPS : caso o aeromodelo caia, saberei com precisão o local.

Fora outras coisas que podem ser implementadas, que ainda não pensei kkkkk !

Pretendo fazer uma DASHBOARD, a qual poderá ser ligada diretamente nos módulos transmissores da FRSKY, e assim teremos todas as informações na tela, sem ter de ficar mudando telas, e com vários tipos de avisos, afinal, quanto menos temos de olhar o rádiocontrole, melhor !

A ideia é utilizar um simples Atmega328, e um display LCD maior, com um sistema simples para configurar tipo um rotary encoder.

A programação será em BASCOM, e o hardware pode ser tipo Frankstein usando um Arduino ( qualquer tipo, pode ser Uno, Leonardo, Nano, qqr um desde que seja um Atmega328.. ) , um módulo de display LCD, e uma caixa a cargo de cada um.... Ou fazer uma pcb onde bastaria apenas ligar o módulo.

Apenas a título de informação, já consegui decodificar o protocolo e receber todas as informações da telemetria, o que é a parte mais difícil, pois até hoje ninguém colocou um projeto aberto para que outros possam seguir. E a FRSKY deixou alguns eros na documentação que me deixaram doido....

A alimentação pode ser feita por uma bateria de lítio ou por 4 pilhas alcalinas, fica a cargo de cada um.

Enfim, gostaria que aqueles que se interessaram possam contribuir com idéias, sugestões, críticas, etc.

Paulo

MatheusLPS · 22 de abril de 2015

Paulo,

ideia interessante. Uso o controle abaixo. Deve ser igual o seu. Imagem ruim pois tirei print de um vídeo que está no meu celular e não do controle que não está comigo agora.

Esse meu já mostra tensão da bateria, número de satélites localizados, consumo da bateria, altitude do veículo. ... e etc.

E realmente ficar olhando para o controle não é muito legal.

Comprei também um tablet para ligar a telemetria nele..... mas ainda não testei....

Talvez usando o tablet pode-se economizar bastante tempo pois já tem os receptores prontos a 50 dólares cada.

Modulos:

https://store.3drobotics.com/products/3dr-radio?taxon_id=34Flw

Software:

http://ardupilot.com

MOR_AL · 22 de abril de 2015

Bom.

Primeiramente acredito que suas siglas sejam referentes ao rádio controle.

Depois.

Um tutorial seria muito interessante... E trabalhoso. Hehehe!

Depois.

Eu incluiria um paraquedas tanto por acionamento manual, como automático.

MOR_AL

aphawk · 23 de abril de 2015

@MatheusLPS,

Sim, é exatamente o mesmo radio, apenas em outra caixa plástica !!!!

Eu atualizei totalmente o meu, coloquei um backlite atrás do display, coloquei um conector Padrão ICSP de 10 pinos para poder atualizar o software, e instalei o famosíssimo OpenTX, tanto na versão que já mostra a telemetria no display, como a versão sem esse recurso. Realmente não fica nada a dever aos rádios bem mais caros.

A única coisa que eu mudei foi o módulo TX, usei um FRSKY DJT e o receptor foi o D8R-II plus. Ficou muito mais confiável, e de quebra veio a telemetria.

Se você tiver um Android, existe um programa que recebe a telemetria via Bluetooth, e basta você colocar dentro do rádio um desses módulos bluetooth baratinhos, tem dezenas de tutoriais sobre isso na Net. vai gastar menos de US$ 10 !

Mas o programa no Android tem os mesmos tipos de problemas, são poucos os alarmes, e não posso fazer a programação de aviso sobre descidas ou subidas, nem de distância do avião até o rádio.

Porisso que resolví fazer do meu jeito mesmo....

Legal esse seu Quad ! Pelo que vejo, veio com um gimball e você vai colocar a Go Pro !

É o que eu fiz no Bixler, sem o gimball, agora estou esperando chegarem os módulos da Immersion para fazer a transmissão da imagem em tempo real.

Mas tem uma grande diferença na necessidade do sistema de display. Eu consigo ficar mais de uma hora planando com o Bixler, sem usar o motor, desde que ache uma boa térmica. Saber se achei, se estou mantendo a altura ou subindo, é muito importante para ajudar a ficar mais tempo com o motor desligado, e assim consigo ficar no ar bastante tempo.

Já no seu Quad, onde o crítico é o consumo da bateria, você já recebe essa informação , seria muito bom se tivesse um alarme também, mas sempre será um voo de curta duração.

Eu tenho um Hex também, com uma bateria de 3600 mAh, usei ele um ano atrás , faz tempo que tá parado.

Tinha uma placa controladora , a famosa kk board 2.0, que controlava bem ele, agora essa placa está no meu glider Bixler3, fazendo a estabilização automática em caso de ventos fortes e também assume o controle mantendo o aviao voando estabilizado em caso de perda de sinal, usando o OpenAero2.

Nunca se sabe kkkkkk !

@MOR,

Olha, estudei muito a documentação esparsa que existe na Internet, pois todo mundo sabia como decodificar a informação do módulo receptor usado sózinho, com apenas os dois sensores de tensão e o medidor de sinal de Rf.

Mas quando se usa o hub, que permite mais um monte de sensores, não tinha quase nenhuma informação, e quem conseguiu fazer isso lançou como um programa para ser usado em Android, mas não deu as dicas.....

Depois de três semanas de sofrimentos, tentativas e erros, ontem de noite finalmente consegui mostrar na tela todos os dados já decodificados, de todos os sensores !

Claro que posso fazer um tutorial sobre a decodificação e postar o programa que faz isso em Bascom, mas prefiro fazer um projeto mais completo, com o sistema de vário já funcionando ( tons indicadores de subida / descida ) .

A parte que era muito difícil eu já fiz... Estou vendo agora qual display que vou usar, eu tentei um com comunicação serial de alta velocidade, mas demora quase 0,4 segundos para fazer toda a atualização da tela e com isto perco alguns frames da telemetria.

Vou usar agora um com interface de 8 bits, preciso conseguir que toda a atualização seja feita em 0,2 segundos, e o grosso desse tempo é perdido nas escritas do display.

Se não conseguir nem com os 8 bits, vou precisar reescrever as rotinas para que sejam totalmente interrupt-driven e tratem todo o protocolo byte a byte, e a parte de display seria feita numa rotina que seria interrompida a todo instante pela recepção serial a 9600 bps.

Paulo

MatheusLPS · 23 de abril de 2015

@aphawk

Pois é. Comprei 3 baterias extras. Ao todo tenho uns 40 minutos de vôo.

Já tenho também o monitor e modulo de 5.8ghz para ver a imagem em tempo real.

Mas é muito ruim ficar olhando para tela. Fico com medo de bater o quad.

Sobre o tópico. ...

Porque não usa um display com comunicação i2c onde o mesmo já possui um controlador interno de escrita no display?

Acredito que fica mais rápido dessa forma.

Tipo esse:

http://www.buydisplay.com/default/4-3-tft-lcd-display-module-controller-board-w-serial-spi-i2c-mcu

Falou

aphawk · 23 de abril de 2015

@MatheusLPS,

Eu já tentei um Oled com I2c, e o ILI9431 com SPI, como ambos são displays coloridos, são muitos bytes a serem trocados, e acaba demorando muito. Como são displays gráficos, fazer os textos em tamanhos diferentes envolve muitos bytes.

ERRATA : Achei o problema, é que eu deixei a monitoração dos dados com saída serial ativada, ou seja, os dados também estavam sendo enviados para a serial de meu computador para visualização; como não usava interrupção na saída serial, ela estava sendo tratada por software e acabava dando problemas na recepcão também. Resolvi o problema da corrupção dos dados da telemetria de duas maneiras simpes : Não usando a saida serial, ou se continuar usando criar um buffer de saída, usando interrupção também, muito semelhante ao buffer de entrada. Isso existe no Bascom....

Eu tenho um buffer serial de capacidade até 255 bytes para ajudar na recepção , ~~mas a 9600 bps está dando overflow na rotina de visualização dos dados, ela está demorando muito.~~

A taxa real de dados é de cerca de 1000 bits por segundo na média, mas existem coisas absurdas nesse sistema, como por exemplo enviarem um monte de dados durante 0,3 segundos, e ficar "mendingando bytes" os 0,7 restantes.

Esse buffer é do próprio Bascom, eu estou pensando em fazer um maior, em ASM, pena que já me esqueçí de como fazer um buffer circular.... Se tivesse 500 bytes de buffer, tudo estaria resolvido, com qualquer display. Quem sabe eu tenha de fazer isso...

Ou podia também simplificar e usar um display tipo caracter, 4 linhas por 20 colunas, ajudaria muito nos tempos da rotina de visualização, mas perderia beleza e quantidade de informações.

Paulo

aphawk · 27 de abril de 2015

Bom, vamos começar a explicar direitinho o que é essa telemetria.

Hoje em dia, podemos comprar sistemas de rádio controle para aeromodelos e drones ( vou abreviar para RC ) bem baratos, como o famoso Turnigy ER-9X, ou os seus próximos parentes, todos eles custando lá fora menos de US$ 60.

Com isto, temos um bom sistema de até 9 canais, o que significa que o receptor padrão possui 9 saídas tipo PPM, onde normalmente ligamos servos para movimentar alguma parte mecânica, ou um controle de velocidade para motor elétrico.

Porém como tudo que é muito barato, existem algumas limitações no sistema de transmissão / recepção, o qual apresentou várias falhas catastróficas, descritas por centenas de usuários.

Para corrigir isto, a empresa FRSKY lançou um módulo de transmissão compativel com essa família de rádio, chamado de DJT, e que além de enviar os comandos normais ao receptor, permite RECEBER dados do receptor !

Para quem tem um rádio FUTABA, também existe um módulo semelhante !

E o receptor padrão é o famoso D8R-II+ , que é um receptor de 8 canais com plena capacidade de transmitir dados colhidos por vários sensores em nosso modelo radiocontrolado.

Esse receptor possui tres conexões externas, sendo que uma é uma porta de comunicação digital que pode ser utilizada para ligar a um sensor ou a um Hub, no qual podemos ligar uma série de sensores.

E possuí também duas conexões para entrada de tensão, as quais permitem tensões entre 0 e 3,3 Volts. São chamadas de A1 e A2.

Esse receptor, quando usado sózinho, sem nenhum outro sensor ou Hub, envia uma telemetria com as seguintes informações :

- Nivel do sinal de RF que o receptor está recebendo do módulo transmissor existente no rádio.

- Nivel do sinal de RF que o transmissor está recebendo do módulo de recepção existente no nosso aeromodelo.

- Tensão na entrada 1

- Tensão na entrada 2

Normalmente, quando o receptor é utilizado sem o Hub ou nenhum outro sensor, utiliza-se um divisor resistivo ligado à bateria do aeromodelo, assim podemos receber qual o valor da tensão da bateria !

Portanto, nesta situação, já temos as principais informações que nos ajudam a manter o controle com o nosso aeromodelo, basta ficarmos monitorando se os níveis de sinais de RF não ficam perigosamente baixos, e nem a tensão da bateria chegar a níveis muito baixos.

Pode parecer pouco, mas isto é suficiente para não perdermos o nosso aeromodelo, cuja queda ou perda significa sempre valores altos, entre R$ 800,00 a R$ 10.000,00 !!!!! Portanto, é melhor sempre estarmos no controle da situação !

O módulo DJT, que é utilizado no rádio, apresenta um conector onde temos acesso aos dados seriais recebidos, e normalmente neste conector utilizamos um display da FRSKY, chamado de FLD-02.

Nesse display, podemos ver todos os dados que falei até agora, e podemos também programar alarmes para que sejamos avisados caso os sinais de RF tenham a intensidade abaixo de um determinado valor, ou que a tensão da bateria caia abaixo de um determinado valor.

Isso ajuda muito, pois não precisamos ficar olhando para a tela o tempo todo, apenas pilotamos os nossos modelos, e se escutarmos algum alarme, aí sim corremos para solucionar, seja trazendo o avião para mais perto, ou até mesmo forçando a aterrissagem antes da bateria esgotar !

Seguem as fotos abaixo :

RECEPTOR A SER INSTALADO NO AEROMODELO

DETALHE DAS CONEXÕES DE TELEMETRIA

TRANSMISSOR A SER INSTALADO NO RÁDIO

DADOS MOSTRADOS NO VISOR FLD-02

A seguir, mostrarei os outros componentes do sistema de telemetria, que são o HUB e os sensores.

aphawk · 27 de abril de 2015

Seguem os componentes do sistema, mas lembro a todos que não é preciso usar tudo isso, e que também existem soluções DIY com Arduíno Nano que

se mostraram idênticas à da FRSKY :

Sensor de bateria Lipo ( pega também as células individuais )

Sensor de tensão comum ( tensão total )

Sensor de corrente 100A ( existe também de 40A )

Se decidirmos utilizar apenas os sensores acima, não há necessidade do Hub, eles podem ser ligados juntos diretamente ao receptor.

Mas, para usarmos GPS ou qualquer um dos outros sensores ainda não mostrados, precisamos do Hub.

HUB

GPS

Sensor de RPM

Sensor de altura ( vario )

Sensor de aceleração triaxial

Sensor de nível de combustível

Esses são todos os produtos fabricados para o padrão D de telemetria.

Todas as informações podem ser vistas nas fotos do display LCD da FRSKY

A seguir, decreverei como essas informações todas são passadas para o display LCD via interface serial.

MOR_AL · 27 de abril de 2015

@aphawk

Bom trabalho!

MOR_AL

aphawk · 27 de abril de 2015

Agora a coisa vai ficar bem mais interessante.....

O protocolo que a FRSKY criou é o seguinte :

De tempos em tempos, é enviado um bloco de informação, chamado FRAME. Esse FRAME sempre possui 11 bytes, e sempre começa e termina pelo byte 0x7E em hexadecimal.

Para melhor explicar, cada frame sempre tem o primeiro byte 0x7E e o ultimo byte 0x7E. Assim, podemos identificar fácilmente o início do frame quando recebemos dois bytes 0x7E seguidos.

Para que isso seja sempre verdade, em nenhuma outra posição do bloco pode ocorrer novamente um byte 0x7E !!! Logo veremos o problema que isso implica....

O segundo byte do frame pode ter dois valores diferentes.

Se o byte for 0xFE, é um frame que contém sempre os dados do próprio receptor apenas, e que inclui os níves de sinal de RF tanto do transmissor como do receptor, e também a tensão nas duas entradas analógicas de tensão do D8R-II plus.

Já se o byte for 0xFD, é um frame que contém os dados coletados pelo HUB, e que tem todos os outros sensores. Chamaremos eles de FRAME DO HUB.

Claro que se um FRAME contém apenas 11 bytes, teremos de receber vários frames para termos os valores de todos os sensores do hub, certo ?

O formato do FRAME com o segundo byte 0xFE, o qual vamos chamar de agora em diante FRAME DO RECEPTOR , é o seguinte :

0x7E 0xFE voltage_A1 voltage_A2 sinal_tx sinal_rx 0x00 0x00 0x00 0x00 0x7E

Onde voltage_A1 e voltage_A2 são os valores da tensão aplicada nas entradas analógicas do receptor D8R-IIplus, e sinal_tx e sinal_rx são os valores em dB do sinal do link. Um detalhe curioso é que o valor de sinal_rx está DOBRADO. ( vai entender ...... )

Até aqui, tudo fácil, exceto por uma coisa... e se o valor da tensão na entrada A1 e A2 forem exatamente 0x7E ??????

Isto vai violar a regra, de que não pode existir outro valor 0x7E NO FRAME !

Para evitar isto, a FRSKY usou uma técnica chamada BYTE STUFF, que implica nestas duas substituições :

- Um byte que deveria ter o valor 0x7E dentro do frame é substituido pelos bytes 0x7D 0x5E.

- Um byte que deveria ter o valor 0x7D dentro do frame é substituido pelos bytes 0x7D 0x5D.

Assim, se recebermos dentro do frame um byte 0x7D seguido de 0x5E ou 0x5D, temos de fazer a troca pelo valor correto !

Complicadinho, não é ????

Mas isto ainda é só o começo.....

FRAMES DO HUB

Quando o segundo byte do frame tem o valor 0xFD, significa que este frame é um FRAME enviado pelo Hub, e possui um protocolo diferente :

0x7E 0xFD valid_num frame_num val_byte1 val_byte2 val_byte3 val_byte4 val_byte5 val_byte6 0x7E onde :

valid_num : numero de bytes válidos no frame ( pode ir de 1 até 6 )

frame_num : numero sequencial de frame ( pode ir de 0 até 31 )

val_bytex : bytes recebidos de dados ( podem ter de 1 até 6 bytes válidos )

Lembro aqui que o comprimento do FRAME sempre será 11 bytes, independente do número de bytes válidos !!!! Portanto, quase sempre receberemos bytes sem nenhuma utilidade, apenas para manter o protocolo de 11 bytes !

Aqui vai começar uma baita confusão agora !

aphawk · 28 de abril de 2015

PROTOCOLO DE TELEMETRIA DO HUB

Já vimos acima que em cada Frame do Hub podemos ter de 1 até 6 dados válidos. Esses dados contém a informação de todos os sensores, e essa informação em sequência acaba criando um sub-frame de telemetria dentro do Frame do Hub ! Vou chamar essa sequência de Sub-Frame do Hub.

Toda informação que vem do Hub começa com um byte 0X5E, e termina com um byte 0X5E também !

Já viram uma história parecida lá em cima ???? Pois é .....

Segue o formato desse SUB-FRAME DO HUB

0x5E sensor_id1 data_id1_low data_id1_high 0x5E sensor_id2 data_id2_low data_id2_high 0x5E ......... até um ultimo 0x5E

ONDE :

sensor_id1 = byte que especifica qual a informação quem vem a seguir ( de qual sensor e que tipo de informação ! )

data_id1_low = byte menos significativo da informação

data_id1_hig = byte mais significativo da informação

Repare que logo após o ID dizendo qual é a informação que estamos recebendo, vem o valor dessa informação, e essas informações todas são separadas, uma a uma, por um byte 0x5E .

Portanto, aqui também podemos dizer que quando recebemos dois bytes 0x5E em sequência, começa um sub-frame do Hub !!!

Já deu para perceber que aqui também não pode ocorrer de termos algum dos valores da informação com o valor de 0x5E , então a nossa querida FRSKY também implementou nesse sub-frame o tal do BYTE STUFF, mas com valores diferentes :

- Um byte que deveria ter o valor 0x5E dentro do frame é substituido pelos bytes 0x5D 0x3E.

- Um byte que deveria ter o valor 0x5D dentro do frame é substituido pelos bytes 0x5D 0x3D.

Assim, se recebermos dentro do frame um byte 0x5D seguido de 0x3E ou 0x3D, temos de fazer a troca pelo valor correto !

Dá para imaginar a confusão que um programa tem de enfrentar...... tratar BYTE STUFF nos frames normais, e depois tratar novamente BYTE STUFF nos sub-frames do hub !

Continuando ....

Os sub-frames do hub são de três tipos :

Sub-frame1 - enviado a cada 200 milisegundos, contém as seguintes informações :

Acelerômetro tri-axial, Altitude do Vario, Temperatura1, Temperatura2, Tensão da célula, Corrente, Tensão do sensor de corrente, e RPM.

Segue o exemplo do SUB-FRAME tipo 1 ( retirei os 0x da frente de cada byte para melhorar a visualização ) :

5E 24 00 04 5E 25 80 FF 5E 26 E0 FE 5E 10 3C 00 5E 21 3C 00 5E 02 EF FF 5E 05 E9 FF 5E 06 18 34 5E 28 02 00 5E 3A 0A 00

5E 3B 05 00 5E 03 63 00 5E

Sub-frame2 - enviado a cada segundo, contém as seguintes informações :

Curso, Latitude, Longitude, Velocidade, Altitude do GPS, nível do combustível

Segue o exemplo do SUB-FRAME tipo 2 :

5E 14 2C 00 5E 1C 03 00 5E 13 38 0C 5E 1B C9 06 5E 23 4E 00 5E 12 EF 2E 5E 1A 98 26 5E 22 45 00 5E 11 02 00 5E 19 93 00

5E 01 18 00 5E 09 05 00 5E 04 64 00 5E

Sub-frame3 - enviado a cada 5 segundos, contém as seguintes informações :

Data, hora

Segue o exemplo do SUB-FRAME tipo 3 :

5E 15 0F 07 5E 16 0B 00 5E 17 06 12 5E 18 32 00 5E

Para piorar ainda mais, a FRSKY não garante que os dados serão recebidos da maneira acima na mesma sequência.... é muito comum recebermos alguns bytes de um tipo de sub-frame, e alguns bytes de outro tipo de sub-frame !

A seguir, veremos a tabela de identificação dos IDs possíveis, e o significado dos bytes de dados de cada Id.

Agora, vamos ver um bloco de dados capturados na saída no módulo DJT , e que normalmente vão para o LCD da FRSKY :

FORMATO DA COMUNICAÇÃO SERIAL

O formato de comunicação serial é 9600 8N1 com nivel de 0 a 5 Volts, porém o nivel do sinal está INVERTIDO, isto é, temos de inverter o nível do sinal antes de fazer a leitura !

Reparem que doideira... abaixo segue uma amostra do sinal REAL capturado em meu computador :

7EFE839D53A9000000007E
7EFD060E5E2128005E027E
7EFD040E19005E055E027E
7EFE829D51AA000000007E
7EFD060FECFF5E06177F7E
7EFD010F5E005E26177F7E
7EFE829D53AB000000007E
7EFE839D51AC000000007E
7EFE829C53AC000000007E
7EFD06105E24D0FF5E257E
7EFD041020005E265E257E
7EFE829D51AE000000007E
7EFD061100045E10C1027E
7EFD04115E214C00C1027E

aphawk · 28 de abril de 2015

Vou fazer uma rápida análise dos dois primeiros frames :

7EFE839D53A9000000007E -> 0 segundo byte, FE, indica que é um frame do receptor, então tem estas 4 informações :

tensão na entrada A1 = 83H = 131 decimal => 131/255 x 3,3 Volts = 1,70 Volts !

tensão na entrada A2 = 9DH = 157 decimal => 157/255 x 3,3 Volts = 2,03 Volts !

Nivel de sinal recebido no receptor = 53H = 83 decimal => 83 dB !

Nivel de sinal recebido pelo transmissor = A9H = 169 decimal , que temos de dividir por 2 => 84,5 dB !

A FRSKY determina que o nível mais baixo de sinal é de 40 dB, na prática se estivermos com os dois valores acima de 45 estaremos bem.

7EFD060E5E2128005E027E -> o segundo byte, FD, indica que é um frame do hub.

06 = temos 6 bytes válidos

0E = numero do frame ( sempre igual ao anterior ou um acima ) , pode ser ignorado

5E2128005E02 => isto é o tal sub-frame do hub !!!! com 6 bytes ( lembre dos bytes válidos )

Vamos decodificar o sub-frame :

5E 21 28 00 = de acordo com a tabela, o ID 21 determina que são os dados da Altitude do VARIO, e são os dados que estão na parte decimal da medida. Os dados são de 16 bits, e são lidos como 0028H, que dá 40. Então, no display, seria mostrado algo como .40 !

Os próximos bytes, 5E 02, indicam que é o ID 02, que é o primeiro sensor de temperatura ! Mas para sabermos o valor desse sensor, teremos de receber o próximo sub-frame do hub, que pode ser o próximo frame em geral, ou não .... por acaso desta vez é mesmo o próximo frame, vamos decodificar parcialmente :

7EFD040E19005E055E027E = > frame do hub, com apenas 4 bytes válidos, numero do frame 0E, o mesmo do anterior, vamos separar o sub-frame :

19 00 5E 05 : os bytes 19 00 devem ser lidos como 0019H, e são justamente o valor do sensor de temperatura 1 , no caso o lcd mostraria 25 graus !!! E a seguir temos o ID 05, que é o sensor de temperatura 2..... Complicado isso de termos de esperar receber outro frame para obter o valor de um sensor identificado neste frame !!!!!!

E assim por diante, vamos separando os sub-frames e decodificando o sinal ......

Pessoal, lendo agora tudo o que coloquei, parece fácil, não é ? Mas acreditem que para conseguir fazer isto eu pesquisei 3 dias seguidos na Internet, pois não existia tudo consolidado, apenas fragmentos de informações obtidas por pessoas que como eu queriam obter algo mais do que o LCD oferecia !

aphawk · 28 de abril de 2015

SENSOR DE TENSÃO PARA BATERIAS LIPO

Embora seja bem difícil de comprar hoje em dia, este sensor envia os valores de cada uma das cálulas existentes na bateria. Mas, se você reparar na tabela de ID, vai ver que existe apenas um único ID para isso, que é o ID 0x06 .

Como isto é feito ?

A FRSKY tem um truque : o primeiro byte logo após o ID do sensor é dividido em dois Nibbles. O Nibble com os 4 bits mais significativos contém o número da célula da bateria em questão, sendo que 0 indica a primeira célula, 1 indica a segunda, e por aí vai.

O outro nibble, que são os ultimos 4 bits, são juntados aos 8 bits provenientes DO SEGUNDO BYTE, e juntos formam um número com 12 bits, o qual fornece o valor da tensão dessa célula em milivolts !

Vamos a um exemplo : 5E 06 1C A3 => id 06 é o da tensão da célula, o 1C dividimos em dois nibbles : 1 e C .

O 1 indica que esta é a tensão da SEGUNDA CÉLULA , e a tensão dela é de CA3 = 3.235 milivolts, ou 3,235 Volts.

Portanto, cada vez é enviada a tensão de uma das células, e pode demorar alguns segundos para que apareçam todas as tensões de uma bateria de várias células, tipo 5S.

ENTENDENDO OS DADOS DO GPS

Os dados de Latitude e Longitude do GPS são recebidos no formato decimal - decimal, e não no formato que estamos acostumados com graus, minutos e segundos !

Porém, o próprio display da FRSKY mostra os dados nesse formato decimal-decimal, o que complica bastante para usarmos algum programa tipo Google Maps.

A melhor coisa é fazer a conversão, e para isso basta seguir esta dica :

-- Convert a NMEA decimal-decimal degree value into degrees/minutes/seconds

-- First convert the decimal-decimal value to a decimal:

-- 5144.3855 (ddmm.mmmm) = 51 44.3855 = 51 + 44.3855/60 = 51.7397583 degrees

-- Then convert the decimal to degrees, minutes seconds:

-- 51 degress + .7397583 * 60 = 44.385498 = 44 minutes

-- .385498 = 23.1 seconds

-- Result: 51 44' 23.1"

Legal, não é ?

SENSOR DE TENSÃO SIMPLES

A FRSKY tem o sensor comum de tensão, para ser ligado diretamente ao receptor, em suas duas portas analógicas.

Lembram que eu disse que essas portas podem receber tensões entre 0 e 3,3 Volts apenas ?

como é possível ler tensões acima disto ?

Vejam novamente a foto do sensor :

Reparem do lado direito, podemos soldar o fio positivo em três locais diferentes .

De cima para baixo, está marcado 1S, 2S e 3S , correto ?

Essa plaquinha nada mais é do que um divisor resistivo, o qual divide a tensão da bateria por 2 ( 1S ) , por 4 ( 2s) e por 6 ( 3S ) !

Assim, sempre teremos nas entradas analógicas uma tensão dentro da faixa correta.

E como recebemos a tensão correta no display LCD da FRSKY ?

Existe uma programação no display LCD, para cada uma das entradas analógicas temos de informar qual o fator de divisão correto, podendo escolher entre 1 , 2, 3, 4, 5 e 6 ! Vejam lá nos primeiros posts, onde coloquei as fotos do display, a ultima tela é exatamente a tela de configuração do display, reparem que está escrito CONFIGURATION RATIO, e seguido de dois valores, que são os fatores de divisão !

Embora o sensor de tensão fabricado pela FRSKY aceite apenas divisão até 4 , se voce está usando uma bateria de tensão acima de 20 volts voce mesmo pode fazer o seu divisor, selecionando os resistores corretos para obter uma divisão por 5 ou uma divisão por 6.

Bom, acho que agora já podemos tratar do projeto em termos de hardware e de software....

Será interessante para quem acha que o Bascom não pode fazer as coisas que o C faz, coitadinhos ..... kkkkk

aphawk · 1 de maio de 2015

Este é o hardware utilizado, simples e barato !

Do lado esquerdo reparem que existem 3 botões, mas o que vamos usar mesmo é um Rotary Encoder, do tipo que pode ser apertado como um botão além de girar para os dois lados. No Rotary encoder temos 4 pinos, sendo um o GND, outro o central Push Button, e os outros dois são os que indicam o sentido de rotação. Estes dois no meu esquema estão com o símbolo L e R. Se quando voce soldar os fios, parecer que o sentido de rotação está invertido, basta trocar um com o outro.

Mas como o Proteus não tem isto, para simular tive de fazer dessa maneira, com uma rotina alternativa durante a compilação.

A ideia é uma plaquinha onde a alimentação virá de uma bateria, ou de várias em série, no minimo com 7V de entrada e no máximo com 15V para não aquecer demais o 7805.

O display ILI9431 existe aos milhares no Ebay, com qualquer tamanho, eu usei um de 2.2" , e tem de ter a interface SPI.

Para compatibilizar o display que é de 3.3V com o restante, usei dois Level Shifter, muito comum e baratos no Ebay. A vantagem é que eles já geram a tensão de 3.3 V a partir dos 5 Volts, então podemos alimentar o display com essa tensão.

Segue a foto deles :

Claro que se voce quiser também pode alimentar tudo com 3.3 Volts e eliminar os dois Level Shifter, mas nesse caso o som gerado para o Buzzer ficará muito baixo, e precisará ser amplificado. Eu preferí usar os dois level-shifters....

Ou também pode usar um divisor resistivo para adequar de 5 para 3.3V, usando resistores como o circuito abaixo :

Mas terá de usar um regulador para gerar os 3.3 Volts, a menos que use um Arduíno que já tem essa saída.

Enfim, escolha a que voce prefere ....

kinucris · 19 de maio de 2015

Olá Aphawk

Encontrei seu Post através do nosso amigo em comum, Google e devo dizer que seu projeto realmente me interessou e serviria feito uma luva rs

Já percebi que você já avançou bastante em seu projeto e a sua postagem é bem atual, li a todos os comentários e gostaria muito que o projeto tivesse continuidade e dou apoio total da forma que eu puder. Não tenho todo o conhecimento técnico como você ou os amigos que deixaram alguns comentários, mas tenho os mesmos DJT + D8R II Plus + HUB + FDDSV 1 + FLD-02 + FLVS-01 (Comprei errado com Smart Port, não encontrei a versão correta para a série D igual o seu) e também tenho um Arduino Uno que sempre me serviu para usos diversos de diversão...

OBS: Está ficando difícil de encontrar os sensores FrSky da série D

Enfim estou interessado no projeto e me disponibilizo a ajudar com futuros testes ou ideias em relação aos diversos tipos de usos que podemos ter com as informações recebidas; Trabalho na área de internet programo em php, posso ter uma noção dos tipos de usos ou funções lógicas.

Aphawk, também me interessei pelo seu kk board 2 controlando o bixler 3 pois estou com um Bixler 2 novo, na caixa que ainda nem coloquei pra vôar pois estou a treinar minhas habilidades em um Easy Star (genérico comprado no ML)

Caso você tenha documentado suas configurações do kk board e/ou possa me enviar algo a respeito via MP ou email ([email protected]) tenho interesse de adicionar uma dessas em meu Bixler 2

Estou seguindo a postagem, estou ansioso pelos resultados obtidos, sei que ter que ter muita força de vontade pois não é uma tarefa fácil que demanda tempo e não é remunerada; Então força ai brother!

Atenciosamente

Elvis Moraes

aphawk · 20 de maio de 2015

@kinucris,

Opa, Elvis, que bom que você achou legal !!!

No momento, ainda não modifiquei o meu software para usar o display, o motivo é que fiquei pensando em como fazer o melhor uso do display, de uma maneira bem útil mas também amigável, e isso me fez dar uma parada para estudar mais algumas coisas sobre o sistema do FRSKY.

Meu software está hoje recebendo todos os dados e enviando pela interface serial, e recebo tudo no meu computador, e verifico que está bem redondinho.

Sobre as dificuldades de encontrar os sensores, sugiro que voce faça o seu sistema, usando um Arduíno Mini ou Nano, um sensor de corrente, um vario MS5611 e três divisores resistivos, voce vai conseguir substituir o FLVs-01, o vario, os sensores de corrente tipo FLA de 40 ou 100 A, e o Hub !!!!

A unica desvantagem é que no momento ainda não conseguimos ligar no Arduíno nem o GPS e nem os sensores de temperatura.... Mas o preço é muito menor, e além disto voce ainda vai ter uma saída analógica para o sinal do Vario, podendo ligar em uma das entradas analógicas do receptor e poder fazer o famoso ario tonal, que indica subida e descida !

Procure no Google pelo OPENXSENSOR :

https://code.google.com/p/openxsensor/

Sobre o Bixler, vai adorar ele !!! Muito potente, pode embarcar nele a telemetria e o FPV ! Eu já troquei o motor por um mais potente e uso um bateria de 4600 mAh, que é uma beleza, semana passada consegui manter ele no ar por 45 minutos com uma bateria de 2200, mesmo sem térmica nenhuma ! Mas cheguei a usar mais de 2100 da bateria.....

Mas use um sensor de corrente, pois ajuda muito saber quanta capacidade você ainda tem disponível na bateria para trazer o bicho de volta.....

Sobre o uso da KKboard, eu implementei nela o OPENAERO2 :

https://code.google.com/p/nextcopterplus/wiki/OpenAero2_Getting_Started

Olha, a plaquinha ajuda muito a estabilizar nos ventos fortes, e principalmente no pouso, e voce ainda grava nela uma posição de servos para o avião voar em círculos caso perda o sinal do rádio !

Outra coisa, se você tiver algum rádio tipo o Turnigy 9x ou um de seus variantes, pode implementar um novo firmware que já trata a telemetria Usando a própria tela do rádio, com muito mais recursos que o display FLD-02 .

E se tiver um desses Taranis Plus, então, o céu é o seu limite, é simplesmente o melhor rádio do mundo, pois usa o software OPENTX 2, e o rádio até fala !!!! E faz coisas absurdas, como rodar scripts LUA que permitem você mesmo escrever várias aplicações que rodam simultâneamente .

Evite sempre mensagens pessoais, o melhor sempre é colocar para todos, pois outros pode achar estes posts e se beneficiar também !

Semana que vem volto a modificar o programa para o display.

Paulo

kinucris · 20 de maio de 2015

visHH @aphawk

Pra ser sincero eu nem sei quais seriam as possibilidades de exibição no Display, como funciona essa questão de Layout, mas quando temos muitas informações eu lembro de uma tela de FPV com um OSD básico onde se exibe MUITA informação de uma só vez nos cantos da tela para tentar preservar ao máximo o centro onde se vê o "bico" do avião, com a vantagem que você não vai ter essa questão do bico e ter de economizar o centro...

Mas acho que o mais interessante seria uma interface onde cada usuário poderia selecionar as informações que quer que sejam exibidas, nem que fossem por meio de Jumpers traseiros, não sei rs

Por que pior que não se ter a informação é não ter a informação e ela ainda assim ocupar espaço... "Por exemplo: 0,0"

Sua resposta chegou com muita informação haha

Perdi o resto da noite pesquisando e lendo a respeito rs

...OpenXSensor parece ser bem interessante e de fácil acesso seus componentes mas necessita obrigatoriamente do OpenTX funcionando em meu rádio que coincidentemente como você citou é um Turnigy 9x mas totalmente original, a única modificação até o momento foi a mudança do transmissor para o kit FrSky DJT (Penso em futuramente fazer o conector para o USBAsp juntamente com o Black Light com a solda do mosfet bs72a - utilizando do conhecimento adiquido com os vídeos do amigo Fabiano Regra neste vídeo https://goo.gl/864UXr) e só aí então vou poder instalar o OpenTX ou equivalente (apesar de que para ser sincero ainda nem explorei ou dominei todas as funções presentes no firmware original do Turnigy)

Bixler - Meu Setup -> http://www.avoo.com.br/viewtopic.php?f=3&t=2

Qual motor você está usando no seu? inicialmente meu Easy Star está com motor/esc/receptor que vai ser do Bixler 2 que são Turnigy D2826 2200kv, Turnigy 40A plush, D8R II Plus, hélice APC 7x5 ... depois de ver vários vídeos do pessoal fazendo longos vôos com FPV e tal usando essa configuração optei pela mesma... O que você acha?

kk board - referência rc groups http://goo.gl/WIVX4Q

Cara pra ser sincero eu só ouvi falar sobre as controladoras de vôo por nome, nem sei de suas funções ou seus potênciais com monomotores, não tenho a miníma ideia de como usa-las, vou ter de pesquisar muito a respeito para chegar próximo deste seu nível de vôo, mas vamos tentando... Eu já tinha visto alguns vídeos do pessoal utilizando até mesmo como Bixler, o tal Gyro da Hobbyking, o que você acha dele apesar de ser bem mais simples...

(Se você puder enviar algumas fotos das suas conexões eu adoraria ver a tralha toda rs)

Preciso comprar os mesmos para ir fuçando, vou procurar alguns tópicos específicos ver se aprendo mais informações a respeito, qualquer ajuda é muito bem vindo rs

(Comprei o Gyro na HobbyKing mas ainda não chegou)

Aguardo ansiosamente semana que vem seus resultados O/

OBS: Ainda não consegui colocar pra funcionar o FBVS-01

aphawk · 20 de maio de 2015

@kinucris,

Pois é, essa interfaçe do usuário é que está me deixando de cabelo em pé ...

Sobre o Openxsensor, ele funciona sim no seu LCD da Frsky ! Não é necessário mudar para o Opentx, voce apenas continuará usando o eu display LCD ok ?

E fazer as mods no rádio é bem simples, na verdade terá de acrescentar dois resistores e mudar dois sinais , e modificar uma coisinha quase no conector do transmissor DJT. Mas tem de implementar de qualquer maneira o conector USBASP, isso tudo demora cerca de uma hora para fazer com cuidado. Mas depois fica uma maravilha ! Existem alguns tutoriais bem completos, vou ver se posto alguns aqui.

Sobre o Gyro, eu acho ele inútil na telemetria, o que vale mesmo a pena é o Vario, mas não a versão antiga, e sim o novo vário de precisão FRSKY, feito para o S-Port, a vantagem é que ele também pode ser ligado no antigo protocolo serial da linha D, que é o seu receptor. mas já que comprou o gyro, fazer o que... use kkkkkkk !

Mas sinceramente, esse vário com o MS5611 usado no OpenXsensor é ainda superior.

Sobre a controladora de voo, essas KK 2.0 e acima são fantásticas, o ultimo modelo delas é ainda superior, pois usa esse mesmo vário MS5611. Todas elas funcionam muito bem, e reagem rápidamente a mudanças na estabilidade do Bixler. é muito interessante voce colocar o avião em uma boa altura, desligar o motor e ligar a placa estabilizadora com a função máxima, que também tenta manter altura, pode soltar o rádio e ficar admirando, o avião prossegue numa boa, sem ameaçar cair, mesmo com mudanças fortes no vento.

Pesquise bem esses tópicos que te passei : OpenAero2 , OpenTX, e OpenXsensor. Tem muita informação, e nisso está o futuro do aeromodelismo ! E acredite, um rádio Taranis Plus é tudo o que você poderia pensar em ter num rádio, tá cheio de gente vendendo os Futabas, Spektrum e os JR's tops, dá para comprar o Taranis e ainda sobra prá outras coisas da telemetria e módulos de transmissão Long Range.

O FBVS-01 é um sensor muito simples, voce configura ele soldando o cabo no terminal correto conforme sua bateria, e o cabo de saída vai na entrada analógica 1 de seu receptor. No display, voce configura o fator de divisão por 6, e pronto. Vai aparecer o valor da tensão da bateria,

Pena que está difícil achar o sensor que mostra a tensão individual das células... mas isso pode ser feito pelo OpenXsensor.

Este fim de semana eu tiro umas fotos do Bixler com as tralhas todas nele kkkkk .

Um abraço.