Estancia de doctorado en el CONNECT – Centre for Future Networks and Communications

Como parte de su doctorado, nuestro compañero Ramiro Utrilla acaba de comenzar una estancia de investigación en el CONNECT – Centre for Future Networks and Communications. Este centro de investigación, financiado por la Science Foundation Ireland y el Fondo Europeo de Desarrollo Regional (FEDER), está constituido por miembros de las principales universidades de Irlanda y centra su actividad en el desarrollo, innovación e investigación de las telecomunicaciones.

Durante los 3-4 meses que dure la estancia, Ramiro estará trabajando en el grupo del Prof. Luiz Da Silva. Una de las líneas principales de investigación de este grupo es la aplicación de Inteligencia Artificial y Machine Learning al ámbito de las comunicaciones.

El objetivo de esta colaboración consiste en abordar el problema de la saturación del espectro, y la coexistencia de los dispositivos que operan en él, desde el punto de vista de los nodos finales, aquellos con más bajos recursos computacionales y energéticos. Para ello, es necesario trasladar el paradigma de la Radio Cognitiva a las características específicas de este tipo de sistemas.

En concreto, la primera aproximación consistirá en adaptar y evaluar técnicas de sensado espectral basadas redes neuronales a MIGOU, la plataforma de Radio Definida por Software de bajo consumo desarrollada por Ramiro durante la primera etapa de su tesis.

Estamos muy ilusionados con esta colaboración entre el CONNECT y el B105 ya que consideramos que su conocimiento en Inteligencia Artificial junto con nuestras capacidades técnicas de implementación pueden dar resultados muy interesantes y novedosos.

¡Os seguiremos informando!

TFM: Development of a protocol for the wireless communication of monitoring data for real- time representation

With the development of the IoT, the number of devices of different nature and size
that are distributed throughout the environment has increased enormously, generating data
continuously. These data can often be processed where we generate them. However
sometimes we can not have enough computing power to do it or we want to access them
remotely to see the correct functioning of a system or for example to store them in a
database.
With this background it makes necessary to develop an electronic system that can be
conected in an easy way to the place where we are generating the information and transport it
to our central node. For our particular case, we aspire to establish a real time stream in order
to represent the data in a graphic, in order to give to the user a proper view of the
performance of his sensor node.
We have developed a WIFI gateway that allows this automation that we have
explained. We have used the Zentri AMW 106, an ultralow consumption WIFI module who fits
perfect in our requirements. We can attach via serial (using UART) to our electronic system to
the module where we generate the data and creating a TCP-IP client send to our server
wirelessly.
We have also made an effort in develop an user friendly application in the server side.

This application has the ability of representing the data we are sending in real time and at the
same time to store in a file having a register. This register can be accessed to consult the
values obtained in a certain time.

PFC: Analysis and Design of a Control and Management System of the Integrity and Load of Trains in the Underground Work based on a Wireless Sensor Network (WSN)

Building or remodelling large underground areas, such as tunnels, are very complex
projects where there are some very specific needs and dangers.
Historically it has been considered that tunnels were dangerous places and therefore it
was inevitable that fatal accidents took place during construction works. In fact, there
have been many casualties in tunnels under construction. However, nowadays, tunnel
safety is an essential aspect all over the European countries and particularly, in Spain.
Also, it is equally important the construction work management during construction
phase: effective management of resources (workers, raw materials, tools, etc.) within
the tunnel and the machinery involved, with the ultimate goal to improve the
effectiveness and efficiency of the construction site. Most of the mentioned resources
are moved by trains, due to their great ability to transport huge amount of materials
using less time/effort.

 

Many of the measures taken in tunnels, and particularly on trains dedicated to this kind of works, are done manually and with the constant intervention of operators and maintenance personnel which may, in some cases, lead to errors, planning delays and as a result, to increase the final cost of the work. In the case of traffic control and railway equipment inside tunnels, mechanisms for monitoring and management are scarce and usually insufficient for proper operation; these environmental, structural and traffic control mechanisms, become critical during indoors construction work.

Therefore it is necessary the development of a system able to: firstly, immediately detect any problem in the train or in the tunnel infrastructure, react quickly and mitigate effectively the possible consequences; and secondly, able to manage train traffic, detecting at all times the position of each train or other machinery(such as trucks) accurately and safely. The system shall manage and act effectively and quickly with all those measures, parameters and location coordinates.

The first objective of this project was to provide key solutions for wireless seamless connectivity and interoperability in rail tunnel infrastructures by considering everyday physical environments of trains which will significantly contribute to decrease incidents and accidents at work, as well as to the optimization of the works of the rail machinery in terms of time, project costs and operation and maintenance of the equipment and facilities.

As a result of the project, it was implemented a prototype capable of managing freight trains at construction work sites, able to prevent disasters and accidents at building (or refurbishment) stage in large underground areas such as tunnels.

The solution designed and developed is able to reduce the effort and time required for integrating WSN solutions and services into tunnel works, railway safety-related and multipurpose systems, and to reduce maintenance costs of on-board WSN services by providing a single general integration indoor platform for wireless sensors and wireless communication services, with centralized and standard interfaces for existing systems.

How to deploy a Node-Red environment on a GCP instance

Son numerosos los tutoriales en Internet que explican cómo montar un servidor Node-RED sobre GCP haciendo uso de clústers. Sin embargo cuesta encontrar (si es que los hay), tutoriales sobre como desplegar dicho servidor en una instancia, por lo que en este tutorial, nos centraremos en este caso. ¿Te suena a chino todo lo que hemos dicho? ¿Por qué montarlo sobre una instancia y no un clúster? Expliquemos brevemente los conceptos más raros de la frases anteriores para entendernos mejor.

  • Node-RED: es una herramienta de programación, de libre distribución, la cual nos permite de una forma rápida, y sobretodo muy intuitiva, desplegar una web con un estilo moderno y funcional. Node-RED hace uso de la programación “en cajas”, en la cual interconectamos distintos bloques ya pre hechos de las librerías disponibles. Node-RED usa Javascript y permite introducir bloques con nuestro propio código, pero para las tareas más sencillas no será siquiera necesario saber Javascript. Un ejemplo de un desarrollo simple en Node-RED sería el siguiente:

node_red_example

Node-RED permite además añadir librerías creadas por usuarios, siendo la librería “dashboard” una de las más populares, pues incorpora cajas con elementos visuales que permiten la interacción con el usuario así como la visualización de datos. Un ejemplo de ello:

maxresdefault

¿Fácil, verdad? Quien diría viendo esa web que se ha hecho sin necesidad de saber ningún lenguaje, solo juntando las cajas correctas. Existen otras opciones, como thingsboard.io, pero para gustos los colores, además de no ser la mayoría gratuitas (o tener planes gratuitos muy limitados). Nosotros preferimos Node-RED porque integra soporte para comunicaciones por UDP, TCP y el reciente MQTT, lo que permite comunicaciones con cualquier tipo de dispositivo, especialmente con dispositivos IoT. Además, la comunidad de desarrolladores es enorme y podemos encontrar muchos ejemplos ya hechos para su libre distribución, siendo estos ejemplos a veces, justo lo que buscamos.

Tenemos muchas formas de ejecutar Node-RED, en nuestro PC (esto es corriendo en un servidor local), en páginas que ponen a nuestra disposición servidores ya montados y listos para empezar a trabajar (FRED) o en servidores virtuales privados (VPS) de los cuales hay cientos de ofertas en Internet (aunque destacan por su catálogo y precios Microsoft Azure, Amazon Web Services [AWS] y Google Cloud Platform [GCP]). Las ventajas de ejecutar nuestro entorno en un VPS frente a nuestro ordenador o un entorno ya hecho (y cerrado) son inmensas: disponibilidad total, herramientas de protección, escalabilidad, no compromiso de nuestros datos privados, gestión de recursos… y esas son solo alguna de ellas.

  • Google Cloud Platform: es uno de los tantos servicios de gestión de VPS que hay hoy en día. Si bien es cierto que uno de los que más fuerza tiene es AWS, Google ofrece algo que no ofrece el resto: un servidor gratuito al año con 24/7 en ejecución. Vale que es un servidor muy modestito (10 GB de almacenamiento; 0.6 GB de RAM y un único procesador), pero es gratis y para diseños simples puede ser más que suficiente. Es por esto que nos centraremos en este gestor VPS en este tutorial.
  • Instancia vs. cluster: Google denomina a cada uno de los VPS que creamos instancia. Un grupo de instancias trabajando de forma conjunta, compartiendo recursos y distribuyéndose el tráfico de red entre ellas forma un clúster. Claro, a priori parece que el clúster es mejor (y lo es), pero no es gratis. La instancia, sin embargo, sí. Siempre y cuando esa instancia sea de las más simples de Google, como ya hemos comentado antes.

Ahora que ya hemos explicado todo un poco, relee si quieres el primer párrafo del post. Ahora ya parece obvio por qué queremos desplegar Node-RED (y no otro) sobre una instancia (y no un clúster), porque…

free

 

Empecemos…

Lo primero, lógicamente, es tener una cuenta de Google activa. Nos dirigiremos a la consola de Google Cloud y activaremos nuestra cuenta, registrándonos en la versión de prueba gratuita.  Solo por registrarnos Google nos regala 300 $ en servicios GCP. Para nuestros propósitos no nos harán falta, pero nos vendrán genial si queremos cacharrear con todas las opciones que GCP ofrece. Completaremos todos nuestros datos (incluida la tarjeta de crédito, pero no pasa nada: Google nos avisará previamente en caso de que hiciéramos algo que incurriera en un desembolso). Tras registrarnos se nos creará nuestro primer proyecto (que podremos renombrar si queremos pinchando en configuración de proyecto).

En el buscador escribimos Compute Engine y en la nueva ventana, una vez cargue, creamos una nueva instancia, con la configuración que vemos en la siguiente imagen:

g1
La zona da igual siempre que sea en América (salvo Virginia del Norte). América es la única región con VPS gratuitas. El tipo de máquina ha de ser micro y permitir el tráfico HTTP y HTTPS. Nosotros hemos elegido Ubuntu por familiaridad con los comandos, pero cualquier otra distribución de las gratuitas que ofrece Google es válida. Notad que para saber que estáis siguiendo los pasos correctos, debe apareceros el texto de la derecha donde os informa de que la máquina seleccionada es gratuita. Pulsamos en crear y esperamos.

Una vez creada, hay diferentes cosas que sería interesante hacer antes de empezar a cacharrear (asignarnos una IP estática y abrir algunos puertos).

-Asignando IP estática podremos entrar en nuestro servidor sin necesidad de consultar qué IP nos ha concedido Google esta vez: siempre será la misma. Para ello escribimos Red de VPC en el buscador y entraremos en la sección del menú lateral izquierdo “Direcciones IP externas”. Seleccionaremos nuestra instancia y cambiaremos su tipo a estática. Le ponemos un nombre identificativo a esta IP y aceptamos.

-Abriendo puertos (bien sea TCP o UDP) permitiremos un acceso remoto a nuestro servidor. Hay que notar que esto es un arma de doble filo, pues si bien no podemos hacer mucho sin tener acceso a nuestro servidor remoto también es una puerta abierta a hackers, por lo que recomendamos abrir solamente los puertos que vayamos a necesitar. En nuestro caso será obligatorio abrir el puerto TCP 1880, pues será el que usará Node-RED tanto para la interfaz de diseño (donde colocaremos las cajitas) como para la interfaz web (donde nos mostrará el resultado de colocar y conexionar esas cajitas). Para ellos tecleamos en el buscador “Reglas de cortafuegos” y elegimos la opción que lleve también escrito Red de VPC.

Creamos una regla nueva:allowtcp

 

El nombre es opcional, todo lo demás, recomiendo dejarlo a esos valores. Cuando cojáis más soltura con GCP os recomiendo etiquetar vuestras distintas instancias para poder elegir destinos de reglas del cortafuegos y así que cada máquina tenga abiertos los puertos que necesita. Por ahora, y como solo tenemos una máquina creada, no pasa nada por aplicar en el campo destinos “todas las instancias de la red”. Guardamos y ya estaremos listos para empezar la instalación de Node-RED sobre nuestro VPS.

Volvemos a la vista de Compute Engine, donde estará nuestra instancia. En el campo “Conectar” pulsamos sobre SSH. Se nos abrirá una ventana nueva y cuando cargue ya estaremos dentro de nuestro VPS.

Para poder empezar a trabajar, tecleamos los siguientes comandos:

Nótese que entre los comandos, se instalará nodejs. En nuestro caso hemos instalado la versión 8.x por ser la recomendada en el momento de realizar este tutorial, pero se aconseja mirar en la página de nodejs cual es la última versión recomendada. Escribimos ahora el comando que instalará Node-RED en nuestro VPS.

Es también interesante instalar algunas herramientas de node-red que nos harán más fácil la gestión de nuestro servidor, por lo que teclearemos:

Después de esto ya podemos probar que Node-RED está correctamente instalado. Para ellos tecleamos:

Lo que debería arrojar en el terminal una salida que acaba con:

Esto es indicativo de que todo está correcto. ¡Probémoslo! Escribamos en nuestra barra del navegador la IP estática concedida por Google (sin http ni https delante seguida del puerto de acceso a Node-RED, separado por dos puntos “:”), algo así como 123.123.123.123:1880. Deberíamos ver esto:

node-red1

 

¡Todo funciona! Sin embargo esto presenta un enorme, enorme inconveniente: cualquiera que sepa nuestra IP puede acceder a nuestro servidor Node-RED y borrarnos todo el trabajo o inyectar código malicioso. Por ello, el siguiente paso, de vital importancia, es proteger nuestro servidor. Volviendo a la terminal abierta por SSH, pulsamos ctrl+C para parar la ejecución de Node-RED y escribiremos:

Lo que nos preguntará por la contraseña con la que deseamos proteger el servidor. Tras escribirla y pulsar intro, nos devolverá una secuencia hash con nuestra contraseña encriptada, que deberemos copiar, pues usaremos ahora. Escribiremos sobre el archivo de configuración de Node-RED. En el terminal tecleamos:

y dentro de este archivo buscaremos el siguiente texto:

adminAuth: {
type: “credentials”,
users: [{
username: “USUARIO“,
password: “HASH_GENERADO“,
permissions: “*”
}]
},

// To password protect the node-defined HTTP endpoints (httpNodeRoot), or
// the static content (httpStatic), the following properties can be used.
// The pass field is a bcrypt hash of the password.
// See http://nodered.org/docs/security.html#generating-the-password-hash
httpNodeAuth: {user:”USUARIO“,pass:”HASH_GENERADO“},
httpStaticAuth: {user:”USUARIO“,pass:”HASH_GENERADO“},

En usuario escribiremos el usuario que queramos, y en los campos password y pass, el hash generado anteriormente. La primera parte protegerá la parte de gestión (donde colocamos las cajitas), la segunda, la parte de visualización (la web que crean las cajitas). Es importante descomentar las lineas necesarias (esto es, eliminar los caracteres “//” con los que empiezan algunas lineas), para que el resultado quede tal y como hemos puesto arriba. Guardamos con CTRL+O y salimos con CTRL+X.

Por último, será interesante que nuestro servidor cargue automáticamente Node-RED cuando se reinicie, lo que hará más tolerante a fallos nuestra implementación. Para ello, escribimos:

Que nos indicará nuestro nombre de usuario. A continuación:

donde copiaremos el siguiente texto:

[Unit]
Description=Node-RED
After=syslog.target network.target

[Service]
ExecStart=/usr/bin/node-red
Restart=on-failure
KillSignal=SIGINT

# log output to syslog as ‘node-red’
SyslogIdentifier=node-red
StandardOutput=syslog

# non-root user to run as
WorkingDirectory=/home/TUUSUARIO/
User=TUUSUARIO
Group=TUUSUARIO

[Install]
WantedBy=multi-user.target

Hay que modificar solo los campos en rojo. Nuevamente, guardamos con CTRL+O y salimos con CTRL+X. Activamos el servicio creado escribiendo:

Comprobaremos que todo se haya hecho correctamente. Para ello primero es necesario reiniciar, por lo que escribimos:

Y tras esperar unos dos minutos, cargamos de nuevo la página con la IP del servidor en nuestro navegador. Ahora, al cargar node-RED debería pedirnos login, tanto a la parte de gestión como a la de visualización.

¡Eso es todo por nuestra parte! Ahora, a jugar.

TFM: DESIGN AND IMPLEMENTATION OF NODES FOR CONTINUOUS MONITORING OF STRUCTURES BASED ON MEMS ACCELEROMETERS AND POWERED BY SOLAR ENERGY

Monitoring of large structures, such as buildings or bridges, is a very important task and must be done constantly, due to the danger that can lead to a sudden failure of these. These failures can cause a large number of damages, not only material, but also human losses.

This project aims to design and implement a system that is capable of monitoring the vibrations of a certain place and must also be energetically self-sufficient. For this, the main purpose is to implement a node of this type based on a MEMS accelerometer and powered by solar energy and batteries. The developed monitoring node must be a low power system because it must be able to work autonomously for long periods of time. This will be achieved through the implementation of a power system based on an external battery recharged by solar energy. For the measurement part, accelerometer data will be collected every so often and stored on an SD card for later reference.

The B105 Laboratory has several types of PCBs that have different modules needed to carry out this project (accelerometers, battery management, SD card …). For the development of the hardware it was decided to take advantage of the PCBs already designed. The modules and components to be used were chosen and subsequently welded with two different techniques: manual and by oven.

The software was programmed in C language and it was decided to perform 3 different implementations: first, software was designed on bare machine to check the correct functioning of the measurement module; Later software with operating system was developed to optimize the performance of the system; Finally, tests were performed measuring vibrations with the accelerometer and stored on the SD card to obtain final results and conclusions.

TFG: Design and implementation of an access control system based on NFC technology

 

The B105 Electronic Systems Lab has an electronic access system in its door based on a Radio Frequency Identification (RFID) card reader. This system was developed more than 12 years ago so the technology it uses is obsolete and several of its features are out of use. The development of this degree project is intended to implement an alternative to this access control system based on Near Field Communication (NFC) technology.

The RFID system requires the use of physical cards, which are easily misplaced and force the user to carry them around with him/her to enter the laboratory. To solve this problem, the new system allows the users to open the door using their smartphone. This makes it even easier to enter the laboratory, as users always have their mobile phone with them. In addition, users are assigned specific entry times, providing greater security and a better access control to the laboratory.

There is an equipment reservation management service in the laboratory that already has a database of members, an application and an administration website. Therefore, these resources have been used to facilitate the implementation of the new system and avoid data replication on the server.

Once the system has been implemented, any user who is registered in the system and has certain permissions can open the door by bringing their mobile phone closer to the reader. To achieve this, the existing access system has been built on and relevant technologies have been studied.

The development and implementation work has been divided into three blocks: the NFC reader, the application and the server. The reader, integrated into the door opening system, acts as an intermediary between the application and the server. On the other hand, the application only has to emulate the access card and send the entry request. Then, the server evaluates this request checking the user information and its database and it sends a response to the reader. Depending on the message received, the reader opens the door or not and finally informs the user of the decision.

TFM: Design, implementation and testing of controllers for USB 2.0 communication between a software-defined radio system and a PC

Massive and rapidly increasing use of wireless devices is raising concerns about eventual saturation of the available spectrum in wireless communications, known as the spectrum scarcity problem. This issue is especially relevant for power- and resource-constrained devices, even more when considering the largely variable and adverse environmental conditions radio channels are usually subject to.  Considering the case of a network of sensor nodes, a smart approach to face this problem is the use of Cognitive Wireless Sensor Networks (CWSNs), which consist in networks capable of modifying their communication parameters depending on the environmental conditions.

One of the ongoing research lines of the B105 Electronic Systems Lab focuses on the development of low-power CWSNs by designing sensor nodes using a Software-Defined Radio system (SDR). Specifically, an architecture based on the Atmel AT86RF215 transceiver and the SmartFusion2 System-on-Chip (SoC) is used to carry out certain cognitive tasks.

The specific objective of this project was to implement communication between the aforementioned elements and a personal computer (PC). To achieve that, a Printed Circuit Board (PCB) was developed to serve as an interface platform between the different hardware elements in the system. Then, the controllers required to manage communication between the transceiver, which acts as data source, and the PC, which is the receiver, are implemented on the FPGA embedded in the SmartFusion2 SoC.

For the successful realization of this project it was necessary to carry out both hardware and software development tasks. In addition, the programming languages C and VHDL were used, as well as the communication standard protocols Serial Peripheral Interface (SPI) and Low Voltage Differential Signaling (LVDS).

TFG: Analysis and design of an energy harvesting system for human body

The aim of this project, was to design a functional prototype for the transformation of energy based on the principle of piezoelectricity, in order to harvest the energy produced. After some research, this is determined to be the best postulate to generate electrical power at a low scale for applications in electrical systems that require low voltage power supply, working as a stand-alone power to charge both, medical and electronic devices.

When a piezoelectric material is exposed to mechanical deformation, a voltage is produced. The theoretical behaviour can be appreciated in the following image:

piezoelectricity

Therefore, the energy that can be harvested depends on two factors: the properties of the piezoelectric material and the amount of deformation applied to the material.

Some of the materials that show piezoelectricity are: quartz, lead zirconate titanate (PZT), aluminum nitride (AlN), zinc oxide (ZnO) and polyvinylidene fluoride (PVDF).

The special property of these piezoelectrics is that it allows them to convert physical energy into electricity, AC. However, we need DC, not AC to power devices. This problem can be solved creating a rectifier bridge with diodes to convert the power from AC to DC, and thus be able to use it.

Although piezoelectric elements generate a lot of voltage, they do not generate many amps. We can solve this problem by wiring all the piezoelectric elements in parallel

Taking into account all the mentioned above, the prototype that has been created is formed by 7 PZT piezoelectrics of 35 mm diameter, as shown in the picture at the top pf the page.

Finally, it has been proved, when charging some capacitors, that it is better to have the shoe sole outside, placed on a smooth surface (as a carpet) and then making pressure on them. In such a way, the most relevant results were obtained. The capacitors were charged more quickly than while walking with the shoe sole inside. The order of magnitude of the power generated by this assembly was mW, and the energy generated was in the order of mJ.

PFC: A Modular-Reconfigurable Presentation System Design and Implementation Based on LEDs

This project “A modular-reconfigurable presentation system design and implementation based on LEDs” consists of a LED screen design and development at hardware and software level, features cited in the name of this project.

In order to approach its design, we have started making an art state investigation, through which some similar projects to this one have been looked into.

Next, we carried out a hardware design and implementation. During this stage two hardware versions were developed.

Then, the software design and development have taken place. A first software stage is executed by the PC and the other stage is executed by the microcontroller. During this phase of the project we have developed many block versions which made the software architecture up.

Later, different hardware and software level tests were performed.

Finally, some full system tests were also carried out.

The project has been developed in seven phases as shown as per below chart.

2

As said before, the presentation system is made up of a hardware and software structure. The hardware structure is constituted by some elements, from which It is emphasized the relevant LED screen and the development board that includes a microcontroller. The software structure has been coded at PC and within a microcontroller too. This main project aim has been to desing a modular system presentation and resettting based on LEDs.

The main objective is broken down into four purposes

  • Draw up a modular and reconfigurable LED screen.
  • Develop a microcontroller software to allow using the LED screen.
  • Develop a software by PC to display a photo on the LED screen.
  • Develop a software by PC to display a video on the LED screen.

It is relevant to clarify that every pixel of this screen is encoded by 24 bits. These bits are G7, G6, G5, G4, G3, G2, G1, G0, R7, R6, R5, R4, R3, R2, R1, R0, B7, B6, B5, B4, B3, B2, B1, B0 as shown as per below chart.

3

The hardware architecture is a set of physical blocks through which this system is based on. In the basis of the system outcome and the hardware requirement some hardware architecture blocks have been defined.  The hardware architecture that makes up the bits is described as per below.

  • PC: It executes processor-transmitter software blocks.
  • USB-serial converter: It Carries GRB bits forward to microcontroller.
  • Microcontroller: It executes receiver-presentation software blocks.
  • Logic level converter: It goes the amplitude up from the PWM to the microcontroller pins GPIO output, from 3.3 [V] to 5 [V].
  • LED screen: It is made up of LED modules. Each module has 25 LEDs. For LED modules manufacturing purposes some LEDs SMD 5050 have been chosen, these LEDs mix an integrated circuit enclosed in. This circuit incorporates a signal amplifier and depending on the manufacturer also a sequential logic block. This way, the signal is empowered through each LED and 24 bits data is addressed to, from which 8 bits are related to sub LED G, 8 are linked up  to sub LED R and 8 bits are connected to sub LED B. So that, color and bright are separately controlled for every LED.
  • Power supply: It is setup into a star topology. Supplies 23 [A] to the system.

By means of next chart, hadware arquitecture is shown as per below.

4

The LED screen is composed by four module rows of LEDs, each module row is assigned by a data line as per below.

5

For the LEDs screen, it has been decided to use several parallel data lines, due to it aims to overcome a LEDs handicap. This handicap consists of when broadcasting a 30 [frames/s] – streaming video. It does not allow to connect more than 1024 LEDs into serial architecture. Essentially because of timing  purposes. Which are exposed by means of this reasoning: If the rate to broadcast this video is 30 [frames/s], this indicates every 0.033 [s] a frame to display on LEDs is loaded. Tframe = 0.033 [s].

On the other hand, Tbit=1,25 [µs] which is a value forced by the LEDs.

As discussed earlier in this report, 24 bits are related to every single pixel, immediately after sending all bits towards the LEDs, a time must be saved for a 50 [µs] reset. This way, sending period expression, it is as it follows:
Tsend = ( 1.25 [µs/bit] x 24 [bits/pixel] x 1024 [pixels] ) + Treset = 0.03077[s]

Checking out on, Tsend < Tframe.

That is, this limitation resides in central premise that, sending time cannot be greater than frame time, whether more than 1024 LEDs are connected in cascade architecture, it is need a time greater than frame time, therefore it breaks that premise.

For the case in which the rate to broadcast this video is 60 [frames/s], could be linked into  cascade connecting factors up to 512 LEDs.

Therefore, there is an inversely proportional relationship between the video rate broadcast and the number of LEDs to be connected in cascade.

The software architecture is composed by two phases, one developed to PC and another to microcontroller.

In the PC phase, processor and transmitter blocks have been processor defined. This stage consists about reproducing a video signal and executing some processor and transmitter blocks for each frame from the video signal.

In the microcontroller phase, it is been defined both receiver and presentation blocks. In this stage continuously some bytes are received through UART and are shown on the screen.

The next diagram shows the software architecture.

6a

Now we describe the software blocks functions

  • Processor block: This block extracts the pixels from each frame and it organises them according to the data line of LED screen. Then, it moves these GRB bits to the corresponding bit of data line and then it stores those GRB bits in an array.
  • Transmitter block: This block is in charge of transmitting in serial the array obtained in the processor block.
  • Receiver block: This block receives in serial the bytes of array transmitted by the transmitter block. That array contains sorted pixels according to line mapping data on the LEDs screen.
  • Presentation block: This block carries the symbols “1” or “0” to GPIOs MCU. Those symbols are generated as from extracted pixels from each frame. It should be clarified that GPIOD pines within microcontroller are linked up to the LEDs screen.

The symbols are illustrated below.

7

Consequently, it is graphically represented by the way different blocks interact one another.

8

For a video composed by n frames, first the processor block is run for all the pixels within frame 1, then transmitter block sends GRB bits associated to frame 1 towards MCU. After that, receiver block is run for frame 1 and while presentation block shows GRB frame 1 bits on the screen, also GRB bits are received from frame 2.

This way, successively software blocks are run for video n frames.

This system has been tested projecting a video composed by 462 frames, this video is reproduced at 29.97[frames/s] speed. Next link illustrates that test.

TFG: Design and implementation of modules for a low cost radar system.

In the last years many low-cost radar modules have appeared on the market, allowing the implementation of this technology in a large number of applications, such as medical applications or people detection.

The B105 Electronic Systems Lab developed a prototype for the control, management and processing of the signals generated by these transceiver radars. The aim of the project is increasing the system versatility while correcting the problems it presented. So, the first step consisted on analysing the existing system and evaluating the aspects in which it could be improved.
radar

Then, the focus shifted to the design of several circuits that allowed to digitally change the amplification and filtering of the analog signals of the radar module. The circuit that modulates the radar transceiver was also modified to make it configurable. Once the designs were made a printed circuit board (PCB) was developed and manufactured.

An update of the existing software was needed since the hardware modules have been modified. Functions that handle the different amplification and filtering configurations of the system were developed. Also, a communication that would allow sending orders from a computer to the module was added. This communication allows the modification of the parameters during the operation of the system. The parameters include the amplification, the filtering characteristics, as well as the modulation parameters of the radar transceiver.