A Community Farm Radio Network

Randy Wang   and    Rajesh Veeraraghavan

2.  What we will build

In this section, we discuss several "stages" of the system that we want to build.  They are not necessarily strictly linear: some of these aspects may be done in parallel.  In each of these "stages," we begin with inspirations derived from Lifelines and, to a slightly less extent, the BAIF-UP program, and go on describing why and how they may be improved.

2.1   Step one: a voice mail system for community radios

Our starting point is a Lifelines-like voice mail system that is connected to a community radio transmission system so that selected content stored in the voice mail database is systematically put on the airwaves.  In addition to the obvious benefits, such as the fact that the answers recorded by experts can be heard by a larger audience, we may be able to achieve much more.

For example, we may air selected questions by themselves, without necessarily waiting for the expert answers first.  We may use this initial airing to elicit a variety of responses.  We may encourage listeners to phone in their own answers based on prior experiences, perhaps with promises of "rewards" such as public recognition if their answers somehow proved "good."  We may encourage listeners to phone in similar or related concerns, with the hope that when an expert or a peer provides an answer later, a single stone could kill multiple birds.  We may encourage listeners to "vote" on questions that are of greatest interest.  (Of course, not all questions or responses deposited in the voice mail system will get air time: perhaps only the highly ranked or those deemed most relevant by experts may pass the "air filter.")

When we finally air selected (filtered) responses (from either peers or experts), we may encourage listeners to phone in testimony on how well some of the responses have worked out in practice.  (Such testimony may help build credibility of the expert opinions in particular and of the system in general, and help fix "bugs" in people's practice.)  With proper supervision, there might even be the hope of constructing a peer-help system.  And as the BAIF-UP anti-poverty program discussed above has demonstrated, the fresh mis-perceptions collected from the "front-lines" (in the form of peer responses left in the voice mail system) may shed particularly valuable light for experts as they attempt to formulate and tailor their own responses: identifying and combating mis-perceptions often should be the first step.

These are merely some of the examples of the new kinds of interactions made possible when we "liberate" the one-to-one exchanges "shackled" in a voice-mail-only system like Lifelines: the key element being enabled by the community radio component is richer modes of sharing.

2.2  Encouraging participation

One of the difficulties we may face is the initial bootstrap process: farmers may be unsure about how the system works or skeptical about its utility in solving real problems.  One way of dealing with this (and some other potential problems) is, again, borrowing a page from the case studies: in the case of Lifelines, field volunteers act as intermediaries between farmers and "the system."  The field workers demonstrate to farmers how to use the system and help them leave questions in the voice mail system and retrieve answers later.  (In the case of Lifelines field workers, they also manually collect complementary materials such as photographs---an issue that we will address later in this writeup.  The reliance on field workers is even more prominent in the BAIF-UP project discussed.)

A seamless integration of the proposed system with existing extension staff is a key strategy that we will follow.  For example, in a program like the BAIF-UP poverty relief project, the staff will continue to periodically meet the participating households face-to-face, but some of the communication, especially that involving the larger community, may be carried by the combination of the voice mail and community radio system.  The staff may also be equipped with voice recorders, which may prove better in certain situations, such as long-duration conversations.  (The critical role played by these staff intermediaries is also something that we have learned a great deal about in the past several years in our other endeavors, namely, Digital StudyHall, Digital Green, and Digital Polyclinic.)  We speculate that the community radio aspect of our proposed system may help it get adopted more easily than the vanilla Lifelines: the radio broadcasts may spread more awareness and the opportunity to be heard on air may simply provide more interest and incentive for people to participate.

An additional technique for encouraging participation is for our system to automatically and proactively dial the farmers with questionnaires, instead of passively waiting for calls.  This has a number of potential advantages: in countries where it is free to receive calls, it saves a farmer the cost of an outgoing call;  it is also potentially easier on farmers in case they don't know or have forgotten how to use the system; it may also be more systematic and ensures more periodic and complete coverage.

2.3  A networked farm radio station kit (or a "station in a box")

If we think of the community radio transmitter as the "output link," an automated phone handling system (a PBX) as the "input link," and our proposed system as the "web server," an aim of ours is to make the exercise of setting up such a system as easy as setting up a web server.  Later, we will discuss the implications for setting up a whole network of these "web servers."

The way Lifelines solves its call center problem is different from how we will approach it.  The Lifelines call handling system is based on a traditional model of running a PBX: a big centralized proprietary system (which includes proprietary hardware and software) from Cisco.  This is an expensive proposition (although in the case of Lifelines, it was probably donated).  There is not much customization available to end users, so it is not an ideal development platform.  (Imagine how the web will look if there is only one expensive centralized web server that is hardwired with a pre-packaged cgi-bin directory that cannot be changed!)

Our system is based on the open-source PBX system called Asterisk, in terms of both hardware and software.  The hardware for running a small PBX is inexpensive: the phone interface cards that we are currently using are only a couple hundred dollars each.  The low cost and extreme ease of customizability makes it ideally suited for decentralized operation, powerful customizations, software development, and small-scale experimentation.  We don't even necessarily require a land-line: such a small PBX can run off a single cellphone.  Low-power FM transmitters also cost only a coupled hundred dollars each.  What this means is that at least hardware-wise, it is feasible to provide a low-cost "station kit" that allows an NGO to easily set up a "node" of our proposed system almost anywhere.  The rest is "just" a matter of software.

When we speak of such a "kit," however, it is important to note that the "kit" can take on several "flavors" (so it's not a one-size-fits-all box), and not all these flavors need to even include any hardware.

For example, a "node" may choose not to run a PBX and depend on other nodes for its phone-handling capability.  (A node opt to run its own PBX for reasons related to issues such as specially customized local applications or call handling capacity: for example, a node, may need to "reserve" all 6-8pm slots everyday to run phone surveys that are managed by a locally-run database.)  A node may choose not to run its own FM transmitter, while still running a local PBX, whose content is funneled to a neighboring node that does run a transmitter that covers the population served by this node.

We anticipate that the voice mail databases will be (naturally) co-located with the nodes that do run their own PBX's.  (This is necessary for performance and reliability reasons.)  There will be several sites that house voice repositories that are kept highly available.  The other nodes in the system use these sites to share voice content with each other and with the rest of the public.  For example, a node, regardless whether it runs its own PBX, may obtain a "feed" from one of these voice repositories and use that to power its own FM transmitter.  It may contribute its own content back to the shared voice repository.  If a node is an existing community radio station and it does not desire to run its own PBX, the "kit" we provide may primarily just be software: it allows the node to configure and access a PBX and a voice repository housed elsewhere.  Although an Internet connection is desired, a node is not necessarily required to have one to participate in this network of farm radio station nodes: a disconnected node may just use "sneaker nets" to share data with its peers, in a way similar to how Digital StudyHall and Digital Green function today.

Our hope is to distribute these farm radio station kits, encourage NGOs to put up their own nodes to serve their communities, and these nodes join an ever-expanding hybrid network, whose members are inter-connected and constantly share content with each other.  The web analogy may be nearly complete---"nearly," because there are a few other enhancements or "advanced features" that we would like to discuss next.



2.4  Voice mailing-lists

In Lifelines, after leaving a question, a farmer is expected to call back later to retrieve the answer.  In our proposed system, the replies may be put on the radio airwaves.  An alternative "output" mode is to program our PBX system to call the questioner back with an answer.  (It need not be one way or the other, but instead it can be both or complementary.)  In addition to the original questioner, the system may dial a number of other phones that have "registered" their interest in certain topics.  We may imagine a mailing-list system that is similar to the email lists that we are used to, except that instead of sending emails to the list members, the system sends voice to a the list members' phones.  In general, the content put out on the mailing-lists may not necessarily be exclusively driven by questions initiated by list members.  For example, instead of questions, a list member may choose to tell each other about a new opportunity (say, a good price on some commodity).  The list can be "moderated" by staff at the server, or even a trusted member who accesses the list over a phone.

There may be a number of reasons why we want the answers to go out on phone lines instead of over the airwaves.  The first is convenience.  The radio broadcast may need to go out at a certain scheduled time.  A particular answer may be only a part of a longer program.  There may need to be a longer delay between when the answer is known and when a polished radio program is produced and ready to run.  A farmer may miss the radio program containing the relevant answer for any of several reasons.  A call back ensures pin-point accuracy and promptness.  The farmer may choose to hit the replay button and hear it again--something that may be more difficult to do to a radio broadcast.  A recipient may even customize features such as preferred call-back times, or whether the recipient prefers to call in to retrieve answers instead.

The second reason may be flexible range.  A topic may be of more private nature.  A topic may not necessarily warrant the wide distribution of the radio airwaves--it may only be meaningful for a smaller group.  There may not be enough time slots on the airwaves to accommodate all the topics.  Members of the list may be outside the radio transmission coverage area.  Content may move from the voice mailing-lists to the airwaves when a topic garners sufficient general interest.  Or it may go the other way: general-interest broadcast on the airwaves may be followed up by more specialized exchanges on the voice mailing lists.



2.5  An audio-wiki

The Lifelines system includes an audio FAQs that allows previous questions and answers to be reused.  As a result of storing these earlier exchanges, a one-time useful communication doesn't just disappear into thin air.  A subsequent query can be potentially more promptly fielded without waiting for expert input.  It also saves expert time as they don't have to waste breath repeatedly answering the same questions.  The Lifelines FAQs, however, could use some further improvements: the FAQs is only accessible by the staff, and the organization of a simple linear list may prove less than satisfactory as the database grows.

One way of establishing better linkage in our voice-mail repositories is simply via tagging, so a user may easily locate and jump to other related groups of topics.  Another is via hyper-linking (for example, by linking offsets within an audio snippet to locations within other audio clips).  There have indeed been several existing efforts of implementing audio hyper-linking that we may leverage.  These tags and links could be weighted based on their popularity or importance to facilitate navigation.  The tagging and linking will hopefully enable us to build a voice repository with richer organizational structures, evolving into something along the line of an "audio-wiki."

In addition to being used by the staff to formulate answers to questions left in the voice mail system, as is the case with Lifelines, the audio-wiki could be used in a variety of other ways.  For example, the staff may navigate the tags and links to include related content during the preparation of radio broadcast programs.  Callers may access parts of the audio-wiki by navigating phone menus.  Listeners may influence the progression of an on-air program by phoning in "votes" as the program "jumps" through the tags and links.  It may even be possible to run such a radio program in a semi-automated fashion (sometimes without an operator making all the decisions).  We may also explore the possibility of "networked links" from within one voice repository to another.

The audio-Wiki may also evolve beyond its audio-only format as, for example, hub staff produces video content that are based on the audio content.  Hubs specializing in some languages may choose to recruit volunteers or hire additional staff to translate selected relevant content available only in other languages in the database.



2.6  Embedded digital broadcasts

In Lifelines, in addition to helping farmers use the phone system, the volunteer staff also help collect photographs that are used by experts to formulate their responses.  The need for photographs has also been observed by other similar successful projects, such as eSagu.  The Lifelines voice-only responses, picked up by the questioners over the phone, however, are not accompanied by other materials.  In the experience of Digital Green, a video-based extension effort, the lack of visuals can sometimes be a severe limitation.  In this subsection, we explore ways of "broadcasting" complementary digital materials such as images.

There are several possible candidates that may serve as the digital "down-links."  One of these is the so-called "Radio Data System" (or RDS), a communication protocol for transmitting a small amount of digital information using conventional FM broadcasts.  The common implementations use a 57kHz subcarrier to carry data at about 1.1kbps.  Commercially available RDS encoders that are readily pluggable into FM transmitters cost a couple hundred dollars each.  RDS receivers can be had for less than $10 apiece, and there are open-source programs that work with them.  The traditional usage of RDS is for carrying a small amount of text information, which may include bits such as station identification, music track information, traffic information, and a small amount of free text.  In our proposed system, we may instead choose to encode and transmit arbitrary digital data, such as images.

Due to the limitation imposed by the small available "bandwidth" of RDS, we may not be able to depend on the needed digital information to be synchronously pushed out along the analog audio broadcasts.  A way around it is to "pre-push" the required digital bits, such as images, in earlier broadcasts, and when the time of the synchronized "simulcasts" arrives, the RDS channel will merely carry commands that instruct a player to display the pre-pushed and locally stored digital images.  (Such "pre-pushing" can be done via other types of communication channels, while the synchronized "play commands" can still always be carried by the RDS channel.)  Despite the need of extra time for pre-pushing, however, this technique should still allow relatively quick turn-around of question-answer cycles: 24-48 hours in the case of Lifelines.

The requirement of a player in this case, however, will be more demanding than a mere FM receiver.  If we desire to display images that are "synchronized" with the audio broadcasts, for example, we will need a receiver device that's almost a computer: it's hooked to a small RDS receiver on the one end and may be connected to a TV on the other end.  The player device can have enough "intelligence" to include features such as subtly panning and zooming the still images to make the content even more dynamic.

Due to its cost, such a setup will most likely only be used in a group setting, such as a "community center," where a group of farmers, along with a staff volunteer may gather to view, listen to, and discuss about the program.  (In our experience with Digital Green and Digital Polyclinic, these group sessions have proved to be extremely productive.)  In such a setting, in addition to displaying agriculturally relevant images such as those of a sick crop to go with the audio broadcast content, we may choose to show pictures such as a farmer practicing a particular technique, which may play an important role in raising the entertainment value of the program and the interest level of the participants.  The player device in this case may also act as a "DVR:" it can be set to record the programs for later replay.  In this scheme, the radio broadcasts are turned into something almost like TV broadcasts, but without the potential legal, technical, and cost implications of doing "real TV."  To enable such a scheme, the "audio-wiki" used to drive the broadcasts should include these complementary materials, such as digital images, from the get-go.



2.7  A farmer database

As is the case with the BAIF-UP poverty relief program, we intend to implement a farmer database that tracks census information as well as their progress.  The farmers' database should be inter-linked with the voice repositories.

3. How is this different from a traditional "community radio"?

Perhaps the most succinct way of describing the differences is just one word: "Internet."  By that we mean that the way the system works, the kind of the applications that are enabled by the system, and the philosophy behind the system are inspired by and more similar to the Internet applications that we have grown accustomed to and love than those of traditional community radio systems.  In this section, we elaborate on these differences.

3.1  The "network effect"

For the most part, a traditional community radio station is a small isolated entity.  Its strength lies in its ability to produce and play highly localized content.  However, while ad hoc exchange of content with the "outside world" is possible, there is not a systematic linkage to "others just like you."  One may think of it as a small "Intranet:" while it could be very valuable in certain roles, in many other ways, an Intranet lacks the power and richness of the "Internet."

In the use cases discussed above, we have enumerated some examples of the good the outside world has to offer: collective wisdom of peer farmers who might have struggled with exactly the same problems, outside experts, "memory" or "history" in the form of prior wisdom stored in a distributed knowledge database (the audio-wiki).  The contributions flow in the other directions as well: the experiences and wisdom of this particular village could help others at a different place and/or at a different time.  At the same time, even as we include more people across a wider area in the system, we are not sacrificing the local relevance advantage of traditional community radio systems--we are not broadcasting one-size-fits-all content typified by mass-media: all the local broadcasts are still tailored and adapted and, indeed, are likely to include interactions directly involving the locals.

What we are discussing here is the "network effect," which needs to reach a certain "critical mass" for it to truly realize its potential.  Perhaps the network effect advantage can be best understood if we look at the audio-wiki component of our community radio system: its construction is something that needs more than the participation of a few isolated villages or farmers, and once it reaches a critical mass of content, it may attract more to contribute and can benefit even more listeners.  This is the reason underlying our desire to provide a community farm radio station kit that encourages the development of a hopefully large network of these stations that share information with each other.

3.2  Application themes

A basic idea underlying the proposed system is to enable interesting applications that are inspired by (or analogies of) today's Internet applications.  In other words, we are interested in imitating the Internet philosophy without mandating the PC-only or broadband-only infrastructure.  In the example use cases discussed in the last section, we have seen some of these application analogies and how they might work in the community farm radio environment: a voice mail system, a "mailing-list" system, and an audio-wiki.  These are probably not the only application analogies and not the only ways to implement these analogies.  In the rest of this section, we discuss some common themes of these application analogies that make them different from traditional community radio stations.

• Interactive and participatory processes.  This is referring to not only interactions between listeners and hosts, or listeners and "experts," but perhaps more importantly, also interactions among peers, such as previous experience of farmers recorded for the benefit of later-comers.
  
  
• Many-to-many communication.  While the notions of "experts" vs. "questioners" might appear to imply some sort of hierarchical system, our aim is to actually enable something that's more like a cross-bar switch, something that enables anyone to communicate with anyone else in the system.  This is in contrast to a traditional mass-media system where a very small number of experts "lecture" a vast non-responsive audience.  In addition to peers, for example, we may enable a volunteer sitting at home in the US, to be able to record something that is delivered to a village FM transmitter half a world away.  Our system is also very different from a traditional phone model, which is intrinsically a point-to-point system.  In contrast, a voice mailing-list system in our case allows the notion of "groups" to be defined and allows "messages" to be beamed to whole groups of listeners.
  
  
• Asynchronous communication.  "Time-shifting" is perhaps as important as "space-shifting" in terms of conveniently delivering the most relevant information to the ones who need it.  The voice mail system and the audio-wiki discussed earlier are important time-shifting tools.  This is in contrast to traditional radio call-in shows where the expert and the questioner must somehow agree to "meet" each other on-air at a specific appointed hour, a severe limitation.
  
  
• A systematic and long-term memory.  In a traditional community radio station, due to legal requirements or due to the desire to reuse, the operator may choose to keep a record of recent broadcasts.  For the most part, however, these saved recordings, stored on tapes, CDs, or even hard disks, are ad hoc and scattered efforts, not easily accessible by a larger audience.  The web, on the other hand, did not rise overnight--it represents the cumulative wisdom of decades of work by many, work not just on production of new content, but work on systematic long-term storage and organization of existing content, all the while keeping everything accessible by everyone.  The audio-wiki discussed earlier is an analogy of this sort, a way of providing long-term storage and organization.  (There could be other ways than the audio-wiki to realize this analogy.)  Such an analogy should allow us to easily locate and retrieve relevant data from the long-term storage, and furthermore, should allow new content to be created that is based on the old content, and should allow meaningful linkages among all this content to be established.
  
  
• Automated/programmatic response.  In a traditional community radio system, almost everything needs the station operator to be in the loop.  An operator can be a double-edged sword: on the one hand, they can play the role of a valuable facilitator or instigator; on the other hand, human elements such as the operator's imagination, his memory, his attention level could be a bottleneck that limits the potential of the system.  In contrast, a lot of the functionalities of the web are delivered to its users without human beings directly involved in the loop.  (Think "cgi-bin" scripts.)  This is a feature that we would also like to imitate to some degree in our system.  For example, the audio-wiki example could potentially allow listeners to use a phone menu or SMS to choose or vote on what they want to hear.  Quizzes and educational games could potentially also be conducted in an automated fashion.  There may be other ways one may productively incorporate automated elements into a community radio system.  We should emphasize, however, our proposed system is never meant to replace humans: the farmers, the experts, the staff, the volunteers will always remain the most important players and the ultimate goal of the system is to connect them more effectively, not to replace them.
  
  

In the discussion of all these "themes," the community radio stations in our proposed system are meant to behave more as "output devices" of a far-reaching networked system, and with it, we hope to reap the benefits that may result from truly connecting those who have long been "outside the system."