Vad betyder i MeshCore: “Collision Group” egentligen?
Du öppnar MeshMapper eller en observer-logg och ser något i stil med:
AMBIGUOUS ID DETECTED
Collision Group:
Repeater-A
Repeater-B
Repeater-C
Repeater-D
Repeater-E
Repeater-F
Första reaktionen är lätt: “Är nätet trasigt?”
Oftast är svaret: nej.
Det här betyder normalt inte att repeatrarna stör ut varandra, att antennen är fel, eller att dina meddelanden inte går fram. Det betyder att analysverktyget inte säkert kan avgöra vilken fysisk repeater ett paket passerade, eftersom flera repeaters delar samma korta identifierare.
Problemet: för kort repeater-ID
När ett MeshCore-paket går genom en repeater lägger repeatern till ett slags spår i paketets vägdata. MeshMapper beskriver det som att varje repeater “stämplar” paketet med ett prefix från sin Public ID, alltså ett hop-ID. I 1-byte-läge är detta bara de första två hextecknen, till exempel 4A eller D5. Det är kompakt och radiosnålt, men det finns få unika kombinationer. (wiki.meshmapper.net)
MeshCore-dokumentationen beskriver att den ursprungliga designen använder första byten av repeaterns publika nyckel i path-data. Med 1 byte finns bara 254 användbara ID:n eftersom 00 och FF är reserverade. I ett växande nät är det därför fullt möjligt att två eller flera repeaters råkar få samma kort-ID. (docs.meshcore.io)
Det är då du får en Collision Group.
Vad betyder “Collision Group”?
En Collision Group är en grupp repeaters som MeshMapper inte kan skilja åt med den korta identifierare som syns i path-data.
AMBIGUOUS ID DETECTED
Collision Group:
Repeater-A
Repeater-B
Repeater-C
Repeater-D
Repeater-E
Repeater-F
Det betyder inte att alla dessa repeaters var inblandade i samma paket. Det betyder:
“Någon repeater med detta korta ID verkar ha varit inblandad, men flera repeaters har samma ID, så vi vet inte vilken.”
Det är lite som att en loggbok säger “SA7” utan suffix. Om flera stationer i området börjar på SA7 räcker inte informationen för att veta exakt vilken station det var.
Påverkar det trafiken?
I de flesta fall: nej, inte själva meshtrafiken.
MeshCore FAQ är tydlig med att paket fortfarande passerar genom repeaters och att meshen inte skadas av duplicerade 1-byte-ID:n. Problemet är i stället att verktyg som MeshMapper och LetsMesh får svårare att analysera vägval och täckning korrekt. (docs.meshcore.io)
Det här är en viktig skillnad:
Radiomässigt: nätet kan fungera.
Analysmässigt: kartan kan bli osäker.
Därför kan meddelanden fortfarande gå fram även om MeshMapper säger AMBIGUOUS ID DETECTED.
Varför MeshMapper blir försiktig
Om MeshMapper gissade fel repeater skulle kartan kunna visa falska länkar, fel täckningsdata och missvisande statistik. Därför hanterar MeshMapper ID-krockar genom att skydda datakvaliteten. Vid krockar kan berörda repeaters sättas i ett slags karantän/excluded-läge så att coverage-data inte felaktigt kopplas till fel fysisk repeater. (wiki.meshmapper.net)
Det kan kännas frustrerande, men det är rätt beteende. En karta som säger “vi vet inte” är bättre än en karta som självsäkert visar fel.
Lösningen: multi-byte hops
MeshCore har numera stöd för längre repeateridentifiering: 1, 2 eller 3 byte. MeshMapper stödjer också multi-byte hops. Med 2 eller 3 byte blir risken för ID-krockar mycket mindre. MeshMapper anger att MeshCore firmware 1.14.0 och nyare stödjer multi-byte repeater hop identification upp till 3 byte, och att regioner som kör 2- eller 3-byte hops får betydligt färre kollisioner. (wiki.meshmapper.net)
På repeatern styrs detta med CLI-kommandot:
set path.hash.mode 2
Det betyder att repeatern använder 3-byte path hash i sina egna advert-sändningar.
MeshCore CLI-dokumentationen anger värdena så här:
0 = 1 byte = 256 unika ID:n
1 = 2 byte = 65 536 unika ID:n
2 = 3 byte = 16 777 216 unika ID:n
3 = reserverad, använd inte
Samma dokumentation förklarar också att path.hash.mode styr den ID/hash-storlek som används när repeatern skickar adverts, och att firmware 1.14+ ska vidarebefordra alla storlekar oavsett denna inställning. (docs.meshcore.io)
Praktiskt åtgärdsrecept för repeaterägare
För en repeater som till exempel Sa7cmz Solar Repeater skulle en rimlig process vara:
ver
get path.hash.mode
set path.hash.mode 2
reboot
Efter omstart behöver repeatern höras av MeshMapper igen, helst via en flood advert. MeshMapper-dokumentationen beskriver processen: uppdatera firmware, sätt 2- eller 3-byte med set path.hash.mode 1 eller set path.hash.mode 2, starta om och skicka en flood advert så att repeatern kan uppgraderas i MeshMapper som multi-byte-capable. (wiki.meshmapper.net)
Det är också viktigt att regionens MeshMapper-inställningar matchar nätets praxis. I adminpanelen finns Hop Bytes, där regionen kan konfigureras för 1-byte, 2-byte eller 3-byte repeateridentifiering. MeshMapper beskriver även att duplicate repeater IDs kan upptäckas som en admin-alert. (wiki.meshmapper.net)
Ska alla byta direkt?
För repeaters: ja, om de kör firmware 1.14+ är det normalt klokt att sätta 2- eller 3-byte adverts.
För companion-noder är man mer försiktig. MeshCore FAQ anger att äldre repeaters före 1.14 bara repeterar 1-byte path hash och droppar 2- eller 3-byte-paket. Därför bör en region samordna övergången innan vanliga klienter börjar skicka kanal- och DM-trafik med större path hash. (docs.meshcore.io)
En bra tumregel:
- Repeater adverts: uppgradera gärna till 2 eller 3 byte.
- Vanliga meddelanden från companions: följ lokal regionpraxis.
- Blanda inte vilt utan att prata med communityn.
Vad en observer kan och inte kan lösa
Att placera en observer nära en repeater förbättrar datakvaliteten. Den hör fler paket, bättre signaldata och fler adverts. Men en observer löser inte automatiskt en ambiguous ID-krock.
För att kollisionen ska lösas behöver MeshMapper kunna koppla repeatern till ett längre och unikt ID. Det kräver i praktiken:
- repeater på modern firmware,
- path.hash.mode satt till 1 eller 2,
- reboot,
- advert som MeshMapper faktiskt hör,
- regioninställningar som accepterar rätt hop byte-längd.
Observern är alltså “ögon och öron”, men repeatern måste fortfarande presentera sig på ett sätt som går att särskilja.
Sammanfattning
AMBIGUOUS ID DETECTED betyder inte att din MeshCore-installation är trasig. Det betyder att analysverktyget ser en ID-krock mellan repeaters. Meshtrafiken kan fortsätta fungera, men kartor, traces och coverage-statistik blir osäkra.
Den långsiktiga lösningen är att regionen går mot multi-byte hops, särskilt för repeater adverts. För en modern repeater är nyckelkommandot ofta:
set path.hash.mode 2
reboot
Därefter behöver MeshMapper höra repeatern igen.
Det här är ett typiskt växtvärkproblem i ett mesh-nät. När nätet är litet fungerar korta ID:n fint. När nätet växer behövs bättre identifiering. Det är egentligen ett gott tecken: nätet har blivit stort nog för att behöva mer ordning.