TEMA: kilohertzios por revolucion de dial

hola amigos,

gracias por todos y cada uno de vuestros comentarios
me ha hecho mejorar la comprension del problema

estoy valorando usar uno de estos encoders

www.sdr-kits.net/Webshop/products.php?77&cPath=6

The ebay item id given is invalid, no result has been sent

este kit, incluso sugiere como modificar un encoder "barato"
sdr-kits.net/PAOKLT/PA0KLT_Manual.pdf

respecto al numero de pulsos, efectivamente, tener muchos
pulsos por vuelta implica una velocidad de lectura del encoder
superior (mi idea era usar pooling, no interrupciones)

como una rutina que acelere el salto de frecuencia por pulso
es necesaria, el numero de pulsos por vuelta no es importante
y en eso se ha basado el kenwood ts50

PREGUNTA

conoceis algún criterio para implementar esta aceleración?
he buscado sin exito en internet alguna idea al respecto

creo que la velocidad tendria que cambiar entre

2.5khz/vuelta (1 canal de voz por vuelta)
hasta
25khz/vuelta (la banda de 40metros en 8 vueltas=TS830)

no he visto ningun equipo con saltos mas grandes

250khz/vuelta
2500khz/vuelta (con 8 vueltas de dial se recorre toda la onda corta)

73 eduardo

W8TEE publicó en el boletín del QRP ARCI un artículo sobre el tema, incluyendo código fuente para Arduino.
Tengo un zip, pero no entra por grande.
un saludo
jon, ea2sn

La solución es dependiente del HW y la forma de hacer la conversión giro a orden de subir/bajar.
A fin de cuentas para saber si el giro es rápido o lento se necesita una base de tiempo con la que comparar.
Si dispones de temporizador HW o SW con una granularidad suficiente como para medir el tiempo entre pulsos entonces podrás tomar la decisión.
Piensa que 16 pulsos por revolución son 22,5°, 32 pulsos 11,25° y así sucesivamente. Si el número de pulsos es bajo la sensación es tosca pero si es muy alto la separación entre pulsos puede ser menor a 1 ms y por tanto el polling debería ser menor a 0,5 ms para asegurarte de no perder un estado. Esta frecuencia tan alta (2000 Hz) requiere de un procesador potente para muestrear y hacer cálculos...
Aunque te parezca una exageración 1ms entre pulsos solo tienes que poner el osciloscopio al encoder y darle un golpe al botón para hacer un avance rápido y veras lo que digo.
Además para cada muestreo tienes que asegurarte que no te encuentras en un rebote, cosa que con un encoder caro no sucede.
Una solucion para ver la velocidad es pasar la rotación a tensión mediante un filtro pasoalto de prenfasis y si el muestreo es a velocidad "constante" un filtro FIR te puede valer, pero claro esto es mas tiempo de CPU.

En el PIC yo uso interrupciones por flanco en ambos bits. Cada dibit leído una vez filtrado con el sw antirebote adaptativo se encola en una FIFO suficientemente larga como para no perder pulsos. Cuando haya tiempo se analiza la secuencia y se hacen los cálculos necesarios y aunque el uP esté liado con esta u otra tarea, los pulsos que van llegando del encoder se siguen almacenando...
Si el uP dispone de RTOS mucho mejor, pero si el encoder no se gestiona 100% por HW para que el SW sea menos crítico no queda otra que optimizar mediante interrupciones e incluso ensamblador. El polling puede funcionar bien si solo se dedica al muestreo y poco más, nada de tareas "apropiativas" largas y cosas así.
Y no me enrrollo más. Uf