Encore HT12E (cómo es su codificacion ? )

Buenas.

Tengo un problema ya que no cuento con un oscilospio quiciera saber como es la codificacion que manda el HT12E osea:
- Que envia primero el ADREES y despues los DATOS
- Los envia juntos o por separados
En el DataSheep no entiendo mucho los graficos. Saludos espero que me pueda dar su opinion
 
Retomando este tema que ya es bastante viejo, y para no abrir uno nuevo que este repetido, vuelvo a escribir acá. Me tope con el mismo problema del amigo Kaki, agradecería mucho si me pueden ayudar.

La idea es leer los datos que envía el ht12E, para recrearlos con arduino y así poder comunicarme con varios Ht12D desde un solo arduino y no necesitar varios encoder. La duda es si estos trabajan como otros codificadores los cuales cambian todo el tiempo los datos enviados o son siempre los mismos, de ser así encontrar la relación con el cambio en sus direcciones.. Etc.

Muchísimas gracias
 
hoo arduino que tecnologico

jaja pues no!

por que ya existe , lo que pasa es que el HT12E lo que hace es enviar pulsos de un tamaño definido por bits

es decir 1 bit ocupa un ancho de subida y un ancho de bajada lo que hace el HT es enviar varias veces los mismos datos y por dedundancia el receptor verifica si el dato es valido

por cada adress que haces en el HT12E lo que hace este chip es hacer mas delgado el flanco de subida
el pulso se hace hasta 256 veces mas delgado por eso cuando juegas con el adress corres el riesgo que de sea mas suceptible a la interferencia

eso lo dice claramente la datasheet.

¿como no ser esclavo del ht12E?
pues hacer un micro que envie por UART y un micro que reciva por UART

¿como hacer para que no se confundan?

digamos que quiero enviar el numero 1234 a el receptor A
y al receptor B quiero enviar 4321

si yo envio esos mismos datos se cruzan y todo sera confuso

para que A reciva 1234
y B reciva 4321
debemos poner un simbolo exclusivo para A y uno para B

digamos que para A le asigno el simbolo $
y para B le doy el simbolo #

entonces al transmitir $1234
el receptor A escuchara solo lo que empieze con $

y B escuchara al simbolo #4321

¿va haber perdida de datos?
si

si no enviamos repetitivamente los datos se pierden
ejemplo

al enviar $1234
una sola vez puede que el receptor no escuche completo el mesaje pues se atravezo el perro , paso un avion , una infinidad de problemas de interferencia

debemos enviar ese mismo dato almenos 4 veces como minimo

el receptor debe leer al menos el minimo 4 veces si no se cumplen ese dato no es valido y es como si no hubiera escuchado algo.

¿con que transmitir?

ASK es muy suceptible al ruido y baudios al menos como minimo 75 bauds y maximo de 75 bauds jaja no es mucho

pero es mejor PSK aunque los modulos PSK son mejores y soportan 9600 baudios son mas caros y dificiles de encontrar que un modulo bluetooth

es lo malo que internet esta plagado de los modulos HT12E y el ASK tws433

para usar 8 bits con 2 HT12E solo debes multiplexarlos en tiempo

ejemplo poner 2 ht12E en cascada no transmites nada

pero si prendes uno y el otro esta apagado envias 4 bits bajos y para enviar los 4 bits altos apagas el que estaba prendido y el otro lo prendes
auna velocidad de 500ms no es mucho pero para un led y un rele es buena idea
 
Perdón trilo-byte por mi poca experiencia, una consulta se puede hacer una comunicación UART entre pic inalambrica con unos módulos de RF comunes como los de 433mhz??
Saludos!
 
si es posible pero debe ser a una velocidad relativamente baja

pues ASK se ve afectado por el ruido es basicamente AM

lo que debes hacer es enviar varias veces el byte
es decir para enviar la letra "F" debes enviarla almenos 4 veces y el receptor debe comprobar que lo que enviaste se repitio 4 vece si no se desecha ese dato

esa teoria ya esta en la pagina de Ucontrol con la explicacion de usar los modulos TWS y RWS
esa teoria no la invento el que hiso el tutorial

es algo que se le llama codigos de linea y es un tema basico de la escuela de ingenieria
 
hacer un checksum?
eso nunca lo he intentado pero podria funcionar

si funciona, hace un tiempo hice un programa con un protocolo super sencillo, que era mas o menos asi:

si el emisor debia mandar por ejemplo un 4 le sumaba 5 y mandaba solo dos bytes 4y 9.
el receptor al recibir el 49 le descontaba los 5 y el resultado deberia ser 44, si los dos son 4 entonces el valor correcto es ese, si eran diferentes desechaba el valor y pedia una retransmicion.

(era un poco mas complejo porque se enviaban varios bytes pero en si ese era el principio)

obviamente lo complejo del algoritmo depende de cada quien.
 
Última edición:
Atrás
Arriba