Lista de mejoras para estudiar su inclusión en Maroc:

• Guardar la gráfica de interpolación en formato jpeg
  
• Verificar la entrada de los datos de configuración para evitar errores
  
• Utilizar una base de datos para acceder en todo momento a las lecturas realizadas de cualquier ubicación
  
• Importar lecturas de un fichero excel ya generado
  
• Interfaz inalámbrico (bluetooth o wifi) en la montura
  
• Hacer que la montura se comunique con el SQM directamente para necesitar sólo una conexión entre PC y maroc.
  
• Migrar electrónica a arduino !!!
  
• Migrar aplicación a android !!!
  

http://arduino.cc/it/Main/ArduinoMotorShieldR3
Y esto es arduino con un error grave :dice que controla un motor pap unipolar !IMPOSIBLE¡
con un l298 ,deberia de decir bipolar de 2Amps
http://www.ardumania.es/ardutienda/es/80-motor-shield.html
y mas
http://www.ardumania.es/ardutienda/es/arduino/61-arduino-bluetooth.html
el gran pegote:Viene con bootloader para programarlo sin necesidad de ningún programador externo.
Esto es el ICSP (in circuit serial program )
Datos del fabricante del l298 ver pagina 8/14: http://www.datasheetcatalog.org/datasheet/SGSThomsonMicroelectronics/mXrqqxz.pdf
Es decir que Arduino utiliza los mismos H-drive que nosotros ,que casualidad ¡
Ojo que lo que quiero demostrar es que no son todo flores en arduino

Esta noche prometo volver a la carga ,como buena mosca cojonera.
Pero os digo que ahora mismo ya estaria lista la parte de hardware con Arduino ,cosa que no es nada desdeñable(salvo algunas pifias que ya os comentare como buena mosca)

carduelis spinus escribió:

Esta noche prometo volver a la carga ,como buena mosca cojonera.
Pero os digo que ahora mismo ya estaria lista la parte de hardware con Arduino ,cosa que no es nada desdeñable(salvo algunas pifias que ya os comentare como buena mosca)

Ey, máquina que lo del arduino era una propuesta... Aunque por mí estupendo, lo hablamos el sábado.

No Fernand no voy con mala vista ,solo quiero poner claro que arduino tiene sus fallas y correcciones que habria que hacer .
Ademas esto ya nos sirve para ir teniendo referencias de las placas de arduino que necesitamos
Y luego os cuento unos cortes de pistas que habria que hacer en las placas de potencia de los motores (una por motor) .Ademas del tema de alimentacion de la placa de control(funciona con 5.5V para el micro y 3.3V para el blue)
EN definitiva lo que veo es que arduino no tiene implementada las alimentaciones en sus placas y hay que crearlas externamente
Lo que si ocurre es como siempre dicho que arduino resta creatividad y merma estudio

carduelis spinus escribió:

e
Lo que si ocurre es como siempre dicho que arduino resta creatividad y merma estudio

Ahi le has dado. Esa es la definicion de Arduino, da tiempo a otras cosas pero sin saber a fondo qué estas haciendo, con sus consecuencias (tanto buenas como malas).

Creo que como ya sabes hacer la casa ladrillo a ladrillo, solo tienes que escoger "las habitaciones hechas y amuebladas" . Osea , como un carpintero que va a Ikea a comprar

Comencemos por estudiar la placa de Arduino -Bt:
http://arduino.cc/es/Guide/ArduinoBT
En principio se les olvido poner una proteccion contra inversion de polaridad(maroc si esta preparado para esto ,al menos su placa de control)
A continuacion se les pasa implementar la alimentacion de la placa (maroc soporta 32V en control y 46 V en la etapa de potencia .Soportarian este voltaje los motores ? Si)
No intenteis cambiar el microcontrolador Atmega (se les paso poner un zocalo) ,aunque al ser smd el zocalo no valdria de nada y si es que existe .Ademas olvidan que existen metodos para desoldar componentes smd en manos expertas.
Con maroc mientras mantengamos la misma disposicion de pines incluso podriamos migrar a otros
intercambiando ademas el Xtal(Cuarzo) de 4Mhz a 20 Mhz(lleva tambien zocalo, aunque esto no es del todo recomendable)
Y ahora le toca al Blue :como que no puedo cambiar la configuracion de 115200 Bauds?
tendriamos que recordar los comandos at o indagar en la pagina de CSR Bluecore
En fin hasta aqui teneis donde indagar ,recordad que antes de empezar con MAROC estaba liado en solitario con un proyecto de pasar todos los componentes de nuestros telescopios y monturas a Blue
y al menos me quedo claro el BlueCore 4 y sus comandos AT
Despues de esta parrafada quiero dejar claro que no soy enemigo de nada,solamente quiero exponer que otra vision del tema (con mas curro evidentemente)
Agur

Por si no teniamos bastante:
http://datasheet.electronicafacil.net/CSR/BC41B143A07.pdf
Y con postre ,copa y puro mirad la pagina 83/97 del anterior pdf

Sin entrar a fondo en el tema de arduino, que estoy bastante verde, creo que la decisión importante a tomar es si le damos mayor funcionalidad a la montura.

Me gusta la idea de que sea la montura la que se conecte al sqm para enviar y recibir las peticiones de lecturas

Si además hacemos que el interfaz entre la montura y el pc sea inalámbrico...

Pero el proyecto está recién lanzado. Demos un tiempo a que repose a ver qué ideas y necesidades surgen.

Como mejora, sea de la forma que sea (como dice fernando, solo la montura se conecta al PC, o por bluetooth), el eliminar el cable del SQM dando vueltas, para mi gusto, es el siguiente paso.

Tambien tienes razón Fernando en que es momento de disfrutar del trabajo que se ha hecho. La comodidad de lectura de oscuridad es tal que puede haber juego para mucho (no hace falta que sea solo unos minutos de medida, susituyendo a un humano, ya que puede quedarse mucho tiempo haciendo un trabajo, que para un humano pasando frio, seria tan tedioso que es impensable dicha posibilidad)

Correcto Arturo, y además un tema que Paco Espartero nos comentó y que también es una ventaja del MAROC, aunque no hubieramos caido en ella: es muy importante la estabilidad en la temperatura de trabajo del SQM y, por esto, las lecturas manuales bien hechas han de estar espaciadas en el tiempo y hechas con guantes para que la temperatura de la mano no caliente el SQM. El MAROC puede hacer cientos de mediciones con una temperatura estable ya que no tiene contacto con mano alguna.
Otra cosa, Arduino quizás no sea lo mejor pero abre nuevas posibilidades y compatibilidades. Y, hablando de esto último, Arturo, no me acuerdo del protocolo estandar de control remoto que el segundo ponente nos propuso para aplicar al MAROC. ¿Puedes decirnos cual es?

Edito: Dioni ya había hablado del tema de la temperatura por otro lado pero no lo había leido aún.

Hasta pronto.

JJ escribió:

Otra cosa, Arduino quizás no sea lo mejor pero abre nuevas posibilidades y compatibilidades. Y, hablando de esto último, Arturo, no me acuerdo del protocolo estandar de control remoto que el segundo ponente nos propuso para aplicar al MAROC. ¿Puedes decirnos cual es?

Hasta pronto.

Protocolo INDI

http://docs.kde.org/stable/es/kdeedu/kstars/indi-faq.html

Dicho queda.

Gracias Arturo.

Lo que recuerdo que nos comentaron, fue que el sofware usado por Fernando era ideal, por ser Java, y que sirve para cualquier plataforma. A ver que sale por este lado. Ya no hablaríamos solo del Maroc.

Arturo escribió:

JJ escribió:

Otra cosa, Arduino quizás no sea lo mejor pero abre nuevas posibilidades y compatibilidades. Y, hablando de esto último, Arturo, no me acuerdo del protocolo estandar de control remoto que el segundo ponente nos propuso para aplicar al MAROC. ¿Puedes decirnos cual es?

Hasta pronto.

Protocolo INDI

http://docs.kde.org/stable/es/kdeedu/kstars/indi-faq.html

Más información sobre INDI:
http://indilib.org/index.php?title=INDI_Concepts
http://www.clearskyinstitute.com/INDI/INDI.pdf

El reto aquí sería implementar el protocolo en el micro de la montura. Tiene que tener potencia para leer y generar datos en formato xml. Habria que mirar alguna dispositivo que lo implemente para averiguar que micro/memoria usa.

La verdad es que con arduino nos ahorramos mucho trabajo ,incluso podemos mejorarlo.
Id tomando nota de las correcciones que habria que hacer(son minimas)
Otra os la pongo mañana ,esta tarde voy a un curso a Cadiz ,se trata de que en la placa de potencia del motor el L298 no tiene disipador de calor y dudo de que llegue a los 2 Amp por bobina sin disipador (Maroc los tiene)
Mañana terminare de estudiar la placa arduino-bl y luego las potencias y vemos los cambios que habria que hacer pero os anticipo que son minimos y mejorables
Al final me veo mejorando el Arduino

carduelis spinus escribió:

Al final me veo mejorando el Arduino

Fernando, yo propondría otra mejora en el software, a ver que te parece:
Como tenemos la posibilidad de parametrizar y llegar a más resolución de la que pide el protocolo de NIXNOX (por ejemplo medir grado a grado tanto en horizontal como en vertical), ¿Sería posible que el gráfico en el que van apareciendo los puntos donde se va haciendo la medición (el que parece una diana) fuera dinámico para representar todos los puntos. Digo esto porque me parece que los lugares de medición están predefinidos. Corrígeme si me equivoco.

Hasta pronto.

JJ escribió:

Fernando, yo propondría otra mejora en el software, a ver que te parece:
Como tenemos la posibilidad de parametrizar y llegar a más resolución de la que pide el protocolo de NIXNOX (por ejemplo medir grado a grado tanto en horizontal como en vertical), ¿Sería posible que el gráfico en el que van apareciendo los puntos donde se va haciendo la medición (el que parece una diana) fuera dinámico para representar todos los puntos. Digo esto porque me parece que los lugares de medición están predefinidos. Corrígeme si me equivoco.

Hasta pronto.

JJ, la gráfica "diana" es dinámica. Puedes comprobar cómo queda si activas el modo simulación. Lo que tengo que probar es si el fichero excel generado es correcto cuando cambia el número de lecturas. Creo que sí pero no lo he testeado. Esta tarde lo pruebo en casa.
Por otro lado también tendría que poner algunos chequeos respecto a los parámetros introducidos (valores negativos, numero de lecturas que no sean fracciones, altura máxima > altura mínima... etc) porque ahora suponemos que se definen valores sensatos.

En cuanto a lo que dice JJ, de hacerlo grado a grado, yo lo testeé (hace ya mucho) y con 48 divisiones en azimut y unas 24 en altitud , hacía un recorrido pero al final se quedaba pillado en las 12 ultimas medidas repitiendolas como en un bucle. Eso si, habia llenado de puntos casi, el medio círculo. Como bien dices Fernando, se hizo pensando en el protocolo, y esto es irse muy lejos del protocolo ya.
Si se hiciera como dice JJ, no habría casi ni que interpolar con el Kigrin...

No se si lo que dijo JJ es sobre que los puntos "tuviesen su color" en la toma de datos. No se si a eso se refería con puntos dinámicos. Porque que aparezcan mas puntos (los que quieras hasta cierto limite), si que lo hace.

Creo que para medir tantos puntos hay que "colimar" la medida del SQM con un tubito (comos los oscuros de los telescopios antes de llegar a la salida hacia el ocular) para que solo tome medida de esa porción del cielo(más pequeña que 20º , como indica el manual del SQM). De todas maneras eso creo que los de NIXNOX , nos pueden aclarar las ideas como estas, porque lo mismo he dicho una barbaridad

Perfectamen aclarado por los dos. Ahora recuerdo que cambiando los parámetros para pocas medidas la rejilla de puntos era solo de los que tenía que hacer. Aclarado.
Por otra parte, Arturo, tienes razón en que habría que limitar el "campo de visión" del SQM en caso de intentar mediciones más apretadas. De todas formas, como dices, ha de ser la SEA quién, conocie las limitaciones de los SQM, marque hasta donde puede ser práctico juntar las mediciones.

Hasta pronto.

El SQM-LU que utiliza MAROC tiene una respuesta espacial con anchura a media altura de 10 grados, es decir que registra cielo en unos 20 grados aproximadamente.

Si se muestrea con una red demasiado cerrada (cada 5 grados, por ejemplo) estamos viendo el mismo trozo de cielo en varias medidas sucesivas de forma que no mejoraremos la resolución del mapa sino que lo suavizaremos.

Si se coloca un tubo que haga de diafragma de apertura perdemos señal ya que el detector ve menos cielo y por lo tanto se registran menos fotones por unidad de tiempo. Podría funcionar en cielos brillantes (calibrando el SQM a la nueva apertura) pero no tendría suficiente flujo en los sitios oscuros. El SQM no integra sino que mide flujo que se transforma en frecuencia de la señal y trabaja al límite en cielos muy oscuros necesitando en ellos más tiempo para tener una estadística suficiente.

Mi recomendación es no usar diafragma y muestrear con una red más completa que la del protocolo NixNox pero en posiciones que no solapen o solapen poco. Por ejemplo cada 15 grados en altura 20, cada 20 grados en altura 40, cada 30 grados en altura 60 etc. Sería interesante pintarlo en un circulo. Tampoco es necesario (e incluso sería recomendable) que todas las medidas estén en el mismo VERTICAL (Circulos máximos que pasan por el Cenit/Nadir y perpendiculares al horizonte) o ALMICANTARAT (Circulos menores, paralelos al horizonte)

Jaime

[img][/img]


ESto podria ser una solucion para el cable del motor de Alt

Dos cosas. Por un lado lo que propone Jaime es muy ingenioso, aunque necesitaría una modificación en profundidad del software, a no ser que optáramos por un mapa de medición fijo (el que propone Jaime) además del parametrizado actual. Lo podemos hablar en la reunión de está noche.
La segunda cosa a comentar es el motor que nos has puesto en las fotos Dioni. Es un sistema de conexión que nos vendría de lujo ya que por mucho bluetooth que pongamos, los motores siempre habrá que alimentarlos.

Hasta pronto.

Jué que bueno! Dioni. Como dice JJ , eso nos quita el problema de los cables de Altitud, cosa que siempre harían falta para el motor...

en cuanto al cable que gria con el motor del Azimut... porque la corona esta abajo en vez de arriba (lo mismo estoy equivocado)... ¿Es latoso cabiarla y que el motor quede fijo abajo y que la corona sea la que gire?