Developer mode
Developer Mode
The bcMeter interface has a hidden developer mode for hardware tuning and diagnostics. Changes in developer mode affect hardware directly and can make measurements unusable when set incorrectly. Use it only for support, development, or device-specific provisioning.
Activating Developer Mode
- Open Settings.
- Click the device name text next to "Configuration" 7 times within 3 seconds.
- The name changes to include
[DEV]. - A new ⚠ Dev tab appears in the settings panel.
Developer mode is active for the current page session and is reset when the page is reloaded.
Developer Tab Layout
The Developer tab opens with a warning banner:
Developer mode — changes affect hardware directly. Save only if you know what you are doing.
Settings are grouped by namespace. The values below match the current ESP32 firmware defaults in cfgstore.cpp.
BC Smoothing Algorithm
The first control selects the BC smoothing algorithm. This setting is stored as bc_filter.
| Value | Description |
|---|---|
median3 (default) |
3-sample median filter. Good default for rejecting isolated outliers. |
ema |
Exponential moving average. Smoother trend, slower response to abrupt changes. |
kalman |
Adaptive Kalman-style smoothing based on signal dynamics. |
Calibration (dev:calibration)
| Parameter | Description | Default |
|---|---|---|
sample_spot_diameter |
Sample spot diameter in cm. Used in BC mass concentration calculations. | 0.4 |
filter_scattering_factor |
Filter scattering factor used by the optical correction model. | 1.39 |
device_specific_correction_factor |
Per-device correction factor from lab comparison or provisioning. | 1.0 |
Optical (dev:optical)
| Parameter | Description | Default |
|---|---|---|
burst_measurement |
LED is only enabled during the final seconds of a sample cycle. Experimental power/thermal mode. | false |
adc_block_samples |
ADC samples per sensor/reference block. Higher values reduce noise and increase capture time. | 256 |
led_duty_cycle_370nm |
UV LED brightness/PWM duty for 370 nm channel. | 255 |
led_duty_cycle_520nm |
Green LED brightness/PWM duty for 520 nm channel. | 255 |
led_duty_cycle_880nm |
IR LED brightness/PWM duty for 880 nm channel. | 100 |
cal_k_370nm |
Calibration factor for the 370 nm channel. | 1.0 |
cal_k_520nm |
Calibration factor for the 520 nm channel. | 1.0 |
cal_k_880nm |
Calibration factor for the 880 nm channel. | 1.0 |
shadow_factor |
Weingartner shadow factor. Typical examples: 1.1 diesel, 1.2 urban, 1.5 biomass. | 1.2 |
Pump (dev:pump)
| Parameter | Description | Default |
|---|---|---|
pump_dutycycle |
Base pump power/PWM duty. | 20 |
max_pump_duty |
Maximum pump duty cycle. | 255 |
min_pump_duty |
Minimum pump duty cycle. | 1 |
min_airflow_ml |
Minimum airflow before stall recovery starts, in ml/min. | 70 |
twelvevolt_duty |
12V pump output duty cycle. | 20 |
reverse_dutycycle |
Reverse pump duty-cycle handling for hardware variants. | false |
disable_pump_control |
Disable internal pump control loop. Use only with external control hardware. | false |
TWELVEVOLT_ENABLE |
Enable 12V power output. | false |
log_pump_duty |
Write pump duty cycle into the CSV per sample. | false |
Auto Flow Control (dev:afc)
| Parameter | Description | Default |
|---|---|---|
afc_bc_low |
BC concentration below which AFC moves toward maximum flow. | 300 ng/m³ |
afc_bc_high |
BC concentration above which AFC moves toward minimum flow. | 2000 ng/m³ |
afc_flow_low |
Minimum airflow when AFC is active. | 0.05 L/min |
afc_flow_high |
Maximum airflow when AFC is active. | 0.7 L/min |
afc_slope_gain |
Flow boost per 100 ng/min downward BC trend. | 0.05 |
Hardware (dev:hardware)
| Parameter | Description | Default |
|---|---|---|
airflow_sensor |
Airflow sensor is installed and should be used. | true |
af_sensor_type |
Airflow sensor type: 0 = P0001A1, 1 = P0010A2. | 1 |
enable_wifi |
WiFi connectivity is available. | true |
iot_enable |
4G / IoT modem connectivity is available. | true |
show_undervoltage_warning |
Show warning when the optical 12V rail / ADC is not detected. | false |
System (dev:system)
| Parameter | Description | Default |
|---|---|---|
num_channels |
Number of optical wavelength channels. | 1 |
is_ebcMeter |
Direct emission measurement mode. Changes units and emission-oriented behavior. | false |
device_name |
Device hostname/name used for mDNS and UI display. | bcMeter |
heating |
Enable heating hardware if installed. | false |
use_display |
Device has an attached display. | false |
email_service_password |
Mail service password for DIY/development devices. Provisioned devices normally already have this set. | email_service_password |
onboarding_step_one |
Phase 1 onboarding complete: contact email and WiFi setup. | false |
onboarding_step_two |
Phase 2 onboarding complete: calibration and data sharing choice. | false |
onboarding_email_sent |
Welcome/access email has already been sent. | false |
team_upload_interval |
Cloud/team upload interval in hours when data sharing is enabled. | 1 |
bcmeter_team_email |
Contact email used for bcMeter team workflows. | empty |
last_cal_time |
Timestamp of the last successful calibration. | never |
Onboarding State
The current firmware stores onboarding progress with separate flags:
onboarding_step_one: WiFi/email phase completed.onboarding_step_two: calibration/data-sharing phase completed.onboarding_email_sent: welcome email has already been sent.
The browser also uses local storage and cookies for temporary "Skip for now" behavior. "Don't show again" writes the matching onboarding step flag to the device.
Development Build Detection
When the device is running a development build, the status API returns "env":"dev". The interface shows a red banner:
DEVELOPMENT BUILD — connected to dev backend
12V Power Warning
If the optical ADC is not detected, the interface can show a 12V warning:
⚠ 12V Power Missing — The optical ADC is not detected. Optics and light sensors will not function. Pump and airflow control may be limited by hardware state.
Development Device Variants
The bcmeter-dev Raspberry Pi codebase is useful for development and older prototypes, but it differs from the ESP32 production firmware. Device-specific differences should be treated as implementation details of the same function:
- Networking: Raspberry Pi builds may use Flask and NetworkManager, while ESP32 builds use the embedded web server and ESP-IDF WiFi stack.
- Optics/ADC: Pi builds may reference ADS8344E or MCP342X hardware; current ESP32 V2 builds use ADS1220-based optical acquisition.
- Firmware updates: Pi development devices may update through OS/GitHub release workflows, while ESP32 devices use OTA firmware images.
- Sensors: Development devices may expose DS18B20 or other prototype sensors that are not present on every ESP32 unit.