9 Participatory Sensing
participatory sensing, mobile crowdsensing, contributor records, mobile sensor data quality, aggregation review, sensing evidence
9.1 Start With the Crowd Story
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 Why
A decibel is a ratio wearing addition’s clothes. Sound power, like radio power, can span a million-to-one range between a quiet room and a loud hallway, so engineers compress that range with a logarithm: every doubling of power becomes a fixed \(+3.01\) dB step, and every ten-times jump becomes a fixed \(+10\) dB step, no matter where on the scale you start. That is why two phone models 4 dB apart are not “4 units” apart – they differ by a factor of about 2.5 in actual acoustic power. It is also why a systematic “+3 dB” bias is not a small rounding fudge: it is a real doubling of the reported power, silently baked into every reading that model produces, and it has nothing to do with how many bits the microphone’s ADC uses.
The Derivation
Decibel as a power ratio, and dBm as an absolute reference to 1 mW:
\[L_{\mathrm{dB}} = 10\log_{10}\!\left(\frac{P}{P_{\mathrm{ref}}}\right), \qquad P_{\mathrm{dBm}} = 10\log_{10}\!\left(\frac{P_{\mathrm{mW}}}{1\text{ mW}}\right)\]
The 3 dB and 10 dB rules follow directly:
\[10^{3/10} \approx 2.00\times \text{ power}, \qquad 10^{10/10} = 10\times \text{ power}\]
dB values add where the underlying ratios multiply: \(L_{\mathrm{total}} = L_1 + L_2 \Leftrightarrow P_{\mathrm{total,ratio}} = P_{1,\mathrm{ratio}} \times P_{2,\mathrm{ratio}}\).
Worked Numbers: Grading the Phone Offsets
- Two phone families, 66 dB vs. 70 dB (chapter’s own figures): a 4 dB gap is \(10^{4/10} = 2.51\times\) the acoustic power, not “4 units” of anything
- Stated systematic bias, +3 dB: \(10^{3/10} = 1.995 \approx 2.00\times\) – correcting 70 dB down to 67 dB (the chapter’s own adjustment) removes fully half of the excess power, not a small tweak
- Reference-meter check (chapter’s own numbers): meter reads 64 dB; family A at 65 dB is \(10^{0.1} = 1.26\times\) power; family B at 68 dB is \(10^{0.4} = 2.51\times\) power. A later B reading of 72 dB, corrected by the same \(+4\) dB offset, gives \(72-4=68\) dB – exactly the chapter’s stored adjusted value
- Quantization tie: a 16-bit phone-mic ADC (catalog-typical) has \(\mathrm{SNR} = 6.02(16)+1.76 = 98.1\) dB of headroom – far larger than the 1-4 dB device biases measured above, so “quantization error, fixed with a higher-bit ADC” cannot explain the gap. The biases are calibration/gain offsets between phone models, not sensor resolution noise, which is why the chapter’s accepted fix is provenance and correction, not a better ADC
9.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.
9.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.
9.4 Quick Check: Contribution Quality
9.5 Minimum Viable Understanding
- Participatory sensing is a contribution workflow, not just a larger sensor list.
- Each contributor record needs the same evidence fields before records are compared.
- Contributor context can explain differences between readings that look inconsistent.
- Aggregation should preserve uncertainty, rejected records, and scope limits.
- A shared result is defensible only inside the prompt, collection window, and acceptance rules used to create it.
9.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.
9.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 9.1 as the review path:
- State the shared question.
- Write the contribution prompt.
- Collect the phone reading or contributor note.
- Attach access state, timestamp, units, and context.
- Apply acceptance checks before aggregation.
- Write the aggregate statement and scope limits.
- Record retest triggers.
9.8 Contribution Record
A single contribution should be readable without asking the contributor to explain it later.
Include:
- Prompt version: the exact task instruction used for the contribution.
- Contributor action: what the contributor did, such as start a sample, add a note, or confirm context.
- Phone signal: location, motion, audio feature, image feature, external sensor value, or user-entered observation.
- Access state: granted, denied, unavailable, unsupported, stale, or interrupted.
- Timestamp: when the reading or note was created.
- Context note: placement, surroundings, collection posture, or other condition that affects interpretation.
- Quality state: accepted, suspect, missing, duplicate, or rejected.
- Scope limit: what this contribution 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.
9.9 Acceptance Gates
Contributed readings should pass basic gates before they are aggregated. The goal is not to discard every imperfect record; it is to keep accepted and suspect evidence visibly separate.
Review each contribution for:
- Prompt match: was the record created for the current task?
- Access state: did the required reading exist, or was it denied, unavailable, stale, or interrupted?
- Context note: does the record explain placement or contributor action when it affects meaning?
- Data quality: are timestamp, units, and uncertainty or validity state present?
- Comparability: can this record be compared with the other accepted records?
- Aggregate-ready state: should the record be accepted, kept separate, or rejected?
9.10 Contribution Modes
9.10.1 Active Contribution
The contributor intentionally starts a reading or writes an observation. This mode is easy to explain and review because the user action is visible. It works well for short exercises where each record needs a context note.
Review questions:
- What action starts the contribution?
- What confirms that the contribution completed?
- What happens if access is denied or the signal is unavailable?
- Which context fields must be entered before submission?
9.10.2 Prompted Sample
The app asks for a contribution when a learning activity reaches a defined point. The prompt should be short and consistent so records remain comparable.
Review questions:
- Is the prompt version stored with the record?
- Does the prompt state the expected phone placement or user action?
- Does the prompt collect only the fields needed for the shared question?
- Are incomplete records separated from accepted records?
9.10.3 App-Guided Reading
The app may guide collection using a defined trigger or collection window. This still needs a visible review record because automatic collection can be misunderstood without context.
Review questions:
- What condition starts and stops collection?
- What access and failure states are recorded?
- How does the app keep stale data separate from current data?
- What retest trigger applies if the trigger or collection window changes?
9.11 Aggregation Review
Aggregation combines accepted contributions into a shared statement. It should not hide the uncertainty or the records that were kept separate.
An aggregation review should record:
- the accepted records used;
- the suspect or rejected records kept out of the aggregate;
- the grouping rule, such as same prompt, same location label, same sample window, or same context category;
- the aggregate statement;
- the scope limit and residual concern;
- the retest trigger.
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.
9.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.
9.14 Common Mistakes
- Treating many phone readings as automatically reliable.
- Combining records that were created from different prompts.
- Hiding denied, stale, interrupted, or unsupported readings inside normal values.
- Ignoring contributor context such as phone placement or user action.
- Averaging suspect records without marking them as suspect.
- Making broad public claims from a narrow learning exercise.
- Leaving rejected records and retest triggers out of the review record.
9.15 Knowledge Check
9.16 Matching Quiz
9.17 Ordering Quiz
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.
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
Why Averaging the Crowd Isn't Enough
Participatory sensing comes in two modes, and both feed an aggregation step whose limits you must respect:
- Participatory: the user actively takes a reading (opens the app, records a sample). Higher context and consent, but sparser and self-selected.
- Opportunistic: the app samples automatically in the background. Denser coverage, but less context about how each reading was taken.
Worked example: averaging cannot remove a shared bias
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.
This is the accuracy-versus-precision lesson at population scale: a shared, correlated bias survives any amount of averaging. Crowd size buys precision, not accuracy.
Worked example: gate before grouping
A class receives 12 sound contributions for the same prompt. Eight records include prompt version, timestamp, access state, placement, and a 10 s sound feature. Two have no placement note, one has microphone permission denied, and one uses an older prompt with a 5 s sample window. A weak review averages all 12 and reports a single class result. A stronger review creates three buckets first: eight accepted records, three suspect/incomplete records, and one denied record.
The aggregate then uses only comparable records. If the accepted values are 61, 62, 62, 63, 64, 64, 65, and 65 dB, the median is 63.5 dB and the range is 61-65 dB within the exercise prompt. The report can say "accepted classroom samples were clustered around the low-to-mid 60s dB during this window." It should not say "the classroom is always quiet" or "the school has a safe noise level." Those broader claims would need calibration, repeated windows, and a reference measurement plan.
Practically, this means the app or worksheet should force the evidence fields before submission where possible, and the review table should keep suspect records visible. Hiding suspect records makes the number look cleaner while making the evidence weaker.
Practitioner Knowledge Check
Calibration, Coverage Bias, and Quality Gates
Turning heterogeneous contributions into a defensible result rests on a few disciplines that the raw crowd does not provide by itself.
Cross-device calibration
Learn each device's offset and gain by co-locating some contributors with a reference, or by exploiting overlapping measurements between devices (relative calibration), then normalise readings before aggregating.
Spatial-temporal coverage bias
Contributions cluster where and when people are — busy areas, daytime. The aggregate is a map of the crowd as much as of the phenomenon. Report coverage and weight or flag under-sampled places and times.
Acceptance gates before aggregation
Reject contributions lacking metadata (no location accuracy, no timestamp), out of plausible range, or taken in a bad context (phone in a pocket). Gate on quality first; aggregate second.
Privacy is part of quality
Location-and-time traces re-identify people, so aggregate, anonymise, and collect only the spatial and temporal precision the task truly needs — data minimisation protects contributors and reduces liability.
Worked example: offset correction and coverage limits
Assume a reference meter reads 64 dB during a co-located check. Phone family A reads 65 dB, so its offset is about +1 dB. Phone family B reads 68 dB, so its offset is about +4 dB. A later B reading of 72 dB is therefore stored as a raw observation, but the aggregate uses an adjusted value of about 68 dB. The record should keep both values so reviewers can see the original evidence and the correction applied.
Coverage needs the same discipline. If a neighbourhood map has 180 accepted records but 150 came from two commuter streets between 08:00 and 09:00, the sample count is high but the coverage is narrow. Dividing the area into 12 grid cells may show that only 4 cells have any accepted records and only 2 cells have repeated windows. The aggregate can describe the commuter-street observations, but it cannot support a citywide claim. Under-sampled cells should be marked separately, not coloured as if they were measured.
Privacy constraints also affect the technical design. A learning activity may only need 50 m location bins and 10 minute time bins, not exact GPS traces. Coarser bins can still answer the prompt while reducing re-identification risk. That is why calibration, coverage, acceptance gates, and privacy controls belong in the same review record: each one changes what the final aggregate is allowed to mean.
So a credible participatory-sensing result is never "we averaged everything." It is: gate contributions on quality, normalise across devices to remove per-model bias, weight for uneven coverage, and protect contributor privacy — then aggregate. The crowd supplies scale; these steps supply trust.
Under-the-Hood Knowledge Check
9.18 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.
9.19 Key Takeaway
Participatory sensing succeeds when data quality, consent, privacy, incentives, bias, and participant safety are designed together.
9.20 Concept Relationships
- The shared question defines the contribution prompt.
- The prompt defines which phone signal and context fields are needed.
- Access state and data quality determine whether a contribution is accepted, suspect, or rejected.
- Aggregation combines comparable accepted records under a stated rule.
- Scope limits and retest triggers keep the shared result bounded.
9.21 What’s Next
Continue through the mobile sensing sequence:
- Mobile Web Sensor Labs for browser-based mobile sensing practice.
- Mobile PWA & Audio Labs for installable and audio-oriented lab patterns.
- Mobile Sensors Labs for mobile sensing lab routes and assessment records.
- Mobile Sensors Assessment for checking sensor choice, access state, context, and review decisions.