Proyecto Final - CAN-SAT

Guía De Programación en BASIC

2008-12-05T15:11:00.003-02:00

Cómo último aporte al Blog y sus lectores, estamos orgullosos de anunciarles que hemos confeccionado una guía lo más completa posible para aprender a programar en BASIC. Fue desarrollada interinamente por los autores de este Blog (Matías Maravankin y Ezequiel Wajs). Consta de 57 páginas divididas y sub-dividas en las secciones que creímos pertinente dividirla. Cada explicación incluye un ejemplo a modo ilustrativo. Están también todas las programaciones desarrolladas por nosotros. Todas ellas, salvo la última, fueron probadas y resultaron eficaces.
Sin más, les dejo la portada de la Guía:

Les queremos comentar que esta guía fue hecha sin ánimo de lucro y que es enteramente producto de nuestro trabajo. No es una traducción, todo el material es original.
Por lo tanto esta guía es completamente gratuita para aquel que la necesite o desee tenerla. La guía no se encuentra en Internet ya que carecemos de un servidor ftp propio y porque deseamos hacer un seguimiento de esta, es decir, saber quienes son aquellos que piden nuestra guía.
Es por esto que aquél que la desee puede enviarme un mail a mi (Ezequiel) a ezewajs@gmail.com o a Matías a mmaravankin@gmail.com para pedirnos la guía que será enviada a la brevedad. El peso de esta es de 381Kb, por lo tanto puede ser enviada tranquilamente por e-mail. La guía posee un Menú y Bookmarks jerarquizados que permiten navegar por ella más fácilmente. Basta con clickear el título deseado en el menú para que la guía se sitúe automáticamente en la hoja deseada.

Esperamos que sea de ayuda para aquél que la solicite.
Sin más nos despedimos.

Matías Maravankin y Ezequiel Wajs

Día del Vuelo - 30/10/08

2008-11-17T13:29:00.005-02:00

Nos reunimos temprano en la escuela, para preparar los últimos detalles. Reprogramamos algunos de los PIC's cargándoles los programas hechos la noche anterior, esperando que alguno de ellos pueda efectuar el vuelo.
Luego del viaje de aproximadamente hora y media, llegamos a San Vicente donde nos reunimos junto a dos escuelas mas y distintos miembros de la ACEMA.
El predio pertenece a Guillermo Descalzo, también miembro de la ACEMA.
Ni bien llegamos armamos la carpa donde pondríamos todo nuestro instrumental.
Una vez desempacado todo lo traído del micro, presenciamos algunos lanzamientos, desde su éxito total hasta su destrucción contra el suelo.
Mas tarde, junto con Leandro Arcusin nos dispusimos a probar los programas de emergencia realizados la noche anterior.
Al principio y sin saber porque, los PIC's calentaban demasiado al conectarlos en la placa y aplicarle tensión. Es por esto que rehicimos los conexionados auxiliares (que eran cables y resistencias agregadas a ultimo momento de manera rudimentaria) con mas cuidado.
Los conexionados auxiliares consistían en cables y una resistencia que salían directamente de los ejes utilizados para la alimentación (tornillos largos de bronce que atraviesan todas las placas) e iban a algún puerto del PIC para retornar de la misma manera al otro eje.
Luego de este retoque, el programa auxiliar HPWM8 comenzó a funcionar correctamente.
La forma que utilizamos para detectar el funcionamiento, fue usar una antena creada por alumno de 4to año de electrónica que vinieron con nosotros al campo. Esta antena recibía una señal y emitía un tono de la misma frecuencia por unos auriculares. De esta forma cuando variaba la presión, variaba el sonido. Mientras mas alto estaba el cohete, mas aguda debería sonar el tono de la antena y mientras mas bajo, mas grave.
Contentos con lo que pudimos llegar a improvisar, nos fuimos a almorzar un buen asado.
Después del almuerzo, continuamos dándole retoques finales a la placa.
Nuestro mayor desafío, fue el de montar algún tipo de sensor que nos permitiera detectar el despegue. Para ello, utilizamos dos contactos metálicos, separados por un recorte aislante improvisado. Este recorte, por medio de un hilo, salia del cohete y se ataba a la base, de esta manera al despegar el cohete se arrancaría el aislante y las dos placas entrarían en contacto, detectando así el despegue. Esta tarea no fue fácil, ya que nos vimos dificultados por la estructura del cohete y por la ausencia de un hilo resistente al tirón del despegue. Tal fue la incertidumbre, que no supimos si iba a funcionar hasta el momento del despegue.
Llegada la hora de despegue de nuestro cohete que casi no tiramos por la ausencia de cabezales que encajaran en nuestro cohete. Una vez resuelto este problema, lo llevamos hasta la base de lanzamientos, lo colocamos y nos retiramos a una distancia prudencial.
El lanzamiento fue un éxito y pudimos oír el ascenso y descenso del cohete por medio de la antena antes nombrada.
Felices por lo logrado, nos volvimos hacia el colegio, terminando la jornada no de la mejor manera( porque hubiéramos preferido tirar el cohete con el programa final), pero de todas formas alegres. Les dejamos unas fotos de este memorable evento:

Preparando el "combustible" de los cohetistas.

Armando la carpa, Maravankin nos señala el Norte.

Secretos en reunión es mala educación.

Uno de los despegues.

EL asado.

Gracias Leandro por todo lo que nos enseñaste.
Con cariño Mati y Wajs.

Los alumnos que hicieron la antena... y la antena.

Leandro y Ezequiel dando los ultimos retoques.
Matias vigila que ningun asteroide nos arruine la tarde.

Todos.

Hasta aquí llego nuestra participación en el proyecto de CanSat, comenzada en Marzo y realizada a lo largo de todo el Ciclo Lectivo 2008. Estamos agradecidos con nuestros profesores Edgardo Baez, Leandro Arcusin y Mariano Foullier por los conocimientos y buen humor transmitidos hacia nostros. Cerramos esta jornada que fue sin duda enriquecedora para nosotros deseando que esta bitácora sea útil para aquel que la necesite o la encuentre. Sin más damos por cerrado este Blog que contiene todas nuestras experiencias, éxitos y fracasos.

Matias Maravankin y Ezequiel Wajs.

Noche Previa al Vuelo - 29/10/08

2008-11-11T11:31:00.004-02:00

Nos reunimos en la casa de Ezequiel la noche anterior al vuelo para ver si podíamos hacer algo util antes del vuelo y poder darle una culminación a este año de arduo trabajo. Es por esto que nos quedamos hasta altas horas preparando algunos "programas de emergencia" evitando el uso de división y multiplicación. Los programas eran mucho más simples que el Programa Final V3, pero esperabamos que aunque sea cumplieran con su propósito. Es por esto que surgieron esa noche 3 programas:

HPWM10

El programa toma una medición en 10 bits, la emite por un PWM donde la frecuencia de este es 1000 mas 2 veces el dato medido (igual que en el protocolo), también las reduce a 8 Bit's mediante una operación bastante grosera (ya que lo correcto hubiera sido dividir el dato por 4) y la guarda en la EEPROM.

HPWM8

El programa toma una medición de 8 bits, la emite por un PWM donde la frecuencia de este es 1000 mas 4 veces el dato medido (parecido al protocolo) y luego las guarda en la EEPROM.

Almacenamiento

El programa toma y almacena mediciones de 8 bits

Aquí los programas:
Ultima Posibilidad

*Notese que para evitar multiplicar sumamos varias veces el registro.

Día Trigesimosegundo (32º) - 24/10/08

2008-11-10T20:49:00.004-02:00

El 30/10 sería el lanzamiento del Cohete que llevaría el programa final que venimos preparando a lo largo del año (no preparando textualmente ya que el programa lo programamos en el último mes, pero este programa es la culminación del aprendizaje de toda la programación que estuvimos probando durante todo el año).
Edgardo nos comentó que no estaba muy satisfecho con los rangos con los que trabajaba nuestra placa de altímetro y que prefería utilizar la del año pasado que tenía incluido un potenciómetro que permitía regular el rango de salida. Es por esto que utilizamos el mismo método explicado en el post anterior para calibrar el viejo altímetro, logramos obtener un rango que llegaba hasta los 5V (Límite de los conversores Analógico-Digital del PIC) y partía de un voltaje más bajo que el del Altímetro fabricado por nosotros. Nos dispusimos a grabar 5 PICs, 2 con programas auxiliares que se límitaban a transmitir por antena el Dato que estaban midiendo (en 8 Bit's, para simplificar el funcionamiento, ya que es sólo un programa Auxiliar) y a guardarlo en la EEPROM y otros 3 con el programa principal que contiene las siguientes funciones, todas integradas y de funcionamieto cuasi simultaneo:

Toma de datos en 10 Bit's (1024 posibles valores)
Detección y Aviso de Despegue y Medición de Altura Inicial
Promediado de Datos (Se hace un promedio de 3 datos consecutivos, baja el error)
Procesamiento de Datos (Por programa la Altura del Suelo se vuelve 0)
Procesaimiento de Datos para Transmisión en RF (Para adaptar al Protocolo)
Procesamiento de Datos para Almacenamiento (Se reduce a 8 Bit's)
Guardado de Datos en la EEPROM (en 8 Bit's)
Busqueda de Apogeo (Constantemente chequenado la trayectoría balística)
Subrutina de Apogeo (Simplificada, para mejor funcionamiento en el descenso)
2 Programas en 1 ("Fase de Vuelo" y "Conexión a Computadora")
Programa Interactivo de Conexión a PC para recuperación de Datos

Este día cerramos el protoclo de transmisión que consistía en lo siguiente:

El dato iría montado en un PWM y sería proporcional a la frecuencia de este.
El Duty Cycle (Ciclo de Trabajo) discriminaría si el cohete estaba en vuelo o en tierra.
Las Frecuencias irían de 1000Hz a no más de 3048Hz
El dato (entre 0 y 1024, realmente menos por el procesamiento que recibe en el PIC) sería multiplicado por 2 y luego se le sumaría 1000 y de esta forma se obtiene la frecuencia del PWM.
Aquí la ecuación: F(d) = d*2 + 1000
A la frecuencia medida se le resta 1000 y se la divide por 2 y se obtiene el dato (entre 0 y 1024, realmente menos por el procesamiento que recibe en el PIC).
Aquí la ecuación: D(f) = (f - 1000)/2

CONSECUENCIA: Sólo las frecuencias PARES son admitidas en este protocolo (debido a la multiplicación por 2) , las impares deben ser redondeadas ya que no son posibles.
Aquí el código de programación:
Programa Final V3

El "Programa Final V3" (como lo llamamos, ya que tuvo otras dos versiones anteriores que fueron modificadas) era demasiado complejo para poder probar en el laboratorio ya que había muchas condiciones y variables a simular que para medir en el Protoboard y con antenas receptoras era demasiado engorroso, se necesitaba el Cohete con su infraestructura (el programa estaba pensado con esa filosofía y por lo tanto allí es donde debía ser probado), y más allá de que no disponíamos del cohete en ese momento, hubieramos necesitado que este se eleve, cosa que no podíamos simular. Es por esto que fuimos probando porciones del programa adaptadas especialmente para ser probadas en el laboratorio independientemente de las demás.
Desafortunadamente nos llevamos la sorpresa de que la emisión de datos por RadioFrecuencia no estaba funcionando nada bien. Como no podíamos encontrar el error en la programación, ni siquiera con la ayuda y la pericia de Edgardo Baez y Leandro Arcusin (2 profesores letrados en el tema) hicimos varios cambios consecutivos de Antenas de transmisión y antenas de recepción (estas últimas de laboratorio, para probar si el PIC emitía realmente los datos) y sin embargo no lograbamos recibir cosas coherentes, sino más bien ruido.
Después de un buen rato Leandro Arcusin notó que el PWM estaba variando constantemente y sin pausa, y nos recomendó poner una pausa luego de modificarlo para que no sea pisado constantemente por el dato que sucede al actual. La corrección que nos dió era correcta, pero el programa seguía sin funcionar. Cabe destacar que nos quedamos hasta mucho después del horario escolar que nos correspondía, de hecho era más del doble de tiempo que teníamos ese día en el colegio. Luego de mucho tiempo decidimos asumir que quizá habían errores al operar con el dato para aplicar el protocolo, luego probando, nos dimos cuenta que por alguna razón externa a nosotros el compilador no manejaba correctamente la multiplicación ni la división, haciendo que los registros se cargaran con valores que no estaban permitidos en el protocolo y que las antenas no podían emitir por un impedimento físico. De esta forma concluyó nuestro día con un final muy desalentador, no teníamos un programa útil para cargar en el Cohete ni podíamos hacer nada a nuestro alcance para arreglar nuestro programa, que habíamos programado asumiendo que el compilador haría exactamente lo que le decíamos. Nos retiramos a nuestras casas ya que nos habíamos quedado hasta tan tarde que comenzaban las clases del Instituto Tecnológico que funciona en nuestro colegio por las noches y debíamos liberar el Aula. Damos las gracias a Edgardo y a Leandro por haberse quedado con nosotros y habernos ayudado.

Día Trigésimoprimero (31º) - 17/10/08

2008-11-07T08:37:00.013-02:00

Una vez terminado el altímetro, nos dispusimos a calibrarlo.
Para calibrar el circuito debíamos simular los niveles de presión por los que pasaría el cohete una vez en vuelo, es por eso que utilizamos una campana para crear vacío y generar los posibles valores de presión. La idea original se basa en el método obtenido en la página de Guillermo Descalzo. Esta consiste en un frasco totalmente sellado, excepto por dos agujeros por donde pasarán mangueras, del que se succionará el aire para simular distintos niveles de presión. Al succionar, el agua se abre paso por la manguera y empleando un metro, se determinará la altura a la que llegó el agua. El sistema utilizado es bastante parecido al propuesto por Descalzo, solo que en lugar de emplear un frasco y un altímetro bajo prueba, utilizamos una campana de vacío y el altímetro hecho por nosotros.
En base a los niveles de agua que se presentaban, utilizamos una tabla de equivalencias realizada por Guillermo Descalzo en donde se establecía una altura para cada nivel de agua. Esta es la tabla de equivalencias de Guillermo Descalzo:
El sensor de presión se encarga de asignar un valor de tensión a un determinado valor de presión atmosférica. El circuito estaba conformado por unas resistencias que realimentadas al amplificador hacían que la salida alcance los 5v, pero cuando lo llevamos a la practica no llegábamos ni a 4v y luego de analizar los posibles valores y probar con unas resistencias que saturaban el circuito, logramos llegar a una salida de 4,70v.

Día Trigésimo (30º) - 10/10/08

2008-11-03T14:07:00.002-02:00

El circuito que habíamos impreso tenía algunos errores y utilizando el Protel 99 SE los corregimos. Procedimos a realizar todo el proceso que nos permite tener como producto final un circuito impreso: (La placa de cobre que utilizamos esta compuesta por una cara de cobre y otra de Fibra de Vidrio)

1. Limpiado y lijado de la Placa sobre la cara de cobre.
2. Planchado del circuito ya impreso con Toner en una hoja especial sobre la placa de cobre.
3. Separado de la hoja de la placa de cobre dentro de un recipiente de agua fria.
Subproducto: Placa de cobre con las pistas de Toner cubriendo parte de su superficie.
4. Sumergido de la placa con las pistas en un tanque de Cloruro Férrico durante 20 minutos.
5. Retirado de la placa del tanque de Cloruro.
6. Enjuagado de la placa.
Subproducto: Placa con el cobre disuelto, salvo en las partes bajo el toner.
7. Removido mediante el lijado de las partes con toner.
Subproducto: Placa con las pistas de cobre.
8. Recubrimiento de la cara de cobre con ContacFlux.
9. Agujereado de los pads y demás orificios necesarios.
Subproducto: Placa final vacía.
10. Montado de los componentes en sus respectivos lugares.
11. Soldado de los componentes.
Producto Final: Circuito Impreso.

Día Vigésimonoveno (29º) - 3/10/08

2008-11-03T13:31:00.002-02:00

En vista de que no conseguiamos un sensor y que necesitabamos uno urgentemente para el lanzamiento, desoldamos el sensor de una de las placas de años anteriores.
Le sustituimos los conectores cortados del sensor, por alambres nuevos y lo colocamos en el protoboard, para ver el desempeño del sistema entero.
Conseguimos amplificar las mediciones de variaciones de presion, traduciendolas en variaciones de tensión que son más apreciables que las de la salida del sensor que es de unos pocos miliVolt (mV), de esta forma el PIC puede apreciar con menor error la medición que se está realizando, ya que el PIC mide de 0 a 5 Volt y con una resolución de, como máximo 10 bit's, es decir, 1024 escalones por lo que el escalón más pequeño es de 5V/1024 que es aproximadamente 4 mV . Si no hubieramos amplificado la salida del sensor la medición sería realmente muy vaga. Amplificandola conseguimos un mayor grado de certeza.

Día Vigésimoctavo (28º) - 26/09/08

2008-10-31T11:30:00.002-02:00

Cuando probamos los altímetros anteriores, no andaban bien, es por eso que en el día de la fecha nos dedicamos a diseñar uno propio.
Primero diseñamos un circuito nosotros, es decir con un dibujo esquemático desde cero, que usaba 4 operacionales y por ese motivo, 2 integrados (cada integrado tiene 2 operacionales). Pero al compararlo con el diseño del año pasado, que en su momento anduvo bien pero no disponíamos de él porque el oxido se encargó de arruinarlo, notamos que el diseño tenia 2 operacionales, es decir, un solo integrado, siendo el diagrama mucho mas pequeño.
Es así que recreamos el circuito del año pasado en un protoboard, ya que era mas compacto (característica importante a la hora de meterlo dentro del cohete), y lo quisimos probar, pero no disponíamos de un sensor de presión como el que necesitábamos.
Igualmente sabíamos que el circuito funcionaba por los resultados obtenidos el año pasado, y a pesar de que no lo pudimos probar en el protoboard, imprimimos el circuito para poder hacer la placa en un futuro.

Día Vigésimoseptimo (27º) - 19/09/08

2008-10-31T11:22:00.002-02:00

Estuvimos rediseñando un poco el programa Apogeo 2.0 y nos dispusimos a probarlo utilizando el método explicado anteriormente que consiste en un sistema RC (Resistencia-Capacitor). El programa debía activar un LED, haciéndolo titilar, cuando detecte la descarga del capacitor, no detectar la carga, solamente el descenso de voltaje.
Bajamos el programa al PIC y probamos distintas situaciones iniciales del sistema, en el protoboard. En absolutamente todas el PIC detectó solamente la descarga del capacitor, cumpliendo con lo previsto por el programa.

Día Vigésimosexto (26º) - 12/09/08

2008-10-31T11:14:00.002-02:00

Seguimos en Bariloche!

Día Vigésimoquinto (25º) - 5/09/08

2008-10-31T11:03:00.003-02:00

Despues de estudiar durante 6 años tan arduamente nos mereciamos un poco de relajacion, con vista a las montañas y pasar el tiempo con nuestros amigos.
Es asi que ponemos en pausa el proyecto y nos despedimos de Buenos Aires, para irnos a San Carlos de Bariloche!!!

Día Vigésimocuarto (24º) - 29/08/08

2008-10-31T10:45:00.003-02:00

Al no poder solucionar el problema del transmisor hicimos un nuevo intento, pero nos topamos de nuevo con el mismo problema, es decir que el receptor solo recibía ruido.
El PIC que utilizaba el transmisor distorsionaba la señal, es por eso que hicimos un corto con un cable, desde una pata del PIC a otra, solucionando así el presunto problema, pero al probarlo seguía sin emitir.
Hicimos otra prueba del programador, subiendo un programa mas complejo que el anterior y funcionaba muy bien.

Día Vigésimotercero (23º) - 22/08/08

2008-10-31T10:32:00.003-02:00

El profesor Edgardo Baez nos trajo un transmisor del año pasado y lo probamos para ver si seguía funcionando. Al conectarlo a la computador a través del puerto serie y con un osciloscopio a la entrada del receptor para ver si llegaba señal, solo pudimos visualizar ruido ya que los datos emitidos nunca llegaban.
Estuvimos tratando de solucionar este problema pero sin ningún logro.
Probamos el programador terminado la clase anterior, pero nos encontramos con el problema de que el cable antes hecho, que va desde la placa programadora al protoboard tenia una longitud mayor a la necesaria y esto causaba un problema de atenuación en la señal.
Luego de solucionar el problema, lo probamos pasándole un programa básico al PIC, hecho anteriormente que hacia titilar un LED, y todo anduvo a la perfección.

Día Vigésimosegundo (22º) - 15/08/08

2008-10-06T15:27:00.005-03:00

Volviendo de nuevo al establecimiento escolar, luego de una ausencia de 15 días, continuamos con el proyecto.
Terminamos de preparar los cables, es decir, crimpearlos y soldarlos al conector del puerto paralelo y con esto finalizamos el cable que va de la computadora a la placa programadora y el que va de la placa programadora al protoboard donde esta el PIC a programar.
Terminamos de soldar los últimos componentes de la placa programadora y poner el PIC.

Día Vigésimoprimero (21º) - 8/08/08

2008-09-23T14:28:00.001-03:00

Seguímos en otra. Cabe aclarar que la foto anterior era meramente ilustrativa. Es invierno en este país y no existen playas que se le parezcan ni remotamente a la de la foto aquí.

Día Vigésimo (20º) - 1/08/08

2008-09-23T14:21:00.002-03:00

Celebramos nuestro vigésimo día de trabajo tomandonos unas merecidisimas vacaciones. Volveremos el 15/08/08.

Día Decimonoveno (19º) - 25/7/08

2008-09-23T13:38:00.002-03:00

Comenzamos la clase dedicandonos a rediseñar el programa de apogeo que habíamos creado la clase anterior. Nos propusimos otro enfoque para programarlo ya que el otro se basaba en un método bastante más grosero y propenso a fallas (recordamos que nunca funcinó). Le damos las gracias al Profesor Mariano Foullier por la idea.

El primer programa, lo llamaremos Apogeo 1.0, consistía en la siguiente secuencia de programación:

Se crea una variable de un solo Byte llamada Index y un array 16 de Bytes llamado Array
Index se inicializa en 00 y se utiliza para direccionar a Array
Se ingresa un dato en Array{Index}
Se incrementa Index
Se ingresa otro dato en Array{Index}
Se compara Array{Index} con Array{Index-1} si es mayor Array{Index-1} se vuelve a empezar, sino continua
Se incrementa Index nuevamente
Se ingresa un tercer dato en Array{Index}
Se realiza la misma comparación, si es mayor Array{Index-1} se vuelve a empezar, sino continua
Apogeo Detectado (Sub-rutina de Apogeo)

Es decir, el programa tomaba una muestra, luego otra, y las comparaba, si la primera era mayor que la segunda, el cohete estaba descendiendo, para evitar que el ruido haga activar la rutina de apogeo se tomaba una tercera muestra que compruebe definitivamente el descenso del cohete. Este programa era altamente falible y de hecho nunca anduvo como debía.

Es por esto que programamos el programa que llamamos Apogeo 2.0, cuya secuencia de programación era:

Se crea un Array de 16 Bytes y una variable de 1 Byte que lo direcciona, son Array e Index.
Se crea una variable de 1 Byte usada para contar llamada Cont inicializada en 0.
Se inicializan todos los elementos en 0
Se ingresa el primer dato en Array{0}
Se rotan todos los datos hacia el final del Array (Array{0} pasa a Array{1}, etc.) el último dato se pierde.
Se comparan los datos contiguos desde el principio del Array hasta el final, si los valores van en ascenso es porque el cohete va en descenso, cada vez que hay un descenso de un valor al contiguo se suma Cont.
Si al finalizar la comparación de todo el Array Cont es 3 o más, se ejecuta la subrutina de apogeo. Si no, se ingresa otro dato en Array{0} y se sigue desde ese paso.

Este programa era mucho más efectivo. lo que hacía era ir ingresando los datos de a uno en un Array vacío y compararlo con los demás. De esta forma, cada vez que se ingresa un dato, se ejecuta la comparación completa del Array. Hasta que no haya 3 descensos seguidos, no se salta a la sub-rutina de Apogeo. Este programa si funcionó correctamente y cumple con nuestras necesidades.

Dia Decimooctavo (18°) - 18/7/08

2008-09-22T15:46:00.002-03:00

Se cumple otro año de impunidad y se sigue sin culpables por el atentado a la AMIA.
Concurrimos al acto realizado, en memoria de las victimas.

Dia Decimoseptimo (17°) - 11/7/08

2008-09-19T08:07:00.002-03:00

Comenzamos el día probando el programa de apogeo que previamente habíamos programado vía Internet. A efectos de simular el ascenso y posterior descenso del cohete utitilizamos un potenciómetro que regulamos manualmente, primero subiendo su resistencia y luego haciendola descender, de esta forma pretendíamos que el programa confunda nuestro accionar con el del cohete en vuelo. El programa falló en todas las ocasiones, activandose antes de tiempo o no activandose en ningún momento. Nuestro tutor, Edgardo, nos dijo que el método que utilizabamos para simular el apogeo del cohete no era el apropiado que que la forma de la señal de entrada que estábamos generando se correspondía muy poco con la forma real de la señal, es por esto que nos recomendó utilizar un circuito RC (recomendamos entrar en el link, hay un applet muy explicativo del funcionamiento y la forma de la señal), que se ajustaría más a lo que el programa debía interpretar. Sin embargo, luego de este cambio el programa tampoco funcionó.

Circuito RC:

Gráfico de la señal durante la Carga (Interruptor cerrado) versus descarga (Interruptor abierto):

Por otra parte, terminamos de soldar el circuito que nos permitiría programar el PIC sin utilizar el ChipMax ni sacarlo del Protoboard (mencionado en el post anterior).
Por último nos dispusimos a probar el circuito altímetro para ver como sería el funcionamiento de este. A efectos de hacerlo solicitamos una Campana de Vacío que nos permite reducir la presión del aire dentro de ella y de esta forma simular altura en el altímetro (recuerde que el altímetro es en realidad un circuito medidor de presión).

Campana de Vacío: Ninguno de los dos sensores funcionó correctamente, en un futuro deberemos rediseñarlos.

Día Decimosexto (16°) - 4/7/08

2008-09-01T15:09:00.004-03:00

A partir de esta fecha Ezequiel Wajs se retira por primera vez y hasta el 30 de Agosto a los entrenamientos para las XII Olimpíadas Iberoamericanas de Física (OIF) a realizarse en Morelia, México del 27 de Septiembre al 3 de Octubre. Los entrenamientos de la selección Argentina se realizan semana de por medio en la Universidad Nacional de Rio Cuarto (UNRC) en Rio Cuarto, Pcia. de Córdoba.
Es por esto que el proyecto se vera ralentizado debido a que semana de por medio faltará uno de los dos integrantes.
Matias se avocó al desarrollo de una plaqueta y su correspondiente set de cables que permitirán reemplazar definitivamente al módulo programador de memorias ChipMax debido a que este no suele funcionar en las nuevas computadoras del laboratorio y nos fuerza a utilizar una Notebook que resulta incomoda para trabajar en el aula debido al cableado que requiere para funcionar como una máquina cualquiera de la red. Esta plaqueta programadora se comunica con la computadora sirviendose del puerto paralelo. Esta nueva plaqueta nos permite programar el PIC sin retirarlo siquiera del Protoboard haciendo la programación mucho más velóz. Dedicó el resto del día en la puesta a punto de la placa de cobre/fibra de vidrio para luego someterla al tratamiento con Cloruro Férrico que más tarde daría a lugar al circuito impreso sobre el cual montar los componentes de la plaqueta.
A pesar de estar a más de 800Km. el grupo estuvo en contacto mediante Internet. Ezequiel pidió prestada una computadora de la Universidad mientras que Matias utilizó una del Laboratorio, la comunicación fue posible gracias a un cliente de mensajería instantanea que permitió un ida y vuelta de ideas y datos en vivo. Ezequiel Wajs realizó en Rio Cuarto un programa que detectara el apogeo del cohete es decir el punto más alto que alcanzará en vuelo. Suponiendo que la gravedad será la única fuerza que actuará sobre el cohete luego del impulso inicial proveido por el combustible explosivo (y descartando los cambios de momento que causará la pérdida de masa a medida que el combustible se queme), el vuelo del cohete podrá representarse en función del tiempo con forma de parábola, cuyo vértice será el punto más alto de la trayectoria. Aquí un ejemplo aunitario de la parabola que representa la trayectoria del cohete:Cabe destacar que lo que se ve en el gráfico es la Altura en función del Tiempo, el desplazamiento (teóricamente) se realiza completamente sobre la misma linea recta que es aquella vertical en la cual se lanza el cohete y no un gráfico que denota desplazamiento en el eje X e Y.

Día Decimoquinto (15°) - 27/6/08

2008-08-29T11:32:00.012-03:00

Nos juntamos a debatir como mandar los datos que se obtenian en los dispositivos que estaban instalados dentro del coehete al Receptor terrestre, que en este caso seria una computadora.
Los datos que se necesitan transmitir son del acelerador y el altimetro, para asi poder detectar el apogeo del cohete y poder expulsar la caja hermetica que tomaria una muestra del aire a esas alturas, para luego poder analizarlo.

Para poder transmitir los datos con la mayor fidelidad posible, se estuvo pensando en un codigo que consistia en mandar dos bytes, el primero con la primer parte del dato de altura, precedido por un protocolo que lo identificaba el principio del dato 010XXXXX, y la segunda parte seguida de otro protocolo de bits, identificando el final del dato XXXXX101

Al tener el codigo para mandar, luego de diseñar un sistema bastante fiable, se empezo con la programacion que requería dicho codigo para ser transmitido.
Tambien se habló con Martin Rinemberg algunos de los protocolos que usamos, como la frecuencia y el codigo que se decidió utilizar, para que él los pueda aplicar en su proyecto.

Luego de terminar el programa que utilizaba el codigo, utilizamos el Realterm porque el Hyperterminal de Windows no esta programado para poder decodificar señal en binario.
Es asi que luego de conectar la placa con la pc, pusimos en practica nuestro programa y notamos que fue un total exito.

Día Decimocuarto (14°) - 20/6/08

2008-06-27T12:01:00.002-03:00

Nos juntamos con Martín Rinemberg (Alumno de Informática) quién nos informó que él sería quién se encargara de la interfáz de la PC, por lo tanto el trabajo hecho en la clase previa junto a Mariano Foullier fue descartado. Estuvimos probando algunos programas prototipos que Martín trajo. El optó por utilizar el lenguaje C# (ó C Sharp) para programar la interfáz. Los primeros programas no funcionaron. Martín tenía que ir y venir desde su edificio hasta el nuestro para poder probar los programas así que dedicamos una clase a armarle un cable DB-9 invertido para que el pueda comunicar 2 computadoras y ahorrarse el tener que ir hasta el piso de electrónica para probar sus programas. Además estuvimos el resto de la clase discutiendo con él como serían los datos que debía recibir él, como interpretarlos y procesarlos.
En el 2 Bloque Martín se acercó comentando que no lograba comunicar las PC's de ninguna forma. Es por esto que abrimos el cable y nos dimos cuenta de que habíamos leido los pins al revéz. Arreglamos el cable y sus programas comenzaron a funcionar.

Día Decimotercero (13°) - 13/6/08

2008-06-27T11:35:00.003-03:00

Nos juntamos con Mariano Foullier e intentamos comenzar a desarrollar lo que sería la interfaz gráfica para recibir los datos en una PC. Mariano nos recomendó utilizar el IDE(Entorno de Desarrollo Integrado) llamado Microsoft Visual Basic 6.0. Ya teníamos un conocimiento previo de este lenguaje de programación ya que lo utilizamos en nuestro primer año de especialidad y también en el segundo de ciclo básico. Sin embargo, desconocíamos totalmente el manejo del puerto serie mediante este lenguaje. Mariano nos mostró como configurar el componente que maneja tal puerto e hicimos un programa simple que nos permitió hacer lo mismo que hacíamos con el HyperTerminal hasta el momento, pero obviamente con más posibilidades de procesar los datos (funcionalidad que el HyperTerminal no posee). Estuvimos el resto de la clase probando programas con la interfáz que habíamos creado y tratando de procesar algunos datos. Cosa que logramos exitosamente. Pudimos mostrar en pantalla el voltaje del punto medio del potenciómetro, cosa que antes no habíamos podido hacer debido a que había que multiplicar el valor del Byte por el valor del escalon (0,02V) y eso nos demandaba usar Punto Flotante sistema que resulta muy complejo y demanda mucha memoria. El error de calculo que arrastran tanto la medición de los ADC (CDA) del PIC como el de cálculo de la computadora nos dejaron con un error de ± 0,04V o sea 2 escalones, medición que resulta bastante confiable.

Programación

2008-06-20T22:59:00.003-03:00

En este apartado trataremos todo lo concerniente a la programación del PIC e incluiremos la lista completa de programas que le hemos cargado (que además pueden ser encontrados en los días en que fueron hechos).
Cómo bien aclaramos previamente, programaremos nuestro PIC (por elección propia) en un lenguaje de programación que se llama BASIC. Un lenguaje de programación es un lenguaje que se utiliza para controlar el comportamiento de una máquina, en nuestro caso el PIC. Consiste en un conjunto de símbolos, instrucciones y reglas sintácticas y semánticas que definen su estructura, su funcionamiento, interpretación y el significado de sus elementos y expresiones.

Las reglas sintácticas son aquellas que nos explican como debe ser escrito un programa en este lenguaje. Por ejemplo:

En C todas las instrucciones, declaraciones y/o funciones deben finalizar con un punto y coma, y las rutinas y estructuras de control marcan su inicio y fin mediante corchetes por lo tanto un buen programa de C podría verse así:

void main (void)
{
char variable;
printf("Hola mundo!");
getch();
}

La semántica nos da la noción de como deben ser escritas las declaraciones, instrucciones y/o funciones. Por ejemplo:

En C las variables se declaran de la siguiente forma: "TIPO_DATO NOMBRE;" por lo tanto una buena declaración de variable en C sería:

char variable;

Los lenguajes de programación pueden ser clasificados de acuerdo a su "nivel", donde un lenguaje de alto nivel es aquel que se acerca más a las nociones humanas de la sintaxis y la semántica y un lenguaje de mas bajo nivel es aquel que se aleja mas de estas nociones. Por lo tanto un lenguaje de mas bajo nivel es de más difícil interpretación para un ser humano (obviamente de mejor interpretación para la máquina). El BASIC es un lenguaje de Alto Nivel (el C que es el lenguaje dado en las ejemplificaciones también es de alto nivel pero no tanto como el BASIC). Los lenguajes de programación se traducen a código de máquina (1's y 0's) para poder luego ser realmente interpretados por la máquina, esto, a veces, se hace mediante un programa que se llama "programa compilador". El nuestro es el PIC BASIC PRO (PBP). A continuación explicaremos las nociones básicas del lenguaje aplicadas a la programación de PIC's.

BASIC

COMENTARIOS: Pueden hacerse para que el programador o alguien que lea el programa se guie, no influyen absolutamente en nada en el programa, el compilador las descarta cuando le toca traducir el programa. para poder hacer un comentario hay que indicar su inicio y este es válido por el resto de la linea. El inicio se puede marcar (en BASIC) mediante un punto y coma o un apostrofe. Ejemplo: INDEX=0 ;Pongo index en 0.

VARIABLES: Sirven para almacenar datos y manejarlos pueden tener variados tamaños, desde un BIT a un par de Bytes. Deben ser declaradas de la siguiente forma: NOMBRE VAR TAMAÑO. Ejemplo: PERRO VAR BYTE. Acabamos de crear una variable a la cual en el resto del programa llamaremos como PERRO cuando la queramos usar y su tamaño es de 1 Byte (8 BIT's).

ENTRADAS/SALIDAS: Estos son generalmente pins, puertos o canales del PIC, pueden ser nombrados según su ubicación y posición. Ejemplo: portb.2. Donde lo que va despues del punto indica el Bit del puerto B que se utiliza (los puertos son generalmente de 8 Bits, por lo tanto es de 0 a 7). También se les puede asignar un nombre al igual que a las variables. Ejemplo: BOTON VAR portb.2. De esta forma cada vez que digamos BOTON el compilador interpretará que es el Bit 2 del puerto B.

ESTRUCTURAS DE CONTROL: Son aquellas que permiten interpretar y comparar datos y actuar de acuerdo a estas interpretaciones. Son varias y muy intuitivas y por lo tanto no ahondaremos en cada una de ellas, las que utilizamos son IF, WHILE y REPEAT-UNTIL y su estructura es:

IF (CONDICION) THEN
DECLARACION A
DECLARACION B
DECLARACION Z
ELSE
DECLARACION 1
DECLARACION 2
DECLARACION N
ENDIF
Explicación: Si sucede condición se ejecutan A, B y Z. Si no, se ejecutan 1. 2 y N, luego finaliza y se sigue normalmente con el programa.

REPEAT
DECLARACION1
DECLARACION2
DECLARACIONx
UNTIL(CONDICION)

Explicación: Se repiten las declaraciones 1, 2 y x hasta que se cumpla la condición indicada. Esta condición suele irse dando adentro de las declaraciones que contiene el bucle(una variable que se aumenta hasta llegar a un valor determinado, etc.).

WHILE (CONDICION)
DECLARACION1
DECLARACION2
DECLARACIONx
WEND

Explicación: Mientras se cumpla la condición se ejecutaran las declaraciones 1, 2 y x, una vez se deje de cumplir la condición, se sale del bucle.

DECLARACIONES: Son aquellas que actuan en el programa modificando distintas variables, estados y memorias, es decir, los comandos de acción que desencadenan una secuencia de pasos en el microcontrolador. Ejemplo1: HIGH portb.1 Ejemplo2: PERRO=PERRO+1.

Esta fue la introducción básica que esperamos permita comprender los programas que iremos haciendo. A continuación estan todos los programas hechos por el grupo:

TODAS LAS PROGRAMACIONES - Upload a Document to Scribd

Día Décimosegundo (12°) - 6/6/08

2008-06-06T10:58:00.004-03:00

Continuamos con el intento de confeccionar un programa que permitiera manejar la memoria EEPROM. Antes que nada queremos aclarar que intentamos aprender el manejo de esta memoria debido a que tenemos planeado que el módulo montado en el CAN-SAT no solo envie sus adquisiciones de datos a tierra sino que también almacene unas pocas para poder leer una vez recuperado el módulo en tierra (en caso de que el enlace de Radiofrecuencia con tierra se rompa por un periodo de tiempo o por todo el vuelo). El PIC tiene 256 posiciones de memoria EEPROM por lo tanto la cantidad de datos que podemos salvar con seguridad es bastante acotada.

Ahora sí, continuamos redactando lo que concierne a la actividad del día.
Durante la semana y por separado investigamos en nuestras casas (con los HelpTopics de MicroCode) y descubrimos nuestro error. Estabamos utilizando las instrucciones incorrectas o interpretando mal su funcionamiento. Logramos determinar el funcionamiento de las 3 instrucciones dadas previamente:

EEPROM:
Sirve para guardar datos en tiempos de compilación. Le indica al grabador de memoria que setee las direcciones indicadas de la EEPROM con los valores dados. Se hace una única vez (cuando se programa el PIC).

READ:
Sirve para leer datos en tiempos de ejecución. Es decir, para leer de la EEPROM datos almacenados en esta y guardarlos en variables que se encuentran en la memoría principal y se borraran una vez que se corte la alimentación del PIC.

WRITE:
Sirve para escribir datos en tiempos de ejecución. Es decir, para guardar datos almacenados temporalmente en variables que se encuentran en la memoría principal y se borraran una vez que se corte la alimentación del PIC.

Por lo tanto las instrucciones que necesitabamos eran READ y WRITE y no EEPROM ya que nosotros queremos guardar datos que se obtendran mientras el PIC se encuentra activo (de hecho el PIC es el dispositivo encargado de obtener estos datos).

Decidimos que el uso de Arrays era innecesario ya que de hecho se podía reemplazar por solamente 2 variables (recordando que un array es un conjunto de variables direccionable y por lo tanto supone utilizar mas espacio en memoria que solo 2 variables). Hicimos un programa utilizando variables normales (de un Byte de tamaño u 8 Bit's) que pudo ser compilado y pasado al PIC. El programa anduvo a la perfección. Aquí la programación.

Es el programa mas complejo que programamos hasta ahora y consiste en varias etapas que explicaremos:

El PIC se conecta a la PC mediante el cable que armamos y una vez prendido envía el siguiente texto que se lee por HyperTerminal:

LUEGO DE PRESIONAR UNA TECLA TIENE 2 SEGS.
SI PRESIONA EL BOTON LEE, SI NO GRABA.
REINICIE EL PIC CUANDO SE ENCIENDA EL LED POR 2 VEZ.

Esto le indica al usuario lo que debe hacer:

Una vez que el usuario presiona una tecla del teclado (cualquiera), el PIC le da 2 segundos para decidir que va a hacer. Si presiona el Botón que está en el Protoboard (conectado al PIC) se leerá lo que esta guardado en los primeros 10 sectores de la memoria EEPROM, si no lo presiona durante 10 segundos se harán adquisiciones analógicas del punto medio de un potenciómetro y las guarda en los primeros 10 sectores de la memoria EEPROM. Todos estos tiempos se indican en el Protoboard mediante un LED que se prende o apaga según la ocasión y la actividad. Una vez finalizada cualquier actividad hay que desconectar la alimentación del PIC y reconectarla, para que se resetee y así demostrar que los datos almacenados fueron realmente guardados en la EEPROM (cualquier otro dato se borra al cortarse la alimentación). Cuando se reinicia comienza de nuevo el proceso permitiendo adquirir los datos guardados en la sesión anterior o guardar nuevos.
El programa anduvo perfectamente y supuso el avance mas grande hasta la fecha. Ya estamos listos para comenzar a programar el programa final, es decir, el que irá realmente en el módulo CAN-SAT.

Día Décimoprimero (11°) - 30/5/08

2008-05-30T09:35:00.002-03:00

Comenzamos el día con la consigna de comprender y hacer buen uso de los Arrays y lograr comprender y aplicar el manejo de la memoria EEPROM (memoria no-volatil) interna que posee nuestro PIC. Averiguamos las distitnas instrucciones de BASIC que permiten este manejo e intentamos llevarlas a la práctica con un programa simple que incluyera Arrays. Estas funciones se llaman:

READ
WRITE
EEPROM

Creímos que la instrucción EEPROM era la que nos ayudaría a grabar datos en la memoria y por lo tanto el programa contenía esta instrucción.
Al compilar el programa recibíamos un error referido a una variable. Como obteníamos este error de compilación no podíamos pasar el programa al PIC (cuando se produce un error de compilación el compilador no finaliza de generar el programa en lenguaje de máquina y por lo tanto no se puede programar un microcontrolador). Como el error tenía que ver con una variable supusimos que el error estaba en la lógica utilizada para el manejo del Array (que es la lógica que aprendimos para manejar arrays en C con Leandro Arcusin). Investigamos más y no encontramos ningún error aparente. Por lo tanto, descartada esta posibilidad, tuvimos la seguridad de que el error residía en como estabamos manejando la EEPROM. Desafortunadamente malgastamos mucho tiempo en tratar de hacer que el programa funcione sin verificar las instrucciones de manejo de memoria interna y finalizamos el día sin poder probar ningún programa en el PIC.

Día Décimo BIS (10º II) - 26/5/08

2008-05-27T20:53:00.008-03:00

El profesor Rubén Bernardoni estaba tomando examen de Electrónica Analógica por lo que tuvimos la hora libre y decidimos continuar avanzando con las funciones del PIC. Es así que probamos el programa que habíamos diseñado para las mediciones analógicas hacía ya varias clases y que nunca habíamos podido probar debido a que hubo problemas con la comunicación "ChipMax<-->PC". Cargamos ese programa y reordenamos el circuito. Este consistía en el PIC, un preset cuyo punto medio estaba conectado al RA0 (Puerto Analógico 0) y un LED conectado (a través de una R de 330Ω) al RB0 (Bit 0 del Puerto B). El PIC16F819 posee conversores ADC (Analog To Digital Converter - Conversor Analógico/Digital) lo cual permite hacer mediciones sin necesidad de más componentes. La conversión que elegimos nosotros se efectua en 8 bits por lo cual el resultado puede ser de 0 a 255 y son equivalentes el 0 a la masa del circuito y el 255 a la VDD. Por lo tanto, haciendo regla de 3 simple, un escalón equivale a 0,02V o 20mV. Aquí la programación.
La Configuración Inicial la obtuvimos de los archivos de ayuda (Help Topics) del MicroCode Studio. El programa checkea constantemente la tensión del RA0, si esta es menor que 128 (o sea la mitad de VDD (2,5V) enciende el LED, si es mayor lo apaga. El programa anduvo a la perfección.
Continuamos avanzando, decidimos integrar las mediciones analógicas con la comunicación con la PC. Aquí la programación.
El programa se comunica con el usuario a través de HyperTerminal y le avisa que presione M si quiere obtener la medición. Si presiona M (o m) el programa devuelve el valor de B0 y avisa que hay que multiplicarlo por 0,02V para obtener el Voltaje. Mas adelante utilizaremos un entorno programado por nosotros que nos permitirá presentar los datos de una forma mucho mas ordenada y legible. El programa funcionó a la perfección. El PIC quedó convertido en un Voltímetro (De 0V a 5V).

Día Décimo (10º) - 23/5/08

2008-05-23T20:51:00.008-03:00

Volvimos a intentar programar el PIC desde la PC, fallamos nuevamente. Este resultado era frustrante ya que no era la primera vez que fracasábamos en programar el PIC cuando antes lo habíamos logrado sin mayor grado de dificultad. Mariano Foullier nos sugirió que el problema que podíamos estar experimentando era a causa del ChipMax (Grabador de memoria) y la PC (fallas en la comunicación entre estos). Solicitamos la Notebook y procedimos a utilizar el ChipMax desde allí. El programa funcionó a la perfección.

Rápidamente nos avocamos a recuperar el tiempo perdido en las clases anteriores y comenzamos a investigar acerca de las funciones que necesitábamos. Encontramos la página TODOPIC.COM que básicamente es una traducción de los Help Topics (Temas de Ayuda) del MicroCodeStudio y nos fue muy útil (junto con la ayuda de Mariano Foullier) para interiorizar las nuevas instrucciones que utilizaríamos. Estas eran las instrucciones de comunicación con la PC. Primero nos avocamos a comprender y utilizar la función SEROUT, que manda bytes en serie por uno de los bit's de algún puerto. Una vez hecho el programa lo bajamos al PIC (esta vez desde la Notebook) y anduvo a la perfección. La comunicación se realizaba a través de HyperTerminal (Software que permite utilizar en COM1 para comunicarse usando distintos protocolos). Aquí la programación.
De esta forma el programa mostraba por HyperTerminal cada medio segundo el mensaje"Hola Edgar, lo hicimos andar! Iteracion: #X" Donde X es la N vez que se repetía el loop. Esto significó un avance muy grande para nosotros, pero seguimos investigando y nos propusimos cerrar el día habiendo programado una comunicación de 2 vías (Ida y Vuelta, PC<-->Micro). En la página previamente mencionada nos informamos de la función SERIN, que recibe bytes en serie por uno de los bit's de algún puerto. Una vez programado lo pasamos al PIC y anduvo a la perfección. El programa preguntaba si había alguien y si se respondía "SI" tenía una respuesta particular, si se respondía algún otra cosa respondía con la misma respuesta siempre. Aquí la programación.

Terminamos el día con un gran avance. Nos restaba las mediciones Analógicas y aprender a hacer un sistema de adquisición de datos.

Día Noveno (9°) - 16/5/08

2008-05-23T08:54:00.010-03:00

El profesor Edgardo Baez nos trajo dos PIC16F819 completamente nuevos.
Para tratar de programar uno de los PIC's, abrimos todos los programas, y tratamos de cargarle una programación muy básica, que consistía en prender y apagar constantemente un LED.
Al tratar de cargar el programa en el PIC, nos topamos con un error del MaxLoader (Software del Grabador de memoria), que no reconocía el PIC, pero era porque no lo habíamos configurado previamente, así que configuramos todo debidamente y cargamos el programa.
Igualmente una vez hecho todo el circuito en el protoboard no prendía el LED. Mediante ningún medio logramos correr el programa dentro del PIC.
Decidimos no estancarnos con eso y pasar a hacer alguna otra parte del proyecto. Es así que comenzamos a probar los sensores viejos de presión que fueron montados en los años anteriores. Para eso cortamos la cobertura plástica de un cable de red y lo utilizamos como "tubo" para colocar en la boquilla de los sensores y así poder variar la presión utilizando nuestra boca, ya sea soplando (aumenta la presión) o aspirando (disminuye la presión).
La plaqueta armada en el 2006 no funcionaba. La del 2007 presentaba variaciones al soplar o aspirar pero no habíamos calibrado el sensor, no poseíamos métodos para hacerlo, y tampoco sabíamos si lo estaba, es así que la calibración del sensor se postergó para otra ocasión, para saber si las variaciones efectivamente respondían a la fuerza que soplábamos.

Existe la posibilidad de que rearmemos la plaqueta con un sensor nuevo y con un diseño propio.

Día Octavo (8°) - 9/5/08

2008-05-09T11:51:00.005-03:00

No pudimos conseguir otro PIC para este día, nos dedicamos a averiguar proveedores que nos pudieran suplir con tal instrumento. El precio promedio que conseguimos fue de 5 U$S aprox. Mientras tanto estuvimos a punto de programar otro PIC que nos dió Mariano Foullier para seguir practicando y aprendiendo programación, pero este PIC (16F628A) carece de ADC y éso lo volvía significativamente diferente del 16F819, solo poseía comparadores y programar este PIC significaba usar una lógica distinta de la que tendríamos que usar para el PIC que utilizamos y por lo tanto nos limitamos a programar en la computadora.
A su vez, nos dedicamos a preparar un cable que nos permitiera conectar algunos pins del PIC al puerto serie de la computadora para comenzar a programar un sistema de envío de datos con una PC. Partiendo de un cable de Mouse viejo, lo cortamos (descartamos el conector que venía con el cable ya que no usaba los pins indicados). A partir de un DB-9 nuevo y los conductores que venían dentro del cable de Mouse armamos un conector polarizado (para evitar conectarlo al revéz).

Día Séptimo (7°) - 2/5/08

2008-05-02T10:27:00.002-03:00

Preparamos todo el circuito para hacer una nueva prueba de programación. Pero antes probamos si seguía cargado el programa de la semana anterior. Cuando hicimos la conexión y testeábamos su funcionamiento, vimos que por alguna parte del circuito salió un poco de humo. Inmediatamente apagamos la fuente y comenzamos a buscar la falla. Nos dimos cuenta que la fuente estaba en 6v.
Al ver que el programa seguía funcionando correctamente (a 5v) intentamos reprogramar, cargamos el siguiente programa y pudimos (aparentemente) hacerlo. Generamos 2 nuevos programas mas simples para saber si la falla era de programación, pero ni siquiera los programas mas simples andaban. Es asi que consultamos con un profesor para ver que sucedia.
El profesor Leitner nos explicó que si bien el programador del PIC podía no devolver errores, podría haberse quemado un registro (o varios) que no permiten correr un programa nuevo (esto explica por que el programa siguió andando hasta que le cargamos otro).
Es así que empezamos una búsqueda, de un nuevo PIC, que lamentablemente no teniamos y empezamos a buscar distribuidores del mismo.
Luego nos acordamos que en el departamento de Fisica, había uno que no estaba en uso, así que lo fuimos a buscar para el día siguiente.

Día Sexto (6°) - 25/04/08

2008-04-25T11:38:00.001-03:00

Previamente habíamos tenido problemas con la programación debido a que desconocíamos la configuración básica del PIC, entonces en esta clase nos avocamos a entender esta última. Con ese fin, Mariano Foullier se sentó con nosotros y leyendo, tanto el datasheet del PIC como los archivos de ayuda del MicroCode Studio conseguimos los comandos que dejan al PIC listo para el programa principal. Estas lineas de código incluyen la configuración del clock y demás parámetros internos irrelevantes al caso. Algunas de estas cosas no podían ser programadas directamente en Basic ya que este lenguaje para este PIC carece de esas funciones, por eso procedimos a configurarlo en Assembler (las instrucciones las sacamos del Datasheet), mediante el comando ASM - ENDASM que permite insertar código en este lenguaje dentro del mismo compilador de Basic. De esta forma los programas comenzaron a ser funcionales. Esta configuración es el principio de cada programa. Agregando lo de la semana anterior obtuvimos el siguiente programa.

El programa anduvo a la perfección, nos dedicamos a hacer programas mas complejos. Para el final del día habíamos realizado un programa que manejaba 2 entradas digitales (Botones) y en función de que combinación era la presionada, el LED titilaba con distintas frecuencias. Aquí el programa.

El programa funcionó a la perfección. Dimos un gran avance con respecto a las clases anteriores

Software Utilizado

2008-04-19T09:56:00.001-03:00

En este apartado colocaremos los distintos tipos de Software que hemos ido utilizando a lo largo del proyecto. Iremos ampliando esta sección a medida que utilizemos nuevo Software. Los programas utilizados son:

MicroCode Studio

El MicroCode Studio es el IDE (Integrated Development Interface - Interfaz De Desarrollo Integrada) que utilizamos para programar el PIC. El lenguaje de programación con el que funciona este IDE es el BASIC que es un lenguaje diseñado para ser de fácil interpretación, es altamente humano en cuanto a esto. El compilador que utilizamos para poder traducir la programación de BASIC a lenguaje de máquina es el PicBasicPro cuyos archivos de ayuda y descripción (uno por cada Microcontrolador que puede programar) son muy útiles a la hora de configurar inicialmente a los Microcontroladores. Aquí un snapshot del MicroCode Studio:

MaxLoader

El MaxLoader es la herramienta de eeTools que nos permite bajar los programas compilados al PIC. Es de una interfaz sencilla que permite borrar, verificar, leer y programar memorias y Microcontroladores. Tiene un catalogo variado de Microcontroladores que permite programar y funciona con varias de las herramientas de grabación de eeTools como ChipMax, TopMax, etc. Aquí un snapshot del MaxLoader:

HyperTerminal

HyperTerminal es el programa de comunicaciones que nos permite comunicar al Microcontrolador con la PC, es un porgrama sencillo que permite utilizar distintos tipos de puertos para comunicaciones, en nuestro caso el COM1. El HyperTerminal permite setear muchas opciones de funcionamiento, como velocidad de transmisión, protocolo, etc. En nuestro caso usamos en protocolo N9600 (9600 Baudios, bytes negados y un bit de Stop). HyperTerminal es una apliación que se instala junto con Windows. Aquí un Snapshot del HyperTerminal:

Herramientas Utilizadas

2008-04-19T08:20:00.007-03:00

En este apartado colocaremos los distintos tipos de Herramientas (y Hardware) que hemos ido utilizando a lo largo del proyecto. Iremos ampliando esta sección a medida que utilizemos nuevas Herramientas. Los programas utilizados son:

ChipMax

El ChipMax es el Hardware grabador de memorias utilizado para grabar la programación en el PIC. Es una herramienta proveída por eeTools. Consiste en un módulo de programación que tiene un zócalo en el cual se pueden colocar componentes de hasta 40 patas. Se conecta a la PC mediante un cable al Puerto Paralelo (Printer Cable al Parallel Port). Para programarlo se necesita el Software MaxLoader. El módulo contiene dos LED's indicadores, uno que indica si se está recibiendo alimentación "POWER" (va a 220V mediante un transformador), y el otro que indica si el módulo está escribiendo o leyendo datos dentro de un circuito integrado mediante la etiqueta "BUSY". El ChipMax es bastante rápido, programar el PIC toma de 4 a 7 segundos. Aquí una foto del módulo:

Osciloscopio

El Osciloscopio Digital (también llamado ORC por los antiguos Osciloscopios de Rayos Catódicos, CRO en inglés), es una herramienta que permite visualizar señales eléctricas tanto analógicas como digitales. Cabe aclarar que para interpretar las señales analógicas (Siendo el Osciloscopio Digital) es necesario convertirlas en valores digitales mediante un ADC (Analog To Digital Converter - Conversor Analógico Digital). Básicamente un Osciloscopio es un Tester que permite graficar los valores en función del tiempo. Consiste en un Display y una botonera que posee botones y diales que permiten obtener medidas y ajustar parámetros de medición. Posee 2 entradas o "Canales" (Channels) por las cuales ingresan las señales. Los terminales de medición (Puntas de Osciloscopio) son cables especialmente blindados para evitar la distorsión de la señal que viaja por el. Poseen una punta particular que permite engancharse a terminales, pins y cables. También un cable cocodrilo que es para conectar a la masa (0V) del circuito y así tener la referencia, el conector mediante el cual se ingresa al osciloscopio es un BNC. El que utilizamos nosotros es el modelo TDS 220 de la marca Tektronix. Aquí una foto del osciloscopio:

Tester (Multímetro)

El Tester (o Multímetro) es una herramienta que permite medir varios parámetros eléctricos, estos son:

Diferencia de Potencial Continua y Alterna (Tester en modo Voltímetro)
Intensidad de Corriente Continua y Alterna (Tester en modo Amperímetro)
Resistencia (Tester en modo Ohmetro)
Continuidad de Conductores y Diodos.

El Tester consiste en un display de 4 digitos, 4 terminales de entrada de señal (uno para Tensión/Resistencia/Continuidad, un común "common", uno para medir corrientes de hasta 200mA y otro para medir corrientes de hasta 10A) y 2 cables con puntas que son los que ingresan (en distintas combinaciones según la medición) a los terminales del Tester y una perilla central que permite variar el modo y la escala en la que mide el Tester. Cabe destacar que según el modo, las mediciones se efectúan distinto. Para medir Tensiones el Tester debe colocarse en Paralelo a los bornes de los cuales se quiere obtener la diferencia de potencial. Para medir Corriente el tester se coloca en serie al conductor o componente por el cual pasa el flujo a medir cerrando el circuito mediante el Tester (para medir corrientes hay que conectar uno de los dos terminales del Tester en otro conector). Para medir Resistencia o Continuidad los componentes deben estar desconectados y el Tester debe colocarse entre los bornes de los componentes. El tester que usamos nosotros es el Wavetek 15XL. Aquí una foto:

Fuente de Alimentación

La Fuente de Alimentación es el dispositivo que provee la energía eléctrica para el funcionamiento de los circuitos. Posee un transformador y un circuito rectificador que convierte la señal alterna de 220v a una continua cuyo valor es regulable dentro de las siguientes opciones: 3V/4,5V/6V/7,5V/9V/12V. La corriente máxima que permite entregar la fuente que utilizamos (que posee un fusible) es de 2A. La fuente es de la marca MW2122A. Aquí una foto de la fuente:

Protoboard

El Protoboard, o tableta experimental, es una herramienta que nos permite interconectar elementos electrónicos, ya sean resistencias, capacidades, semiconductores, etc, sin la necesidad de soldar los componentes. Esta lleno de orificios metalizados -con contactos de presión- en los cuales se insertan los componentes del circuito a ensamblar.
El Protoboard esta dividido en cuatro secciones, las dos externas están conectadas verticalmente (según la foto) y las dos internas, con cinco orificios cada una, están conectadas horizontalmente, los orificios están conectados internamente, por lo que no es necesario rehacer estas conexiones.

Día Quinto (5°) - 18/04/08

2008-04-18T12:05:00.005-03:00

Conseguimos el Entorno de Desarrollo (IDE) y el compilador. El programa utilizado para este fin es el MicroCode Studio. Aprendimos mas del lenguaje y su implementación. Comenzamos a programar pero fallamos en el pasaje al PIC debido a que no supimos utilizar bien el MaxLoader (Programa que transfiere la programación a través de la interfaz ChipMax). La programación era errónea también ya que nos salteamos todo el paso de la preparación del PIC (Setear en Clock interno, WatchDog, etc.). Quizá logramos hacer llegar la programación al PIC pero al llevarlo a Protoboard no conseguimos resultados prácticos (debido a lo anteriormente mencionado).

El programa consistía en hacer titilar un LED.
Como mencionamos previamente, se salteaba toda la parte de seteo del PIC por lo tanto el programa consistía de estas simples lineas de código:

LED VAR portb.0

start:
HIGH LED
PAUSE 200
LOW LED
PAUSE 200

GOTO start

Día Cuarto (4°) - 11/04/08

2008-04-11T11:57:00.001-03:00

Durante el transcurso del día recolectamos y leímos datos acerca del Microprocesador a utilizar. Nuestro tutor nos explico conceptos del funcionamiento electrónico básico del mismo, tales como las entradas analógicas, digitales, oscilador interno, etc.
Vimos el Hardware utilizado el año anterior para el lanzamiento. Recibimos un PIC 16F819 pero no comenzamos a programarlo porque carecíamos del Entorno de Desarrollo y el Compilador y de los conocimientos del Lenguaje utilizado (Basic).
Elegimos Basic por sobre C (a pesar de que apenas habíamos visto unos comandos básicos) porque lo consideramos mas simple, humano y dinámico.

Día Tercero (3°) - 4/04/08

2008-04-04T11:39:00.002-03:00

El día comienza con una charla sobre el Blog en la cual aprendimos a crearlo, mantenerlo y actualizarlo. Se habló de la importancia de este para la difusión del proyecto fuera del marco escolar.

Finalmente optamos por realizar el proyecto CAN-SAT. Nos reunimos con nuestro tutor (Edgardo Baez) a discutir y aprender los objetivos del proyecto y ver las opciones que había para realizar dentro del proyecto.
El profesor Ruben Bernardoni nos entregó los documentos del grupo que se había encargado el año anterior del proyecto.
Nos informamos de las distintas partes de las cuales estaba compuesto el proyecto, básicamente estas eran:

Sistema de comunicaciones con tierra
Programación del Módulo

Elegimos la programación del Módulo que va montado en el CAN-SAT. Esta consiste en la programación de las adquisiciones de los valores que obtienen los sensores y la programación de la secuencia de expulsión que consiste en expulsar la lata en el apogeo y abrir una compuerta para luego cerrarla y así tomar una muestra de aire de la alta atmósfera.

Día Segundo (2°) - 28/03/08

2008-03-28T10:40:00.001-03:00

Se proponen proyectos alternativos a los anteriormente planteados.
Surgen del grupo varias opciones:

Guitarra Láser

Básicamente consistiría en una guitarra de 7 diapasones, más otro diapasón que reemplazaría al rasguido de la guitarra, con las 6 cuerdas correspondiente. Los diapasones más la cuerda correspondiente, estarían compuestos por un emisor y un receptor láser. El sonido característico de cada nota se daría al analizar las entradas de los diapasones y de las cuerdas pulsadas. El proyecto fue desalentado por los profesores debido a la poca eficiencia y calidad sonora que tendría el instrumento.

Monitoreo de Maniobras en Lugares Peligrosos

Básicamente, un sistema de rastreo y posicionamiento virtual de un móvil en un area a explorar. El móvil poseería un emisor de RF mientras que al inicio del resinto habría 2 antenas separadas por una distancia conocida. Esto permitiría mediante triangulación de señales ubicar al móvil en un mapa esquemático en una computadora, al mismo tiempo que se veía una transmisión en vivo de lo que observaba el móvil mediante una cámara IP a bordo. El proyecto fue descartado debido a la complejidad matemática del sistema de referencia que permitiría ubicar al móvil y por la limitación técnica de la sensibilidad necesaria por las antenas para ubicarlo con presición.

Dia Primero (1°) - 14/03/08

2008-03-14T10:32:00.001-02:00

Comienza la materia Proyecto Final 2008
Se dan los objetivos de la materia y los plazos:

Obtención de un Producto Final (30/10/2008)
Información Asociada al Producto (20/11/2008)

La información asociada al producto consiste en:

Cuaderno de Laboratorio
Manual de Transferencia
Manual de Usuario
Blog

Se expusieron las distintas opciones de proyectos para realizar, que fueron:

Vinchuca
Biotrón
Sensor de Sabor
Medición de Parámetros Ambientales (Ruido, CO2, Calidad de aguas, Mapeo)
CAN-SAT (Cohete/Cámara)
Tablero de Basket
Submarino+Barco
Telemetría de Auto Radiocontrolado
SAC-D
Baby Caller+Imágen
Antena para medir Irradiación Solar
Iluminación Con LED'S
Calefón Solar

Se forma la dupla Maravankin-Wajs pero no se decide ningún proyecto en particular. Las opciones primeramente adoptadas fueron:

Sensor de Sabor
CAN-SAT
Telemetría de Auto Radiocontrolado