8 Participatory Sensing

8.1 Start With the Crowd Story

Keep Each Person’s Context Before Combining the Crowd

Picture residents using their phones to map street noise. One reading comes from a pocket, another from an open hand, and a third from beside a bus. A bright average can hide those different conditions and make one area look louder than it was.

Start with the decision the map will support and the people affected by it. For every contribution, retain the phone identity, place, event time, arrival time, measurement unit, user prompt, and a short context note. Explain what people agreed to share and how they can stop or correct a record.

Run a small field check before merging the data. Place two phones together, move one indoors, delay an upload, repeat a record, and submit a value with missing context. Check which records remain comparable, which need a warning, and which should stay out of the combined result. Keep the originals so disagreement remains visible.

This check cannot remove every phone difference or participation bias. People and devices change. The deeper sections show how contribution records, calibration, privacy, coverage, and feedback support an honest crowd result.

Participatory sensing starts with many small records, not one magic average. Each contributor brings a phone, a prompt, an access state, a place, a time, and a context note that must be reviewed before records are combined.

Phoebe’s Field Notes: What a “+3 dB” Phone Bias Really Costs

The mathematical gist. Decibels turn power ratios into additions: $L=10\log_{10}(P/P_{ref})$, so a 4 dB phone-family gap means $10^{4/10}=2.51\times$ acoustic power. A repeated +3 dB bias is nearly a doubling, not a rounding error; preserve device provenance and correct against a reference meter rather than blaming ADC bit depth.

Math Bridge · guided foundationsWhat does a phone's decibel bias mean physically?Let Phoebe turn the chapter's 1-4 dB offsets into power ratios and a reviewable correction. Learn the maths

8.2 In 60 Seconds

Participatory sensing uses phones carried by contributors to collect observations for a shared sensing task. The value comes from many scoped contribution records, not from assuming that every phone reading is automatically comparable. Each record should show the prompt, phone signal, access state, context note, data quality checks, accepted or rejected state, and the decision the combined data can support.

This chapter keeps the workflow bounded. It does not ask learners to run open-ended campaigns or make claims outside the exercise evidence. It teaches how to review contribution evidence before combining phone-based observations.

8.3 Learning Objectives

By the end of this chapter, you will be able to:

• Explain how participatory mobile sensing differs from a single-phone sensing record.
• Design a contribution prompt that produces reviewable sensor evidence.
• Identify context fields needed to compare contributed readings.
• Separate accepted, suspect, missing, denied, and unsupported contributions.
• State what an aggregate contribution set can and cannot support.
• Record retest triggers for changes in prompt, phone signal, context, or acceptance rule.

8.4 Quick Check: Contribution Quality

8.5 Minimum Viable Understanding

Participatory sensing is a contribution workflow, not simply a larger sensor list. Give every contributor record the same evidence fields before comparing records, because placement and other contributor context may explain readings that initially look inconsistent. Aggregation must preserve uncertainty, rejected records, and scope limits instead of hiding them in a single value. A shared result is defensible only inside the prompt, collection window, and acceptance rules that produced it.

8.6 Prerequisites

• Mobile Phone as a Sensor: phone signal roles, setup evidence, and interpretation limits.
• Mobile Sensors Intro: mobile sensing vocabulary and basic phone signals.
• Mobile Sensor APIs: access state, permission handling, timestamps, and data quality fields.
• Sensor Applications: Domain Overview: decision questions, measurands, validation records, and retest triggers.

8.7 Participatory Sensing Workflow

A participatory workflow starts with a shared question and a clear prompt. The prompt tells contributors what to observe, when to collect, which phone signal or note is needed, and what context must be recorded. Without that shared structure, the combined data set is difficult to review.

Use Figure 8.1 as the review path:

1. State the shared question.
2. Write the contribution prompt.
3. Collect the phone reading or contributor note.
4. Attach access state, timestamp, units, and context.
5. Apply acceptance checks before aggregation.
6. Write the aggregate statement and scope limits.
7. Record retest triggers.

8.8 Contribution Record

A single contribution should be readable without asking the contributor to explain it later. Preserve the prompt version and the contributor’s action, such as starting a sample, adding a note, or confirming context. Identify whether the phone supplied location, motion, an audio or image feature, an external sensor value, or a user observation, and keep that source with its granted, denied, unavailable, unsupported, stale, or interrupted access state. The timestamp and context note capture when and under what placement, surroundings, or collection posture the record was created. Finally, classify it as accepted, suspect, missing, duplicate, or rejected and state what it can support—and what it cannot prove.

The same fields should be used for every contributor in the exercise. Mixed records can still be useful, but the review should identify which fields changed.

8.9 Acceptance Gates

Contributed readings should pass basic gates before they are aggregated. Before combining anything, inspect Figure 8.2 to see why prompt match and access state come before data quality and comparability. The goal is not to discard every imperfect record; it is to keep accepted and suspect evidence visibly separate.

Read Figure 8.2 from left to right. First confirm that the record answers the current prompt and that the required reading existed rather than being denied, unavailable, stale, or interrupted. Next, check whether placement or contributor action is documented when it affects meaning and whether timestamp, units, uncertainty, and validity state are present. Comparability is a later decision: only records made under compatible rules should enter the same aggregate. The final gate therefore labels each contribution as accepted, separate, or rejected instead of forcing unlike evidence into one result.

8.10 Contribution Modes

8.11 Aggregation Review

Aggregation combines accepted contributions into a shared statement. Before calculating or summarising, inspect Figure 8.3 to see how the accepted and suspect streams remain separate until the grouping rule has been declared. This prevents a convenient result from hiding uncertainty.

Read Figure 8.3 from the two input groups into the grouping rule. Accepted records supply the aggregate, while suspect or rejected records remain visible beside it rather than disappearing. The grouping rule—such as a shared prompt, location label, sample window, or context category—states why the selected records are comparable. Only then should the review write the aggregate statement, its scope limit and residual concern, and the condition that triggers a retest. That sequence connects the shared result back to the individual contribution evidence.

Avoid broad claims from narrow contribution sets. For example, a set of learner sound observations can support a comparison inside the exercise prompt. It should not be presented as a complete environmental assessment unless additional evidence and review rules are supplied.

8.12 Worked Review: Shared Sound Observation

Scenario: learners submit short sound-condition notes from phones during a classroom exercise.

Shared question

Which accepted observations describe louder or quieter local conditions during the exercise?

Prompt

Start one sample, keep the phone uncovered, and add a short context note about placement and surroundings.

Contribution record

Each record stores prompt version, access state, timestamp, derived sound feature or observation note, and context note.

Acceptance checks

Reject records with missing timestamp, interrupted collection, missing context, or a note that does not match the prompt. Keep uncertain records separate instead of averaging them into accepted records.

Aggregate statement

Accepted observations can be compared within the exercise scope. The record does not prove long-term sound conditions or conditions outside the contribution window.

Retest trigger

Repeat the review if the prompt, sample window, phone placement expectation, or acceptance rule changes.

8.13 Worked Review: Route Context Note

Scenario: contributors record a brief motion-and-location note for a route segment during a learning activity.

Shared question

Which route notes appear consistent enough to compare within the activity?

Prompt

Start the note at the marked segment, keep the phone placement consistent, and submit only one note for that segment.

Contribution record

Each record stores prompt version, phone placement, location uncertainty when available, motion signal summary, timestamp, access state, and completion state.

Acceptance checks

Separate notes with missing placement, broad location uncertainty, duplicate submissions, or interrupted collection. Do not treat phone motion as a direct statement about the contributor’s movement unless placement supports that interpretation.

Aggregate statement

Accepted notes can support a bounded comparison of submitted route observations for the activity. They do not prove continuous route conditions or conditions outside the submitted segment.

Retest trigger

Repeat the review after changing the route prompt, phone placement instruction, grouping rule, or access path.

8.14 Common Mistakes

More phone readings are not automatically more reliable. Do not combine records made from different prompts or hide denied, stale, interrupted, or unsupported outcomes among normal values. Contributor context such as placement and user action may explain apparent disagreement, so it must survive aggregation. Suspect records should remain marked instead of being averaged silently. Keep public claims within the narrow learning exercise, preserve rejected evidence, and name the change that would require the contribution and aggregation rules to be tested again.

8.15 A Crowd of Phones Is a Crowd of Different Instruments

Participatory sensing turns many people's phones into one distributed instrument — thousands of contributors mapping noise, air quality, or traffic at a scale no fixed sensor network could match. That is the promise: coverage and scale for almost no hardware cost.

The catch is that every phone is a different, uncalibrated instrument. One contributor's microphone is more sensitive than another's; one runs an older sensor with a different offset. Combining their readings into a trustworthy map is therefore a data-quality problem, not merely a data-collection one. The hard engineering is in what you do after the readings arrive.

Before treating coverage as trustworthy evidence, inspect Figure 8.4 to see where participatory sensing can be applied and which constraints grow with scale. The application branches explain the attraction; the cross-cutting challenges explain why collection alone is not the engineering result.

Read Figure 8.4 outward from participatory sensing into transportation, environment, health, and safety use cases. Then return to the privacy, battery, and data-quality constraints that cross every branch. More contributors expand spatial and contextual coverage, but they also multiply instrument variation and governance obligations. This connects the scale promised by crowdsensing to the acceptance and aggregation records developed later in the chapter.

Intuition: crowdsensing is like asking a thousand people to measure temperature with a thousand different thermometers, none of them checked. You get huge coverage, but you cannot just average the numbers and call it truth.

Worked example: the same sound event on two phones

Suppose four learners stand in the same hallway during a 30 s activity. Two Android phones report A-weighted sound features near 66 dB, while two older phones report 70 dB for the same event. The difference is not automatically a real 4 dB sound gradient. It may be microphone gain, case obstruction, operating-system audio preprocessing, or phone placement.

A reviewable contribution record keeps the comparison bounded: prompt version noise-v2, sample window 10:15:00-10:15:30, phone model family, access state, placement note, and whether the phone was held open or kept in a pocket. If the older phones are known to read about +3 dB high from a co-located check, their 70 dB readings become about 67 dB before aggregation. If placement is missing, those records stay suspect instead of being averaged into the accepted set.

The important habit is not memorising one correction value. It is treating each phone reading as evidence with provenance. Participatory sensing becomes defensible when records carry enough context to explain why two measurements can differ before the learner makes a shared claim.

Overview Knowledge Check

1000 contributors report a noise level. Averaging their
readings reduces RANDOM error by about sqrt(1000) ~ 32x.

BUT: 600 of them use the same popular phone model, whose
mic reads a systematic +3 dB high. That +3 dB is the SAME
on all 600 devices, so it does NOT average away -- the
aggregate is biased about +2 dB regardless of crowd size.

Averaging fixes random scatter (precision), never a shared
systematic bias (accuracy). More contributors do not help.

8.18 Knowledge Check

8.19 Matching Quiz

8.20 Ordering Quiz

8.21 Summary

Participatory sensing turns phone-based observations into useful shared evidence only when each contribution is reviewable. The core workflow is prompt, contribution record, context note, acceptance check, aggregation rule, scope limit, and retest trigger. Aggregation should make accepted and suspect records visible instead of hiding evidence gaps.

8.22 Key Takeaway

Participatory sensing succeeds when data quality, consent, privacy, incentives, bias, and participant safety are designed together.

8.23 Concept Relationships

The shared question defines the contribution prompt, and that prompt selects the phone signal and context fields each record needs. Access state and data quality then determine whether a contribution is accepted, suspect, or rejected. Aggregation can combine only comparable accepted records under an explicit rule; it does not repair missing context or incompatible prompts. Scope limits keep the resulting statement bounded, while retest triggers reopen the workflow when the question, collection window, access path, or acceptance rule changes.

8.24 What’s Next

Continue through the mobile sensing sequence with Mobile Web Sensor Labs for browser-based practice, then use Mobile PWA & Audio Labs for installable and audio-oriented patterns. Mobile Sensors Labs brings the lab routes and assessment records together, while Mobile Sensors Assessment checks sensor choice, access state, context, and review decisions.