FtaTV

Les presento la versión alfa 0.0.0.0.0.1 de mi aplicación para configurar y ajustar un motor diseqc 1.2.

Es una aplicación que implementa gran parte del protocolo Diseqc 1.2, pensada para aprovechar al máximo las opciones de los motores para nuestras antenas.

Permite

• Mover el motor al estilo USALS
• Moverlo de a pasitos tan chicos como el motor lo permita
• Moverlo a una cantidad especí­fica de grados
• Moverlo a cualquier posición guardada en el motor
• Guardar posiciones.
• Gestionar lí­mites por software.
• Monitorear un TP

Por el momento está en español e ingles dependiendo de la configuración de la pc donde se ejecute.

Requiere librerí­as QT y corre en versiones 32 y 64 bits de cualquier linux.

Explicaciones cortas en la siguiente miniatura (click para agrandar)


Lugar de descarga: ni ida... aún no lo subí­ a ningún lado.

Si... yo asistí­ a las clases de parto !!!
Ya nació la criatura y como verán está en excelentes condiciones.-

Mis mas sinceras felicitaciones para nuestro querido amigo Sergio por el trabajo, el empeño y la garra que le puso a este Software.



Salu2

SergioDanielG escribió:Les presento la versión alfa 0.0.0.0.0.1 de mi aplicación para configurar y ajustar un motor diseqc 1.2.

Mis mas sinceras felicitaciones por semejante proyecto, me he quedado sin palabras así­ que:

Para ser una "versión alfa 0.0.0.0.0.1" está mas que completa y desarrollada
Esto creo que es el comienzo de algo que va a superar cualquier frontera...
... y los fabricantes de estos motores que le vayan pegando una ojeada porque esto promete y mucho.
Solo para desasnarme: esto solo serí­a aplicable a placas satelitales para PC?
Gracias por compartir este gran trabajo

satpinamar escribió:Para ser una "versión alfa 0.0.0.0.0.1" está mas que completa y desarrollada

Gracias satpinamar. La versión es alfa 0.0.0.0.0.1 porque empezó siendo una simple utilidad para pequeñas cosas como guardar posiciones en el motor, pero lectura tras lectura del protocolo Diseqc 1.2, me hicieron ir agregándole opciones. Y hoy ya está internacionalizado (entiéndace en varios idiomas) aunque solo español e inglés, pero de muy sencilla traducción a otros idiomas.

Ni salió a la calle y ya es un código que casi necesita ser reescrito (anque solo por prolijidad y legibilidad), además le faltan implementar a full las opciones de Transponder, pero con placas que tengan blindscan esto no es problema.

satpinamar escribió:Esto creo que es el comienzo de algo que va a superar cualquier frontera...
... y los fabricantes de estos motores que le vayan pegando una ojeada porque esto promete y mucho.

Asi es, espero que no tenga lí­mites. En otro topico habí­a comentado mis intensiones de hacer un software para blindscan, y este el primer gran paso para llegar a eso.

satpinamar escribió:Solo para desasnarme: esto solo serí­a aplicable a placas satelitales para PC?
Gracias por compartir este gran trabajo

Así­ es, por el momento solo para placas satelitales en linux. Para portarlo a windows me faltan conocimientos, pero sé donde conseguir muy buena info

Y tal vez para el final del dí­a pueda tener un videito mostrando su funcionamiento...

Muy bueno y muy interesante este proyecto.
Te hago una consulta: con lo que has investigado hasta el momento, has logrado detereminar si la velocidad de movimiento del motor (que sabemos es mayor para 18v que para 13v) es una limitación del motor, de los receptores (STB) o del protoclo diseqc? Ya sea por el consumo (mA) o por los tiempos mí­nimos de espera entre comando y comando especificados en el protocolo...
Porque de lograrse una mayor velocidad en el posicionamiento también serí­a otra gran ventaja a tener en cuenta.
Lo bueno también de este software es que tal vez al menos se pueda programar que entre satélite y satélite siempre se mueva a velocidad de 18v, es decir, se conmute a polaridad H (18v), se posicione y luego regrese a la polaridad requerida (H o V) por el usuario.

satpinamar escribió:Muy bueno y muy interesante este proyecto.
Te hago una consulta: con lo que has investigado hasta el momento, has logrado detereminar si la velocidad de movimiento del motor (que sabemos es mayor para 18v que para 13v) es una limitación del motor, de los receptores (STB) o del protoclo diseqc? Ya sea por el consumo (mA) o por los tiempos mí­nimos de espera entre comando y comando especificados en el protocolo...
Porque de lograrse una mayor velocidad en el posicionamiento también serí­a otra gran ventaja a tener en cuenta.
Lo bueno también de este software es que tal vez al menos se pueda programar que entre satélite y satélite siempre se mueva a velocidad de 18v, es decir, se conmute a polaridad H (18v), se posicione y luego regrese a la polaridad requerida (H o V) por el usuario.

La primer limitación es el sistema mismo, en DVB se trabaja con 13 y 18 volts solamente (aunque leí­ que en japón utilizan un sistema con 24v), la segunda limitación es el voltaje que pueden entregar los STB y la tercer limitación está en el motor que tiene protección por alto voltaje; por consiguiente, no se puede mover mas rápido

Pero lo que sí­ se puede hacer es decirle via comando diseqc que utilice 18v antes de empezar a moverse, consultar el estado del motor y cuando llegó a su posición enviarle comandos para que cambie al TP que corresponda. Ahí­ ganamos tiempo, bah! en realidad optimizamos...
En el caso de que el TP sea Horizontal o Left, evitar este paso para ahorar unas milésimas de segundos. Aunque hay que tener cuidado con los STB que devuelven timeouts muy rápidos porque marcarí­a sin señal u obligarí­a a reenviar comandos.

Las respuestas del motor por protocolo no superan (o no se deben esperar) mas allá de los 150ms (una décima y media de segundo, ajustable por parámetro), con lo cual el tiempo de demora en gestionar esos comandos realmente no es notorio teniendo en cuenta que los motores puden demorar hasta 65 segundos en recorrer todo el arco ( mi motor se mueve a 2.5°/seg a 18v con 160° para recorrer)

La verdad es que el protocolo Diseqc tiene mucho para sacarle el jugo al máximo. Ojalá todos los softwares lo implementes de forma completa porque no es imposible usar por ejemplo un motor y un diseqc al mismo tiempo.

Muy Bueno Sergio !!!

Estas realizaciones me alegran la mañana en la oficina.-

Estaremos atentos a los progresos del desarrollo y su publicación.-

Estos dias estoy invirtiendo mucho tiempo con el motor DiseqC, porque uso el Openbox para todas las pruebas y resulta que muchos Firm. tienen diferencias y Bugs. en el manejo del motor, para colmo el firm Holandes del Premium HD que estoy usando es MUY chucaro a la hora de mover el motor y se queda "Idle".-

Este "Hobby" demanda mucho tiempo

Gracias lasmotos!
Y es cierto, este hobbye demanda mucho tiempo, pero qué lindo que es cuando se dispone de tiempo para dedicarle

Vos sabés que una de las cosas que siempre me llamó la atención es la manera diferente en que los programas manejan los diseqc y eso que tengo vistos varios muchos, tanto para linux como para windows... Grandes programas que solo gestionan mini diseqc (2x1) o solo 4x1, muchos grandes desperdicios porque he visto gente decir "esto no me sirve" solo por el hecho de no tener soporte completo para diseqc y hoy habiendo visto lo que vi, realmente no entiendo porqué esto es así­...

Sí¬ y a eso sumale el diferente manejo de los motores DiseqC entre los distintos fabricantes de receptores Linux y No Linux.-

Recuerdo hace algunos años cuando trabajaba en informática médica, los fabricantes anunciaban la compatibilidad para el intercambio de información entre equipos pero a la hora de implementar te encontrabas que cada fabricante le agregaba, quitaba o modificaba algo al standard para asegurarse el software propietario, creo que eso algo ha cambiado en la actualidad, pero fue muy dificil entonces.-

Te felicito, amigo, veo que lo lograste!!!!!!!