Hola querido lector,
esta entrada es pequeña, prometido.
Como sabrás, el integrado DS1307 es un reloj RTC (Real Time Clock) muy popular entre la comunidad arduino, dada la facilidad de manejo y el amplio soporte, y cuando digo amplio, es AMPLIO, porque hay librerías a carretadas, pero en todas echo algo en falta: poder usar la señal de reloj.
Si te has leído el datasheet del DS1307, sabrás que puede generar una onda cuadrada con un pulso de duración determinada (para más detalles mira la página 5).
En concreto, me voy a centrar en el pulso de 1hz: 1 segundo.
¿Por qué? Porque muchas veces hace falta un contador preciso.
El caso más común es implementar un reloj usando arduino, y cuando digo arduino, digo cualquier otro microcontrolador.
La gracia de usar este pulso de reloj es la estabilidad del mismo, asi como manejarlo en otra clase de circuitos digitales, sin necesidad de utilizar un microcontrolador.
Activar la señal de reloj es muy fácil desde arduino con este código:
Wire.beginTransmission(B1101000);
Wire.write((byte)0x07);
Wire.write((byte)B10010000);
Wire.endTransmission();
Sólo hace falta ejecutarlo una vez, salvo que se retire la pila de botón y se pierda toda la configuración, en cuyo caso, hay que volver a ejecutar el código.
¿Manejo? Fácil: el pin 7 del DS1307 tiene la salida de la señal.
En arduino, puedes conectarlo al pin 2 o 3 (interrupción 0 y 1 respectivamente), para manejarlo con una interrupción.
No voy a entrar en muchos detalles, porque está bien documentado, pero un código de ejemplo sería algo asi:
bool pulso_reloj;
void recibe_pulso() {
// El código a ejecutar en una interrupción debe ser mínimo
pulso_reloj = true;
}
void setup() {
Serial.begin(9600);
pulso_reloj = false;
attachInterrupt(0, recibe_pulso, RISING);
}
void loop() {
if (pulso_reloj) {
Serial.println("Pulso de reloj");
pulso_reloj = false;
}
}
Espero que te resulte útil.
¡Hasta la próxima!
Mostrando entradas con la etiqueta desarrollo. Mostrar todas las entradas
Mostrando entradas con la etiqueta desarrollo. Mostrar todas las entradas
lunes, 16 de enero de 2012
martes, 3 de enero de 2012
Intervalómetro DIY - Prototipo
Hola querido lector,
prometo ser breve en este post, lo justo para comentarte que el primer prototipo está montado, a falta de solucionar el enganche del sensor infrarrojo en la cámara.
Te pido que no seas muy duro con las críticas, porque esta es la primera placa que monto, y no está tan depurada como podría, pero funciona, y bien, ahí es nada.
He procurado cuidar tanto como ha sido posible el consumo, dado que es un dispositivo a usar durante varias horas a lo largo de la noche.
Recuerda que hablamos de componentes que trabajan a 5V, luego implica tener una fuente de alimentación acorde.
En mi caso, decidí usar un portapilas con elevador de tensión incorporado, con resultados francamente buenos.
Relativo al consumo, como decía, intenté cuidarlo al máximo, tanto como permiten los componentes usados:
49mA con retroiluminación
10.7 mA sin retroiluminación
Cuando hablo de retroiluminación, me refiero al display LCD, para lo cual puse un interruptor, de modo que se pueda encender y apagar, para reducir el consumo mientras discurra la cuenta atrás.
Insisto en lo comentado anteriormente: es la primera placa que armo, y por tanto, se pueden mejorar mil aspectos, como desconectar la retroiluminación automaticamente al comenzar la cuenta atrás, y un largo etc, pero de momento quiero centrarme en tener un aparato funcional.
Recuerda, querido lector, que el código fuente, y los esquemas, están disponibles en github:
https://github.com/cbolanos79/Nikon-Intervalometer
El fichero placa_topos.fz tiene el esquema y los componentes en formato Fritzing (te recomiendo descargar la última versión).
¡Hasta la próxima!
prometo ser breve en este post, lo justo para comentarte que el primer prototipo está montado, a falta de solucionar el enganche del sensor infrarrojo en la cámara.
Te pido que no seas muy duro con las críticas, porque esta es la primera placa que monto, y no está tan depurada como podría, pero funciona, y bien, ahí es nada.
He procurado cuidar tanto como ha sido posible el consumo, dado que es un dispositivo a usar durante varias horas a lo largo de la noche.Recuerda que hablamos de componentes que trabajan a 5V, luego implica tener una fuente de alimentación acorde.
En mi caso, decidí usar un portapilas con elevador de tensión incorporado, con resultados francamente buenos.
Relativo al consumo, como decía, intenté cuidarlo al máximo, tanto como permiten los componentes usados:
49mA con retroiluminación
10.7 mA sin retroiluminación
Cuando hablo de retroiluminación, me refiero al display LCD, para lo cual puse un interruptor, de modo que se pueda encender y apagar, para reducir el consumo mientras discurra la cuenta atrás.
Insisto en lo comentado anteriormente: es la primera placa que armo, y por tanto, se pueden mejorar mil aspectos, como desconectar la retroiluminación automaticamente al comenzar la cuenta atrás, y un largo etc, pero de momento quiero centrarme en tener un aparato funcional.
Recuerda, querido lector, que el código fuente, y los esquemas, están disponibles en github:
https://github.com/cbolanos79/Nikon-Intervalometer
El fichero placa_topos.fz tiene el esquema y los componentes en formato Fritzing (te recomiendo descargar la última versión).
¡Hasta la próxima!
miércoles, 7 de diciembre de 2011
Intervalómetro DIY - Requisitos y software
Hola querido lector,
si recuerdas, hace tiempo comenté la idea de hacer un intervalómetro/circumpolómetro, pero quedó en el cajón de los proyectos pendientes, por varios motivos.
Como hace frío por estas fechas, y apenas hay bichos para macrear, o se esconden cuando yo llego, he retomado el trabajo con paisajes. Pero no todos los paisajes son diurnos, y tengo muy abandonada la fotografía nocturna, excusa ideal para retomar el proyecto que ocupa estas líneas.
Aunque el software estará centrado, inicialmente, en fotografía nocturna, la puerta queda abierta a las necesidades que surjan: intervalómetro puro y duro, circumpolómetro (estar varias horas dale que te pego al mando aburre), y un largo etc.
No lo comento explicitamente, pero este artículo presupone algunos conceptos sobre el manejo de una cámara reflex en modo manual, y la fotografía nocturna.
Si no has manejado esta disciplina, te recomiendo visitar la web de Noctámbulos, donde encontrarás amplia información.
Requisitos.
- Facilidad de uso: primordial porque no tiene sentido volverse loco navegando por menús, ni tocando mil botones. Todas las funciones deben estar en una sola pantalla.
- Simplicidad y bajo coste: no sólo es una cuestión económica, sino de circuitería: cuanto menos componentes, más simple de montar. No es lo mismo usar pilas, que una batería li-po, por ejemplo.
- Bajo consumo: de nada sirve tener un aparato estupendo si se queda fuera de servicio a mitad de una foto. Como todo, hay que buscar un compromiso, dependiendo de los componentes usados, y dependiendo de la batería.
- Batería: debe tener larga duración, aunque el consumo sea poco, y fácil de recargar.
- Nada intrusivo: si hay algo molesto en la fotografía nocturna, es que alguien encienda una luz, o quedarte ciego por un fogonazo del display de la cámara. El intervalómetro no debe violar ninguna de estas reglas.
Acorde a estos requisitos, he decidido usar un display LCD de 16x2 líneas (sumamente común), y un arduino como cerebro.
El control de la cámara lo haré con un diodo led infrarrojo, a modo de mando a distancia.
¿Por qué hacerlo así? Esta es una cuestión muy particular: mi cámara, una Nikon D40, no tiene otra opción para dispararla en remoto. Así de simple.
Como por ahora voy a centrarme en un primer prototipo funcional, voy a dejar de lado el asunto de la batería, hasta analizar el consumo del circuito, y las dimensiones que pueda tener una vez ensamblado.
Sí puedo adelantar que voy a usar un display lcd de color rojo, el más discreto y cómodo que he visto por ahora para usar de noche.
Interfaz.
Dejando de lado cuestiones tan específicas, lo primero es lo primero: el interfaz.
Tal como dije anteriormente, debe ser muy simple de manejar, esta es una cuestión prioritaria.
¿Por qué? Si nunca has hecho fotografía nocturna, querido lector, imagina estar en un lugar recóndito a las tantas de la mañana, pasando frío, equipo a cuestas... lo último que necesitas es pelearte con un aparato, o tener que echar mano del móvil para calcular datos.
Pues bien: he optado por usar dos pantallas para el modo de fotografía nocturna.
Una primera se encargará de recoger los datos y procesarlos, y una segunda, de la cuenta atrás.
Primera pantalla: recogida y procesado de datos.
I1600 f5.6 1s
I 200 f8 16s
La primera línea son los datos de entrada (exposición calculada en la cámara con el mayor ISO y apertura de diafragma).
La segunda línea son los datos para calcular la exposición final.
Muy sencillito, ¿verdad?
En cuanto al manejo, el planteamiento inicial, y recalco, inicial, es moverse por los diferentes parámetros usando botones:
- select: entra en el modo de navegación (se mueve por los diversos parámetros), y también en el modo de edición (cambiar el valor de algún parámetro).
- cancel: sale del modo de navegación y edición.
- +: se mueve hacia la derecha en el modo de navegación, y aumenta el valor de un parámetro.
- -: se mueve hacia la izquierda en el modo de navegación, y decrementa el valor de un parámetro.
Insisto: es un planteamiento inicial, un prototipo.
Con el uso, iré viendo si se puede simplificar, no tanto por usar más o menos botones, sino por la agilidad en el manejo.
Por supuesto, este es el menú para recoger los datos.
Una vez recogidos los datos, hay que procesar la información, calcular el tiempo final de exposición (hay Recuerda: el intervalómetro va a funcionar como un mando a distancia que dispara el obturador, no tiene capacidad de manejar ninguna otra función.
Segunda pantalla: cuenta atrás.
Tan simple como dos mensajes.
Primero:
Cuenta atrás
Segundo:
9999s
El segundo mensaje se repetirá hasta agotar la cuenta atrás.
Un detalle importante: la cuenta atrás va en segundos. Parece obvio, pero no lo es tanto como aparenta.
Software.
Teniendo claros los requisitos y el interfaz, desarrollar el software es cuestión de pensar un poco, e implementarlo.
Según el hardware empleado, habrán algunas ligeras variaciones, pero siempre teniendo en mente la capacidad de ampliar funciones con poco trabajo.
No me voy a extender en detalles, porque el código fuente está en un repositorio público, y dado el amplio soporte de Arduino por parte de la comunidad, abundan los ejemplos y librerías para manejar el hardware.
Para los más curiosos, decir que tanto el software como los esquemas los voy a liberar bajo la licencia open source más liberal que encuentre.
Repositorio y primer prototipo.
Código, esquemáticos y demás información útil la puedes encontrar en https://github.com/cbolanos79/Nikon-Intervalometer
En cuanto al primer prototipo, lo puedes ver funcionando en http://youtu.be/BsPX2Q66zIs
La siguiente entrada tratará el montaje del hardware, y pruebas reales.
¡Hasta la próxima!
Como hace frío por estas fechas, y apenas hay bichos para macrear, o se esconden cuando yo llego, he retomado el trabajo con paisajes. Pero no todos los paisajes son diurnos, y tengo muy abandonada la fotografía nocturna, excusa ideal para retomar el proyecto que ocupa estas líneas.
Aunque el software estará centrado, inicialmente, en fotografía nocturna, la puerta queda abierta a las necesidades que surjan: intervalómetro puro y duro, circumpolómetro (estar varias horas dale que te pego al mando aburre), y un largo etc.
No lo comento explicitamente, pero este artículo presupone algunos conceptos sobre el manejo de una cámara reflex en modo manual, y la fotografía nocturna.
Si no has manejado esta disciplina, te recomiendo visitar la web de Noctámbulos, donde encontrarás amplia información.
Requisitos.
- Facilidad de uso: primordial porque no tiene sentido volverse loco navegando por menús, ni tocando mil botones. Todas las funciones deben estar en una sola pantalla.
- Simplicidad y bajo coste: no sólo es una cuestión económica, sino de circuitería: cuanto menos componentes, más simple de montar. No es lo mismo usar pilas, que una batería li-po, por ejemplo.
- Bajo consumo: de nada sirve tener un aparato estupendo si se queda fuera de servicio a mitad de una foto. Como todo, hay que buscar un compromiso, dependiendo de los componentes usados, y dependiendo de la batería.
- Batería: debe tener larga duración, aunque el consumo sea poco, y fácil de recargar.
- Nada intrusivo: si hay algo molesto en la fotografía nocturna, es que alguien encienda una luz, o quedarte ciego por un fogonazo del display de la cámara. El intervalómetro no debe violar ninguna de estas reglas.
Acorde a estos requisitos, he decidido usar un display LCD de 16x2 líneas (sumamente común), y un arduino como cerebro.
El control de la cámara lo haré con un diodo led infrarrojo, a modo de mando a distancia.
¿Por qué hacerlo así? Esta es una cuestión muy particular: mi cámara, una Nikon D40, no tiene otra opción para dispararla en remoto. Así de simple.
Como por ahora voy a centrarme en un primer prototipo funcional, voy a dejar de lado el asunto de la batería, hasta analizar el consumo del circuito, y las dimensiones que pueda tener una vez ensamblado.
Sí puedo adelantar que voy a usar un display lcd de color rojo, el más discreto y cómodo que he visto por ahora para usar de noche.
Interfaz.
Dejando de lado cuestiones tan específicas, lo primero es lo primero: el interfaz.
Tal como dije anteriormente, debe ser muy simple de manejar, esta es una cuestión prioritaria.
¿Por qué? Si nunca has hecho fotografía nocturna, querido lector, imagina estar en un lugar recóndito a las tantas de la mañana, pasando frío, equipo a cuestas... lo último que necesitas es pelearte con un aparato, o tener que echar mano del móvil para calcular datos.
Pues bien: he optado por usar dos pantallas para el modo de fotografía nocturna.
Una primera se encargará de recoger los datos y procesarlos, y una segunda, de la cuenta atrás.
Primera pantalla: recogida y procesado de datos.
I1600 f5.6 1s
I 200 f8 16s
La primera línea son los datos de entrada (exposición calculada en la cámara con el mayor ISO y apertura de diafragma).
La segunda línea son los datos para calcular la exposición final.
Muy sencillito, ¿verdad?
En cuanto al manejo, el planteamiento inicial, y recalco, inicial, es moverse por los diferentes parámetros usando botones:
- select: entra en el modo de navegación (se mueve por los diversos parámetros), y también en el modo de edición (cambiar el valor de algún parámetro).
- cancel: sale del modo de navegación y edición.
- +: se mueve hacia la derecha en el modo de navegación, y aumenta el valor de un parámetro.
- -: se mueve hacia la izquierda en el modo de navegación, y decrementa el valor de un parámetro.
Insisto: es un planteamiento inicial, un prototipo.
Con el uso, iré viendo si se puede simplificar, no tanto por usar más o menos botones, sino por la agilidad en el manejo.
Por supuesto, este es el menú para recoger los datos.
Una vez recogidos los datos, hay que procesar la información, calcular el tiempo final de exposición (hay Recuerda: el intervalómetro va a funcionar como un mando a distancia que dispara el obturador, no tiene capacidad de manejar ninguna otra función.
Segunda pantalla: cuenta atrás.
Tan simple como dos mensajes.
Primero:
Cuenta atrás
Segundo:
9999s
El segundo mensaje se repetirá hasta agotar la cuenta atrás.
Un detalle importante: la cuenta atrás va en segundos. Parece obvio, pero no lo es tanto como aparenta.
Software.
Según el hardware empleado, habrán algunas ligeras variaciones, pero siempre teniendo en mente la capacidad de ampliar funciones con poco trabajo.
No me voy a extender en detalles, porque el código fuente está en un repositorio público, y dado el amplio soporte de Arduino por parte de la comunidad, abundan los ejemplos y librerías para manejar el hardware.
Para los más curiosos, decir que tanto el software como los esquemas los voy a liberar bajo la licencia open source más liberal que encuentre.
Repositorio y primer prototipo.
Código, esquemáticos y demás información útil la puedes encontrar en https://github.com/cbolanos79/Nikon-Intervalometer
En cuanto al primer prototipo, lo puedes ver funcionando en http://youtu.be/BsPX2Q66zIs
La siguiente entrada tratará el montaje del hardware, y pruebas reales.
¡Hasta la próxima!
martes, 6 de septiembre de 2011
Facebook y los cambios constantes
Hola querido lector,
hoy me voy a permitir el lujo de hablar sobre esta gran red social, y digo gran, por el número de usuarios y la comunidad, porque en otros aspectos, bajo mi experiencia como usuario y desarrollador, cada vez languidece más.
Por una parte, hace pocos días advertí un cambio a la hora de visualizar imágenes: en vez de mostrar un popup (cuadro emergente) con fondo negro, como venía siendo habitual, se muestra uno con fondo blanco.
¿Qué relevancia tiene? Pues mucha: el fondo blanco distrae, el enlace para cerrarlo no es suficientemente visible, las flechas de navegación tampoco, y no favorece tampoco a las imágenes.
Si no, está el ejemplo de flickr: cuando realizó el último cambio de interfaz, añadió la posibilidad de ver las fotos sobre un fondo negro, y vaya si realza la imagen y ayuda a aislarla del entorno, porque, en definitiva, se trata de eso: centrar la atención en la imagen, sin distracciones, y realzarla.
Y esto sin hablar con los cambios en la disposición de la barra de chat, cada vez menos accesible.
Pero lo más molesto, pero realmente molesto, son los cambios en el API, y la cantidad de agujeros en la misma, algo que, personalmente, me pone nervioso: no sólo tienes que atender los requisitos de un desarrollo, sino encima, pelearte con un API mutante, que cambia sin previo aviso y no tiene el suficiente soporte, como para migrar.
Está muy bien mejorar, de hecho, debería ser una exigencia, tanto personal como profesional: la constante mejora y la excelencia, pero no a costa de dejar atrás a usuarios y desarrolladores.
Y es que nada frustra más que pegarte horas y horas indagando cómo hacer algo a base de atar cabos sueltos, buscando ejemplos (no todos usamos PHP) y haciéndolos funcionar.
Un ejemplo práctico: se me dio la necesidad de publicar en el muro de una página de Facebook, desde una aplicación en Ruby On Rails.
¿Problemas? A punta pala, como se dice en mi pueblo.
El problema radica en la arquitectura del API, y me corrija alguien si me equivoco: todas las publicaciones se hacen usando como identificador el ID de una aplicación, y un valor denominado ACCESS TOKEN, el cuál está ligado al objeto donde quieres publicar (página, aplicación, etc...).
Visto así, parece fácil, ¿cierto? Pero aún queda otro problema: ¿cómo obtienes el valor ACCESS TOKEN?
Para una aplicación es trivial: en la configuración de la misma, te viene dado, pero si quieres usar el muro de una aplicación, la cosa cambia enormemente.
A grandes rasgos: hay ejemplos, y se agradecen que existan, en stack overflow, pero pueden funcionarte (ves la ventana de Facebook pidiendo autorización para dar permisos de una aplicación sobre tu página y luego obtienes el ACCESS TOKEN), o no (obtienes el ACCESS TOKEN).
¿Solución? Usar el explorador del Graph API, poner el ID de la página para ver la información de la misma (al lado de donde pone GET), pulsar sobre "Get Access Token", ¡et voilá!: tienes el cuadro de diálogo pidiendo los permisos.
Asignas los permisos (publish_stream, manage_pages, offline_access), obtienes el ACCESS TOKEN y ¡¡maravilla!! tu aplicación postea en el muro de la página.
En esta página tienes un ejemplo de uso: http://stackoverflow.com/questions/4883699/easy-way-of-posting-on-facebook-page-not-a-profile-but-a-fanpage
Y aquí termina esta entrada, no sin antes aclarar que no comento con acritud, pero sí con ánimo de animar y mejorar una plataforma puntera, y facilitar la vida a quienes desean colaborar y crear alrededor de.
¡¡Hasta la próxima!!
hoy me voy a permitir el lujo de hablar sobre esta gran red social, y digo gran, por el número de usuarios y la comunidad, porque en otros aspectos, bajo mi experiencia como usuario y desarrollador, cada vez languidece más.
Por una parte, hace pocos días advertí un cambio a la hora de visualizar imágenes: en vez de mostrar un popup (cuadro emergente) con fondo negro, como venía siendo habitual, se muestra uno con fondo blanco.
¿Qué relevancia tiene? Pues mucha: el fondo blanco distrae, el enlace para cerrarlo no es suficientemente visible, las flechas de navegación tampoco, y no favorece tampoco a las imágenes.
Si no, está el ejemplo de flickr: cuando realizó el último cambio de interfaz, añadió la posibilidad de ver las fotos sobre un fondo negro, y vaya si realza la imagen y ayuda a aislarla del entorno, porque, en definitiva, se trata de eso: centrar la atención en la imagen, sin distracciones, y realzarla.
Y esto sin hablar con los cambios en la disposición de la barra de chat, cada vez menos accesible.
Pero lo más molesto, pero realmente molesto, son los cambios en el API, y la cantidad de agujeros en la misma, algo que, personalmente, me pone nervioso: no sólo tienes que atender los requisitos de un desarrollo, sino encima, pelearte con un API mutante, que cambia sin previo aviso y no tiene el suficiente soporte, como para migrar.
Está muy bien mejorar, de hecho, debería ser una exigencia, tanto personal como profesional: la constante mejora y la excelencia, pero no a costa de dejar atrás a usuarios y desarrolladores.
Y es que nada frustra más que pegarte horas y horas indagando cómo hacer algo a base de atar cabos sueltos, buscando ejemplos (no todos usamos PHP) y haciéndolos funcionar.
Un ejemplo práctico: se me dio la necesidad de publicar en el muro de una página de Facebook, desde una aplicación en Ruby On Rails.
¿Problemas? A punta pala, como se dice en mi pueblo.
El problema radica en la arquitectura del API, y me corrija alguien si me equivoco: todas las publicaciones se hacen usando como identificador el ID de una aplicación, y un valor denominado ACCESS TOKEN, el cuál está ligado al objeto donde quieres publicar (página, aplicación, etc...).
Visto así, parece fácil, ¿cierto? Pero aún queda otro problema: ¿cómo obtienes el valor ACCESS TOKEN?
Para una aplicación es trivial: en la configuración de la misma, te viene dado, pero si quieres usar el muro de una aplicación, la cosa cambia enormemente.
A grandes rasgos: hay ejemplos, y se agradecen que existan, en stack overflow, pero pueden funcionarte (ves la ventana de Facebook pidiendo autorización para dar permisos de una aplicación sobre tu página y luego obtienes el ACCESS TOKEN), o no (obtienes el ACCESS TOKEN).
¿Solución? Usar el explorador del Graph API, poner el ID de la página para ver la información de la misma (al lado de donde pone GET), pulsar sobre "Get Access Token", ¡et voilá!: tienes el cuadro de diálogo pidiendo los permisos.
Asignas los permisos (publish_stream, manage_pages, offline_access), obtienes el ACCESS TOKEN y ¡¡maravilla!! tu aplicación postea en el muro de la página.
En esta página tienes un ejemplo de uso: http://stackoverflow.com/questions/4883699/easy-way-of-posting-on-facebook-page-not-a-profile-but-a-fanpage
Y aquí termina esta entrada, no sin antes aclarar que no comento con acritud, pero sí con ánimo de animar y mejorar una plataforma puntera, y facilitar la vida a quienes desean colaborar y crear alrededor de.
¡¡Hasta la próxima!!
Suscribirse a:
Entradas (Atom)