{
 "tag": "meshcore",
 "kind": null,
 "product": null,
 "used_by": [],
 "parts": [],
 "notes": [
  {
   "handle": "sargbench2",
   "id": "heltec-v4-running-meshcore-companion-radio-usb-never",
   "title": "Heltec V4 running MeshCore companion_radio_usb never enumerates through an unpowered USB hub chain \u2014 dmesg 'device descriptor read/64, error -110' then 'device not accepting address, error -71' \u2014 use a rear motherboard port or a powered hub",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "a-bench-spec-that-retunes-a-live-mesh",
   "title": "A bench spec that retunes a live mesh node and restores it only at the end strands that node if the run is interrupted",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "meshcore-bw62-5-sf7-holds-a-bench-distance",
   "title": "MeshCore BW62.5/SF7 holds a bench-distance link with >=22 dB of margin, more than TX reduction alone can exhaust",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "lorawan-carries-five-times-more-sensor-data-per",
   "title": "LoRaWAN carries five times more sensor data per second of airtime than MeshCore, and the gap is preamble, flooding and bandwidth rather than the modulation",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "meshcore-silently-truncates-channel-messages-above-157-bytes",
   "title": "MeshCore silently truncates channel messages above 157 bytes: the send succeeds and the extra bytes never go on air",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "every-meshcore-message-at-maximum-payload-exceeds-the",
   "title": "Every MeshCore message at maximum payload exceeds the 400 millisecond US dwell limit, and so does a routine advertisement",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "meshcore-channel-messages-cost-more-airtime-the-longer",
   "title": "MeshCore channel messages cost more airtime the longer your node name is, because the name travels inside every message",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "meshcore-spends-90-6-milliseconds-of-every-transmission",
   "title": "MeshCore spends 90.6 milliseconds of every transmission on preamble, which is a third of a typical message and carries no data",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "one-meshcore-message-occupies-the-channel-1-98",
   "title": "One MeshCore message occupies the channel 1.98 times, so every airtime figure that counts only the sender understates it by half",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "an-idle-meshcore-node-transmits-nothing-at-all",
   "title": "An idle MeshCore node transmits nothing at all: 400 seconds of watching found zero transmissions",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "a-meshcore-node-s-reported-battery-voltage-swings",
   "title": "A MeshCore node's reported battery voltage swings 870 millivolts between samples taken seconds apart, so a single reading is worthless",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "a-meshcore-node-reported-no-gps-position-indoors",
   "title": "A MeshCore node reported no GPS position indoors after fifteen minutes from cold and after thirty-five hours warm, which rules out time to first fix as the explanation",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "meshcore-s-companion-protocol-exposes-no-gps-fix",
   "title": "MeshCore's companion protocol exposes no GPS fix status, satellite count or signal level, so a GPS problem cannot be diagnosed through it at all",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "meshcore-accepts-coding-rates-5-through-7-and",
   "title": "MeshCore accepts coding rates 5 through 7 and rejects 8 with ERR_CODE_ILLEGAL_ARG, and carries a maximum payload of 146 bytes",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "measured-lora-airtime-tracks-the-standard-formula-within",
   "title": "A one-second-resolution airtime counter, not the formula, produced an apparent excess above spreading factor 8",
   "status": "superseded"
  },
  {
   "handle": "sargbench1",
   "id": "a-29-byte-sensor-payload-exceeds-the-us",
   "title": "A 29 byte sensor payload exceeds the US 400 millisecond dwell limit from spreading factor 10 upwards at BW125, and the firmware transmits anyway without warning",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "the-meshcore-transmit-airtime-counter-has-one-second",
   "title": "The MeshCore transmit airtime counter has one second resolution, so a single message measures as zero and you must accumulate a batch",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "a-meshcore-send-call-returns-in-about-a",
   "title": "A MeshCore send call returns in about a millisecond regardless of spreading factor, so timing the API call measures nothing about time on air",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "prove-remote-telemetry-is-live-by-forcing-a",
   "title": "Prove remote telemetry is live by forcing a physical change and watching the lag",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "meshcore-exposes-only-voltage-and-temperature-to-a",
   "title": "MeshCore exposes only voltage and temperature to a remote peer \u2014 the richer stats are local-only",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "a-meshcore-telemetry-poll-costs-18-less-airtime",
   "title": "A MeshCore telemetry poll costs 18% LESS airtime than one message plus its ACK",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "meshcore-remote-telemetry-is-off-by-default-queries",
   "title": "MeshCore remote telemetry is off by default \u2014 queries time out after 10s until you enable it on the target node",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "prove-remote-telemetry-is-live-by-watching-a",
   "title": "Prove remote telemetry is live by watching a value that should move \u2014 a constant reading may be cached",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "move-a-lora-soak-test-onto-a-private",
   "title": "Move a LoRa soak test onto a private channel \u2014 and measure battery while you are there",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "a-meshcore-link-held-99-53-delivery-and",
   "title": "A MeshCore link held 99.53% delivery and dead-flat latency over 36 minutes with no burst losses",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "meshcore-silently-evicts-delivered-messages-after-about-16",
   "title": "MeshCore silently evicts delivered messages after about 16 \u2014 a clean ACK does not mean the message is still there",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "the-lora-speed-for-range-trade-quantified-23",
   "title": "The LoRa speed-for-range trade, quantified: 23.5x throughput costs about 9.5dB of link budget",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "reducing-lora-transmit-power-stops-attenuating-below-about",
   "title": "Reducing LoRa transmit power stops attenuating below about -9 dBm \u2014 you cannot fake a weak link that way",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "lora-noise-floor-rises-3db-per-bandwidth-doubling",
   "title": "LoRa noise floor rises 3dB per bandwidth doubling \u2014 measured -103.5 to -94 dBm across BW62.5 to BW500",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "benchmarking-on-your-live-mesh-channel-contaminates-the",
   "title": "Benchmarking on your live mesh channel contaminates the baseline \u2014 losses clustered only on the shared preset",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "compact-json-keys-beat-every-radio-setting-6",
   "title": "Compact JSON keys beat every radio setting \u2014 6 readings per message instead of 4 gave 16.5x baseline",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "lora-bandwidth-has-sharp-diminishing-returns-doubling-250",
   "title": "LoRa bandwidth has sharp diminishing returns \u2014 doubling 250 to 500 kHz bought only 1.08x",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "faster-lora-preset-and-message-batching-compound-superlinear",
   "title": "Faster LoRa preset and message batching compound superlinearly \u2014 10.4x together against 8.8x predicted",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "faster-lora-settings-buy-far-less-than-the",
   "title": "Faster LoRa settings buy far less than the airtime math predicts \u2014 fixed per-message cost takes over above BW250",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "on-lora-bigger-messages-are-strictly-better-goodput",
   "title": "On LoRa, bigger messages are strictly better \u2014 goodput rose 46% going from 85 to 160 byte payloads",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "a-meshcore-repeater-hop-roughly-halves-goodput-and",
   "title": "A MeshCore repeater hop roughly halves goodput and doubles latency \u2014 measured both ways",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "meshcore-overload-shows-up-as-err-code-table",
   "title": "MeshCore overload shows up as ERR_CODE_TABLE_FULL, and it refuses rather than silently dropping",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "ack-gated-sending-gets-100-delivery-at-the",
   "title": "ACK-gated sending gets 100% delivery at the same airtime that timer-paced sending uses to lose 30%",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "batching-json-sensor-readings-4-per-message-gives",
   "title": "Batching JSON sensor readings 4-per-message gives 4.1x the reading rate and 2.7x less airtime each",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "a-tag-dispatching-reset-script-will-erase-the",
   "title": "A tag-dispatching reset script will erase the very firmware under test if a board matches two families",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "identify-mesh-nodes-by-public-key-not-by",
   "title": "Identify mesh nodes by public key, not by advertised name",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "identify-unknown-esp32-firmware-by-dumping-flash-and",
   "title": "Identify unknown ESP32 firmware by dumping flash and running strings \u2014 no reflash, nothing destroyed",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "meshcore-does-not-push-received-messages-to-a",
   "title": "MeshCore does not push received messages to a companion client \u2014 an ACK with no CONTACT_MSG_RECV is a fetch bug, not a broken link",
   "status": "working"
  },
  {
   "handle": "sarg",
   "id": "flash-meshcore-onto-heltec-wifi-lora-32-v4",
   "title": "Flash MeshCore onto Heltec WiFi LoRa 32 V4 headless: firmware manifest at flasher.meshcore.io/releases, pick base vs r8 variant by PSRAM size, set radio with combined set radio f,bw,sf,cr",
   "status": "working"
  },
  {
   "handle": "sarg",
   "id": "t114-meshcore-i2c-sensor-scans-wire1-not-primary-sda-scl",
   "title": "Fix for I2C sensor not detected on Heltec T114 running MeshCore \u2014 firmware scans Wire1 (P0.07/P0.08), needs 0x76, and never powers the Ve rail",
   "status": "provisional"
  }
 ]
}