Jorge,

Citação de: minilathe em 14 de Julho de 2010, 20:20

"o molho não deve ser mais caro que o peixe".

Como parece que a solução minimalista original está sendo abandonada em favor de algo um pouco mais elaborado, é incontornável a adoção de um protocolo multibyte que inclua o indispensável preâmbulo e o barato checksum ou CRC. É desejável e útil o handshaking e alarme em caso de falha ...

Algo do tipo:

preâmbulo (indica o início do quadro)
joystick 1
joystick 2
joystick 3
joystick 4
I/O
Checksum

O Tx pode responder com checksum + código de erro, se incorreto, indica falha de comunicação ou outra qualquer, como flooding ...


PS: Linguado à la belle meunière é o que escolho quando tenho opção. É bem possível que eu goste do minimalismo mais que qualquer um por aqui ... 

Há duas questões colocadas por voce, bem especificas da camada de enlace, da qual estamos tratando:
(1) Controle (detecção) de erros
(2) Delimitação de quadros

(1) No caso da deteção de erros, eu não faria a principio, por uma questão de começar pelo +simples. Não é complexo fazer um checksum. Mas coloco aqui a questão, acho que se os autores não usaram será mesmo necessário? O que acham?

(2) No caso da delimitação do quadro, voce sugeriu um preâmbulo. Que normalmente seria uma sequência de ocorrência única na transmissão. Nesse caso, seria necessário adotar também uma codificação orientada a caractere, para que esta sequência não se repetisse no meio do quadro. O que, acho, complicaria um pouco mais.

Estava pensando em fazer algo simples, delimitar os quadros usando temporização, que é como o programa original trabalha.

Na seguinte sequência: T1 - T2 - T1 - T2 - T1 - ....

Onde:
        T1: tempo de transmissão (todos os bytes do quadro em sequência, separados por um pequeno intervalo entre bytes menor ou igual a 1 byte)
        T2: Intervalo de silêncio, igual ou maior que T1 (por exemplo: 2xT1)

Usando uma simples rotina de temporização, e sendo T2 >= T1, é sempre possível o receptor sincronizar com o transmissor.

Havendo comunicação bidirecional, teríamos:

T1 - T2 - T3 - T4 - T1 - T2 - T3 - T4 - T1 - T2 - T3 - T4 - T1 - T2 - T3 - T4 - ....

Onde
T1 - tempo de transmissão da estação base (EB)
T2 - tempo de silêncio da EB (>=T1)
T3 - tempo de transmissão do ROV
T2 - tempo de silêncio do ROV (>=T3)

Para haver sincronismo nos dois sentidos, usa-se um temporizador em cada estação.

O que acham??

Jorge,

Citação de: C N C N o w ! em 14 de Julho de 2010, 21:05

Citação de: minilathe em 14 de Julho de 2010, 20:20

"o molho não deve ser mais caro que o peixe".

Como parece que a solução minimalista original está sendo abandonada em favor de algo um pouco mais elaborado, é incontornável a adoção de um protocolo multibyte que inclua o indispensável preâmbulo e o barato checksum ou CRC. É desejável e útil o handshaking e alarme em caso de falha ...

Algo do tipo:

preâmbulo (indica o início do quadro)
joystick 1
joystick 2
joystick 3
joystick 4
I/O
Checksum

O Tx pode responder com checksum + código de erro, se incorreto, indica falha de comunicação ou outra qualquer, como flooding ...


PS: Linguado à la belle meunière é o que escolho quando tenho opção. É bem possível que eu goste do minimalismo mais que qualquer um por aqui ... 

Há duas questões colocadas por voce, bem especificas da camada de enlace, da qual estamos tratando:
(1) Controle (detecção) de erros
(2) Delimitação de quadros

(1) No caso da deteção de erros, eu não faria a principio, por uma questão de começar pelo +simples. Não é complexo fazer um checksum. Mas coloco aqui a questão, acho que se os autores não usaram será mesmo necessário? O que acham?

(2) No caso da delimitação do quadro, voce sugeriu um preâmbulo. Que normalmente seria uma sequência de ocorrência única na transmissão. Nesse caso, seria necessário adotar também uma codificação orientada a caractere, para que esta sequência não se repetisse no meio do quadro. O que, acho, complicaria um pouco mais.

Estava pensando em fazer algo simples, delimitar os quadros usando temporização, que é como o programa original trabalha.

Na seguinte sequência: T1 - T2 - T1 - T2 - T1 - ....

Onde:
        T1: tempo de transmissão (todos os bytes do quadro em sequência, separados por um pequeno intervalo entre bytes menor ou igual a 1 byte)
        T2: Intervalo de silêncio, igual ou maior que T1 (por exemplo: 2xT1)

Usando uma simples rotina de temporização, e sendo T2 >= T1, é sempre possível o receptor sincronizar com o transmissor.

Havendo comunicação bidirecional, teríamos:

T1 - T2 - T3 - T4 - T1 - T2 - T3 - T4 - T1 - T2 - T3 - T4 - T1 - T2 - T3 - T4 - ....

Onde
T1 - tempo de transmissão da estação base (EB)
T2 - tempo de silêncio da EB (>=T1)
T3 - tempo de transmissão do ROV
T2 - tempo de silêncio do ROV (>=T3)

Para haver sincronismo nos dois sentidos, usa-se um temporizador em cada estação.

O que acham??

Se eu entendi direito acho que fica bem simples, o quadro transmitido a starta um tempo de silêncio sempre igual ou maior que o tempo que ele levou para ser transmitido e assim sucessivamente, por toda a transmissão ?

Seria algo assim:

Comunicação uni-direcional (+simples)

Estação de comando:
(1) A comunicação sempre começa pela estação de controle, o envio de um quadro de comando.
(2) A estação de comando sempre envia um quadro a intervalos regulares (T2).

ROV:
(1) Fica escutando a rede (cabo), se um comando chegar, verifica se chegou sem erros (a manteiga do linguado do Jorge... ) se chegou com erro, descarta. Se chegou sem erros processa o comando.

Comunicação bi-direcional:

Estação de comando:
(1) A comunicação sempre começa pela estação de controle, o envio de um quadro de comando.
(2) A estação de comando sempre envia um quadro a intervalos regulares (T2).
(3) A estação aguarda por uma resposta do ROV, se não chegar no tempo esperado (T2), vai para o passo (1).
(4) Se recebeu um quadro, verifica se chegou sem erros, se ok processa e espera T4 antes de ir para o passo (1), senão vai para o passo (1).

ROV:
(1) Fica escutando a rede (cabo), se um comando chegar, se chegou com erro, descarta. Se chegou sem erros processa o comando.
(2) Envia um quadro de resposta.
 

Pelamordasdeusas Anderson !

O dedo caiu aqui em cima do enviar, foi mal...
[/quote]

já escolheu a(s) bateria(as) e motor(es) e tem definido o peso do sistema? Não sei porquê ... mas eu acredito que a comunicação serial apesar de importante e já ter sido muito bem comentada aqui poderia ser deixada mais para frente ... não?

Anderson,

Senhores,
A diretriz do projeto é que possa ser bastante simples. Quanto...,  é uma questão de coerência pois não se pode abdicar de qualidade e bom funcionamento. Há que se pensar porém na possibilidade de execução com o mínimo possível de implementos para que estes possam ser adquiridos como acessórios, o que capacita o projeto a um grande número de usuários. Portanto acredito que para este primeiro módulo o projeto precise atender as seguintes necessidades:

• Locomoção com dois eixos de liberdade - Joystick
• Profundidade - Potenciômetro deslizante
• Iluminação para utilização de camera Frontal
• Iluminação camera trazeira
• camera de vídeo frontal
• camera de vídeo trazeira
• Servo

O mínimo possível de sofsticação com relação a segurança também é interessante. Como exemplo o sensor de umidade. Este equipamento navegará em águas rasas, chegando a uma profundidade máxima de 50 metros.

Comandos enviados:
(1) Locomoção com dois eixos de liberdade - Joystick
Eixo X - 3 bits
Eixo Y - 3 bits
(2)Profundidade  - Potenciômetro deslizante
Eixo Z - 8 bits??
(3)Iluminação para utilização de camera Frontal
L1 ON/OFF - 1 bit
(4)Iluminação camera trazeira
L2 ON/OFF - 1 bit
(4)Servo
Posição do servo - 2 bits

A profundidade tem a ver com o foco / zoom da câmera ou a profundidade do ROV?

A profundidade tem a ver com o foco / zoom da câmera ou a profundidade do ROV?

Gil,

Não, essa profundidade é de locomoção do aparelho mesmo. Agora você tocou em um ponto interessante, a câmera com zoom abre um leque muito grande de opções. É uma função que será opcional (câmera com ou sem  zoom).

Por gentileza:

Quando forem fazer citações de textos dos colegas, evitem de r4eprodurir o conteúdo completo das mensagens..

Esta é uma campanha da "Ablação Caudal"...