 Good morning everybody, I am Chaitanya, he is Jojo, he is Chandrachandrak, Santoshwini Vasan, Karthik Kapadia, Rohit, Dhruv Jyoti and Raghavendra, Rasika. We have all been working on this clicker hardware since the past two months. Clicker hardware is a personal audience response system or personal response system which allows a large group of people to interact among themselves. A person in a remote place can conduct any quizzes and the person from somewhere else can answer those quizzes using this clicker hardware. There will be a specific time allotted within which every individual has to answer the questions and each clicker will be, and through each clicker he can answer the questions and these answers will be recorded in a database after which the results can be immediately displayed in the form of a bar graph. There will be a serial number behind every clicker and this serial number it helps to identify which person has given what answers and all these data regarding the clicker ideas will already be stored in the quiz present as database. Using the clickers you can answer various kinds of questions that is yes or no kind of questions, multiple choice questions, numerical questions, true or false or more than one answer questions, multiple answer. This is the clicker version 2 that is going to be developed in IIT Bombay and this is the front view of it. The TNY it represents a true and yes key the F slash N it is false or no. The remaining key is like 1, 2, 3, 4, 5, 6 and above it A, B, C, D, E that is used to answer different, that will represent the options. So you can click on that respective option by using these buttons. We have been given the clicker version 2 that is going to be developed. It's an enhanced version of clicker version 1. It consists of certain features and those features have been given as task for us to implement. In that one of the tasks that we have been assigned is inter IC sound that is I2S. I2S interface is used to transfer the digital audio samples between the CC2510 or CC2511 board and the external audio device. The most common application is used, it's used in CD applications and it has this CC2510 board it has the I2S functionality implemented in itself as a peripheral. So what we need to is we need to design the code as per our requirements, modify the timing changes and according to output that we want, according to sound that we want to listen at the specific rate, we modify the code. The chip it also provides a functionality of MULA compression and expansion. Compression is done at the transmitter side where the data that we send through the mic that is being compressed and it is sent through the radio function and then it is being at the receiver side it will again be received with the radio and the data will be expanded and then received. This is the objective, our objective is only one way wireless audio transmission using I2S and radio. We have followed the famous rule divide and rule, we have divided the main task into sub tasks, we have achieved them individually and we have integrated all the tasks to accomplish the main task. That includes we have configured the radio to send and receive the buffer and we have sampled the audio input that is what we speak through the mic, we have sampled it and we have initialized the audio buffer at the transmitter end and then whatever we are sending we have to rebuild the audio at the receiver side. That is rebuilding audio from buffer received at Rx and finally we have combined all the tasks to accomplish our task. The tools that we have used in accomplishing our task is IDE kyle mu version 4, the development board is smart RF 04 EB with CC2510 evaluation module, we have used Windows XP hyper terminal, free serial port monitor version 3.31, smart RF flash programmer version 1.11.1 and we have used the mic and headphones. Mic is used to transmit the data and headphones is used to listen the transmitted data. There is this RF board that we have worked on, the two peripherals that you can see there, the green one represents the mic, they can give the input as the voice and the other peripheral that is connected to the headphones where you can get to listen to the voice. And the LED is glowing, we have used that glowing of the LEDs to check the correctness of a code. For each block of code, we glow some LEDs, if the LEDs are glowing, we have confirmed that that only that part of the code works and the remaining part has to be checked. Instead of if there is some error, we won't know where exactly there are risks. To pinpoint the location, we have used LEDs and that is the black thing with the antenna again that is the radio that is used to send and transmit the data. And the board below it is the evaluation module that is used to dump the code that we have written. We have been able to verify our code using the hyperterminal, it's a better way to do it compared to the LEDs, we have tested the output of the code by viewing it in the hyperterminal and we have used UART communication to check the control flow of the code and to check the correctness of the code. By this, with the help of this hyperterminal, we can get to know where exactly the delays and the noises occur in the code. This is the snapshot of the hyperterminal that we have used in a voice transmission. Whatever we speak, the values come in between in a range of 1 to 100. So, is it correct or not? We can check using that values and the length of the buffer that we send when that gets displayed there and that is, we have also used UART communication that is sent serial function is defined in that. If you give any statement in that and display code after that, that statement gets displayed. So, you can check whether it is being displayed or not. That part of the code is being executed or not. This is the schematic diagram of I2S radio interfacing. This shows what exactly happens in the device. Using that mic, we send the audio input that is being sampled and then it is being sent to I2S receiver for mic. In the I2S receiver, the data is being compressed and then it is sent to radio for transmitting it. Then at the receiver module, there will be another radio which will receive these waves and then it is again sent to the I2S transmitter for speaker. In this I2S transmitter, the previous data that was compressed, now it will be expanded and then it will be given to the speaker. Speaking about the progress of the code and all, the ClickLab had already developed the code for a simple audio loopback. Audio loopback is, you can speak into the mic and hear from the same device itself. We had that code and we had to improvise it for our new. Basically, we made code for I2S communication and we found that it was highly distorted. We had to try different variants and to find where the problem was. What we did is that, as you said earlier, we would be having a transmitter part and a receiver part. In the transmitter part, we have used time, CC251 has four timers. In that, we have set timer one to, we have set it at eight kilohertz and it will generate and interrupt at every specific interval of time. And in the timer ISR, we are doing the sampling, filling them in the buffer and then sending it. So, this is a flowchart for the main function of transmitter. Here, we initialize all the peripherals, enable all interrupts, and then it's an infinite while loop. The rest of the processes happens in the ISR. This is a flowchart for ISR. First, we check if any interrupt is pending. If interrupt is pending, then we get two bytes, the ADC result that we obtain is of size two bytes. We obtain them, then start new ADC conversion. We have to convert the ADC result obtained into signed 16-bit values. Then, using the I2S coprocessor, we have to convert, we have to compress it. And the compression protocol uses micro low compression. And then, after that, the compress result is filled in the buffer. The buffer has cells of size one byte. And the total size of the buffer is 15. Due to the radio function constraints, we have the first cell to be filled with the size of the buffer. So, basically, we are sending 14 audio samples in one buffer. Once the buffer is completely filled, we will be sending the buffer via radio in the ISR itself. Earlier, we tried to send it from the main function, but it was causing some delay. Also, while trying to display messages via UR, that also used to cause delay. All these distorted our output. Now, we removed all these. We tried to send the buffer in the ISR itself. Now, the distortion has been very much in hand. And then, we update the buffer point, the ingredient point, and clear the interrupt. And this records every specific envelope time, set according to the eight kilohertz. And now, going to the receiver part. This is the flowchart for the main function. There also, we initially sold peripherals. And we check if a flag is raised. The flag is to pinpoint that a new buffer has to be received. Once the buffer is completely used to feed the speaker, we had to receive a new buffer. And for that, the flag is raised from the interrupt. And in the main function, we check for the flag, and then we receive the radio buffer. Going to the ISR of this function. Here also, the beginning is the same time, whether we check for the interrupt printing and all. And then, we get new value from the buffer. As I told earlier, the buffer will have values from 1 to 14, 14 audio samples. Then, we get those values are compressed values. So, we have to micro expand them. Then, to give them in the speaker, there's one functionality called delta sigma modulated in CC2500. So, we are feeding these values to, we are updating DSM frequency, and then that will give the corresponding output in the speaker. And then, we go to the buffer. We check if the buffer is completely used up. And if it's completely used up, then we raise the flag to receive a new buffer. And then, in such a way, we'll get the new buffer from the main function. This is a part of the ISR. We have almost reached the pinnacle of success in our task. The only problem that we're facing is, it's the sliced harshness in the background. We are able to successfully transmit the data and receive the data in the receiver side. A slight amount of harshness and a fine tuning is required that we are working on it. Thank you. Now, I invite Dhruv Jyoti and Raghavendra to continue with the SD card. Okay. So, we have been assigned a task of interfacing an SD card with the CC2511. And this is as part of the clicker hardware thing. Now, everybody knows what an SD card is. You must have used it with your mobile phone. It is mainly a non-volatile memory card, which is very frequently used in portable devices. It is one of the most popular medium of external memory. And we can have memory size as large as 2 TB. And that shows the importance of SD card. And our task is mainly to communicate with the SD card to perform various tasks like reading, writing, erasing, etc. This is the module which has been given to us and on which we have been testing our codes. It basically contains that LCD screen, that is a 16 cross 2 screen, where you can test our outputs. And the peripheral you can see above, that is mainly our SD card, which has been connected to the board. Next, this is a difference which we have compared. That is the SD bus mode and the SPI bus mode. Now, the SD card provides two ways of communicating with it. That is the SD bus mode and the SPI bus mode. Basically, if you look at the features, you will be finding that the SD bus mode is more advantage than the SPI mode. It is faster. But here we have chosen SPI bus mode because of some features. Firstly, it will put less load on our processor since we are using many other peripherals on our board. Therefore, this is a very important property. Secondly, the number of pins which are used by the SPI bus mode is less. Similarly, since we are integrating many features, this also helps us. Lastly, the interfacing of the card using SPI communication has been proven. It is used in a widespread manner and that is why we also decided to use it. Next, this is the aim of our task. We have divided it into four parts. Firstly, it is the initialization of the card. Secondly, the ability to write data into it. Third is the reading of data and just displaying it on the LCD or our terminal. Lastly, it is erasing data from the card successfully. This is mainly the flow diagram that we are following. Third, the main part of interfacing an SD card is mainly the initialization part. As you can see, the main task is that once we can get the card initialized, we have the ability to write data into it or read from it or erase it. The first two steps mainly show the process of initialization. First, we need to initialize the IC for SPI communication since that is the mode we are using. We need to send commands and get a correct response which we will verify that we have sort of initialized it. Next, this is, I would like to explain how exactly the communication is taking place or data transfer is taking place between our CC2511 and the SD card. Now, as you can see, both of them has 8-bit registers and the way the data is transferred is mainly like the MSB of the 8-bit register of CC2511 goes through the LSB of the SD card and similarly, the MSB of the 8-bit register of SD card goes through that of CC2511. So, suppose if you want any response or any data from the SD card, we just have to send any 8-bits from our CC2511 to the SD card and since it is forming a ring-type structure, so the 8-bits present there will automatically be coming in. And after this, in the second point, as you can see, there are some specific commands which are related to different operations. Suppose for initialization, we have to provide the commands something cmd0 and cmd1. These are sort of predefined in the SD card. We just need to provide the commands using these registers and the SD card will be performing the task and these commands are mainly 48-bit long and thus, since the size of our register is only 8-bit, therefore, we need to send it in packets of 8 cross 6. And next, when the SD card receives that 48-bit command, it will be acknowledging it with the help of a response. We can check that response and we can verify whether our command is correct or not. And as I already said, this response can be easily obtained by just sending any 8-bits to the SD card and we'll be getting the response on to our 8-bit register of CC2511. Now I'm going to explain the different steps which we have followed. Firstly, it is mainly the initialization part. Now the steps are mainly the steps we have followed while developing the code. Firstly, for initialization, we need to provide the 74 clock pulses. That is like you can provide about 74 ones to the SD card to wake it up. It is mainly to make the card go to SPI mode. Secondly, we need to send a cmd0 command. That is mainly the command is 0 with argument 0. That will sort of make the card go to idle state. And the idle response for that should be 0x01 which will show that it has accepted a command and it has acknowledged it. After we receive that command, we need to send a cmd1 command. That is 1 with argument 0. That will begin the initialization process and it should give us a response of 0x00. And these steps mainly comprise the initialization part and after this has been confirmed, we can go with the future task. Now next, these are some of the points which we have came across while developing the code. Firstly, we have observed that we need to keep the clock frequency during the initialization part below 400, mainly this 350 to 400 kW range to have a high probability of proper initialization. And secondly is the frequency that we have used. We have sort of initialized it at 100 kW frequency. Thirdly, there is something called chip select which sort of selects our SD card and this needs to be made high before we sort of initialize it as output or input. This is mainly because of the floating voltage that may arise. Suppose if we do not sort of initialize it, we may have some floating values. So to prevent that, we just sort of make it high. And lastly, delays should be avoided as and where possible because since we are using sort of SPI communication which is synchronous, so delays can make it go out of that stage. Now next is the present status. We have been able to initialize the card about 70 to 80% of the times. Still we are having some hardware-based problems I guess which is preventing our 100% success. Next part was mainly writing data into it. Similarly, as you can see, we need to send a command cmd24 and the start block from which we want to write it. And that is mainly at 512 bytes. If it is correctly done, we should get a 0x00 as a response. Now when the card acknowledges this command, we need to send 0xfe as a start block. It is just still the card that we are ready to transmit data. After we have sent a 0xfe, we can send our data into it. And after sending our data, we need to send a 16-bit CRC. CRC is mainly a cyclic redundancy cycle. So to check that, we need to send this 16-bit CRC to the card which is a sort of dummy in this case because CRC has sort of no significance in SPI mode. But since our command length is about 48 bits, so we need to send this 16-bit CRC. So if the above steps are correctly done, we should get a proper response of 0x05. Otherwise it will indicate that there are some errors. And next we need to wait for the card to complete the writing part which the data we have sent. It should complete the writing and after that we should wait for it to go into idle state. And then we can proceed to the next steps. So the things which we have came across during the development of this code was mainly like while sending the initial command for making the card realize that we are sort of writing into it, we may have to send it multiple times. For us, a retry of about 10 times was enough. And secondly after receiving the data, we need to wait for an extra 8-clock pulses before we are sort of deselecting the SD card. And the present status of the part is mainly, it has been implemented in hardware and we have observed correct response. But whether the data has been correctly written or not, it could not be verified as the next function which we are using is sort of, we have not tested it properly. So next part is mainly reading data from the card. Similarly, here also we need to send a command that is CMD 17 along with the starting block. It is sort of similar to writing when the card will be acknowledging this command, it will be sending a response byte of 0x00. And then before it is ready to transmit the data to our CC2511, it will be sending a start token of 0xfe and then it will be transmitting the data. And similarly as in last case, it will be sending a system with CRC which can be neglected here. And if every step goes perfectly, then we will be getting a 0x00's response. Here the points to be noted are similar. It should be about 512 bytes. Secondly, it has to be multiple things. And after receiving, we need to keep 8 extra clock pulses. Now this is the last part. This is mainly the erasing data. Similarly, we need to send commands. Firstly, we need to define the starting block, then the ending block, and then we need to send commands CMD 38 which will delete in this range. And this is the conclusion of what we have been able to achieve around 70% of the task as initialization consists of a very large part. And what we have found that the initialization is the main bottleneck and once we have sort of overcome that, the result of part will automatically fall into place. Thank you. Good morning everyone. So our task was the USB interfacing with HDCC. So basically as we all know in the clicker version at the receiver we have the USB interface so that the receiver can receive the data from the clicker directly on the computer for the obvious reasons which we all know about the USB that is hot fluggable, speed management, or the power management, etc., etc. So our task was basically to design a firmware, USB firmware which will allow the device to communicate with the PC. So the TI has already given the library for writing this application, applicable firmware but it works on IAR which is an ID which is not open source, proprietary software it is. So our task was to develop applicable firmware with the help of the TI's library which will work on SDCC. SDCC is an open source software which is not software, it is a compiler so we have to manually link it so it is not ID, it is just a compiler so we have to use this SDCC to develop the applicable firmware. So before moving to it, we will just start with the basics of the USB. So as we all know USB communication is always the host centric, always the host or the main part of the is PC. PC always starts the communication and the device has to respond to the request which the PC is asking. So USB communication basically falls into the two categories. First we have to initialize the device so that PC or the host can know about the device and second is the device task that is to communicate or whatever it is maybe for the like we have the USB pen drive for which the task is to store the data or for the CDC or for the clicker where task is to have the communication between the PC and the host with the RF. So this is what the two tasks basically and every USB transaction consist of many transactions which consist of packets and in order to understand this packet we must know the elements of the transfer so let's move to the elements of the transfer which are, they are like this endpoints so endpoints are like the source or the syncs of the data so whatever we try to send to the PC is hold into this buffer endpoints 0, endpoints 1 so there are basically 16 endpoints which USB supports but the CC2511 supports only 5 endpoints so we have 5 endpoints along with the endpoints 0 other thing is element of the transfer is the descriptor descriptors are like the data structures so that the host can learn about the device which the descriptor includes the device descriptor configuration descriptor device descriptor is like what the device is going to do what is its configuration so the configuration descriptor provides which power it supports whether it's self-powered or powered from the USB bus etc interface is like functions what functions it supports its class etc etc endpoint descriptors are what the size of the descriptor and which endpoints we are going to use basically and the string descriptors are just to have the knowledge about the class what class we are using what is the vendor like this next is the pipe basically when you start the communication you must have the connection between the host and the device which is termed as the pipe so when we are supposed to develop the firmware our task is to design this pipe so that host can communicate with the device so basically before a device can start a communication with the PC the most important thing is the enumeration the enumeration includes the host assigning the address to the device there is a transfer of the data standard request which takes place between them and then host assigns the address sets the configuration and then we can have the standard communication between the host and the device so during the enumeration what happens is basically the host sends the standard request and it is the job of the device firmware to response to this request and give the appropriate information according to the request and at the host side basically that manager plug and play manager decides which driver to use based on our response the firmware response so this is basically the what is called the enumeration basically the computer starts with the address get the device this is what the host asks for the device it sets the address and it is the task of the firmware to give this descriptors or to give the appropriate information and so that enumeration process can happen and next we can communicate with the PC efficiently so next thing is the device classes so as we all know most of the USB devices they have the similar tasks but their protocol is different so when the task is same but the protocol is different we have the different device classes so these are the existing device classes like audio class which includes MIDI devices HID class as we all know mouse and the keyboards mass storage as we all know pen drives printer class there is a smart class and the CDC class in the clicker version we are using the CDC class which is the communication device class as we need to modulate and demodulate the data so at the EC we are basically we are getting the data through the RF and then we are transmitting data to the PC so we are able to have the modulation and demodulation so we are using the CDC class so this is the brief info about the CDC class which we are using these are what the descriptor this is what the data we are supposed the firmware supposed to give to the host when the host asks for the data so we are using that kind of CDC class where the device descriptor and the class is 0 to there is no need to have this but we still have mentioned it so what are the duties of the firmware basically so basically the as I said earlier the USB communication is always host centric the host starts the communication and the device has to respond to this request so the task of the firmware is to know what are the requests developed which are the asked by the host and to respond to this request then to detect the communication directed to the chip then to perform the error checks then to exchange the data with the host so these are the basics of the USB transfer so we will now move to what we have done coming to what we have done we have modified the IR library for the USB and we have successfully compiled all the files in SDCC we have also been successfully implemented the SDCC code for serial transmission difficulties that we are facing the most difficult part on our side was to compile the .asmd file which contains the lookup table in SDCC as there is no much documentation available for the SDCC assembler but we compile it with the ASX8051 assembler command and we created this .real file that is rl file but the problem we are getting is when we link that file with the main file we are not able to get our serial transmission also working properly so also we are facing some optimization problems in some files that is when we link that file to the main file our program flow stops and we are having a discussion about this with our mentors on 22nd they told us to leave working on the SDCC and we are told to work on KLID so we have been recently working for last few last four days on ID and we are hopeful that we will complete we will implement that in KLID among the three days thank you good morning everyone my name is Prashika working as a summer intern in the clicker hardware team the task assigned was bootloader as the documentation was not provided so we have to understand it and then implementing a similar program in IEI system so coming to the what is a bootloader all of you must be familiar of the fact that whenever computer starts or window starts once the control is transferred to the BIOS that is bootloader and then the operating system actually starts talking in terms of clicker device it is a piece of software code that resides in the flash memory of CC2510 or CC2511 which allows the user code to be transmitted over a serial cable rather than rather than providing a debugger so why do we need a bootloader first of all no debugger no debugger is required when we are using a bootloader hence it adds close effectiveness to a device chip is programmed via the serial cable via the USB and in case of long programming times when the interconnections are very large bootloader is very useful these are the softwares worked upon while completing the task yield new version IAR made it work bench smart rf programmer flash.exe and free serial port monitor the task was divided into three main sub tasks that is the study of timer module, flash module and serial module as the bootloader is using the serial module to write the data in the flash the study of flash and serial module was very very much required then understanding the key program of the bootloader and developing a similar one in IAR coming over to the flow chart that is actually what a bootloader program is doing first of all we are ensuring the proper reset that is whenever we do the reset synchronization command is provided then the configuration of user ports and flash modules are done then we are sending the synchronization message reading data from the serial that is the hex file to be transmitted is it is transmitted from the PC to the serial cable and we have to read it from the serial after reading the hex file the instruction and the address from the hex file are extracted and these are written in the flash at the desired address and then the program is executed the progress till now is we have successfully studied and implemented all three of the modules and also implemented successfully on the hardware chip we have thoroughly studied the key bootloader program and also developed in IAR and successfully implemented coming over to the execution we have used the software flash.exe the command flash one led.h it is used to load the file led.h through the serial com one and the flash is for the program after we press enter it is waiting for the synchronization command from the hardware as soon as we press the reset command this is what it happens is three serial port monitor synchronization message that is hello is sent then the request that is from the serial data is read that is the instruction after we read the instruction we send it back to the computer so that computer will send next instruction only if it receives the previous one successfully it is because the whole of the program should be written successfully and the program proceeds only when each instruction is correct this is an example of writing the serial.exe file in the flash memory after all the program is written we have sent the simple j and q characters on the serial and you can see that it is successfully writing it the problem was mainly in the x data declaration of the buffers we have used two of the buffers we have overcome problem in one we have overcome problem in one buffer that is it is successfully implemented in x data memory but when we are trying to send the data using the x data buffer it is not sending data is getting corrupted the future work to be done is proper declaration of x data memory and also this program is to be further developed in the sdcc because main is on the sdcc compiler now I request Chandra to come so actually what a simulator does is simulator actually mimics mimics anything simulator actually means mimicking anything any real life object and the simulator we have developed mimics the microcontroller cc2510 and first of all we had to develop the simulator in linux environment so that it is open source it can be used by others and the second task was of development of gui in that too in linux so first we started developing the simulator in linux environment using so we started off with a command line interface but later on we changed to gui as we found qt was helpful and very easy to learn so this is the snapshot of a x file which is the input to the simulator because x file is that which we feed into the microcontroller so this x file is fed into the our simulator this is our simulator and it describes all the registers now we will open the x file into it now this is the x file for blinking of leds so first of all what we have done is we have decoded it decoded the opcodes into the corresponding mnemonics and for the corresponding mnemonics we have written the fun sense and the corresponding fun sense are related to these SFRs which we can view from the sides now in the sides you can see all the SFRs are there these are the common SFRs on the left hand side on the right hand side are the specific SFRs for the cc2511 now what we can do is we can step through each instruction so we just press the step button the orange will show the previous instruction executed and the blue or we can just move and the green will show the current line of instruction which is yet to be instructed now we just step one more and you can see move actually moves the number 7 which is in hexadecimal form to sp pointer now sp register, sp is the stack register as you can see the stack register has changed and we are also able to display it actually this simulator we have developed after we came to know that there were two simulators in linux environment for 8051 and cc2510 has a 8051 core and so we thought that we could just modify the existing simulators but its documentation was not available properly moreover I think according to my knowledge this is the first simulator in linux environment that has a GUI and the another feature another special feature of this is that we keep a track of the last instruction also because in other simulators when we tried to play dump our code we found that it jumped from one instruction to the other so we tried to solve this problem in this simulator that's all thanks I think our planning for giving half an hour for every team is absurd there is lot of work that has been done which I now realize and I am sure that every time every team would have similar things to say so we would like to modify that time I am thinking online so I will come back with an answer but before we go over let me just raise some questions that I have here about the voice thing you said buffering at you are doing some buffering and you have to transmit one buffer and then you have to fill up the other buffer and then transmit the second buffer so what is the delay between the two if any is it measurable we could approximate it to some about 2 milliseconds about 2 milliseconds is this additive can you process the stream at the receiving end at the speed at which it arrives the samples arrive no it's difficult we need to implement direct memory access DMA in it but since at the receiver end I will have practically infinite resources of a PC equivalent of appliance I should be able to take these streams as they come assemble enough of them in my internal buffer before starting the voice reception at the receiver end yeah but the problem is that CC2511 has only 32kb of flash memory but this would no no no not CC2511 at CC2511 will receive like this but after it receives I can use to buffer the incoming stream no yeah that can be done so that has not been attempted the clicker software team I saw that they resumed that the voice samples would be coming and you were buffering them at your end right so the point I think everybody missed out no it's okay point that everybody missed out is that it is not necessary the clicker speaks or a student speaks at the same moment the student should also be heard particularly you would have seen that in in TVs and all there are two separate channels one coming via satellite you will see it through delay there are lip sync problem visual signal comes first audio signal comes later or vice-versa so these things are possible but given that the delays are only in two packets I believe it should not matter but we need to examine that and this problem will have to be handled at the software end so there is no coordination with the software team per se you just independently solve this problem wonderful that is not how you will solve large problems in life you will have to coordinate on the interfacing of SD card so what are the processing capabilities of the SD card you just mentioned one for example it can respond to some command only such commands are available different commands have you seen I guess 56 commands 56 commands I don't know how many of the rest of the team have been listening to this conversation SD card and such cards are considered to be plain memory cards but plain memory cards have fairly large processing capability if for nothing else the processing capability is to permit access to memory locations transfer of data both ways and that is not implemented just as memory transistors so there is a processing capability an equivalent of a micro microcontroller sitting there as part of the SD card you should note this that in future whenever you see a memory card you please understand that there is an implicit processor inside that memory card in fact there is absolutely no device which does not come with processing capability some explicitly have it I don't have it I was worried about your definition of percentage success 70 percent 80 percent 90 percent how they will do you measure this percentage each time we sort of reset the device suppose 70 percent means out of 10 times I will be resetting I will be getting 80 percent it will be getting initialized so what you are saying is if you reset the device 10 times you can reset it 8 times so you call it 80 percent now is it black magic either it resets or it doesn't reset 8 times what on earth cannot make it reset the remaining 2 times no no I am saying once I reset the device out of 10 times 8 times it will be getting initialized and 2 times it will be sort of not initialized as I mentioned earlier correct so why should it not initialize I guess the problem maybe with the hardware that is what I feel maybe some capacitor values need to be changed capacitor values change while you are resetting no means like the hardware is fixed right so maybe we need to make some changes there I grant you that there is a hardware problem okay so you can see the problem with open source components in general the open source software is not well documented in fact the people who wrote simulator they have written it in reports they did not mention it the rudimentary documentation which they got after contacting the author was in Hungarian so now they will have to study Hungarian first to study that documentation which was not possible but this is precisely the reason why people who work on software which is open source must work harder to write proper documentation on whatever they do it's a chicken in a because documentation is not good people won't use it because people won't use it better documentation and better code will not result who will break these jinx we can blame the open source community but as long as any one of us is writing even 10 lines of code for release in open source ask this question by keeping a hand on your chest have you put together adequate documentation such that somebody else in the world does not say the same thing about you and your code the answer is often no and that's why I'm glad that the simulator is not just the simulator but there is some documentation that is there is claim I don't know how good it is but I will personally check it but good effort I would like to specifically get the following people captured on camera this is a team from my operational side led by Rajesh the camera is on that side so this is Rajesh Savita Savita is there anyway let me tell you that this particular clicker thing an idea which we started working on exactly two years ago two years and four months to be precise I had mentioned this earlier and the first set of summer interns actually produced a working prototype it was not a packaged prototype it was a card which people used to carry in hand two people were required one person carrying the card the other fellow carrying the power supply and this was demonstrated in our convocation hall successfully at the end of that summer then our team worked on it produced version one in nine months flat which I tried to use in my in my CS101 but we had problems with that so we started working on version two and while my team has done a whole lot of work preliminary but I think I am grudgingly admitting that this team which has worked here and also I think whatever report I have read about the clicker software team I think interns have contributed very very significantly to our effort and contrary to my suspicion that we may not be able to meet the deadline it appears that for this years offering of CS101 in IIT Bombay and certainly for the national workshop in December we shall be using clicker version 2.1 or 2.0 what you call it so let's give a big hand to the interns team wonderful job