|
|||||||||||||||||||||
| I attended the IEEE 802.15 standards meeting at Vancouver where I met a lot of people working on VLC. A task group TG7 was given the responsibility to standardize visible light communication. The meeting discussed a lot of important aspects regarding the MAC layer and the PHY layer. For the first time in my life I felt like I was part of a big research time courtesy my advisor Prof. Little. I was really motivated after this meeting. Also I was able to work with a new team of people at the Smart Lighting Center at BU. The second generation prototype leaped to 1Mbps. This required major changes in both the receiver and the transmitter circuit. The transmitter had to be a high current and yet fast switching circuit which though does not reach theoretical bounds of analog devices but involved a lot of out of box thinking. The major shift in receiver circuit was to adopt a transimpedance amplifier unlike Prototype I where the photocurrent was directly amplified.
|
Fig: Prototype II |
| Also a lot of filtering was involved to remove ambient noise, the omnipresent 60Hz noise and the noise from CFLs. A range of 3-4m was still achieved. The range could be extended but our requirement was around 4m. The receiver circuit details cannot be revealed at this moment. But I would soon add it. The transmitter circuit details are even more sensitive. The theoretical bounds of analog devices have not been reached yet and there is still a lot of scope to improve the data rate. Once we are able to reach those bounds the next task would be to do some device level research where the LEDs and photodiodes would be changed so that they have lower capacitance for faster switching and a higher output photocurrent respectively. There is still a long way to go but if 10Mbps is reached this can be a really product in the market. | |
Ethernet Connectivity
Written by Kandarp | 
| This is a good embedded systems project I undertook which involved making my VLC prototypes have Ethernet connectivity. Although fairly established and well documented, Ethernet technology was still not easy to integrate with the prototypes. We could get hold of the PHY layer and a MAC layer driver. But still this did not give me enough abstraction. Also implementing TCP/IP was not a good idea as we wanted it to be compatible to other network protocols. After a lot of thought it was decided to go with FPGA boards as they provided more flexibility against microcontrollers. Spartan 3e starter boards were used. This board had a SMC LAN83C185 which had a PHY layer on it. Now the PHY layer could have been used alone.
|
Fig: Spartan 3e FPGA board |
| But it has a Media Independent Interface (MII) which it used to talk to other layers. Either a seperate module could have been written in VHDL which would have talked to the MII or a prebuilt MAC layer.Two MAC layer modules are available in the Xilinx EDK. The Ethernet MAC and TEMAC. The ethernet MAC supported 10Mbps and 100Mbps while the TEMAC supported 10Mpbs, 100 Mbps and 1000 Mbps. Since the ethernet MAC was lighter and easier to use and since our prototypes could only communicate at 1Mbps now, we decided to use that only to regret it later. To facilitate the timers, interrupt controllers and other custom modules we need a microprocessor. The softcore Microblaze was used in this case. It took considerable amount of time to test the whole system with the ethernet MAC layer. Since our prototypes could communicate only at 1Mbps and the ethernet was shooting packets at 10Mbps there was no way we could have buffered all those packets. Hence the MAC layer and in turn the PHY layer needed to be paused. This might seem weird but the 802.3 standard provides for ethernet pause frames. Now the issue was that the lighter ethernet MAC did not have this functionality and hence we had to shift to the TEMAC. | |
Antenna Diverstiy Project
Written by Kandarp |
Internship at Ember was an eye opener for me in many ways. They taught me all the industry standards for coding practices for both C and JAVA. A lot of other small confusions like how different is Link quality Indicator (LQI) from Received Signal Strength Indicator (RSSI) for RF signals. It was fun to work with them. The antenna diversity project assigned to me was unique. I had to write a code in C for a Parker actuators which had two perpendicular beams about 50 cm in length. One of their sensor node was to be mounted on this. The beams where treated as an X-Y grid hence the name X-Y plotter. So I had to write the code to move the beam in units of 5 cm. So the beams would start at (0,0) and then move to (5,0) ; (10,0)......(50,0);(50,5);(45,5).... and so on.
At each point I would have to send packets from atleast 50 other nodes to this node on the plotter. Graphs of LQI and RSSI where plotted. Different nodes with single and multiple antennas at various orientations where used. All these graphs were then compared to see how mulitple antennas at a given (orthogonal) orientation actaully helps in multi path fading. The data of LQI and RSSI were recorded in a file from where it was extracted using Matlab. I wish I could show you those beautiful graphs but I have been barred to do so.
Link Quality Analysis
Written by Kandarp |
This was the second project I did at Ember Corporation. The problem was that even after the customers had complained that they were not able to get RF signals in some pockets of their field where they had deployed the sensor nodes. While debugging it was found that Link Quality Indicator (LQI) did not quite agree with Received Signal Strength Indicator (RSSI) values at these places. Hence this experiment was conducted where I was asked to extract values from real customer data in text files and plot the values of LQI and RSSI with respect to the how the nodes where spread. It was concluded that RSSI is a very sensitive indicator compared to LQI. LQI is measured between 0 to 0xff or 255. The RSSI in turn is measured in dbm. So if one wants to find the where does RF signal dip on a from a zoomed out point of view LQI should be used. But to exactly pin point where the strength dipped RSSI should be used.
Nuclear Radiation Controlled Robot
Written by Kandarp |
| During the 3rd year of my undergraduate studies I had this opportunity to do a summer project at the prestigious Bhabha Atomic Research Center (BARC), Trombay, India. It was a very unique project because I was using nuclear radiation for the first time in my life to perform a task which is usually done using RF or Infrared signals. In simple words I had to design a remote control for a motor which was to be fitted in a robot. This robot was supposed to travel inside gas pipes looking for holes and leaks. The petroleum giants loose quite a lot of money if expensive natural gas or any other gas for that matter leaks through pipelines. Also it was almost impossible to look for it manually for a tiny hole in pipes running for kilometers. But the problem I was dealing with was that RF is very very unreliable through thick metal pipes. Infra red is out of question was it was not line of sight. My mentor at BARC decided to use nuclear radiation. Do not be scared this was harmless radiation from an isotope of Cobalt, Co-60.
|
Fig: Block diagram |
| As it can be seen from the diagram a stick containing Co-60 was waved in front of the robot. On board the robot was a Geiger Muller counter with a custom designed circuit. A Geiger Muller counter gives out electrical pulses proportional to the radiation. The closer the stick, stronger the radiation, and stronger the radiation the more the pulses. A pulse shaping circuit gave out nice 0-5 Volt pulses which were read by the 8051 microcontroller. I had wrote a simple C code for the 8051 which would count the number of pulses and actuate the motor accordingly. Although simple it was exhilarating to see the motor run when I brought the Co-60 stick closer while testing the device. | |
Animated Human Arm Movement
Written by Kandarp |
| Sensor networks is very interesting because of two reasons, one the technology exists but no one has been able to think of a killer application yet and two because it brought a lot of new challenges for everyone in the wireless communication domain. I took a course at Boston University where we had to do a project using the Mica2dot and Mica2 sensor nodes. These are very small devices called motes which had light sensors, mic and accelerometers on them. After a lot of brain storming I decided that we would make a system which would mimic human arm movement in real time. Now the issue was that these motes had a very low quality accelerometers and did not give accurate values to find position with respect to each other. Hence I decided to use light sensors.
|
Fig: System illustration |
| This might sound funny but if you are going to move your hand mostly you would be moving it under a single light source. The closer the sensor is to the light source the higher the light sensor output and vice versa. I got a lot of points like (light value, height). Did some curve fitting and hence was able to get reasonable idea of position of the motes. As shown in the figure I used 3 mica2dot motes and placed it on a plastic pipe (can be a human arm) and used the mica2 mote as the base station. The motes sent packets containing the light values to the base station which was in turn sent to the computer. Here the light values were extracted from the packets and then I used my curve equation to map it on a graph showing arm movement. The applications can be wide ranging from medical to gaming. | |
