 The idea here is to have three systems connect with each other to communicate, right? So three systems communicate to give you, give some valid data that we use for the user, meaningful for the user, right? So one research component is this one. So this one is a TI product. It has accelerometer, magnetometer, parameter, temperature sensor, altitude sensor, all kinds of sensor related data, right? So what we are trying to do is gather the data from here, accelerometer, gyroscope, magnetometer, they are their basic stuff. But temperature sensor is something that no, none of the analysis actually have, right? So since none of it have the intent to utilize this, sir, all such that the application can gather this data, and update the information to the corresponding user, who is nominated, right? So this will communicate to Android via Bluetooth, low energy, 4.7, the latest one. So we have got this Nexus 7 device, it is rooted to allow Bluetooth 4.0, right? This has a 4.0 module, but it is not enabled by Bluetooth, we need to route it, and then enable it such that it can communicate through the low energy APNs, right? So this is... Group one for a hacking night. This one is there. Another one is this setup. What we have here is an Arduino board connected with an Ethernet computer, along with the... I think it's a 8-bit LCD display, right? So what this display is going to give me is, it is going to read the data, the mobile is going to read the data from this device, it is going to pass this table, identify what are the values, and let's say the user is setting up a particular location, say, this building as my home location, right? As my central location. And from this, he can set a threshold where if he crosses beyond this location, it will automatically start getting this Android... Consistently keep listening for this location, and the moment it detects, it is outside of that property, it will start listening, getting information, connect to this, and it will start getting information from this device. And once it gathers all this data, collects it, do some manipulation such that all things are readable for the user, and all those data are uploaded to a server, right? Because we cannot communicate back directly to this setup, right? So it uploads all the details to a server per user. So every single user will have his own account for the server that is automatically created, a database is maintained on the server, right? So we get this information, we upload it, keep it on the server, right? Now, this setup cannot have any data pushed on the server. So what will happen is, with this setup, we'll be constantly coding the server. And it's again another service call. We'll pull the server and with the device ID. This one is going to have a device ID. Ideally, what would happen is this device will have... This device ID will be mapped to the particular user's account through a CMS or some system, which we are not going to do today, right? But we'll be hard coding this device ID with that. So by mapping the device ID to the particular user, when polling, that corresponding, all the details are brought to this device. It gets all the device and shows up, right? So in this application, what can be intended? The use cases will be people who like to travel much, people who do trekking much. Or in certain cases where children and parents want to know their children's location for safety purposes. We have special children as well as children who are going far away from home. Even for old persons. All they need to do is, I mean, we appear, thinking of implementations where we can identify a hardware that will use a 3G SIM card and it will automatically communicate with the network. That by avoiding any purpose where a children needs a phone to do all this stuff. By carrying this device in a bag, it will automatically do all those stuff. But right now, what we're doing is through the Android device, it will be uploaded. So any travelers, they don't have to constantly call them and say, hey, here I am, here I am, here I am. They don't have to remain there. All these data are going to be already available. Anyone who wishes to know where this guy is, all they need to know is if he's nominated, the data is going to be available in his mobile. Already in this device. Through this server. Or through this setup, if he has it installed. Let's say in a children's case, a parent can have a small display somewhere where he can just say, okay, that'll be my child. What does he know of us? Another bigger device that will plot up a map and will pinpoint its location. And it can also show the temperature in which it's currently, any spike in temperature is going out of control. Sometimes people don't want to be in places where there is, it's quite uncomfortable. So people will get to know all these information. So all this is what the actual idea is. And to extend it further, we also have some sort of a crowd source idea. Meaning people who are trekking or travelling, they can say, okay, I have been in this place. It will constantly keep uploading the data. Where in people who want to trek, they want to know some information, they can always come to a website which will list, okay, some user who was at this place, he has recorded this is the temperature and this is the height at which it is available, et cetera, et cetera. So they can be prepared, right? So for the temperature and all those stuff. So that kind of, a kind of, a Twitter kind of update, but with maps involved, locations involved, communication involved. In extension, we will be also adding the activity recognition API. So like we will also analyze the whole movement of this whole thing. Activity recognition as, you know, it takes the activity walking, sitting, activity, activity. Meaning whether he's cycling or running or driving or walking or he's idle. So we're planning to do that as well, right? So all this stuff integrated, we are trying to display it somewhere on a portal that can be used for everyone, not only those who were nominated. That's the whole picture. Whatever we have done right now is we have an Android application that's not yet completely ready, but the logic is there for waiting and listening for GPS and identifying if it is outside of the threshold that is set. So within kilometers, if say, I have set this as home location, within 10 kilometers if I am, no problem. If it is outside, it's going to detect the threshold, it's going to automatically indicate, right? So it's going to automatically upload the data. So we have that set up. Android device right now listens to the GPS and it will get the data. And it will, it's, we are still waiting on the integrating group with low energy. We are, and another thing is he has been working on it. He has been able to start the scan, discover this device, pair with it, and he's able to get the details from those data. It's not parsed yet. We need to parse it. What's the data is available? What's the data? I'm trying to parse the data. Because I'm, specific protocol structure where we get the data in a very raw format. And the conversion techniques are all, it's kind of a raw, raw, raw, and I'm getting it from the device. So I need to parse those data, get it in a readable format, and then parse it and then send it to the server. So Bluetooth low energy is something that we have actually started here. First thing we are trying to understand and we are trying to analyze it. And we have not worked on it before, so it's taking a bit of time. Bluetooth low energy is from only 4.3. 4.3 is only available right now in Nexus. Not in any other much of use. So we are trying to, unlike the most latest AP of Android 3. And what we are here is actually working on setting up a server, a local server that will actually give some predefined data. We'll be actually sending the information that we get from this device and the location details from the device. We'll be uploading it to the server. Services are parsed, it's not complete yet. One service is ready, uploading service is ready, getting the details, that's not yet ready. So getting the details service is required by him. He's the one who's working on this setup, display setup. So what he'll be doing is, he'll be writing a service that will use this device. This service will keep folding the service, that server, and it will get the information and it will populate that information in a concise manner. What is needed and what is not needed? What we have here is something like a beacon. A beacon doesn't compromise privacy. But at the same time, we do a small logic of where the person is. So we want to bring that small abstraction. We want to respect their privacy also. But they'll definitely know if they're close or what, based on the color codes that they will try to give. So if you're near this, there's already light here, which will indicate if the user is outside the boundary, it'll start showing up in red color. And if he's inside the boundary, it'll start showing up in green. If he's coming near full, it's green. So people can feel positive that, yeah, he's somewhere near. And if he's very far, if he's crossed boundaries, that means it'll give a red. So we respect privacy at the same time, giving a general idea of what his position is. So this will be a gradual shift. This is not like red and then green. It shifts from red to green. So there's a huge change of the color so that it shows that he's nearby. But if we do that... So we go through the entire color spectrum just to show that he's in the... in progress of coming towards green. So it will not be a jump from red to green. So color codes are also important for us. So it won't be a red and green. We want to show a positive approach wherever it is. So we think of it. But this is a general idea of the hardware that we have there.