Surat preparing for 24×7, reportedly planning on providing to recently resettled urban poor first.

Professor Asit Biswas stated, during a visit to Nagpur, that 24×7 water a good solution for “cheap” and “good quality” water (quotes from the ToI article, not necessarily from him).  The article also includes more details of the 24×7 project by OCWL in Nagpur, including 30% of pipes to be replaced and supply to 3 lakh (300,000) households.  Prof. Biswas also stated huge distribution system losses – citing 60% in Delhi – as the main factor for lack of 24×7.

ToI points out that this time of year in which more consumers in Mumbai complain of water quality problems (the newspaper looked at complaint records, a shockingly low 167 over 3 months in all of Mumbai).   BMC states that it is unlikely they will need to cut water supplies this summer because of high enough levels in the source lakes. Hindustan Times reports that the areas from Mulund to Vikhroli are getting 24×7, with it extending to eastern suburbs as of last week and, soon to Ghatkopar and Kurla.  I’m still surprised that I’ve seen so few details on how this was implemented (normalization of connections, installation of meters, repairing pipes, etc), but perhaps I just haven’t looked hard enough.

Expansion of 24×7 planned in the budget of Karnataka that was recently approved which included 1700 crore to expand Hubli-Dharwad, Belgaum, and Gulbarga’s 24×7 and 146 crore for Mangalore’s.  Nagpur’s JNNURM project for 24×7 is reportedly 68% done for the pilot areas and 1% done for the city (I’m not sure what that percent quite means).

The dry season is heating up with reports of reduced water availability around the country.  In Pune, construction sites will no longer get water, but more dramatically a newspaper in Mangalore announced that the nearby dam had only 9 day’s supply of water. According to this article, it suggests that some of the problems with achieving 24×7 in Mangalore have been due to a reduced budget which did not allow for rehabilitation of old pipelines, leading to high leakage rates especially in transmission lines.

Housing societies in Ahmedabad have apparently taken it upon themselves to install water meters to encourage conservation – reportedly using less water and reducing down their electricity bill.  Debate still ongoing about installing meters in Pune.

Also, in attempting to start collecting leakage rates in various cities:

• 35% Visakhapatnam
• 38% in Mangalore.

Mangalore is starting to close public taps, illegal connections, and meter connections in preparation for 24×7, and Pune is looking at installing meters,  costing the plan right now, and conducting a water audit. ToI reminds us that in Nov of last year, the civi standing committee approved the 24×7 water supply scheme with the Italian consultant Studio Galli Ingegneria to make the plans.

Revived 24×7 proposal in Visakhapatnam (in AP), and dissent in Bhopal over a potential 24×7 scheme.

Other related news, ToI notes that Nagpur is starting to try to collect arrears – estimated to be 70 crore ($14 million USD), noting that each year cost recovery has decreased – by keeping offices open longer.

There have been some great articles in the ToI and India Express this month about water management in cities in India.  ToI looks at the water crisis in Bangalore using examples from several places in the city. Electronic City, who say they even are having trouble with obtaining supplies from tankers and purchased borewell water and are asking consumers to cut back. Residents in Sarjapur (where I usually stay when I’m in Bangalore!), completely depend on tankers (since there is no BWSSB pipelines here) who have been changing their prices, and another residential area, Whitefield, have 24×7 if they are in gated communities (not clear where that comes from) but use water tankers outside of the gated communities.  Interestingly, an area of the city called Austin Town is expected not to have a big problem because of the presence of defense establishments nearby who harvest rainwater (I assume this means that many people in Austin Town are using borewell water).

I’m excited to see several reporters this month discussing water scarcity concerns in more detail than the usual ‘lack of sufficient monsoon rains’ that is too often seen at this time of year.  ToI has a great article on Pune, where the utility has been cutting the water supply this summer and officials cite leakage and lost water as the reason.  There are reportedly 11.5 TMC of water set aside for Pune, and 14TMC area drawn from the reservoirs, however, officials cite losses and management problems as the reason for cuts, with various finger-pointing as to whose responsibility it is to reduce UAW (reportedly at 40%). The article goes on to talk about the role of water theft, sewage treatment, quotas from the reservoirs, and rainwater harvesting and their options and problems for mitigating the problems, and a review of some of the past measures put forth and shelved in the past (the reporter did a great job giving the problem of urban water scarcity the complex analysis it requires, far above many other articles I’ve seen in Indian newspapers – definitely check it out).  Indian express has a good (if brief) interview with PMC Water Chief, where he discussing uncontrolled growth of the city and planned recycling of wastewater and reduction of leaks.  Bangalore reports surface water depletion, particularly in small lakes, as development has changed land patterns and affected drainage. The Deccan Herald mentions that some people blame water scarcity on new developments. ToI reports problems in the Pench I4 project in Nagpur, which is supposed to increase capacity by 115 MLD by increasing pumping and water treatment plant capacity, and also potential threats to the current supply due to a new dam in AP – though it also mentions 50% UAW which would, if reduced, effectively increase the supply of water.

PS – Happy AWWA Fix a Leak Week!

• While this is slightly old news that I missed out on previously, Malkapur, in Satara, Maharashtra has 24×7 water for all residents.  From this article, it seems that the government of Maharashtra authorized an upgraded water supply in 2002, which was commissioned in 2005, and a new revision to the project to bring 24×7 with 100% metering and volumetric tariffs.  Earlier in 2011 it was given the prime minister’s award for excellence in public administration.
• Gujarat is moving to 24×7 supply: Surat has plans for 24×7 supply with a first phase of 4,000 households starting in March, and a new planning document suggests piloting 24×7 for villages.  According to the article, Gujarat had also planned a 24×7 metered water supply in 2008 though nothing happened.
• Proposals for 24×7 for several zones in Jaipur are ‘under consideration’, though the article states there is a pilot project in two parts of the city.
• Also under a JNNURM scheme, 24×7 is coming to Coimbatore, starting with old corporation areas.  It seems a fair bit of upgrades with take place, including replacement of pipelines, new water tanks, and a new feeder main and distribution name.

Updates from previously mentioned cities:

• h/t to commenter Joby for links to this source, Veolia is linked to Orange City Water in Nagpur, which the local partner company, Vishvaraj Infrastructure, now highlights on their website.

Nagpur continues with its 24×7 supply project through privatization, despite opposition.  Veolia has been the operator for the pilot project, but it seems that the scale-up operations will be handed to a different company, Orange City Water Limited.  According to the ToI, the NMC has created a vehicle for the privatization arrangement called Nagpur Environmental Service Ltd, which will work in partnership with the OCWL.

As per agreement, OCWL will take over the entire work, from water treatment plants to billing, for a period of 25 years. The private operator will also execute 24×7 water supply project.

The handover does not appear to be going over smoothly, since only 35 of over 400 employees have agreed to work for NESL, so there are few experienced staff to help with the handover. The stand-off seems to be over as of today, with a rather strange arrangement where employees will stay with NMC and continue to operate the water ‘works’ while OWCL will operate the ‘water’ (the ToI explains this as clear as it can be with the liberal use of quotes in this article title), with a guarantee that areas will ‘receive water equally’ (equal time? equal water? equal pressure?  How will they track this anyway?) within 7 months.

I have been poking around on the internets to figure out exactly who OCWL is, as it had been reported earlier this year that the 25-year contract would be awarded to Veolia.  However, the name OCWL appears to come up only in reference to Nagpur (I’m doubting a relation to Orange City, FL).  Veolia in India usually operates under the name Veolia Water India Private Limited, as far as I know.  Who is OCWL?  Do they operate anywhere else? Are they an Indian company?

It seems, looking to other 24×7 projects accomplished through privatization, that it could be possible to retrain plumbers and incorporate them into the operation.  I believe this is what is being done in Hubli, where plumbers can get certified in the “modern” methods needed for any new types of technology.

A less controversial 24×7 project has been approved for Pune with an Italian company.

The consultant is supposed to execute all steps of the project from preparing detailed project report (DPR) to completion and maintenance of the project. The consultant will provide service for 11 years, including five-and-a-half years of preparing DPR and implementation of the project.

In the first phase, the consultant should prepare DPR, conduct basic water audit, detect distribution losses and get approval to the DPR from authorities. In the second phase, the consultant is supposed to prepare tenders for the project and ensure implementation of the project in five years.

In the third phase, the consultant is supposed to ensure repairing and maintenance, to prevent distribution losses, to increase number of water treatment plants and to increase automation. Bidkar said that the consultant is supposed to take into account problems in water supply in the next three decades.

There doesn’t appear to be a pilot project in Pune, but it seems this is a new approach where the company will first operate water supply and then upgrade it, as opposed to other ones (Karnataka, Nagpur) where the company is brought in specifically to upgrade to 24×7.

We had heard about the idea of using mobile phones/PDAs for collecting survey data from friends, who had experience with mostly commercial software for similar household surveys.  The most frequent advantage cited was the instantaneous availability of data, allowing the research teams to continuously monitor what was happening, fix data issues with data collection while it was still occurring, and enabling presentation of data very soon after completion of the study. After our experience running significantly (by an order of magnitude) smaller-scale studies, also in India, and having to deal with pile-ups of paper and data entry woes, we decided to at least consider an electronic method.

1. Design your study. I’m presuming this is all being done on a separate track from ODK.  The relevant things you need to know about your study before deciding to use ODK: location/context (is there easily a source of power for charging the phones frequently enough? What are conditions for enumerators going to be like?  Is there technical knowledge/ability among the field supervisor staff?), study size and length of time (relevant for hardware selection and budgeting).
2. Decide whether ODK is for you. We looked into several other software/hardware options, including Windows Mobile, Nokia, and iPhone – MobileActive’s guide Comparing Mobile Data Collection Toolshas a great listing of the options available (this didn’t exist when we were making our decision).  We downloaded samples, including ODK, to try it out, and looked at the following factors that were most relevant for us:
   1. Budget – this was our biggest consideration, since we are operating on a very tight budget.  The quick estimate we got for commercial software (Windows Mobile, iPhone) was at least US$7,000.  After pricing out the costs of phones and software, ODK was a clear winner.  After our sample size doubled from 2000 to 4000 households a few months into setup (after we had already decided to use ODK), we looked at our budget and discovered that the cost of the hardware (Android phones) was less than what the photocopying/data entry costs associated with a paper-based system would have been.
   2. Language support – Our study is in the state of Karnataka, and our survey is administered in the language Kannada.  Currently, Android does not support many complex language fonts, including various Indian languages (see thread in ODK Implementers list).  However, we’re in an urban setting and found that most of or enumerator staff would have at least basic knowledge of English letters. Also, many people in India are familiar with transliteration – turning Kannada sounds into English letters – as it’s common in text messages and store signs.  We talked with many Kannadigas and decided transliteration of Kannada would work for our enumerators (part of our interview process for hiring involved reading a bit of transliterated Kannada).
   3. Usability for research team – I was the ‘programmer’ (by programmer, I mean I used to change up the html on geocities pages back in ’97, have taken classes that involved FORTRAN and MATLAB, and am reasonably adept at looking at existing code and using cut-copy-paste.  While we were still deciding on whether to use ODK, I tried out the demo forms, made adjustments and used the basic features, loaded it onto a borrowed Android phone, and set up Aggregate.  I figured if I could get through this in a day, combined with the helpful team on the ODK listservs and some friends in Berkeley’s CS department, I could manage setting up ODK.
   4. Features – Our most important requirement was skip logic – in fact, that was one of the main reasons we wanted electronic data collection.  Our survey is extremely complicated, as we’re trying to document things like the various sources of water that people use and many other features of such a supply.  This translates into >8 different options for a source of water, with 4-20 questions after they say ‘yes’ to any one of them.  This level of complexity would have been impossible in paper form, so the main feature requirements for us was skip logic and the ability to input numbers/decimals/text; everything else (constraints, GPS, etc) was icing.
3. Make the basics work.Once we made the decision, I needed to teach myself how to use ODK, and also be able to let my other team members know what was and was not possible.  To get set up with the basics, I set up a 10 question survey that used all of the types of questions we intended to use.  The steps I went through:
   1. Find an Android phone to borrow or use the emulator (I followed these instructions to the letter and it worked).
   2. Download ODK Collect on the phone/emulated phone through the marketplace or the website directly (often the marketplace didn’t work on my emulator, so I just navigated to the website on the phone’s browser and downloaded) using these instructions.
   3. Try out the sample forms on the ODK appspot server. Download them to your device, fill them out, send them back to the server, view the data on the server. Get a feel for how they work.
   4. Set up ODK Aggregate (optional).  This wasn’t necessary, but I was in the US when I got started on this and thought I’d be using it, so I set it up and tested it., so had plentiful internet and was using Google appspot for testing(we never even ended up using anything that involves the internet for our actual study).
   5. Download one of the sample forms.  Upload it to your Appspot site by using the ‘Upload form’ option.  Change the server on your ODK Collect (phone or emulator) to your own appspot site address (press ‘menu’ when you’re on the main screen), find your form, and bring it do your device.  Try out the form, send data back, view it on you appspot. Congrats!  The groundwork for everything you’ll do is set.
   6. Read up the Xform tutorial and follow the examples.  Try your own forms through the whole system.  There’s now ODK Build, but I knew we’d be using very complicated logic which is not supported in Build at this time, so I decided to code from scratch.
   7. Edit your sample forms, incrementally.  Since I didn’t really know what I was doing, I found it was best to change just one question at a time, constraint, question type, etc, so when something went wrong (which it, of course, did nearly every step of the way as I made mistake after mistake), I knew exactly where to find the problem.  Don’t worry, there will be lots of crashes and problems, but that’s learning!  Just take it slowly and be patient.  And use the Validator.
   8. Make a 10-question form that includes all of your survey question types.  I went through the pilot questionnaire (at this point, the final one was not yet finished by my colleagues) and chose 10 questions that incorporated all the types of questions and constraints I was likely to have (multiple choice, text/integer/decimal entry, GPS, skip logics with 4 relevancies, various constraints etc.).  I worked on getting a form to work that incorporated all of these.  From then on, I just copied and pasted from this form to make the full survey.
4. Decide on your hardware. I looked through the relevant question in the FAQs and also pricing and decided based on others’ experiences with ODK in the field and cost to go with MyTouch phones. We ended up needing more phones when we were in India, so we got one of the 3 Android options readily available in our town – the Sony Ericsson Xperia x8.  Again, cost was our biggest concern.  It’s worked fine, though recently we’re having some trouble with the GPS.
5. Decide how data will be transferred between Androids and a computer.This is dependent on the design of your field logistics.  Are the enumerators bringing the phones back to a central point daily?  Weekly?  Will you have a computer at that point?  How often do you want data transferred?  Also, are there privacy concerns for your data?  Who will be there when something goes wrong with whatever system you have set up?
   1. No internet?:  As a team we decided on logistics: that the phones would be handed in by the enumerators each evening and given back each morning.  This meant that there was no reason for us to even have SIM cards in the phones or use the internet for our transfer of data at all.
   2. Aggregate: Aggregate is not (yet) secure on its own, so we would’ve needed to add security to it ourselves and figure out how to put it on a computer.  I wasn’t sure I was easily capable of this, so I’d need to call on a friend to help.  While possible, this was not ideal – since I was the one in the field, I wanted to be capable of handling any issue that came up.
   3. KoboPostProcessor: I discovered the best solution for us was KoboPostProcessor.  This takes the forms produced by ODK Collect and transcribes it into a .csv file.  I made the decision to use this and shelved it for a later to actually set up and figure out (of course, it would be better to at least have gone through the process of getting it to work a few times before decided to use it!).
6. 6. Convince your survey writers to give you the ‘final final’ survey questionnaire. Our survey went through extensive 2-3 months piloting – all in paper form – before it even got to a ‘final form’.  Our survey is extremely long, and divided into 10 sections, and some sections were finished before others.  I required at least 95% completion of sections before I started programming, as I knew it would be a lot more work for me to make changes later.  It’s tempting when things are not printed out in paper to keep making changes until the last minute, but I think it’s important to set deadlines and constraints about how much can be changed after a version is given to the ‘programmer’.
7. 7. Code your survey.
   1. Decide how you’ll handle language issues. Since the survey was still undergoing piloting and the translation was not yet done, and I don’t speak Kannada, everything was coded initially in English.  We decided that our survey was incredibly long, and since others had reported running into crashes with long surveys, we wanted to keep the English and Kannada versions entirely separate.  Also, we knew almost all of our surveys would be in Kannada, so there likely wasn’t going to be a need for a separate English survey. ODK has great functionality for changing languages within the form, but we didn’t use any of that.  I completed everything in English and copied and pasted the Kannada language in over the English later.
   2. Keep things simple. We wanted the screens to be as uncluttered as possible, and the questions to be as simple and plain as possible.  A lot of this is survey craft, but relevant for ODK:
      1. Question numbering. All of the questions in the paper survey were numbered, since its necessary for paper-based skip logic.  However, we left the numbering out of the ODK form because there was really no need for it – the skip logic would be taking care of itself, and it just added more text to the screen that there was no reason for the enumerators to need to see or keep track of. 
      2. Groupings. While for ourselves, we had sections like ‘Child Health’ or ‘Water Treatment,’ and our first version of the ODKized survey had these as ‘groups’ that then showed at the top of the screen, we realized there was really no reason for the enumerators to need this information and it just added more things that cluttered up the screen.  It was useful for us, early on in the programming and testing phase, but we got rid of it for the final form. 
      3. Hints. Many of our questions had hints like ‘Enter 99 if don’t know’ or ‘DON’T read the options’.  The first version was full of long, convoluted various forms of these, so we standardized the 4-5 basic messages that appeared throughout the survey and made them as short as possible.
      4. Constraint messages. While it’s great that you can put in specific constraint messages, we felt it flashed for too short of a time for our enumerators to read and process (especially considering they would have been in transliterated Kannada, which is slower for reading).  We started out with specific constraint messages but ended up simplifying and just leaving the default there for everything except one question where we wanted to be specific. 
   3. Annotate your survey document. This is likely a personal preference and I don’t know if this will work for everyone, but it certainly did for me.  Our survey was being written and piloted by printing it out in Word.  I took the word document and started making my own ‘coding’ annotations to it.  In almost all questions, my colleagues had put in the skip logic and constraints.  Skip logic in a paper questionnaire is generally backwards from the way ODK thinks about it.  In a paper questionnaire, the answer to question 4.1.1 might be: Yes (if yes, skip to question 4.1.3).  ODK works backwards, and instead you need to append to question 4.1.3 that it is only a relevant question if 4.1.1=yes.  Annotating in Word was necessary for me to keep all of this straight.  Before each question in the Word doc, I’d write (in a different font) notes for myself: the name of the variable (CostWater), the relevant parameters (int, constraint <10000; relevant if PayWater=1, hint: ‘99 if don’t know’), and the values that would be given for each multi-choice.  We also knew we’d be teaching the enumerators that any ‘don’t know’ in a numerical input question would be ‘99’, so I made sure our constraints accounted for this.  In retrospect, while annotating was a great idea, doing so in Word and doing so while the survey was still being amended was not.  It made changes hard (if my colleagues wanted to make a change to a question, they’d make it on their version, do ‘track changes’ and then I’d have to go back to my version and make the same change; vice versa for when I found mistakes in their skip logic, etc.).  I couldn’t annotate directly to their document, since it was in a formatting useful for printing it out daily and using it in the field for piloting.  I think what I would recommend is using either Excel or at least a table in Word to keep track of it.  I haven’t thought this through, but in the next month I’ll be programming again an updated survey document for Round 2 and I’ll append this if I find a better system.  In the end, it was great we had this annotated document, and I made sure that everything that ended up in the coding of the form was also reflected in the document.  This made pulling out the information to make a codebook easy.
   4. Adjust all questions work with ODK. Through the annotations process, you’ll find some questions whose format or skip logic that won’t really work with ODK.
      1. Range answers. One that came up many times in our survey was ‘range’ answers.  For example, a question like ‘how many days ago did you last collect borewell water’ might have an answer of 3, 4, or 3-4 days.  We would have to do this using a text input, so the enumerators would have to switch from the text to the numerical keyboard to type “3-4”.  Adding symbols complicates matters too, and since most of the answers to this question were not a range, we didn’t want to complicate things by having them switch between keyboards.  We came up with a few solutions: 1) Turn it into a multi-select (with the values of 1, 2, 3, 4, etc.) and instruct the enumerators to select both ‘3’ and ‘4’ if the answer was 3-4; 2) Make single-select ‘buckets’ like ‘less than 2 days, 2-4 days’ etc. or 3) Use a decimal input and instruct enumerators to use ‘3.5’ in the event they reported 3-4 days.  The solution we used varied depending on the question and the resolution of answers that we got.
      2. Tables. One of our questions in the paper format involved a table, where the enumerators would fill in information about water containers, including sizes, materials, shape, etc.  A table worked great on paper, but is hard to translate into ODK.  I first started with a repeating group, where each of the questions (size, material, shape, etc) was asked in turn.  This worked well until I discovered that KoboPostProcessor would not work with repeats (see my comment above that I should’ve tried it out much, much earlier).  I then make it into a forced repeat (rather than using a loop, just asking the questions again and again).  But since we were allowing for up to 15 different storage container combinations, this grew quickly into an extra 75 questions, which led to worries about crashes due to survey length (we were also using the previous version of ODK collect – maybe the new one could handle this)?  We ended up deciding that 1) we didn’t need this information from all 4000 households; 2) it was much, much easier to fill this information out in table form; and 3) we were nervous about the enumerators holding the phones over the water storage containers as they measured the tops and sides of them.  So we decided to have them fill out this information in a 1-page paper format at only their first house of the day.  Some of our other info for houses is on paper (name and address information and consent scripts (an ethics committee protocol), sheets that household IDs are checked off of, etc.), so the enumerators were used to having some paper out during the survey, and we were set up for a small amount of data entry.
   5. Work on small sections first. Luckily our survey was already broken into smaller sections, so I coded forms individually by section.  It made it much easier to debug than a huge long form would have been.  If there were relevancies that depended on previous sections, I left a commented note to do this when I integrated them.  I also named each with different groupings (Section 5, Section 6, etc) to make it easy to navigate.  For our complicated issues with relevancy and constraints, I mostly borrowed from the great example of the icmi form (on the ‘example forms’ page on the ODK site).  Some of the things I tried worked, some didn’t; when I came upong something that I wasn’t sure was possible, or that left me feeling like it was a huge hassle/danger of leading to fatal crashes, I asked my friends to change up the survey to accommodate easier logic (adding a new question, breaking up one question into several, etc).
   6. Extensively test sections. Our survey includes complicated skip logics.  I enlisted the help of my colleagues and everyone else who was around to test every possible permutation.  When there were crashes (there always were), I’d go to the code of the screen that it had crashed near and try to find the problem.
   7. Slowly integrate sectional forms together. I started to bring sections into one ‘master’ form and test, tested extensively at each step of the way.  No, testing again and again is not fun, but every time I’d get ambitious and confident, I’d end up with a bug I couldn’t trace.
   8. Get your translation right. This isn’t an ODK issue, but we wished we had had this advice beforehand to make sure we put the time in our schedule.  We sent our survey out for help with translation to some students who had done some translation work for us in the past.  We also got it independently back-translated.  When our field supervisor came on board, we had to spend many, many hours going question by question with him making sure the survey questions were asking what we wanted them to ask (my favorite: a translation for the answer ‘buried’ for the question ‘where do you put your child’s feces’ had been translated into the Kannada ‘on your ancestor’s grave’).  While sending it off and not being a part of the process is a good first cut, make sure you account for the copious one-on-one time needed with someone who speaks both languages and understands what it is you’re trying to get at with your questions.
   9. Extensively test final form. My colleagues made a flow chart of the especially tricky skip logic sections and went through step by step to make sure everything checked out with ODK.
   10. Set up data transfer. We used KoboPostProcessor.  First I hooked up the phone, navigated to the ODK>forms folder on the phone, took the forms to my computer in a folder I called “raw data”.  I then set the KoboPostProcessor to Transcribe from “raw data” to “transcribed data” folder.
       1. I didn’t get the Sync feature of KoboPP to work, so a friend wrote a [[simple python script]] which could pull data from multiple phones at once to the computer.
       2. KoboPP does a great job pulling the data from the xml forms to a .csv, however, for some reason it re-aligns all the columns in a strange order.  To alleviate this, I added numbers in front of all of the variables, e.g. A01, A02, B01 etc (a fair amount of work, but I think better to do after the form was programmed, in case there were changes to the survey and re-numbering would have been worse).  We would then just re-sort the columns in Excel.
       3. We also found that KoboPP on my computer (Windows XP) would break the answers of Multi-select questions into separate columns (with associated ‘1’s and ‘0’s’, our field supervisor’s computer (Windows 7) would not.  My only guess is that this is a Windows issue, since we tried it on several other computers and came up with the same results.  We ended up having to re-transcribed the first week’s worth of data, since we had switched computers that were doing this operation a week into the survey.
       4. KoboPP doesn’t work with repeats in the forms, so we rid of the few of these we had.
   11. Prepare the phones. We went through the phones and put ODK collect on all of them, changed settings (simple background, not allowing a rotating screen, hiding all apps on the home page, putting ODK Collect on every single page, airplane mode, etc).  We then put our forms on all of them by hooking them up to a computer and manually putting the form into the ODK>forms folder.  I’ve found that sometimes the form doesn’t entirely get onto the phone properly the first time – I have no idea why, but sometimes, after putting a form onto the SD card and trying to open the form in ODK, it would crash.  So whenever we loaded a new form to the SD cards of the phones, we’d run through each survey at least once and save it to make sure it was working OK before handing them to the enumerators.
   12. Train the enumerators. Refer to Neil’s excellent guide.  We followed this exactly, though with the first few days set aside for teaching the enumerators to read transcribed Kannada.
   13. Set up a daily system. The procedure for the end of each day: 1) connect 4 phones through USB hub; 2) test that they’re all there using the android debug bridge (adb); 3) run the script to pull the data; 4) count that the number of forms in the folder matches what was expected (he has a paper from the enumerator teams each day that states the number of households each visited); 5) repeat for other 4 phones, and check numbers; 6) transcribes data and re-sorts it; 7) check that household IDs in the transcribed .csv match what was expected, and check through data for errors; 8 ) charge phone batteries and delete data from the phones; 9) password protect all data (complies with our CPHS protocols).
   14. Bi-monthly. Every 2 weeks the enumerator teams finish a ‘ward’ (geographically specified area).  At this time we go through the data to check that things are making sense and have enumerators return to households to fix issues (the wonderful thing about electronic data collection!), check the accuracy of GPS (enumerators re-take coordinates if accuracy is >20m), and make maps of coordinates to make sure they stayed within boundaries (and re-do households if they haven’t).

Our first 4-month round is almost done, and we have 3 more rounds – 9 months left.

Questions?  Email me at ekumpel (at) berkeley (dot) edu