Variabele lengte hash.

Als je bang bent voor veel "ikke", kun je dan niet gewoon aan de andere kant van het ID beginnen?

Er zijn al zoveel protocols 'uitgevonden'...
Bijv. UNI/O van Microchip: http://ww1.microchip.com/downloads/en/devicedoc/22076d.pdf

Zomaar een idee:

Gebruik het ID om een LFSR random number generator te initialiseren. Draai die 10 slagen. Concatenate de uitkomst en ID.

Zo voorkom je dat devices uit dezelfde batch dicht op elkaar zitten in een binairy search.

Ander idee:

Laat devices op een enumeratie-request met een (random) delay reageren. En laat ze alleen reageren als er niet al niemand anders reageert. (dat kan onbetrouwbaar zijn afhankelijk van je onderliggende communicatie-techniek, YMMV)

Zo zal er waarschijnlijk steeds slechts een de eerste zijn, en die kun je dan enumereren, en vertellen dat ie verder zijn bek moet houden.

Voordeel van deze techniek is dat ie ook werkt zonder uniek ID.

Blurp: Thanks. Goed plan!

In plaats van lfsr initializeren wat mij betreft liever iets van CRC32 (uniq) | uniq gebruiken, De uniq ids zijn nu 96 bits, dus dan wordt dat samen een 128 bits. Mooi rond.

Ook dat met delays dat kan: wacht een random veelvoud van 2* tijd om een byte te versturen. En dat reset je als je hoort dat iemand anders aan het antwoorden is. En met de "probe" kan je doorgeven: Vandaag is maximum veelvoud: 100. (als je bijvoorbeeld 10 devices verwacht).

2* byte tijd is wat mij betreft gekozen om 1 byte tijd de tijd te hebben om "hey, d'r is wat binnengekomen" te verwerken en daarop te reageren. Als je bij zo'n "hey iemand anders reageert" steeds je oude random blijft houden, dan krijg je dat als alle devices die < 5ms hadden gekozen ondertussen gerageerd hebben je 5ms extra gaat wachten voordat iedereen die 5.1 had gekozen gaat reageren. Kortom, je moet een nieuwe random verzinnen als er voor einde van je random een ander blijkt te reageren. Ohh!!!

Nog makkelijker: als iemand reageert voor jou, dan blaas je de hele "reageer op verzoek" af. De master verwerkt rustig dat iemand geantwoord heeft, probeert hem tot stilte te manen en stuurt dan op z'n gemak een volgende "stuur met maxrandom=xx een antwoord".

Op 15 augustus 2020 16:18:56 schreef rew:
Nu kan ik gewoon afkijken naar wat "onewire" of RDM doet, maar "not invented here" dat kan natuurlijk beter.

Wie zegt dat? Veel is er al bedacht en de kans dat je het zelf beter kunt wordt met de jaren kleiner.

Diverse van dit soort protcollen doen bit-voor-bit het uniek id aflopen, maar als dan bijvoorbeeld op onewire je 30 tempsensors hebt uit dezelfde batch, dan krijg je dus de eerste dertig probes steeds "Ikke!!!!"

En precies na 30 probes heb je ze ook allemaal gevonden want per iteratie heb je er elke keer eentje te pakken, de devices met een niet dominant bit worden weggezeeft, daar is toch niks mis mee? En de 31-ste scan levert een ID van allemaal 1-nen, dus kun je dan stoppen.

Of stoor je je aan het feit dat als je een 96-bits ID hebt 31(nodes)x96 bits moet oversturen?

Dan kun je een 32 bits hash maken van je originele 96-bits ID bijvoorbeeld door domweg een SHA te gebruiken en er 32 bits af te knippen. Dat dan door de enumaratie/collision detection mangel heen halen.

De vraag is hoe je nu zeker weet dat er geen 2 devices dezelfde hash hebben? Zou alleen kunnen door nadat je de enumeratie gedaan hebt aan het device vragen: Stuur me een getal <magic> teug met een random delay en dan kijken of je ook dat nummer terug ziet. Als het verpest is of je krijgt 2 nummers dan heb je op die 2 nodes een collision gehad en moet je weer iets anders moeilijks gaan doen om dat op te lossen.

Maar alles bij elkaar gaat je dat denk ik geen verkorting (in tijd) van je enumeratie opleveren. Je wint aan het begin en verliest het weer aan een check later.

Wat is nu je echte doel?

Op 15 augustus 2020 17:51:38 schreef rew:
Nog makkelijker: als iemand reageert voor jou, dan blaas je de hele "reageer op verzoek" af. De master verwerkt rustig dat iemand geantwoord heeft, probeert hem tot stilte te manen en stuurt dan op z'n gemak een volgende "stuur met maxrandom=xx een antwoord".

Je kunt het heel simpel maken, zelfs zonder collision detect in de slaves. Als je N devices hebt, en de maxrandom tijd is veel groter van N*lengte antwoord dan is er een goede kans dat twee antwoorden niet tegelijk komen.

Oftewel:

• Master stuurt enumeratie-request met max-respons tijd.
• Slaves sturen na random delay tussen 0 en max respons antwoord.
• Master enumereert alle slaves waarvan een goede respons ontvangen is, en maant ze verder tot stilte.
• Master stuurt nieuwe request voor resterende slaves, net zo lang tot er geen respons meer komt.