Abandoned 2026-09-14

MeshCore-FH Postmortem

A frequency-hopping layer for MeshCore, designed to keep narrowband operation legal in the US. It was wrong, and this is the record of what was tried, what it ran into, and what is actually established about Part 15 for anyone tempted to try the same thing.

Considered 2026-09-13 Abandoned 2026-09-14 Context MeshCore issue 945

This design was published, reviewed, and withdrawn inside 24 hours. Its central claim, that it complied with 47 CFR 15.247(a)(1), was false. The specification and its source have been removed and should not be relied on or cited.

What is left here is the part worth keeping: a map of the three regulatory routes available in 902 to 928 MHz with primary sources, a catalogue of what the design ran into, and the one question that is still genuinely open. The aim is that the next person considering this does not spend a day rediscovering it.

§1 What was considered

Issue 945 is eleven months and 377 comments long. Its subject is that MeshCore's US preset, 62.5 kHz at SF7, fails 15.247(a)(2)'s 500 kHz minimum bandwidth, so most US nodes operate outside the rules. The obvious fix is to widen to 500 kHz, and the standing objection is that Seattle and Boston both measured utility meter traffic every 300 kHz across the whole band, against which a 500 kHz channel has nowhere to hide.

Frequency hopping looked like the way to have both. 15.247 permits narrow channels if you hop, so the idea was to keep a narrow signal, gain diversity against the meters, and satisfy the rules at the same time. The design that came out of that was 125 kHz at SF8, 50 channels spaced 200 kHz, 2000 ms dwell per channel, with every node computing its channel from a shared clock and a shared pseudorandom sequence so receivers hopped in lockstep with transmitters.

It was published, then attacked by four independent adversarial reviews, then withdrawn. The order of those first two steps was the original mistake and everything else followed from it.

§2 Why it was abandoned

Not because of the defects, which are catalogued in section 4 and were all individually fixable. It was abandoned because the case for building anything at all did not survive contact with the numbers. Three reasons, in descending order of how solidly established they are.

1. The payoff is negative against a setting already deployed

The design was pitched as 1 dB better than the 500 kHz alternative. That compared against SF10 and omitted SF11, which is what Philadelphia actually runs. At 500 kHz / SF11 the sensitivity is about 1 dB better than today's 62.5 kHz preset and 1.5 dB better than this design, with no network split, no shared clock, the full 255-byte packet size, and coverage under existing module grants. The omitted row was the entire argument.

2. The architecture bought nothing over a much simpler one

FCC guidance KDB 558074 section 10(b) states that hybrid systems have neither a 500 kHz minimum bandwidth nor any minimum number of hopping channels, and Semtech puts the hybrid power ceiling at about 22 dBm for 125 kHz LoRa, which is what the radio does anyway. So 50 synchronised channels delivered zero dB over a handful of channels. The elaborate structure existed to reach a provision that gave it nothing.

3. The stated benefit was probably the wrong mechanism

The justification was dodging utility meters. Those meter networks are themselves frequency hopping systems, so a 300 kHz comb on a spectrum analyser is a max-hold of a hop pattern rather than fixed occupancy, and no static channel plan dodges a hopping interferer. What hopping actually offers against that is time diversity, which is a real but far smaller benefit, and not the one that was claimed. See section 6.

§3 The regulatory map

This is the part worth keeping. Issue 945 has spent a year arguing about which rule applies without anyone assembling the three routes side by side. Everything in this table is quoted or measured from a primary source, not inferred.

Rule text from 47 CFR 15.247. Hybrid rows from FCC KDB 558074 D01 section 10(b), items (1) through (5), and FAQ 5. Hybrid power ceiling from Semtech AN1200.64: "a typical LoRaWAN gateway ... is categorized as a hybrid system with an 8 dBm/3 kHz power density limitation if using LoRa modulation. That converts to about 22 dBm output power for BW125 LoRa."
	Digital modulation (DTS) 15.247(a)(2)	Frequency hopping 15.247(a)(1)	Hybrid 15.247(f)
Minimum bandwidth	6 dB BW ≥ 500 kHz	none	none
Minimum channels	n/a	50 if 20 dB BW < 250 kHz 25 if ≥ 250 kHz	none
Dwell limit	n/a	0.4 s per channel per 20 s (narrow) per 10 s (wide)	0.4 s per channel per 0.4 × N s
Channel separation	n/a	≥ greater of 25 kHz or the 20 dB BW	same as (a)(1)
Power limit	1 W	1 W with ≥50 channels 0.25 W with 25 to 49	PSD-limited, about 22 dBm at BW125
Power density	8 dBm / 3 kHz	not applied	8 dBm / 3 kHz, hopping off
Pseudorandom order, equal channel use	n/a	required	required
Receiver hops in sync with transmitter	n/a	required	required
15.247(h) non-coordination	applies	applies	does not apply
LoRa grants exist	yes, at 500 kHz (the common case)	yes 2ARKMOBDLRA1, X94-0005922	yes, at 125 kHz VPYCMABZ, SQG-RM191, M82-WISE1510, RID-LT501

Four numbers that settle recurring arguments in that thread

The 20 dB bandwidth of a 125 kHz LoRa signal is 135 to 167 kHz. Measured across five accepted FCC test reports. So a 200 kHz hop grid satisfies the separation test with margin, and 125 kHz LoRa falls in the under-250 kHz tier of (a)(1)(i), needing 50 channels. Semtech AN1200.26 independently specifies a 150 kHz minimum separation for BW125 and 310 kHz for BW250.
Dwell time is a span, not a sum. KDB 558074 Answer 4: it runs "from the beginning of the first transmission on a channel and ending at the end of the last transmission in that same channel", and "includes any non-transmissions that may occur between transmissions on the same channel". Idle time after the last transmission before hopping does not count. So sitting on a channel for two seconds is fine; transmitting twice a second apart is not.
Occupancy in the window is multiplied, not averaged. Two accepted test reports compute it as dwell per visit times the number of visits within the period, with no division by the period. There is no averaging theory under which a channel visited twice in a 20 second window comes in under 0.4 s.
The FCC has refused to relax the 500 kHz floor. DA 12-839 (2012) dismissed Starkey's petition to lower it to 100 kHz and denied the waiver, stating the Commission "specifically chose the 500-kilohertz minimum 6 dB bandwidth ... to exclude narrowband systems from using the higher power limits of Section 15.247."

§4 What the design ran into

Catalogued because anyone attempting narrowband hopping on this stack will meet most of these. Each was verified against primary sources or against the MeshCore source, not merely asserted by a reviewer.

DwellIndependently keyed per-cycle permutations let a channel be the last slot of one cycle and an early slot of the next, putting 800 ms on one channel inside a 20 s window in about 6% of windows. A compliant sequence needs a no-repeat constraint across cycle boundaries, not just within a cycle.
DwellA per-slot airtime budget is the wrong shape entirely, because dwell is the span from first to last transmission including the gap. Certified hybrid LoRa devices transmit once per channel visit. Copy that.
MTUReducing the packet size to fit a dwell budget breaks MeshCore's routing invisibly. Path hashes are appended per hop while only the path buffer is checked, and over-length packets are dropped through a debug macro that compiles to nothing in release builds. Dispatcher::checkSend, MESH_DEBUG_PRINTLN. Adverts die at the second hop with no error anywhere.
MTUAny packet-size cap must be stated end-of-path, not at the originator, since repeaters grow the packet. 118 bytes becomes 119 and 408 ms at the first repeater, over a 400 ms budget.
MTUThere is no data fragmentation in stock MeshCore to fall back on. PAYLOAD_TYPE_MULTIPART carries only acknowledgements. createMultiAck is the sole producer; the handler's other branch is a FUTURE comment.
ClockA shared hop clock cannot be authenticated within MeshCore's key model. The sync field has to be readable by nodes holding no key for the payload and rewritten at every hop, which excludes both per-pair keys and end-to-end signatures, and there is no network-wide key. One radio sending one packet with a false timestamp moves every node that hears it, and the error then spreads through the sync mechanism itself.
ClockWith no time authority, partitions are permanent and undetectable. If a cycle counter keys the sequence, two groups more than one cycle apart are on unrelated channels and each hears only itself. A regional power outage yields one permanent partition per self-electing repeater.
ClockA proportional-only correction loop leaves a steady-state error proportional to the silence between receptions, so hold time is far shorter than capture range suggests. Needs a frequency-estimating loop. And a plain 32.768 kHz crystal has a parabolic temperature coefficient, so cold overnight drift is several times the room-temperature figure.
LinkComparing sensitivity across bandwidths using a uniform 2.5 dB per spreading factor ladder yields a figure that is pure arithmetic, identical for any noise figure and any chip. And in an interference-limited band, doubling receiver bandwidth collects proportionally more interference, so the honest penalty is far larger than the thermal-noise calculation suggests.
PlanA hop grid commensurate with the interferer spacing is the worst available choice. A 200 kHz grid against a 300 kHz comb shares a factor, so a third of channels sit exactly on an interferer and none is more than 100 kHz away. Choose a spacing incommensurate with the local interferer, or pick channels non-uniformly against a measurement.
MethodA verification test that cannot fail is documentation, not verification. The dwell test here compared a constant against itself and printed PASS while the sequence was violating the limit. If a check has no input that makes it fail, it proves nothing.
MethodAn instrument whose loop drives the logged error to zero will report success regardless of a constant bias in the measurement path. Here a helper clamped airtime to a 200 ms floor against a true 121 ms, most of the tolerance being tested.
MethodDo not validate a timing design on the one board in the fleet with the best clock, and check which oscillator actually drives the system timer. The T1000-E's radio has a TCXO; its MCU timebase is a plain LFXO.

§5 The one question still open

Both the hopping and hybrid routes require that receivers track the transmitter's sequence. 47 CFR 15.247(a)(1): "The system receivers shall have input bandwidths that match the hopping channel bandwidths of their corresponding transmitters and shall shift frequencies in synchronization with the transmitted signals." The natural escape is to claim the hybrid provision instead, since it has no bandwidth or channel-count minimum, but KDB 558074 section 10(b)(5) closes that:

"The hopping function must be a true frequency hopping system, as described in Section 15.247(a)(1). The specific requirements in Section 15.247(a)(1) are: i) a minimum channel separation; ii) pseudo-random hop sequence; iii) equal use of each frequency; and iv) receiver matching bandwidth and synchronization."

Every asynchronous scheme proposed in issue 945 therefore has an obstacle nobody there has raised: channel-activity sweeps, preamble sampling, and anything where the receiver hunts for a transmitter rather than meeting it at a known frequency. But two things stop this being a conclusion, and an earlier version of this page overstated it before they were checked.

First, the FCC never measures it. KDB 558074 section 9(c)(1) asks an applicant only to "Describe how the associated receiver(s) has the ability to shift frequencies in synchronization with the transmitted signals", and the verb has been "describe" in every version from 2000 to 2019, with no test setup and no pass criterion. Second, Texas Instruments published "Asynchronous channel hopping system for FCC 15.247 compliance" in 2015, describing exactly that architecture, and its review of the rule quotes 15.247(a)(1)'s first two sentences while omitting the receiver-synchronisation sentence, reducing the requirement to "50 hopping channels, 400 ms dwell time, 25 kHz minimum channel separation".

So it is a fork, and both branches tell you something:

if the clause binds

Compliant narrowband hopping needs a shared clock, and a shared clock cannot be secured within MeshCore's key model. Narrowband by way of hopping is then not available to MeshCore as it stands, and the choice is 500 kHz or reduced power.

if it does not bind

Asynchronous hopping is available, and much simpler than what was attempted here: a handful of channels, no clock, no flag day. But it rests on the same species of unreviewed reading of 15.247 that issue 945 has been arguing over for a year.

Neither branch is a compliance claim, and presenting one as settled is the specific error that got the original document withdrawn. Twice.

§6 What would actually be worth measuring

One empirical question would settle whether any hopping variant is worth considering, and it needs a software-defined radio and an evening rather than a protocol.

If the utility meter networks are themselves frequency hopping, then interference on any given narrow channel is bursty rather than continuous, and a retransmission two seconds later on a different channel may well succeed where an immediate retry on the same channel would not. That is time diversity, and it is the only benefit hopping plausibly delivers here. It is also measurable directly: capture a narrow channel in 902 to 928 MHz over hours and characterise the interference as burst length and gap distribution rather than as an average noise floor.

If the gaps are long relative to a packet, hopping buys something real and the case can be rebuilt on honest grounds. If the interference is effectively continuous, hopping buys nothing and 500 kHz is simply the answer. Either result is a contribution to issue 945, and neither requires forking anything.

§7 Provenance

The withdrawn design, the four adversarial reviews that found its errors, and this page were all produced with agentic coding. The design was published before the reviews ran, which was the wrong order and is the root cause of everything above: the architecture survived its author's scrutiny for hours and died in roughly twenty minutes of being attacked properly.

Regulatory text here is quoted from 47 CFR 15.247, 47 CFR 2.1, FCC KDB 558074 D01, and DA 12-839. Bandwidth and dwell figures come from accepted FCC test reports, identified by FCC ID so they can be checked. Read those rather than this page. Nothing here is legal advice, and compliance is the operator's responsibility.