Me he pasado dias y dias mirando los graficos que publique en la entrada anterior y otros similares, y como no puede ser de otra forma les he sacado mil pegas.

La primera, es de formato, tanto el CSV, como esos png’s que se generan son bastante inmanejables. Archivos de 600 Mg en texto plano con los datos no es precisamente el formato más cómodo, y los png’s de 80 Mg tampoco. Ademas, con todos esos datos procesados, se podían hacer bastante mas cosas si los tuvieramos en un formato adecuado

Así que me he puesto manos a la obra, a intentar buscar otra alternativa. La primera pasar eso a un formato un poco mas manejable, a falta de una opcion mejor, he optado por volcarlo a un SQL, concretamente SQLite (al menos para empezar)

python RTL-db/rtl2sqlite.py 622M-722M-2k-20150726-17\:00\:39.csv 622M-722M-2k-20150726-17\:00\:39.sqlite3

 

Programar no es lo mio, lo reconozco, pero por ahora que funciona. Acabamos de pasar un CSV infernal a una tabla donde poder programar despues las consultas que necesitemos. E

Para que nos hagamos una idea de como afecta, vamos a utilizar como ejemplo una captura de 1h y un Megaherzio

$ ls -lah 93-94-1k-60m* -rwxrwxrwx 1 ptolomeo ptolomeo 29M ago 1 16:11 93-94-1k-60m.csv -rwxrwxrwx 1 ptolomeo ptolomeo 121M ago 1 16:13 93-94-1k-60m.sqlite3

Por de pronto a nivel de espacio en disco ya vemos que ocupa unas 4 veces mas. es el precio por tener las cosas un poco mas estructuradas :). Veamos un poco mas de informacion de lo que tenemos dentro

$ sqlite3 93-94-1k-60m.sqlite3 sqlite> .schema CREATE TABLE freqdata(freq INTEGER, timestamp INTEGER, weight INTEGER,dbm REAL); sqlite> select COUNT(freq) from freqdata; 3690000 sqlite> select COUNT(distinct(freq)) from freqdata; 1025sqlite> select MIN(freq) from freqdata; 93000000 sqlite> select MAX(freq) from freqdata; 93999997.44 sqlite> select COUNT(distinct(timestamp)) from freqdata; 3600

Es facil de resumir, 1 Mhz de analisis (entre 93M y 94M) separado en 1025 tramos y medido 3600 veces, total casi 3,7 Millones de mediciones.

Pintandolo de la misma manera que hasta hora con el heatmap.py, nos queda algo así. Coincide como veis con unas emisiones de radio FM sencillitas y que se pueden ver bien.

La verda es que estuve mirando el codigo fuente del heatmap.py para ver si lo podia adaptar a obtener los datos del sqlite y tuve que desistir. Sinceramente, pintar unos datos bien estructurados no debía ser tan dificil.

ASí que la segunda parte del ejercicio ha consistido en precisamente eso, extraccion de los datos del SQL y representacion grafica.

Para eso vamos a tirar de nuevo de python y de una gran libreria cientifica que es el matplotlib, tiene una cantidad ingente de representaciones graficas y de posibilidades de calculo.

Contando que tenemos un array completo y sus valores, simplemente hay que alimentarlo tal cual a una de sus opciones gráficas. Tengo bastante dudas en cuanto al rendimiento viendo lo rapido que crecen los archivos,  pero por ahora el resultado parece bastante razonable.

¿Que os parece? Tengo que ver bien como poner las etiquetas de los ejes. Ahora lo siguiente es ver si aprovechando que tenemsos los datos, podemos procesarlos de manera un poco mas seria. Pero eso ya sera en la siguiente entrega 🙂