Single-channel boards listen on one frequency and one spreading factor. A real LoRaWAN gateway listens on eight channels and all SFs at once. LoRaWAN nodes hop channels on purpose, so a single-channel board only catches the frames that happen to land on its frequency.
Laura, two separate things are going on.
Joins: on EU868, join requests use the three default channels, 868.1, 868.3 and 868.5. Your node picks one of the three at random, so a single-channel board on 868.1 hears roughly a third of the joins. That’s your “one in four”. The join accept then hands the node five more channels (867.1 to 867.9), so after joining it hops over eight.
You can pin it after the join for a bench test. In MCCI LMIC, in the EV_JOINED handler:
case EV_JOINED:
// bench only: keep channel 0 (868.1), drop the others
for (int ch = 1; ch < 9; ch++) {
LMIC_disableChannel(ch);
}
LMIC_setLinkCheckMode(0);
break;Don’t edit lmic_eu868.c, and don’t ship this to the field. It can’t help the join itself.
The UDP part is the real blocker though. Hermetry doesn’t support the legacy UDP packet forwarder at all, gateways connect with Basics Station or as a licensed router. So that board was never going to be a gateway in your organisation, which is why it isn’t listed. What you saw in the frames log came from somewhere else. Is there another gateway in the building? Ours picked up a neighbour’s frames before we added our own.
Bench option that works today: any cheap 8-channel indoor gateway that runs Basics Station. Ours cost less than the cold room sensors.