 Hi, sir. Good afternoon, everyone. At first, I present myself and my company. My name is Henrique Kine. I'm a hardware engineer and partner at FI Innovations. FI Innovations is a startup company situated in Brazil. Our primary focus is to develop software, either for small microcontrollers or for a processor based on ARM core and X86 core. And in most cases, we develop the hardware as well for the customer. The hardware should be specified by the customer. We don't have any off-the-shelf work. But the customer sends us his specification, and we choose the right processor and the peripherals. Let's start. The objective of this project was develop a proof of concept using Android system to implement an embedded system solution. The project was based on the quick start board from free scale. And we had to add some features for such proof of concept. Oh, sorry. Here we go. The idea was implement the hard solution using open components and using Android as an embedded system. Normally, Android is used by Hunidia-Humamanshini interface. And this was not our case. We need to use it as an operational system using links. Using it instead the links, for instance. This was the requirement we had to start the project, development of a standalone embedded system, implementation of a graphical interface. This was an optional feature. The system should activate a two-way radio using PTT, the treatment for analogial signal. We have to convert it in digital and in the other side. We have to execute the opposite, convert it back from digital to analog to return it to the radio. Communication between the both sides used TCP IP. Bluetooth is used for other functions, not to communication between the both sides. System overview. Radio over IP is a way to transmit and receive radio communications over the IP network. It's similar to Vipe, where we have bidirectional traffic of all the streams. For this case, half the blacks communication. But for Vipe, you have to add a command layer associated to the connection to control the direction of the stream using the push talk button. Why Vipe? Why we have to? You should use Vipe. This is the typical scenario to two-way radio system deployment. We have to create a radio infrastructure, and it's necessary to deploy stations capable to cover the largest region as possible. To execute this, it is used the equipment that treats the radio signal and amplify it to reach the rados in the coverage area. But to cover a large area, it could be necessary many of such equipment to regenerate the signal. So the RIPE is an alternative to repeater for extending the coverage. And it can be used to link rados in different locations. And the seed counter continents as well, adding the embedded system instead the equipment. This block embedded system is our proof of concept. You can use it drastically to reduce the deployment cost because for every station you have, it's very expensive. Remember that there is no line of sight. If you have a region with no line of sight, you have to put the recover and repeater to retransmit the signal. Even if you don't have a push talk rados in that area. The system architecture is the architecture for our project. Our work was developed to, sorry, our work was developed the embedded system block, as I said, where we installed and customized the Android. This system is a point-to-point communication. As you can see, we have two sites, two nodes. From the two-way radio communicates with the central rados. The central radio is connected to our embedded system. This connection is responsible to send audio from the central radio to the embedded system and PTT signal. This is the way. The embedded system applies audio codification to transform it in a compact audio stream and send it to the other node. Our embedded system is addressed and can only communicate with one other embedded system. On the other side, the embedded system decodes the audio stream and activates the PTT to send the audio to the central radio. It's the opposite. Our hardware. We use the platform from Friskale. The hardware we have used is the QuickStart board from Friskale based on the IMX53 processor. The board is a complete embedded computer with ARM Cortex 8 processor. It has audio, video, storage capabilities. It also has many communication interfaces as WART, USB, and Ethernet. To connect the board to the central radio, we have to assemble the cable. And we also use the other boards to add features to the Friskale QSP. Finally, we have used the evaluation kits for the GPRS modem and Wi-Fi and Bluetooth USB dongles. The deployment. It's a far step to Android deployment. We have to take the Android build system provided by Friskale, the arrangement of the hardware, the midway customization, and the application software. For the first step, you have to download the BSP provided by Friskale. Friskale indicates Adneo Embedded website. You can do this. You can take the BSP. The BSP will automatize all the process to you for the Friskale board. It will download the Android service code, apply the pets to the original Android, insert a new Linux kernel that works for Friskale processor, and execute the necessary adaptations for drives and libraries to work correctly. The second step is related to hardware. It is necessary to customize the kernel provided by Friskale to apply their new hardware functionality. For Wi-Fi dongle, we added kernel pets provided by the manufacturer. The same for the Bluetooth dongle. The GPRS uses only a serial interface to communicate with the CPU. So it's kind of trivial to have only to set up the serial port. GPIO pinmooks modification to support PTT activation and detection. The third step, for some reason, the point-to-point protocol was not working in the board for the distribution we take. We use a new version of the project to do it. We also use the ESPIX library for audio compaction. ESPIX is an open-source library to implement vocoder function. The vocoder, it compacts the raw, old data up to six times the original size. It's very important to save bandwidth, in this case, because of the latency of the network. You can also use the other proprietary library, as, for example, the MB plus 2. If you need more bandwidth, save the last step. We had to add SDK support for new features. We have added two Android. We used Java native interface to add the new functions. Conversion of commands for the GPRS modem was done, because GPRS modem used 80 commands for Wi-Fi and Bluetooth dongles. There was no change for this application, once they were detected automatically. It was added the GPIO functionality for the PTT. And for the AutoCodec, it was mapped the functions using C language, low-level development. The application software. The application software can be divided in two main environments, the configuration engine and communication engine. The configuration engine executes the network setup, establishes the point-to-point connections, gives the operation log and operation status. While the communication engine manages the PTT, the audio compaction, and transmits the audio stream to the other nodes. It was implemented a common line interface to set up the embedded system and to get the stats from it as well. No need for graphical user interface. You can use only a console port to any terminal to get stats or set up the embedded system. The commands you can use are to set up the local internet interface and set up the remote to get log file and read the communication engine status. For this flow, you have a prompt in the terminal. You type the command, the command is written, and you have the response for it. Now, here I have the flowcharts for the task of embedded system for the both sides of the connection. The transmission side, the side, it is waiting for the PTT. Once the PTT is asserted, it receives the audio from the radio. The audio is then coded to be compacted, and the stream is sent to destination on the other nodes. For the receiver side, it is waiting for the audio stream from the transmission side. When it is detected, the audio is received, and the code, the embedded system, activates the PTT for the radio and sends the audio for it. These two tasks occur concurrently, and once PTT is detected in one side, the receiver for this side will ignore the audio that could be received by it. So if you have considerably latency in the network, this must be an issue, and the operator will have to treat this waiting a bit more to adapt to such delay or consideration. So our objective was using the Android in an embedded system and application where we normally should use the embedded Linux. And it had a good performance for it. The behavior of the software was excellent if we consider the fact that the Android system is bigger than Linux's system. Android customization was challenging, but as much as difficult as deploying Linux, maybe just a little bit more complex. Java was not a problem for performance. There are many possibilities to improve this concept, add a graphical interface to control the hardware. Technically, you have unlimited possibilities of protocols to be used for main different functions to be added to the concept. I'd like to thank you for that. If you have questions, feel free to ask me. Maybe I will forward the question because I'm the hardware engineer, not the developer for this project. Sorry, my presentation was very short because we have some issues with one customer of mine. And we have to change it last time in our presentation. Yes, for this case, we established only point-to-point for our communication. Maybe you can have a broadcast function, but we have not tried this. We only established point-to-point connection. Please, if you have a technical doubt or question, you can use the contact at finovations.com and we will be glad to answer you. Yes, this is a good question. Our objective, as I have said, was to do a proof of concept to demonstrate that Android is very feasible to be used as an embedded system. So I don't know to answer it for a very deep issue regarding the implementation, but this is what we have just to try to use Android as an embedded system. And maybe it can be easy to create more applications over the hardware you are using. My question, I appreciate your attention. Thank you.