Meerdere zenders, en 1 ontvanger

Meerdere zenders op 1 ontvanger, bijvoorbeeld bij een draadloze quizschakeling of een Audience Response System of meerdere sensoren.

Het lijkt zo eenvoudig, 1 ontvanger, zenders sturen een Id mee en dan komt het goed. Maar als 2 signalen tegelijkertijd binnenkomen dan gaat het mis als ze allemaal op dezelfde frequentie werken.

1: Dit is op te lossen door niet elk apparaat automatisch te laten sturen, maar door dit verkeer te regelen door een master. Die geeft dan aan wanneer welk apparaat zijn data mag sturen.

2: Maar wat nu als het om snelheid gaat, zoals een quiz. Hoe zorg je dat iedereen in real time mee doet. 2 mensen kunnen best kort na elkaar de knop indrukken. Hoeveel vertraging kan er in zo'n systeem zitten voordat wij mensen een vertraging ervaren? Is dit genoeg om nog steeds het verkeer via een master te regelen?

3: Andere manier zou zijn om kleine frequentie verschillen aan te brengen, maar dan moet ik dit na de ontvanger gaan opsplitsen of meerdere ontvangers gebruiken.

Als punt 2 werkt is dit eenvoudig te combineren met punt 1. Het lijkt me een kleine uitbreiding om letters/cijfers op te sturen nadat de snelste deelnemer is geselecteerd.

De vragen komen een beetje omdat ik voor de klas sta en het me aardig lijkt om het te gebruiken, en uit nieuwsgierigheid naar de hoge bedragen voor dergelijke systemen. Is het echt zo ingewikkeld of wordt er flink aan verdiend.

Voor de duidelijkheid toch wat eisen voor zo'n systeem om de discussie een beetje af te bakenen.

  • Geschikt tot 100 deelnemers per ontvanger
  • Ontvanger past ongeveer in een ruimte van 10*10*10cm (stand alone) of een usb dongle (pc)
  • 1 knop per deelnemer (buzzer achtig)
  • 2 richtingsverkeer voor feedback naar de deelnemer
  • Bereik van 20 meter
LED there be light
Frederick E. Terman

Honourable Member

Als je een 'master' zou willen gebruiken, moet iedere knop behalve een zender ook een ontvanger hebben.

Maar als de knoppen toch al een ontvanger hebben, heb je geen verkeersregelaar nodig. Het is dan voldoende dat een knop alleen kan zenden als hij geen andere knoppen ontvangt.
Het is dan echt 'eerst komt, eerst maalt'.

Een combinatie is natuurlijk ook mogelijk: de knoppen zenden eerst een 'acquisitie' packet uit; wordt een knop door de master erkend als eerste ('wint' hij dus de acquisitie), dan mag hij de rest van de data sturen.
Het is hierbij niet nodig dat de knoppen elkaar kunnen ontvangen; ze hoeven alleen de master te kunnen ontvangen.

Dit is eigenlijk een variant op packet radio verkeer, en veel mogelijke oplossingen vind je daar ook terug. Mijn eerste oplossing heet Carrier sensed multiple access; de tweede wordt toegepast bij 'hidden nodes', waar aanvragers niet naar elkaar (kunnen)luisteren, zoals bij satellietverkeer.

Keramisch, kalibratie, parasitair: woordenlijst.org

Ja ik was er al vanuit gegaan dat iedere knop een zender en ontvanger bevat.

Maar hoe voorkom je dat signalen tegelijkertijd rond gaan en elkaar verstoren.

LED there be light
Frederick E. Terman

Honourable Member

Als de knoppen elkaar kunnen horen, zullen ze niet zenden als er al een andere zendt.
Gebeurt het een enkele keer toch (een 'collision'), dan krijgen ze geen respons en proberen overnieuw, na een willekeurig aantal milliseconden (random generator, iedere keer anders, anders zouden ze stééds precies tegelijk zenden).

In mijn tweede voorbeeld kijkt de master alleen naar de header, is die binnen dan geeft hij de knop 'spreektijd'.
Mislukt ook dit, dan weer hetzelfde verhaal.

Alles is na te lezen in stukken over packet radio.

Keramisch, kalibratie, parasitair: woordenlijst.org

Ik was er al vanuit gegaan dat 'spreektijd' reguleren een mooie oplossing was. Dat houd de data in eerste instantie klein, hoeft alleen maar de ID van de knop te zijn.

Maar goed als de knoppen dus allemaal naar elkaar luisteren, dan zal in de meeste gevallen er geen probleem zijn.

Packet radio ga ik me nog even wat meer in verdiepen dan 10 minuutjes.

Hoeveel tijd is er nodig om een signaal te versturen? Als de knop zijn header verstuurd hoeveel tijd moet het dan wachten voor het opnieuw wat verstuurd? Ik kan het niet zo goed inschatten, maar kan dit snel genoeg dat deelnemers het niet doorhebben?

Klinkt verder nog altijd eenvoudig. Alles op dezelfde frequentie, niet te veel poespas. Nog even afgezien van het op de juiste manier versturen van een signaal.

Als we een standaard behuizing gebruiken moeten de kosten toch kunnen halveren?

LED there be light
Frederick E. Terman

Honourable Member

Hoeveel tijd het kost hangt van jouw ontwerp af! Hoeveel bandbreedte heb je, hoe snel kun je klokken, hoeveel tijd heeft de (digitale) squelch van de ontvanger nodig om te herkennen dat er iets binnenkomt (zolang moet de zender al zenden voordat de header mag komen) ... enzovoorts.

Werk je op 5 GHz met een perfect signaal, dan heb je het over een paar ms. Met goedkope 433MHz spulletjes een paar honderd keer zo lang, maar dan gaat het nog over tienden van seconden - die trouwens voor iedereen gelijk zijn, maar wel goed merkbaar.

e: Als je duplex kunt werken, haal je al een enorme snelheidswinst, doordat de boel niet steeds hoeft in te slingeren. De 'turn around time' voor het luisteren naar de master vervalt dan.

[Bericht gewijzigd door Frederick E. Terman op 19 mei 2012 12:05:21 (15%)]

Keramisch, kalibratie, parasitair: woordenlijst.org

Ik heb even de tijd genomen om na te denken wat er nu staat.

Ik wil nog aangeven dat dit geen lopen project voor mij is, of iets wat ik in korte tijd wil bereiken, meer een proof of concept, begrijpen hoe het kan werken, en of het haalbaar is om het na te maken, binnen een hobby budget. (geen betaalde ontwikkelingsuren dus :))

Wat voor onderdelen zijn er beschikbaar waarmee het kan. eisen voor printplaten, programmeertaal beperkingen, en waarom zijn er wel forums te vinden waarop het wordt besproken, maar kan ik geen bevestiging vinden dat het gelukt is? Is het zo complex of zo duur qua techniek?

[Bericht gewijzigd door Joeri de Man op 19 mei 2012 18:06:14 (30%)]

LED there be light
Frederick E. Terman

Honourable Member

Ik had er nog nooit van gehoord dat iemand dit gemaakt zou hebben. In studio's zie je altijd gewoon bedrade knopjes, en de 'quiz-schakeling' is hier al vaak onderwerp van gesprek geweest.

Wat jij wilt komt erg overeen met het aanvragen van een datablok in packet-switched netwerken, dus dat wiel is al eens uitgevonden.
Maar dat is iets anders dan te zeggen dat de draadloze quiz-knopjes al bestaan als hobbyproject. Ik denk dat je de eerste zult maken!

Ik zou me over printplaten, zenders, ontvangers en programmeertalen nog geen zorgen maken.
Eerst moet je eens tijdschema's opstellen van wat er zou kunnen gebeuren, wat de reacties moeten zijn..

Het is jammer dat packet-radio al zo oud is - eigenlijk grotendeels vóór internet goed onderweg was. De informatie staat wel op het net, natuurlijk, maar is niet gemakkelijk te vinden omdat er bijna nooit naar gevraagd wordt.

Zoek in elk geval eens op X25, CSMA, 'hidden node' en kijk wat je vindt.

Keramisch, kalibratie, parasitair: woordenlijst.org

Een idee wat door ons forumlid HMH werd aangedragen was om een timestamp mee te sturen. Als er dan probleem is met botsingen is de orginele tijd beschikbaar. Dan kan er als het binnen is gecontroleerd worden wie het snelst was.

Bij de volgende vraag worden dan eerst weer alle knoppen weer op 0 ingesteld en de timers gestart.

Maargoed die tijdscherma's worden ondertussen in elkaar gezet.

LED there be light
Frederick E. Terman

Honourable Member

Dat is een slim idee, maar het zadelt je op met een extra verantwoordelijkheid, namelijk het tijdbeheer.
Als je dat goed kunt oplossen is het een mogelijkheid, maar het mist de robuustheid van het 'ruwe' protocol.

Keramisch, kalibratie, parasitair: woordenlijst.org

Wat bedoel je met het "ruwe" protocol?

We hebben al een aantal technieken genoemd:

  1. knoppen luisteren naar elkaar en zenden niet als er al verkeer is
  2. Bij een botsing zend de knop na een random wachtperiode opnieuw zijn signaal uit.
  3. Master geeft aan welke knop wat mag doen.
  4. timestamp meesturen om volgorde te bepalen.
  5. Duplex

punt 2 Het lijkt me dat punt 2 altijd voorkomt.

Combineer je punt 2 met punt 4 dan weet je zeker wie er als eerste gedrukt is.

Punt 1 twijfel ik een beetje over, het voorkomt wel dat alle knoppen blijven sturen, maar vereist wel dat er continue geluisterd wordt.
Iig als het werkt voorkomt het een hoop botsingen.
Vereist wel dat de ontvangers onderscheid kunnen maken tussen ruis en datapakketen van de knoppen.

punt 4 een idee was om de capture module of iets gelijkwaardigs te gebruiken. Deze telt direct op het kristal van de microcontroller, en zal de waarden gelijk opslaan zodra op de knop wordt gedrukt.
Deze wordt weer op 0 gezet vanuit de master

punt 3 Zal van toepassing zijn indien er meer dataverstuurd moet worden. Dus eerst een Id sturen, en dan krijgt de knop pas toestemming zodat er geen botsingen zijn.
Master kan ook voor de terugkoppeling zorgen.

LED there be light
Frederick E. Terman

Honourable Member

Met 'ruw' bedoel ik: tijd van ontvangst bepaalt wie het eerst is.
Als de knop geen bevestiging van ontvangst krijgt, moet hij opnieuw zenden, net zolang tot hij wèl bevestiging binnen heeft (of het packet time-out gaat).

Als de knoppen niet naar elkaar luisteren werkt dit al, maar soms kan er extra vertraging optreden doordat er maar steeds doorheen gezonden wordt door iets 'latere' knoppen.
Het is (uiteraard!) te berekenen vanaf welk aantal knoppen bij welke trafficload dat een probleem wordt. Het is vanzelfsprekend een exponentiele functie. :)
Dit systeem heet 'pure Aloha'.

Je zou ook kunnen afspreken alleen te starten op vaste tijden ('slotted Aloha'), maar dat lijkt me hier ondoenlijk: je moet dan per knop een nauwkeurige timer gaan bijhouden, en bovendien moet de knop dan wachten tot het volgende slot is aangebroken. Dat strookt niet met de quiz-gedachte.

Wel praktsich is wèl naar elkaar te luisteren. Je voorkomt daarmee een hoop storing van packets die al bezig zijn verzonden te worden. Je kunt dan dus, voor dezelfde kans op xx vertraging, meer knoppen kwijt. Dit systeem heet CSMA.

Of je al je data de eerste keer al verzendt, of alleen een ID ('ik, ik!') is een keuze die je nog weer onafhankelijk kunt maken. Het voordeel van kortere packets ligt weer in de bezettingsgraad. Dat kan belangrijk worden als latere knoppen ook nog iets mogen doen.
Als alleen de eerste geldt, dan is CSMA mogelijk al genoeg.

Als je duplex kunt werken, dan kun je ervoor kiezen de knoppen continu naar de master te laten luisteren. Je hebt dan niet de turn-around vertraging tussen zenden en luisteren. Omdat de knoppen nu niet naar elkaar luisteren, maar naar de master (en continu), loopt het 'zwijgen opleggen' dan via de master, bijvoorbeeld doordat die alle ontvangen packets in bijna-real-time (dus bit voor bit) heruitzendt.

Google eens op AX25, protocol, packet radio. Al deze problemen had je daar ook.

Keramisch, kalibratie, parasitair: woordenlijst.org

Dat mag dan goed uitgezocht zijn, het is zeker geen eenvoudige materie.

Aan de andere kant, een aantal onderdelen van het protocol kan al door de juiste tranceiver module worden vervangen.

Bijvoorbeeld het controleren op het ontvangen signaal wel behoort tot het netwerkje.
Het versleutelen en ontcijferen van de data.

Fijn dat je alle termen weet FET, dat scheelt toch wel met zoeken.

LED there be light
Frederick E. Terman

Honourable Member

Klopt, veel is tegenwoordig ingebakken. En het hoeft natuurlijk niet het X25 (of AX25) protocol te zijn; je kunt iets simpelers nemen.

Dat gezegd hebbende, hier ben ik wel zo'n beetje aan het eind van mijn kennis. :) Hoop dat het lukt, dat zou een leuke first zijn volgens mij.

Keramisch, kalibratie, parasitair: woordenlijst.org

Lijkt wel een klusje voor de RFM70 transceiver module (Voti.nl).

Daar zit ik inderdaad naar te kijken Kees.

Als ik het goed begrijp handelt die zelf de paketten af. Kan geen duidelijkheid vinden over de interferentie, maar ik denk dus dat die alleen data doorgeeft wat aan de eisen voldoet.

Dan hoef ik dus niet zelf een protocol te maken.

LED there be light