Hace algún tiempo (bastantes años ya), vi en algún lado, a saber, un documental de la 2 de naturaleza, o quien sabe, en una de esas revistas de ciencias que tiene el peluquero de tu barrio mientras esperas hasta que llega tu turno, que los mosquitos no soportaban ciertos sonidos y tenían que huir lejos de la fuente emisora. En concreto, se trataba de un sonido, o más bien ruido de frecuencia 22KHz. No eché mucha cuenta salvo la de “dato interesante”, pero la sorpresa fue que un día navegando por Internet me topé con una página que decía que dicho mecanismo no sólo sirve para repeler a mosquitos, sino también para espantar a los jóvenes para evitar que se reúnan en las calles y molesten a los vecinos que no pueden dormir. Me quedé asombrado del dato y por lo visto se aplicaba en ciertos lugares de Londres... No sé hasta que punto es ese dato fiable y mucho menos eficaz. Me surgió la duda de ¿qué ocurre con los vecinos?¿están inmunizados? En fin, lo que si es cierto es que al generar este tipo de ruidos a ciertas frecuencias si resulta eficaz en algunos animales e insectos, pero con personas parece que no. La explicación más lógica tal vez se deba a que el oído humano sólo percibe sonidos comprendidos en el rango 20Hz – 20KHz, por lo que cualquier foco emisor que no esté en esa banda será inaudible por las personas y por consiguiente, tendrán poco efecto.
En este documento expondré varios mecanismos, algunos inventados ya, pero bajo poco estudio y falta de documentación, y otros son algunas soluciones o diseños que propongo.
Resulta que desde el momento en que me informé de ese dato, hasta hoy, cada año transcurrido con las llegadas de los veranos que han pasado desde entonces, suponía investigar un poco sobre el tema, por intentar construir mi propio repelente de insectos (sobre todo de mosquitos), no llegando nunca a llevar nada a cabo por falta de tiempo. Este año sin embargo me decidí a ponerme manos a la obra y he llegado a diseñar e implementar varios mecanismos, todos siguen la misma filosofía, pero cada cual es distinto y posee sus ventajas e inconvenientes.
Por tanto, pasaré ya a explicar cada uno.
En los primeros que comentaré, el mecanismo consiste en generar una onda de sonido, por lo que es necesario incorporar un altavoz, normalmente un zumbador, altavoz ultrasónico (piezoelectrónico), o en su defecto un tweeter (altavoz para agudos/altas frecuencias).
La cuestión principal radica en generar la onda y diseñar el sistema para lograr un buen alcance, ya que hay que recordar que las ondas mecánicas necesitan de un medio para propagarse, y que la energía de la onda mecánica decrece mucho más rápido con el aumento de la distancia que en el caso de las ondas electromagnéticas, esto se debe principalmente a la disipación de calor producida por el rozamiento de las partículas del aire.
Según dicen, parece que las ondas cuadradas afectan más que las ondas senoidales (a la misma frecuencia). No obstante, según los experimentos que he realizado, cualquiera de las dos producen los mismos resultados.
PRIMER DISEÑO.
El primer diseño, consiste en construir un circuito electrónico conectado a un altavoz. Algunos de los diseños planteados, tal vez ya lo hayáis visto en alguna ocasión. Básicamente la idea consiste en generar una onda cuadrada mediante los siguientes métodos:
1º Multibrivador astable con dos etapas
2º Oscilador astable con un timer (por ejemplo con un 555)
3º Con los timers de un microcontrolador
1º Multibrivador astable con dos etapas.
Se trata de una configuración bastante conocida ya para los que se dedican al tema de la electrónica. Se consigue generar una onda cuadrada mediante la carga y descarga de dos condensadores, en distintos períodos debido a la imperfección durante el proceso de fabricación de los transistores, existente entre las dos etapas (cada una formada por un transistor).
La explicación detallada del funcionamiento, la podéis encontrar http://es.wikipedia.org/wiki/Astable.
Simplemente hemos de tomar los valores de R (en la figura R2 y R3) y de C, de forma que se cumpla la ecuación:
Frecuencia (en Hz)= 1/(1.38*R*C)
2º Oscilador astable con un timer (NE555)
Se trata de una de las posibles opciones (como oscilador astable), que presenta este antiquísimo integrado. Dicha configuración aparece en su datasheet, por lo que no hay que complicarse mucho para implementarlo:
Simplemente hay que darle valores a las resistencias y condensadores. Jugando con las resistencias R1 y R2, obtenemos el periodo del semiciclo en el que la onda está en nivel alto (Th) y en nivel bajo (Tl), tal que cumplan las siguientes ecuaciones:
Tciclo = Th + Tl
Th = 0.7 * (R1 + R2) * C1
Tl = 0.7 * R2 * C1
Si la frecuencia (f) es la inversa del periodo (Tciclo), entonces tenemos que:
En el ejemplo, he puesto resistencias de valor R1=1Kohm, y R2=2Kohm aproximadamente, conservando el valor de C1=10nF (constante), por lo que la frecuencia de la onda cuadrada generada es de aproximadamente 28KHz. Dependiendo del tipo de insecto o animal que se quiere repeler habrá que variar la frecuencia. Para mayor alcance, simplemente hemos de aumentar la amplitud de la onda, o lo que es equivalente, aumentar el volumen del sonido, que en nuestro circuito se traduce en aumentar la tensión de alimentación del NE555, hasta cierto umbral marcado por el fabricante (ver el datasheet).
En la simulación podemos observar la señal de salida:
3º Diseño mediante microcontrolador
En este caso se utiliza un microcontrolador para generar la onda cuadrada. Se puede optar por un microcontrolador que posea modulación por ancho de pulso (PWM), para precisar más las características de la onda, pero dado que no es necesario ir más allá, seguiré el método usando un microcontrolador gama baja: el PIC 16F84. Para llevar a cabo este diseño hay que seguir dos fases. La primera es diseñar la circuitería para el microcontrolador y la segunda, diseñar el software (firmware) de éste. A parte de eso, se necesitará un circuito independiente para grabar el firmware en la memoria (EEPROM) de éste.
Existen dispositivos universales para grabar toda una familia de microcontroladores, pero a menos que no haga falta para otros proyectos, recomiendo montar en una placa el nuestro propio (específico para el PIC 16F84), ya que resulta más económico.
Hay buena documentación al respecto, pero de forma genérica se puede citar el programador serie COM84:
Las conexiones TXD, GND, RTS, DTR y CTS, corresponden a la conexión con el puerto serie del PC, que es en donde desarrollaremos el software a grabar. Este circuito no necesita alimentación externa para la grabación, ya que la toma a través del PC.
Una vez disponemos del grabador, diseñamos el circuito de nuestro repelente (lo más sencillo posible):
Con la herramienta MPLAB compilamos el siguiente código:
Código:
#include "p16f84a.inc" ; This includes PIC16F84A definitions for the MPASM assembler
STATUS equ 0x03
PORTB equ 0x06
TMR0 equ 0x01
INTCON equ 0x0B
org 0x00
goto INICIO
org 0x05
INICIO
bsf STATUS,5 ;banco 1
clrf PORTB
movlw b'00000000' ;divisor frecuencias por 2, asignado a TMR0
movwf TMR0
bcf STATUS,5 ;banco 0
BUCLE ;bucle principal
bcf PORTB,0 ;bit 0 PORTB a 0 (RB0 = 0)
call ESPERA
bsf PORTB,0 ;bit 0 PORTB a 1 (RB0 = 1)
call ESPERA
goto BUCLE
ESPERA
bcf INTCON,2
movlw 0xEC
movwf TMR0 ;cargamos el valor 0xEC en TMR0
FIN_C
btfss INTCON,2 ;¿fin de la cuenta?
goto FIN_C ;continuar hasta que TMR0=256
return ;fin cuenta, volvemos al bucle principal
end
Y generamos el binario (fichero con extensión .hex). Una vez lo tenemos, pasamos a grabarlo en el microcontrolador. Para ello podemos programarnos nuestra propia herramienta para transferir datos por el puerto serie (por ejemplo utilizando la estructura de datos DCB de Windows, y las funciones CreateFile, GetCommState, SetCommState, etc...). Para ello bastaría con atender al protocolo que usa el microcontrolador para recibir datos del puerto serie (nota que el PIC 16F84 no posee un bus SPI para ello, por lo que es necesario consultar el datasheet de este microcontrolador).
No vamos a programar nada aquí y ahora sobre transmisión del puerto serie, puesto que no es el objetivo en este momento. Si quieres optar por implementarlo, que sea únicamente con fines didácticos. En algún otro post comenté algo muy básico sobre el manejo del puerto serie: http://foro.hackhispano.com/showthread.php?t=33519#2. Pero sería recomendable obtener más documentación.
El método a seguir para la grabación del firmware será utilizando herramientas tipo ICProg (las cuales ya llaman a las funciones de la API que ya he comentado).
Si seguimos estos pasos, ya tendremos listo nuestro repelente de insectos, similar a los dos circuitos anteriores.
En la simulación, podemos observar la salida, mucho más limpia que con los anteriores diseños:
SEGUNDO DISEÑO
El segundo mecanismo consiste en implementar un software que aproveche las capacidades del PC, de forma que se consiga el mismo propósito que mediante el circuito anterior.
Existen ya aplicaciones, las cuales no estoy nada contento con su funcionamiento (o tal vez no supiera usarlo, y no voy a citar nombres de ningún programa), por lo que me vi obligado a diseñarlo yo nuevamente.
Hay dos formas de hacerlo, la primera es utilizando la función Beep, contenida en kernel32.dll para usuarios de Windows, y que comenté en la ezine nº1 de HackHispano, por lo que no voy a entrar en muchos detalles. No hace falta tarjeta de sonido, puesto que dicha función se encarga de aprovechar el contador interno del PC (8254 ó 8253), el cual se encuentra accesible en las dirección 42h del mapa de E/S independiente en la arquitectura x86. Dicho contador aprovecha la frecuencia del reloj del sistema (oscilador de cristal), por lo que si se opta por escribir en ensamblador la rutina, simplemente habría que programarlo adecuadamente, eso si, bajo versiones superiores a W95/98/ME, habría que codificar un driver, puesto que las instrucciones IN/OUT del procesador sólo son accesibles en modo supervisor. Por tanto, la forma más fácil es realizar las llamadas al sistema operativo mediante la función beep como dije, y que éste se las apañe como pueda para programar y acceder al contador para hacer sonar el altavoz interno.
A modo de ejemplo, el efecto similar al circuito anterior sería el siguiente fragmento de código:
Código:
#include <windows.h>
while(1){
Beep(28000, 1000);
}
TERCER DISEÑO
Como tercera opción, y solución al problema del volumen, podríamos aprovechar la tarjeta de sonido del PC y conectar los altavoces ultrasónicos a la salida de audio.
Tenemos el mismo problema, y es que podríamos implementarlo directamente mediante un driver de función que, por debajo conectara con el driver de bus PCI que nos ofrece el sistema operativo, y por encima, con la aplicación de usuario, o bien, aprovechando el driver de función que ya nos da el fabricante de la propia tarjeta (lo cual ya nos ahorra muchísimo código), y sólo tendríamos que realizar la parte de software correspondiente a las llamadas al sistema (API WIN32), es decir, la aplicación de usuario.
Dichas llamadas podemos realizarlas directa o indirectamente. Directamente bastaría con utilizar las funciones que ofrece el subsistema de la api win32, que se encuentran exportadas en las diferentes librerías (DLL’s). Indirectamente, consistiría en utilizar interfaces intermedias, por ejemplo mediante DirectSound, la cual se encargaría al final de realizar las correspondientes llamadas al sistema. La diferencia entre ambas radica principalmente en la facilidad y manejabilidad de las funciones, ya que normalmente una interfaz superior (como puede ser DirectSound) suele abstraer lo que se encuentra por debajo de ella, ahorrando gran parte de código engorroso.
Yo emplearé el método de las llamadas al sistema. El mecanismo es similar al comentado en la ezine nº4 de HackHispano: (articulo “Creando un osciloscopio”), por lo que no voy a entrar en detalles sobre estructuras de datos. La única diferencia radica en que en vez de usar las funciones WaveInXXX, utilizamos funciones del tipo WaveOutXXX, para escribir la estructura TWaveHdr (la cual contiene el puntero al buffer que contiene los datos de la señal a transmitir), en la memoria de la tarjeta de sonido.
Lo primero sería escribir el código para generar la señal que queremos que reproduzca la tarjeta. Para ello utilizamos un array de bytes de tamaño prefijado. En cada posición del array guardamos un valor comprendido entre 0 y 255 (puesto que utilizamos 8 bits por muestra, y 2^8 = 256, es decir, tenemos 256 posibles valores puede tener una muestra de la señal en un instante determinado).
Supongamos que tenemos un array de 64K elementos. La forma de obtener por ejemplo una señal senoidal de frecuencia 28KHz, y utilizando una frecuencia de muestreo de 11500 muestras por segundo, sería la siguiente:
Código:
for i:=0 to 65535 do begin
muestra_i:=sin(i*2*PI*28000/11025);
datos[i]:=Byte(Trunc(127*muestra_i+128));
end;
Y así tendríamos el array relleno con valores comprendidos entre 0 y 255, puesto que la señal senoidal está acotada en el intervalo cerrado [-1, 1].
Puesto que en los anteriores diseño hemos generando ondas cuadradas, aquí no íbamos a ser menos, así que podríamos hacer lo siguiente:
Si sin(x) > 0 => datos[i] = 255;
Si sin(x) < 0 => datos[i] = 0;
Si sin(x) = 0 => datos[i] = 0;
Una vez generada la onda y almacenada en el array (datos), completamos la estructura de datos TwaveHdr que será la que escribamos en la memoria de la tarjeta de sonido:
Código:
var
Onda: TwaveHdr;
Begin
...
Onda.lpData:=PAnsiChar(@datos);
Onda.dwBufferLength:=65536
Onda.dwFlags:=0;
Onda.dwLoops:=0;
...
end;
A continuación debemos indicar al sistema que queremos hacer uso de la tarjeta de sonido. Esto lo hacemos mediante la función WaveOutOpen(). En ella, debemos pasar como parámetro un puntero hacia una variable de tipo TWaveFormatEx.
En esta estructura de datos, indicamos el tipo de formato que utilizaremos, por ejemplo PCM, número de canales a utilizar (por defecto 1), bits por muestra, frecuencia de muestreo, etc...
Por último llamamos a las funciones WaveOutPrepareHeader() y WaveOutWrite(), para preparar y escribir los datos respectivamente en la tarjeta de sonido. En estas funciones debemos pasar como primer parámetro el identificador (handle) del valor devuelto por la función WaveOutOpen(), y como segundo parámetro un puntero hacia la estructura TWaveHdr.
Una vez realizado, cerramos todo lo que haya abierto, utilizando WaveOutUnPrepareHeader() y WaveOutClose(), con un pequeño matiz. Por un lado, si lo cerramos mientras se están leyendo los datos (del array “datos”), produciremos un error. Por tanto hemos de esperar a que finalice toda la reproducción antes de cerrar nada. Por otro lado hemos de tener presente que una vez reproducida toda la onda, ya no se volverá a reproducir más veces. Esto lo solucionamos por ejemplo mediante un bucle que se repita indefinidamente (o las veces que queramos, acorde a un tiempo de reproducción). Ahora bien, si en la segunda pasada del bucle se intenta reproducir nuevamente la onda mientras se estaba reproduciendo la anterior tenemos un problema de concurrencia que debemos resolver.
La forma de resolver la concurrencia la dejo en manos del lector, puesto que es un campo bastante amplio como para extender mucho más este texto . De forma general, los mecanismos existentes pueden ser la concurrencia, la sincronización y la comunicación. Podríamos ir desde la creación de hilos en el cual el primer hilo que ejecute el código desactive las interrupciones (instrucciones sti y cli de los procesadores de la arquitectura IA32) y las vuelva a activar una vez finalizada su ejecución, hasta la creación de eventos, por ejemplo usando las funciones CreateEvent() y ResetEvent(), pasando por la creación de semáforos, los cuales suspendan la ejecución si la tarjeta está en uso y la reanuden cuando deje de estarlo.
Por tanto, una solución mucho más sencilla (aunque no tan elegante, pero si mucho más simple), consiste en que sea nuestro propio proceso el que se suspenda durante el tiempo de reproducción y vuelva a continuar una vez finalizado. Para ello podemos hacer uso de la función sleep(), contenida en kernel32.dll, que recibe como parámetro el número de milisegundos que el proceso permanecerá suspendido. El problema radica en que no sabemos cuanto tiempo dura la reproducción. Bien, esto depende del tamaño elegido para el array de datos. Cuanto mayor sea el array, más tiempo tardará en reproducir toda la onda. La forma de obtenerlo según lo expuesto aquí, es la siguiente: si sabemos que tenemos 65536 muestras y utilizamos una frecuencia de muestreo de 11025 muestras por segundo, quiere decir que tardará aproximadamente unos 5.9443 segundos en reproducir toda la onda, además le añadiremos un margen de seguridad debido al error que se pueda cometer truncando decimales (La función sleep recibe un valor de tipo Cardinal).
El código final quedaría por tanto así:
Código:
const
frecuencia = 28000;
MAXBUFFER = 65536;
PI = 3.14159265358979;
var
FormatoOnda: TWaveFormatEx;
Onda: TWaveHdr;
fin: THandle;
idOnda: HWAVEOUT;
i: integer;
datos: array [0..MAXBUFFER-1] of byte;
muestra_i: Extended;
begin
while true do begin
ZeroMemory(@FormatoOnda, SizeOf(FormatoOnda));
FormatoOnda.wFormatTag:=WAVE_FORMAT_PCM;
FormatoOnda.nChannels:=1;
FormatoOnda.wBitsPerSample:=8;
FormatoOnda.nSamplesPerSec:=11025;
FormatoOnda.nBlockAlign:=FormatoOnda.nChannels * FormatoOnda.wBitsPerSample div 8;
FormatoOnda.nAvgBytesPerSec:=FormatoOnda.nSamplesPerSec * FormatoOnda.nBlockAlign;
FormatoOnda.cbSize:=0;
if (WaveOutOpen(@idOnda, WAVE_MAPPER, @FormatoOnda, fin, 0, CALLBACK_EVENT)<>MMSYSERR_NOERROR) then begin
ShowMessage('Error: No se ha podido abrir la tarjeta de sonido. Comprueba que está instalada correctamente');
Exit;
end;
FillChar(datos, MAXBUFFER, 128);
for i:=0 to MAXBUFFER-1 do begin
muestra_i:=sin(i*2*PI*frecuencia/FormatoOnda.nSamplesPerSec);
if muestra_i>0 then begin
muestra_i:=255;
end;
if muestra_i<=0 then begin
muestra_i:=0;
end;
datos[i]:=Byte(Trunc(muestra_i));
end;
Onda.lpData:=PAnsiChar(@datos);
Onda.dwBufferLength:=MAXBUFFER;
Onda.dwFlags:=0;
Onda.dwLoops:=0;
if (waveOutPrepareHeader(idOnda, @Onda, SizeOf(Onda))<>MMSYSERR_NOERROR) then begin
WaveOutClose(idOnda);
ShowMessage('Error: No se ha podido preparar la onda');
Exit;
end;
if (waveOutWrite(idOnda, @Onda, SizeOf(Onda))<>MMSYSERR_NOERROR) then begin
WaveOutClose(idOnda);
ShowMessage('Error: No se ha podido escribir en la tarjeta de sonido. Comprueba que no esté en uso');
Exit;
end;
sleep(((MAXBUFFER div FormatoOnda.nSamplesPerSec)*1000)+1000);
if (waveOutUnprepareHeader(idOnda, @Onda, SizeOf(Onda))<>MMSYSERR_NOERROR) then begin
WaveOutClose(idOnda);
ShowMessage('Error: No se ha podido vaciar el buffer');
Exit;
end;
if (WaveOutClose(idOnda)<>MMSYSERR_NOERROR) then begin
CloseHandle(fin);
ShowMessage('Error: No se ha podido liberar la tarjeta de sonido');
Exit;
end;
end;
end;
Si todo marcha bien, tendremos listo nuestro repelente de insectos a la frecuencia que queramos (indicada por la constante “frecuencia”), así mismo la duración de cada iteración. Por supuesto esta solución no es eficiente en cuanto al tema de concurrencia, pero no me gustaría desviar mucho más el tema de este hilo, quizás en otra cuestión que se plantee.
Conectando la salida de audio de la tarjeta a un altavoz para agudos (por ejemplo un tweeter) o bien a un altavoz piezoelectrónico, tendremos listo nuestro repelente de insectos.
En este diseño y en los anteriores mediante circuitos electrónicos, podemos observar la señal generada a través de un osciloscopio, pero si no disponemos de ninguno, podemos usar el planteado en la ezine nº4. Para este último diseño, bastaría con conectar la salida de audio a la entrada de micrófono mediante dos conectores jack.
CUARTO DISEÑO
En este diseño y en los restantes, se cambia la filosofía de tener que generar una onda sonora, y resulta que obtenemos el mismo efecto (y más limpio, ya que se elimina el efecto producido por la contaminación acústica), generando ondas electromagnéticas.
Este mecanismo es el que presenta la mayoría de los repelentes de insectos que anuncian en la TV... aparatos que cuestan un dineral a mi parecer, y que por supuesto no he comprado (ni compraré).
Dichos aparatos según decía el anuncio, generaban la señal por todo el cableado de la casa...
Cuando escuché ese dato pensé que eso era mentira, que no se puede alterar nada de la red eléctrica del hogar, puesto que si lo hacemos correríamos el riesgo de estropear el resto de electrodomésticos conectados a las tomas de corriente. Pensaba que se podría tratar de algo similar a la suma de dos señales senoidales, algo así como:
V(t) = [220 sen (2*PI*50*t)] + [A sen (2*PI*28000*t)]
La primera sería la llamada onda portadora (la de la red eléctrica a 50Hz en Europa), y la segunda sería la onda moduladora, la cual posee la frecuencia a la que se desea repeler a los insectos (por ejemplo los 28KHz que hemos estado usando hasta ahora). Si no se interfieren los electrodomésticos, pensé que tal vez la amplitud “A” de la moduladora debía ser muy pequeña, ya que en el instante en que ambas alcanzan su máximo valor tal vez se correría el riesgo de fundir más de un dispositivo.
Me inquietó el tema y decidí investigarlo, no obteniendo mucha información, tan sólo algo que me llamó la atención y que desconocia: El Protocolo X10.
Breve explicación al Protocolo X10
Este protocolo se usa en domótica para el control de dispositivos, aprovechando el cableado eléctrico del hogar.
Dicho protocolo establece (y cito textualmente) que “cuando la corriente alterna pasa por cero, entonces podemos enviar o no un pulso de 120KHz. Con la presencia de un pulso en un semiciclo y la ausencia del mismo en el semiciclo siguiente se representa un '1' lógico y a la inversa se representa un '0'”
Puesto que la corriente del hogar es corriente alterna trifásica, cuando se desea enviar por ejemplo un 1 lógico, se ha de sincronizar para enviar dicho pulso de 120KHz en las tres fases (se ha de conocer el desfase entre cada una de ellas para saber en qué instante colocar el pulso).
Con una secuencia de “envíos” o “no envios” de pulsos en los ceros de la corriente alterna, se puede enviar información digital a cualquier otro dispositivo del hogar, el cual puede interpretar o no (dependerá si posee la circuitería adecuada para anular la señal portadora, es decir, la corriente eléctrica). Los “paquetes” enviados formarían una secuencia de 11 bits, es decir, 22 pasos por cero de la corriente alterna.
el tiempo de transmisión de un paquete (11 bits), corresponderá por tanto con 220 ms para una corriente de 50Hz, es decir, si se producen 50 ciclos/segundo, y para enviar un paquete de 11 bits se necesitan 11 ciclos (22 pasos por cero), entonces 11/50 = 0.22 segundos.
Similitud con el repelente de insectos
Pues bien, si de verdad estos dispositivos que anuncia la TV repelen a los insectos aprovechando el cableado eléctrico, la única solución que se me ocurre es que funcionen de forma similar al protocolo X10. En vez de transmitir 120Khz como establece dicho protocolo, se enviaría la frecuencia a la que se desea repeler los insectos (por ejemplo 28 KHz), y en cada paso por cero, equivale a enviar un “1”.
Ahora bien, ¿en donde radica la potencia de éste método? puesto que el campo magnético generado en este caso, según la ley de Ampere, a través de los cables es pequeño, la onda electromagnética resultante también lo será. La potencia del mecanismo radica en que dichos campos son generados por cada uno de los cables del hogar. Esto se traduce en múltiples campos electromagnéticos repartidos por todos aquellos lugares que posean cables a lo largo de los suelos y paredes.
No obstante esto sólo son suposiciones, puesto que no dispongo de material para comprobarlo y desconozco su eficacia. Lo que sé lo expongo aquí por motivos didácticos.
QUINTO DISEÑO
Este diseño es el que expongo como solución alternativa. Si de verdad el cuarto diseño (el que anuncia la TV) funciona, es decir, las ondas electromagnéticas dan resultado para repeler insectos, entonces este también.
Se basa en un transmisor de radiofrecuencia que emite en principio una señal portadora de frecuencia la que se quiere para repeler insectos. Se podría a su vez sumar una onda moduladora a la anterior de frecuencia superior para repeler otro tipo de insectos. De momento no puedo ofrecer más información puesto que no lo he diseñado aún. En cuanto lo tenga os lo muestro.
VENTAJAS Y DESVENTAJAS DE CADA UNO DE LOS DISEÑOS EXPUESTOS
La principal diferencia entre los tres primeros diseños y los dos últimos como ya he dicho es que los primeros generan ondas sonoras y los segundos ondas electromagnéticas. Por tanto el análisis hay que enfocarlo desde este punto de vista.
Las ondas mecánicas (sonoras), a pesar de que en este caso no sean con frecuencias dentro del rango audible por el ser humano, presentan el inconveniente de la contaminación acústica. Si la amplitud (volumen) de éstas es bastante grande, por ejemplo para aumentar el alcance, se podría correr el riesgo de romper algún objeto. Recuerda que las ondas con mayor frecuencia (agudos) poseen más energía que las de baja frecuencia (graves). A su vez las ondas mecánicas poseen menor alcance que las electromagnéticas, ya que las primeras necesitan del medio para propagarse y se producen transformaciones de energía cinética de las partículas que vibran en calor, por lo que a medida que se propaga la onda sonora, va perdiendo amplitud, hasta el momento en que se desvanece, por lo que si generamos dos ondas, una sonora y otra electromagnética a la misma amplitud y frecuencia, la primera se habrá anulado antes que la segunda con el paso del tiempo.
Además de ésto, los tres primeros diseños necesitan de un altavoz especial (zumbador, piezoelectrónico o en su defecto un tweeter).
Con estas conclusiones, podemos deducir que los tres primeros diseños son para corto alcance, por ejemplo mientras estás con el PC, puedes ahuyentar los insectos, o bien, si es mediante circuitos, para hacerlos portables, llevándolos en un bolsillo (si el zumbador elegido es pequeño), mientras paseas por el campo, y los dos últimos (si es que de verdad funcionan las ondas electromagnéticas para repeler insectos), son para cubrir áreas más extensas, por ejemplo una casa.
Por último, hay que comentar un detalle importante. Parece ser que algunos insectos, pasado un tiempo, consiguen adaptarse a la señal que enviemos, por lo que todos estos inventos se pueden fastidiar si no inventamos algo que lo solucione. Como solución se puede proponer el ir cambiando periódicamente la señal generada, de forma que durante cierto tiempo (unos dias) se genera una señal de frecuencia X, y a los dias siguientes subimos por ejemplo a frecuencia X+Y (dentro del rango al que no lo soportan).
Otra cuestión es que si deseamos un repelente "universal", es decir, que nos ahuyente todos (o casi todos) los insectos posibles, lo primero es que es necesario conocer las distintas frecuencias que no soportan cada familia de insectos. Como solución a esto se puede pensar en realizar un turno rotatorio (con un cuanto o ranura de tiempo de unos segundos o pocos minutos), con cada una de las frecuencias a emitir. Por ejemplo, durante 1 minuto se espanta a los mosquitos (frecuencia X), durante el minuto siguiente a las moscas (frecuencia Y), al siguiente a los roedores (frecuencia Z), etc... No obstante esto lo dejaremos para la versión 2 de estos diseños 
En fin, espero que os hay gustado o que os haya sido de utilidad.
Un saludo.
Marcadores