sábado, marzo 12, 2016

Buenas Maneras (II): Errores y excepciones

En C++, en JAVA y en C# (y supongo que en la mayoría de los lenguajes de alto nivel), existe una herramienta muy potente para la gestión de errores dentro de un programa: las Excepciones.

A decir verdad en C++ no pasan más que por ser un retorno de un int por una vía distinta a la habitual, sin embargo sigue siendo un camino a tener en cuenta. Hay que tener en cuenta que las excepciones no son necesariamente errores en una función, sino situaciones excepcionales y distintas al flujo normal del programa (la propia definición de la palabra lo dice).

He observado que algunos programadores utilizan las excepciones para devolver valores o ejecutar un código dentro del flujo normal del programa, y esto a mi modo de ver es un error muy grande.

Para hacerlo más claro voy a explicar un ejemplo:
Un programa que comunica el PC con un microcontrolador vía serie. Al enviar el PC una orden, el micro responde que la operación no se ha podido realizar de forma correcta. Algunos programadores utilizan una excepción para informar al usuario, lo cual es un error. En este caso deberíamos tener en cuenta los posibles casos que el micro pueda informar y tratarlos adecuadamente.
Debemos dejar las excepciones para resolver problemas que nos surjan fuera del flujo normal, e intentar dejar las respuestas de las diferentes partes del programa al margen de las excepciones.

Otro ejemplo un poco menos claro:
En el mismo programa de antes se debe tener en cuenta que el micro pueda estar desconectado u ocupado realizando alguna otra tarea. Esto generalmente provocará un TIMEOUT en la llamada al puerto serie. Muchos programadores utilizan una excepción para informar al usuario que el puerto no responde (en la propia excepción). Si bien el TIMEOUT es una excepción en sí misma, no se debe utilizar para informar al usuario, sino que, lo que se debería hacer es recoger la excepción y tratarla en el flujo normal del programa (reintentos de enviar el comando, informar al usuario, etc.).

En definitiva para una función cualquiera la cabecera debería seguir la siguente pauta:

tRespuesta Funcion(tParametros) throw tExcepcion

Donde tRespuesta definirá las respuestas normales de la función y tExcepcion definirá los errores y excepciones que no hayan podido ser tratados dentro de la función o que deban ser informados a otras funciones.

En C el tema cambia, ya que no existen las excepciones de forma nativa, así que u optamos por utilizar librerías externas que implementan macros para realizar esta función, o directamente nos montamos nosotros el sistema.

En mi caso he decidido hacer esto último de una forma muy sencilla: todas mis funciones devuelven un entero:
int Funcion(tParametros)

de tal forma que si el entero es un número negativo la función está devolviendo un código de error. Si la función devuelve 0 (OK) es un funcionamiento normal y dejo los números positivos para la devolución de otros resultados (por ejemplo números de bytes leidos de un puerto, número de estado de una máquina de estados, etc.)

De esta forma siempre puedo hacer el siguiente código:

#include "error.h"
return = foo(parameters);
if(return < OK) { // Tratamiento de los errores }

He incluso tratar cada uno de los posibles errores por separado con un switch-case-default.

Evidentemente reconocer los posibles problemas dentro de la función (punteros no válidos, indices fuera de rango, etc.) corre a cargo mío, pero es un sistema que me funciona bastante bien y muy simple y rápido de implementar.

Sólo hay que tener en cuenta que los valores a devolver por la función siempre tienen que ser enteros positivos y que si se necesitaran otro tipo de valores se deberá pasar un parámetro por referencia para guardarlos allí.

Un apunte, algunos microcontroladores tienen implementado una serie de traps, es decir funciones a las que se llaman cuando hacemos una operación prohibida (como una división por cero), estas traps ya hacen de excepciones (aunque en realidad son errores graves) por lo que se debería no intentar que saltasen nunca ya que hacerlo debería significar hacer un reset del programa.


S2

Ranganok Schahzaman

sábado, marzo 05, 2016

Entendiendo los... Osciloscopios (III): cuantificación

Una vez que hemos determinado el muestreo, el convertidor analógico-digital (ADC) tiene que cuantificar el valor de la señal recibida (dado que ha de pasarlo a información digital), y como no tenemos una memoria infinita truncará la resolución con la que se adquiere la medida.

Dependiendo del número de bits que resuelva el ADC se tendrán más o menos niveles. Por ejemplo para un ADC de 8 bits se tienen 256 niveles posibles de tensión, para uno de 10 bits 1024 niveles, etc. (a razón de 2^n niveles). Es decir, si ponemos una señal rampa (continúa) a la entrada del osciloscopio, el ADC lo digitalizará de la siguiente forma:

Cuantificacion Midthread
Niveles de cuantificación con 4 bits
Los escalones serán más finos cuantos más niveles (más bits de información por muestra) tengamos. Con cada bit extra se dobla el número de niveles, por lo tanto queda claro que nos interesan un ADC del máximo número de bits posibles.:
2-bit resolution analog comparison3-bit resolution analog comparison
Cuantificación de una
señal senoidal con  2 bits
Cuantificación de una
señal senoidal con  3 bits
Además hay que tener en cuenta que, aunque aquí se muestra todos los niveles de cuantificación disponibles para la señal, en un osciloscopio la cuantificación se realiza para el fondo de escala (es decir para lo que se muestra en pantalla), por lo que para la señal los bits disponibles siempre serán menos.

Aquí nos encontramos con el problema de siempre: no lo podemos tener todo, los ADC's tardan un tiempo en cuantificar la señal, y este tiempo augmenta según augmenta el número de bits, por lo que tener un ADC de 6GS/s y 24bits será tremendamente complicado (y muy muy caro). Así que debemos preguntarnos que cuál es la resolución y la velocidad que necesitamos para nuestra aplicación -evidentemente 6GS/s y 24bits servirán para practicamente todas las aplicaciones que necesitemos, sin embargo ¿necesitamos tantos datos?-.

Por un lado ¿cómo de rápidos serán los cambios? No es lo mismo leer una señal térmica (que toma algunos segundos en variar) que una "glich" en la señal, por lo que necesitamos un ancho de banda suficiente para detectar la señal (ya hemos hablado de esto y como mínimo necesitamos el doble del ancho de banda de la señal).

Además de eso, de que magnitud es el cambio para que sea relevante respecto a nuestra señal principal:
  • En una señal de 5V con 8 bits tendremos 256 niveles, es decir que cada bit corresponderá a unos 20mV (5V/256 = 19.53mV) de resolución
  • Si utilizamos 10bits tendremos 1024 niveles que cada bit corresponderá a unos 5mV (5V/1024 = 4.88mV)
  • Para 12bits, es decir 4096 niveles, la resolución será de aproximadamente 1mV (5V/4096=1.22mV), etc.
¿Realmente necesitamos ver la variación de 1mV sobre una señal de 5V (un 0,02% de la señal)?

Por lo que debemos tener una idea de la variación necesaria de la señal para que esta sea suficientemente importante para ser registrada, sobretodo sabiendo que si necesitamos mayor resolución en un punto aplicaremos una ganancia a la señal analógica antes del ADC, o lo que es lo mismo cambiaremos el fondo de escala a un valor menor (en vez de 5V aplicaremos 2V, 1V, 500mV, etc. en las ecuaciones anteriores).

Por otro lador  en un osciloscopio nos limita la resolución de la pantalla, por lo que si la pantalla es Full HD, es decir, con 1080 pixeles de altura, ¿qué sentido tiene tener 12bits (4096 niveles)? Seremos incapaces de representarlos en la propia pantalla del osciloscopio, y eso sin contar que muchos osciloscopios todavía utilizan pantallas con resolución VGA (o XVGA) de 480 pixeles de altura.

Lo más sencillo es sacrificar la velocidad y tener ADCs de más bits (podemos tener 24bits y 110kS/s muy baratos), o, por el contrario sacrificar los bits y tener major velocidad (8bits y 250MS/s bastante asequibles). Por ejemplo, los osciloscopios modernos de bajo coste (<500€) suelen tener 8bits y 1GS/s de muestreo en total (para los 2 o 4 canales que tienen). Incluso los de marca de coste asequible aumentan la velocidad sin cambiar el número de bits (8bits y 2GS/s). Es decir, los fabricantes en general están de acuerdo que, en un osciloscopio es más importante la velocidad de muestreo que el número de bits aplicados a cuantificar la señal.

S2

Ranganok Schahzaman




sábado, febrero 20, 2016

Buenas Maneras (I): Llaves e identaciones

Inauguro una pequeña guía de estilo de como me gusta encontrar un código cuando trabajo en él (llamadme maniático si queréis).

A la hora de diseñar e implementar un nuevo firmware (o programa) no tengo mucho problema, ya que lo hago a mi gusto, sin embargo a la hora de mantener un programa o firmware realizado por otra persona es donde me suelo encontrar los problemas... Depende de lo hijop#t@ "limpio" que sea el programador anterior, que el código este comentado, indentado correctamente y bien diseñado.

Existen muchas guías de estilo (de hecho todos los proyectos grandes tienen la suya propia), pero yo me he hecho la mía a lo largo de los años y he notado que los errores se reducen y me es más sencillo leer y entender código antiguo.

Para no liarnos escojamos un lenguaje de programación de base: C++. Escojo este porque permitirá hacer comentarios tanto para lenguajes de bajo nivel (C), como para alto nivel (Java o C#).

Hoy vamos ha hacer algunos comentarios del estilo básico a la hora de escribir un programa (lo que llamaríamos la caligrafía).

Antes de empezar

Antes de empezar hay que tener en cuenta ciertas cosas:
  1. La guía de estilo debe ser clara en todas las situaciones. Yo recomiendo partir siempre de alguna guía ya establecida en un proyecto grande, de esta forma habrá muchos temas ya contemplados y que ni siquiera se nos habrían ocurrido en el primer momento (a título personal yo uso la guía de ANSI de base).
  2. La guía de estilo debe ser la misma para todos los participantes de un proyecto. No es nada agradable ver distintas partes del proyecto formateadas de forma diferente, además es confuso y puede llevar a errores.
  3. La guía de estilo debe ser estable en el tiempo de vida de un proyecto. Las guías de estilo no son inmutables, todo el mundo incorpora prácticas nuevas y mejores en su programación, sin embargo en un mismo proyecto es importante mantener la misma guía de estilo a lo largo de todo el tiempo de desarrollo para no crear confusión a la hora de leer el código. Aquí hay dos opciones, o se mantiene el estilo anterior o se cambia en todo el código. Hacer una u otra cosa dependerá de muchas cosas pero si se va a cambiar todo el código hay que tener en cuenta que haremos una pequeña ruptura con el código anterior (sobretodo si utilizamos un control de versiones), y hay que hacerlo de forma muy controlada.
  4. Se debe automatizar el proceso. Independientemente que interioricemos el proceso de escritura es importante usar un IDE que puedas automatizar el proceso de corrección de estilo (la mayoría de los IDEs modernos ya tienen esta opción incluida), de esta forma será mucho más sencillo. Sin embargo, en ningún caso implica que debamos dejarlo todo al IDE, en multitud de ocasiones no tendremos la oportunidad de realizar la automatización, por lo que será bueno que nos acostumbremos a escribir el código según la guía que hallamos elegido.

Llaves e identaciones

Primera regla de las identaciones usad siempre tabulaciones y no espacios esto incluye a no convertir las tabulaciones en espacios. A parte de ser una manía mía, implica desplazarse por el código más rápido y evita desajustes en el código cuando se tocan accidentalmente las teclas Supr o Retroceso. Sólo recomiendo usar los espacios para casos extremos en los que no haya más remedio (cuando no se puedan usar tabulaciones como el caso de esta bitácora). Otra cosa, las identaciones que ocupen el tamaño de 4 espacios (esto generalmente se puede utilizar Veamos ejemplos incorrectos, a mi modo de ver, de usar las identaciones:

¡¡¡ HORROR !!!, esta forma de programar hace que el código sea cada vez más ilegible (sobretodo cuando llevas 10000 líneas de forma similar). La solución correcta sería:

Sí, ya se que queda más largo el código, pero queda más limpio y te deja sitio para poner los comentarios que hagan falta. Por cierto poner !i o poner i==0 no es indiferente, la primera se deberá utilizar cuando sea una variable de verdadero o falso (booleano) y la segunda cuando sea una variable numérica. Otro:

 Esto queda feo con ganas, a parte que (personalmente) le tengo una manía horrible a poner la llaves no de forma identada (que empiece el bloque y lo acaben en la misma columna), y sobretodo cuando en vez de a=0 hay 100 líneas de código te puedes perder. Quedaría así:

o en este caso que tenemos una sóla línea:

fácil limpio y corto. Sin embargo es recomendable utilizar la primera opción para que las llaves limiten el bloque (menos propenso a errores). Otro ejemplo con la instrucción switch, partirmos de:

Cuando tenemos que hay mucho código dentro de los case queda muy sucio y poco comprensible. Una buena forma de no perdernos sería:

Así tenemos alineado el código y dentro de unas llaves, por lo que será más legible y más fácil de seguir. Siguiendo con el switch es bueno que la variable a sea de tipo enum (no siempre se puede), de esta forma podremos hacer un código más descriptivo, y por lo tanto más sencillo de leer.


Más adelante seguiremos avanzando con este y otros temas que nos permitirán aumentar la productividad a la hora de escribir y corregir código.

S2

Ranganok Schahzaman

lunes, octubre 12, 2015

4xcopter. Primer prototipo

Hace pocos días he recibido el primer prototipo del la placa de control.
PCBs empaquetada
El fabricante (elecrow) me las ha enviado en unas 3 semanas (50x50mm, 2 caras con máscara verde) por sólo 13€.
Parches aplicados
La verdad es que estoy bastante contento con el resultado, pero...
  • He visto que he cometido un error en el regulador de corriente: el patillaje es erróneo, cambia la posición de los pines Vin y GND entre el SOT23 y el SOT89. La solución parcial ha sido la de usar un LE33 en formato TO92.
  • Las vías no tienen máscara, si bien esto no es un error y a la hora de depurar incluso es una ventaja, es mejor que estén cubiertas por que dan menos problemas durante la fabricación: se evitan contactos erróneos, sobretodo si se sueldan los componentes a mano.
  • El color de la máscara me gustaría más en negro o azul, el verde está bien para prototipos y para PCBs que no van a la vista, pero para las placas visibles mejor usar otro color.
  • El cable de la foto es simplemente para juntar 3.3V analógico con 3.3V digitales, el un principio se generan con dos reguladores distintos, pero como no he montado todos los componentes me faltaba esa alimentación. En la siguiente versión irá una resistencia 0R para cuando se quiera juntar las pistas (incluso se podría usar una resistencia que formase un filtro paso bajo).
Me faltan hacer bastantes pruebas, y seguramente me surgirán más cosas a cambiar pero por ahora es suficiente para empezar a programar.

S2

Ranganok Schahzaman

lunes, junio 01, 2015

NSd (VII): Sensores

A parte de los sensores de posición y orientación que lleva la IMU la idea de la sonda es que lleve algunos sensores más que permitan medir datos atmosféricos, para ello hemos ideado una batería de pruebas que tenemos que recoger:
  • Iluminación: a parte de llevar una pequeña cámara (que nos dará información de a qué punto estamos mirando), podemos medir la radiación recibida en distintas longitudes de onda, usaremos los canales(con el pico de radiación entre paréntesis):
    • Rojo
    • Verde
    • Azul
    • IR cercano
    • UVA: también se podría medir UVB y UVC pero es más difícil de conseguir los sensores y para una primera sonda creemos que no es necesario.
    • IR térmico: es interesante medir la temperatura del objeto al que estamos apuntando (la Tierra por ejemplo), tambien podríamos usar un array de sensores (8×8 a 32×32) y tener ua pequeña imagen térmica
    • Iluminación/Blanco (“clear”): es una combinación de los canales Rojo, Verde y Azul
  • Temperatura: a parte de medir la temperatura interna para comprobrar el correcto funcionmiento de la sonda y calibrar las medidas de los sensores, podemos hacer una medida directa de la temperatura externa
  • Presión:A parte de obtener la altura barométrica (y la altura real si se tiene un barómetro en tierra), se puede hacer una medida de la presión atmosférica
  • Humedad relativa
  • Concentración de Gases: se puede medir distintos gases, sin embargo para esta medida no hemos encontrado todavía ningún sensor que mida los gases y cumpla con las condiciones de la sonda (excepto CO2).
¿Se os ocurre alguna medida más?

domingo, mayo 24, 2015

NSd (VI): Aplicaciones: Medida de datos atmosféricos

He visto la siguiente noticia, donde unos científicos quieren hacer una medida del viento a 100m para realizar pronósticos más precisos para predecir el comportamiento de los generadores eólicos. La sonda es una buena manera de hacerlo, ya hemos visto que se puede anclar muy fácilmente la sonda al suelo y además esta ya enviará parte de los datos que nos (presión atmosférica, humedad y temperatura), así que sólo nos queda saber la dirección y velocidad del viento.

En tierra y parados, medir la dirección y velocidad del viento sería relativamente fácil de hacer, sin embargo en una sonda colgada de un globo que se mueve y gira en varios ejes hay alguna complicación más… El hecho de utilizar giroscopios y acelerómetros, repartir correctamente los sensores por la superficie, utilizar formas aerodinámicas que impidan el giro libre y repartir el peso correctamente nos ayudará a recoger los datos de una forma ordenada y que luego sea fácilmente procesable.

Por ejemplo si la carcasa es en forma de gota de agua (o el perfil de un ala de avión) la brújula digital nos podría servir como veleta, ya que la forma de la carcasa haría que la sonda girará en dirección del viento. Para medir la velocidad del mismo podemos mirar la inclinación de la sonda o realizar la medida por resistencias o hilos calientes o directamente con un anemómetro de aspas.

domingo, abril 26, 2015

NSd (V): Definición del proyecto

Nos hemos dado cuenta que habíamos empezado a trabajar ya en el desarrollo de la sonda y todavía no habíamos publicado una defición del proyecto en condiciones.

El proyecto NSd trata de construir una sonda meteorológica (sub-espacial) que mida parámetros de la atmósfera y pueda realizar fotografías de gran altitud. Constará de dos partes bien diferenciadas, la sonda propiamente dicha (encargada de la recogida y transmisión de los datos) y la estación de tierra (encargado de la recepción de datos y el procesado y presentación de los mismos).

Sonda
A su vez la sonda constará de 3 partes diferenciadas:
  • La IMU (Unidad Inercial)
  • Los sensores
  • La parte de radiofrecuencia
IMU
La unidad inercial es el cuerpo de la sonda, se encarga de recoger los datos de posición y orientación de la sonda para contextualizar el resto de datos proporcionados por los sensores. Constará de:
  • Un procesador.
  • Un giroscopio (3 ejes).
  • Un acelerómetro (3 ejes).
  • Un magnetómetro (3 ejes).
  • Un altímetro barométrico.
  • Un GPS.
  • Un sistema de almacenamiento.
De esta forma tendremos una medida muy completa y exacta de la posición y orientación de la sonda en todo momento. Además dado que queremos un sistema compacto el mismo procesador que tenga la IMU nos podrá servir para recoger los datos del resto de sensores y para transmitir la información a la estación de tierra.

Sensores
Los sensores irán repartidos en una o varias PCBs dependiendo de la necesidad de espacio que ocupen o de la posición en la que hayan de ir. Nosotros hemos escogido unos sensores para medida atmosférica, sin embargo el diseño podría tener otros sensores dependiendo del uso que se vaya a dar (ver la sección de aplicaciones):
  • Una cámara (QVGA-VGA) a color
  • Sensores de luz para los siguientes canales: rojo, verde, azul, ultravioleta (UV a 400-410nm), Infrarrojo cercano (IR a 850nm), Infrarrojo térmico (IR a )
  • Humedad relativa
  • Temperatura interna y externa.
  • Gases: CO, CO2, O3
Radiofrecuencia
Como ya explicamos antes queremos enviar imágenes/vídeo y los datos de las medidas a la estación de tierra, para ello queremos emplear dos frecuencias:
El empleo de estas frecuencias es debido a que son en la banda de uso libre: 868MHz es para uso de dispositivos de “corto alcance” y 144,8MHz es de servicio de radioaficionado (1), si transmitimos en protocolo APRS podríamos conseguir que los aficionados de la zona de vuelo pudieran seguir la evolución de la sonda.

Módulo de recuperación
Suele ser interesante tener un canal de comunicaciones auxiliar para localizar la sonda en caso de perder el canal principal. Habíamos pensado en utilizar un módem GSM para enviar la posición una vez en tierra para recuperar la sonda. Para que fuera totalmente auxiliar debería funcionar de forma autónoma por lo que sería implementar una PCB independiente con:
  • Un microcontrolador.
  • GPS.
  • Módem GSM.
  • Alimentación independiente.
Sin embargo este módulo no es totalmente imprescindible, ya que tenemos el canal ARPS, por lo que podríamos no usarlo en caso que no tuvieramos tiempo de implementarlo todo.

Estación de tierra
La estación de tierra se encarga de recoger, procesar y presentar los datos. Dado que la sonda lleva un sistema de almacenamiento no es imprescindible hacerlo todo en tiempo real y podríamos espaciar las recepciones para reducir el ancho de banda y, por lo tanto, reducir las interferencias y el ruido (para aumentar la distancia de envío). La estación estará compuesta por:
  • Sistema de posicionamiento.
  • Sensorización en tierra.
  • Recepción de la señal.
  • Sistema de procesado y presentación.
Sistema de posicionamiento
El sistema de posicionamiento será un GPS, con ello podremos saber el recorrido del equipo de seguimiento de la sonda, en caso que esta vuele libre; o afinar la posición de la sonda a un error pequeño, en caso que esté fijada.

Sensorización en tierra
Es muy interesante conocer la presión barométrica en tierra, de esta forma se puede conocer la altura real de la sonda (y no sólo la altura barométrica) y así corregir el error del GPS. Sin embargo los sensores no se tienen porque limitar a eso; se podría tener, por ejemplo, una estación meteorológica completa.

Receptores de la señal
Es lo más importante de la estación de tierra, los receptores de los datos de la sonda nos permitirán saber la posición en cada momento y por lo tanto podremos recuperarla.

Sistema de procesado y presentación
Básicamente es un PC en el que se representarán los datos recibidos (tablas, hojas de cálculo, gráficos, mapas, etc.) y se procesarán (altura real en función de la barométrica, iluminación dependiendo del apuntamiento, etc.).

Si cuidamos un poco el diseño podemos reutilizar algunas PCBs (IMU como sistema de posicionamiento del equipo de tierra, etc.) por lo que bajaremos el precio.

(1) Fuente: Cuadro Nacional de Atribucción de Frecuencias.

EDITADO: Los servicios de radioaficionado no son de transmisión libre, sino que están sujetos a una licencia.

domingo, abril 19, 2015

NSd(IV): Aplicaciones: Fotografía aerea

Una de las posibles aplicaciones que tendrá la sonda es la de poder realizar fotografías aéreas geoposicionadas.

Con la estación base fijada en una posición durante bastante tiempo (>30min) se puede fijar la posición GPS de la sonda con bastante exactitud (<10cm), además el acelerómetro y los giroscópios el ángulo de apunte de la cámara y los movimientos que esta tenga. A partir de aquí se podrían hacer fotos de alta resolución a un bajo coste, incluso juntar varias fotos para realizar una de larga exposición (con los datos de los giroscópios y los acelerómetros se podría corregir las desviaciones por software).

Para elevar el conjunto (la cámara y la IMU) sólo nos hace falta un globo de helio y para anclarla y dirigirla nada más sencillo como una caña de pescar:“Skyfishing” with a GoPro HERO and 30 Helium Balloons from Tom Guilmette on Vimeo.

S2

Ranganok Schahzaman

domingo, abril 12, 2015

NSd(III): Android in Space

Una forma más o menos sencilla de tener una sonda es usar un móvil de última generación, estos disponen de GPS, GSM/GPRS/3G, Acelerómetros y/o giroscopios, cámaras con posibilidad de grabar vídeo (a veces incluso HD), etc.

Lo único que les haría falta es una transmisión radio con mayor alcance que la red móvil y ya trendríamos practicamente toda la sonda (exceptuando los sensores, claro). Y esto es lo que han hecho algunos ingenieros de Google, han cogido varios telefonos Nexus Galaxy S y los han puesto en 7 sondas. El resultado se puede ver en las imágenes y vídeos que ha grabado al efecto:
Nos enteramos de la noticia gracias a este post de Abadía Digital.

S2

Ranganok Schahzaman

domingo, abril 05, 2015

NSd (II): Vídeo

Una de las posibilidades que tiene la sonda es grabar vídeo desde las alturas.

Tener un vídeo del vuelo a la vez que los datos que va recogiendo la sonda nos puede dar una perspectiva mejor de lo que está pasando en cada momento. Sin embargo se nos plantea un problema, transmitir vídeo implica una gran cantidad de datos a transmitir por lo que o tenemos un ancho de banda importante (incompatible con la legislación de las frecuencias ISM).

Para distancias cortas (<1km) no tenemos tanto problema, podemos usar alguna de las frecuencias de ISM que se reservan para datos en banda ancha (en 868MHz serían desde 869.7MHz a 870MHz), estas frecuencias tienen el inconveniente de que tienen muy limitada la potencia a la que se puede transmitir (5mW de potencia radiada aparente (1)), pero tenemos una disponibilidad del 100% del canal (300kHz), aunque tendremos más posibilidades de sufrir interferencias.

Para largas distancias, al necesitar mayor potencia de transmisión, nos tendríamos que situar en la banda de 869.4MHz a 869.65MHz que nos permite una transmisión de hasta 500mW (de PRA) pero solo un 10% de tiempo de ocupación del canal, por lo que tendremos que:
  1. Reducir el tamaño del vídeo,
  2. 2.- reducir la velocidad de reproducción (fps)
  3. 3.- y/o comprimir el vídeo.

Reducir el tamaño del vídeo es relativamente fácil, lo único que necesitamos es que un sensor que capte distintos tamaños o descartar parte de la imágen para quedarnos con un tamaño menor (siempre que el sensor nos envíe los datos en RAW).

Reducir la velocidad de reproducción tambien es fácil (relativamente), sólo necesitamos descartar los frames intermedios. Aquí tenemos un problema ¿cuántas imágenes por segundo necesitaremos?, si utilizamos el vídeo para controlar un aparato (por ejemplo un cóptero) nos interesará tener tiempo real (25-30fps), sin embargo si sólo queremos tener una panorámica del entorno podremos transmitir con mucha menos frecuencia (1-2fps o incluso menor).

Comprimir el vídeo resulta más complicado que las anteriores, para esto necesitaremos un hardware independiente que nos haga el trabajo (existen drivers para sensores de cámara que ya lo hacen automáticamente) o un hardware bastante más potente que el que usamos (un PLD o FPGA, o un procesador ARM9 por ejemplo), sin embargo esto suele chocar con las necesidades de bajo consumo que tenemos. Si la frecuencia de envío es pequeña (1-2fps) podemos comprimir las imágenes como independientes (.jpg) que reduce los requerimientos de hardware para hacerlo, sin embargo no es la mejor opción.

Otra solución es no transmitir el vídeo, sino registrarlo para realizar el post-procesado, de esta forma podríamos tener un vídeo en alta calidad que sincronizaríamos a posteriori con los datos recibidos. Para ello únicamente tenemos que poder interactuar con la cámara que utilicemos, una opción que hace sistemasorp en este post.

De todas formas transmitir vídeo no excluye una segunda cámara registrando todo el viaje.

S2

Ranganok Schahzaman

(1) La potencia radiada aparente es aquella potencia con la que habría que alimentar una antena dipolo λ/2 para que, en un punto determinado del espacio, crease la misma intensidad de campo que un transmisor determinado, con ambas antenas dirigidas en la dirección de máxima radiación. (PRA (dBm) = Pt(dBm) + Gd (dBi) – 2.15dB)