Advies gevraagd: betrouwbaar WiFi-opzet indoor event

[pgmw]

Hallo,

Ik ben op zoek naar advies voor het opzetten van een betrouwbare mobiele/private WiFi-oplossing voor indoor evenementen. We zijn een non-profit organisatie met een beperkt budget, maar willen investeren in hardware die we de komende 2–3 jaar kunnen hergebruiken.

We hebben beperkte ervaring met WiFi-opstellingen op deze schaal en zouden graag advies krijgen over met name geschikte access points en netwerkopzet.

We hebben hier zelf niet veel ervaring mee op grotere schaal en zouden graag input krijgen over bijvoorbeeld benodigde hardware (voornamelijk geschikte AP's)

Situatie / doel:
Tijdens het evenement willen we een stabiel, WiFi-netwerk opzetten dat los staat van de bestaande (onbetrouwbare) wifi in de sporthal. We hebben wel toegang tot het bekabelde internet en patches die zich in de hal bevinden.

Het netwerk wordt gebruikt voor:

• 5 mobiele telefoons die via WiFi video streamen (DroidCam) naar een productiecomputer (livestream productie)
• ±25 vrijwilligersapparaten (telefoons) die via internet resultaten invoeren (laag dataverbruik, eventueel alternatief via 5G mogelijk)
• Totaal: ±30 actieve devices op piekmomenten

De productiecomputer verwerkt de videostreams en verstuurt de uiteindelijke livestream via een bekabelde internetverbinding (400 Mbps down / 180 Mbps up), beschikbaar vanuit een patchkast in de zaal.

Belangrijke details:

• Speelzone: ±35 × 35 meter
• 3 van de 5 camera-telefoons bewegen tijdens het evenement
• Publiek: 300–400 personen, maar zij gebruiken dit netwerk niet
• Bestaande wifi in de hal is zwak (mogelijk 1 AP in de hoek)
• Bekabeld internet is beschikbaar via patchkast en mogelijk bestaande patchpunten

Wat we fysiek kunnen doen:

• Access points plaatsen op ~2–3 meter hoogte (op de ingeklapte tribune-constructies - met o.a. tie-rips)
• Ethernet bekabeling trekken naar vrijwel elke locatie
• AP in het midden van het veld is mogelijk, maar liever vermijden
• Bestaande patchpunten kunnen gebruikt worden

---

Wat we graag willen weten:

1. Hoeveel access points zijn realistisch voor stabiele dekking in een 35×35m indoor ruimte?
2. Is dekking vanaf alleen de randen voldoende, of ontstaan er dode zones in het midden?
3. Is een mesh-oplossing hier realistisch, of is een volledig bekabelde backhaul sterk aan te raden?
4. Welke hardware zouden jullie aanraden met een budget van ongeveer €1000?
5. Hoe groot is het impactprobleem van roaming voor bewegende camera-telefoons? En is dit op te lossen?

Wat voor informatie we hebben gevonden. Alleen kunnen we niet beoordelen of dit juiste info is:

• 4 AP’s in de hoeken + eventueel 1 centraal AP indien nodig
• WiFi 6 op 5 GHz met 40 MHz kanaalbreedte om interferentie te beperken

Budget:
Ongeveer €1000 totaal (AP’s + bekabeling). Aangezien het om een investering gaat, is dit uiteraard een schatting, er is wel wat 'extra' budget.

Afbeeldingen:
Hieronder nog een aantal afbeeldingen van de zaal. Puur ter indicatie.
De ingeklapte blauwe tribunes kunnen gebruikt worden om AP's op te bevestigngen. Deze zijn ongeveer 2 meter hoog. Het rode vierkant getekend is 'ongeveer' het speelveld.


Hieronder nog een plattegrond over de indeling:
Wij denken dat het mogelijk is om AP's op de groene vierkanten neer te zetten, en de rode vierkanten is dan eventueel een patch aansluiting. Daarnaast, in het midden van het veld zouden we eventueel nog een AP kunnen plaatsen mocht dit echt noodzaklijk zijn.

---

Alle tips, ervaringen of voorbeeldopstellingen zijn welkom. Vooral praktijkervaring met vergelijkbare indoor events zou ons enorm helpen.

FYI: Dit is de sporthal in de Galgenwaard in Utrecht.

[jant]

35 meter x ~35 meter != 35m2

Op design.ui.com kun je een plattegrondje uplooien in jpeg en dan AP's toevoegen. Dat laat geeft een idee van de dekking.

[ Voor 162% gewijzigd door jant op 25-05-2026 14:26 ]

[franssie]

Van hoek tot hoek zou het dan 50 meter zijn. Dus een AP is het midden, ook al is het niet gewenst, hoeft maar 25 meter ver hoeven te stralen. Heb je ook geen controller etc nodig.

[itsalex]

Ik denk als je in de hoeken gaat zetten, en sporthal is van metaal vaak dus dak en draagbalken dat je juist storting gaat krijgen. Ik zou sowieso al iets naar binnen doen zodat je dekking meer omni is. Daarnaast zou je eventueel 2dehands Unifi NanoHD doen, eventueel nog een paar extra punten. WiFi 6 moet ook de ontvangende partij aan kunnen/hebben. Met een Unifi PoE switch en router zou je al heel ver kunnen komen.

[pgmw]

jant schreef op maandag 25 mei 2026 @ 14:04:
35 meter x ~35 meter != 35m2

Op design.ui.com kun je een plattegrondje uplooien in jpeg en dan AP's toevoegen. Dat laat geeft een idee van de dekking.

Ah ja! Foutje van mij :-) Ik kan helaas de titel niet meer aanpassen. Ik zag het direct nadat ik het had gepost.

Die designer is inderdaad van goede toegevoegde waarde. Thanks!
Ik kom hier bij een oplossing van mogelijk twee modules, dat zou nog eens kunnen werken.

franssie schreef op maandag 25 mei 2026 @ 14:21:
Van hoek tot hoek zou het dan 50 meter zijn. Dus een AP is het midden, ook al is het niet gewenst, hoeft maar 25 meter ver hoeven te stralen. Heb je ook geen controller etc nodig.

Begrijp ik. Ik ben alleen bang dat je aan de randen dan geen bereik gaat hebben. Ik heb even nagevraagd en het is geen probleem als we een of twee nodes in het speelveld in het midden plaatsen.

itsalex schreef op maandag 25 mei 2026 @ 14:30:
Ik denk als je in de hoeken gaat zetten, en sporthal is van metaal vaak dus dak en draagbalken dat je juist storting gaat krijgen. Ik zou sowieso al iets naar binnen doen zodat je dekking meer omni is. Daarnaast zou je eventueel 2dehands Unifi NanoHD doen, eventueel nog een paar extra punten. WiFi 6 moet ook de ontvangende partij aan kunnen/hebben. Met een Unifi PoE switch en router zou je al heel ver kunnen komen.

Ja dat is dus ook twee van mijn zorgen; WiFI6 en het metaal in de balken.
Omni is wel belangrijk in dit geval.


Ik heb even gekeken (met de designer website) en ik kom dus uit op twee Ubiquiti U7 Pro XGS om zo het hele veld over 5Ghz te kunnen bereiken als ik ze relatief in het midden plaats op ongeveer 2.5 meter hoogte. Aangestuurd met een PoE switch.

Zie ik hier problemen over het hoofd?

[franssie]

Een enkel AP haalt makkelijk 25 meter? Dat is dus vanuit het midden al naar de randen gerekend.

[dion_b]

pgmw schreef op maandag 25 mei 2026 @ 13:30:
Hallo,

Ik ben op zoek naar advies voor het opzetten van een betrouwbare mobiele/private WiFi-oplossing voor indoor evenementen

Belangrijke vraag:

Bedoel je hiermee evenementen die altijd in deze zelfde zaal gehouden gaan worden of wil je ook een oplossing die je naar andere locaties kunt verplaatsen?

In dat laatste geval komt er stukken meer bij kijken, zowel qua techniek als qua afstemming (andere locaties worden doorgaans niet blij van een rogue WiFi-netwerk dat opeens verschijnt en mogelijk issues geeft met bestaande netwerken )

We zijn een non-profit organisatie met een beperkt budget, maar willen investeren in hardware die we de komende 2–3 jaar kunnen hergebruiken.

2-3 jaar is meer dan realistisch. Met goede keuzes kun je rustig langer dan dat blijven werken.

We hebben beperkte ervaring met WiFi-opstellingen op deze schaal en zouden graag advies krijgen over met name geschikte access points en netwerkopzet.

We hebben hier zelf niet veel ervaring mee op grotere schaal en zouden graag input krijgen over bijvoorbeeld benodigde hardware (voornamelijk geschikte AP's)

Eerlijk is eerlijk, hardware is het minst belangrijke bij dit soort dingen en als je dat niet weet, heb je in eerste instantie vooral meer kennis nodig.

Momenteel kun je voor EUR 15 CWNA op Udemy vinden. Ik zou dat zeker overwegen om beter in de materie te verdiepen.

Situatie / doel:
Tijdens het evenement willen we een stabiel, WiFi-netwerk opzetten dat los staat van de bestaande (onbetrouwbare) wifi in de sporthal. We hebben wel toegang tot het bekabelde internet en patches die zich in de hal bevinden.

Het netwerk wordt gebruikt voor:

• 5 mobiele telefoons die via WiFi video streamen (DroidCam) naar een productiecomputer (livestream productie)
• ±25 vrijwilligersapparaten (telefoons) die via internet resultaten invoeren (laag dataverbruik, eventueel alternatief via 5G mogelijk)
• Totaal: ±30 actieve devices op piekmomenten

Wat is de bitrate van die livestreams? Die 30 actieve apparaten boeien weinig zolang de meeste niets doen muv af en toe een webformulier invoeren. De 5 streamers gaan je bandbreedtebehoefte bepalen.

De productiecomputer verwerkt de videostreams en verstuurt de uiteindelijke livestream via een bekabelde internetverbinding (400 Mbps down / 180 Mbps up), beschikbaar vanuit een patchkast in de zaal.

Die productiecomputer is dus bedraad aangesloten?

Belangrijke details:

• Speelzone: ±35 × 35 meter
• 3 van de 5 camera-telefoons bewegen tijdens het evenement
• Publiek: 300–400 personen, maar zij gebruiken dit netwerk niet
• Bestaande wifi in de hal is zwak (mogelijk 1 AP in de hoek)
• Bekabeld internet is beschikbaar via patchkast en mogelijk bestaande patchpunten

Bestaande WiFi:
- welke WiFi-standaard?
- welke band(en)?
- welke kanaalbreedte?
- welke kanalen?
- indien te achterhalen: welk merk+type AP?

Dan hamvraag: heb je toestemming om een bijkomende WiFi-netwerk op te zetten van de gebouwbeheerder en zo ja, zijn daar randvoorwaarden aan gesteld? (bijvoorbeeld: "mag op geen enkele manier bestaande oplossing verstoren")

Die 3-400 mensen kunnen overigens wel een uitdaging vormen: telefoons sturen regelmatig probe requests rond om actief te scannen naar WiFi-netwerken. Eentje is verwaarloosbaar. 400 is dat mogelijk niet... de meer enterprise-grade oplossingen (die nog steeds niet meer dan EUR 125 ofzo per AP hoeven te kosten) hebben opties om eea op dit vlak in te stellen.

Wat we fysiek kunnen doen:

• Access points plaatsen op ~2–3 meter hoogte (op de ingeklapte tribune-constructies - met o.a. tie-rips)
• Ethernet bekabeling trekken naar vrijwel elke locatie
• AP in het midden van het veld is mogelijk, maar liever vermijden
• Bestaande patchpunten kunnen gebruikt worden

2-3m is behoorlijk laag. Kan dat niet hoger? Ik vraag me overigens af of je meer dan een enkele AP nodig hebt voor de dekking. Vuistregel is dat WiFi ~300m kan reiken zonder obstakels, als je de AP in een hoek plaatst in een zaal van 35x35m kom je nooit verder dan 50m. Je zou dan met omnidirectionele antenne in de 5GHz uitkomen rond de -57dBm in de tegenoverliggende hoek (zendvermogen in 5GHz is 23dBm, free space path loss kun je hier berekenen en zou ~80db zijn). Voor stabiliteit heb je minimaal -67dBm nodig, en 10dB is meestal genoeg fade margin. Mogelijk heb je alsnog meer AP's nodig afhankelijkheid van de eisen qua performance. In dat geval wil je geen omnidirectionele antennes gebruiken en zul je in zo'n relatief kleine ruimte waarschijnlijk zendvermogen moeten verlagen.

---

Wat we graag willen weten:

1. Hoeveel access points zijn realistisch voor stabiele dekking in een 35×35m indoor ruimte?
2. Is dekking vanaf alleen de randen voldoende, of ontstaan er dode zones in het midden?
3. Is een mesh-oplossing hier realistisch, of is een volledig bekabelde backhaul sterk aan te raden?
4. Welke hardware zouden jullie aanraden met een budget van ongeveer €1000?
5. Hoe groot is het impactprobleem van roaming voor bewegende camera-telefoons? En is dit op te lossen?

Mesh is sowieso geen goed idee voor live streaming aangezien het latency toevoegt. Maar antwoord op deze vragen hangen af van de benodigde bitrate.

Wat voor informatie we hebben gevonden. Alleen kunnen we niet beoordelen of dit juiste info is:

• 4 AP’s in de hoeken + eventueel 1 centraal AP indien nodig
• WiFi 6 op 5 GHz met 40 MHz kanaalbreedte om interferentie te beperken

4 AP's (laat staan 5) klinkt erg riant voor zo'n kleine ruimte met slechts 5 clients die significant bandbreedte nodig hebben. Je hebt pas 1:1 AP <-> client nodig als je grootste deel van practische bandbreedte per AP per client denkt nodig te hebben, wat in de meerdere honderden Mbps zou zitten - en in dat geval raak je alsnog in de knoop omdat de clients rondlopen. Dat zou je kunnen oplossen door elk een dedicated AP en SSID te geven, maar dat begint erg vergezocht te worden...

Budget:
Ongeveer €1000 totaal (AP’s + bekabeling). Aangezien het om een investering gaat, is dit uiteraard een schatting, er is wel wat 'extra' budget.

Is dit alleen de AP's en bekabeling? Of moet je ook de clients hieruit betalen? Als het alleen de AP's zijn heb je maar een fractie hiervan nodig.

Verder: wie gaat dit beheren. Ga jij dat altijd zijn of moeten anderen (met mogelijk minder kennis) het ook kunnen? Moet de beheersomgeving remote bereikbaar zijn? Of juist nadrukkelijk niet? Is support nodig als het mis gaat? Op basis van de antwoorden hierop kunnen we een geschikt ecosysteem aanraden, dan in combinatie met de antwoorden op de technische vragen daadwerkelijk uitkomen bij bepaalde hardware. Maar dat is dus laatste stap, niet de eerste. Beste hardware ter wereld heb je niets aan als het niet geschikt is voor de situatie of als je het niet kunt inzetten/beheren.

[ Voor 5% gewijzigd door dion_b op 25-05-2026 20:53 ]

[pgmw]

dion_b schreef op maandag 25 mei 2026 @ 20:43:
[...]

Belangrijke vraag:

Bedoel je hiermee evenementen die altijd in deze zelfde zaal gehouden gaan worden of wil je ook een oplossing die je naar andere locaties kunt verplaatsen?

In dat laatste geval komt er stukken meer bij kijken, zowel qua techniek als qua afstemming (andere locaties worden doorgaans niet blij van een rogue WiFi-netwerk dat opeens verschijnt en mogelijk issues geeft met bestaande netwerken )

Beide. In eerste instantie zal het in deze zaal gebruikt worden voor ons jaarlijkse evenement. We zijn er aardig tevreden over.

Ik sluit niet uit dat de hardware (of deels) gebruikt zal worden voor 'andere' evenementen op andere locaties en kleinere of grotere opzetten.

2-3 jaar is meer dan realistisch. Met goede keuzes kun je rustig langer dan dat blijven werken.

Dat is fijn om te weten. Onze ambitie is om door te blijven groeien tot een europees niveau evenementen te organiseren, tegen die tijd zal er mogelijk ook meer budget zijn voor iets serieuzere oplossingen en laten we dit mogelijk ook regelen door externe partijen. We moeten ergens beginnen :-)

Eerlijk is eerlijk, hardware is het minst belangrijke bij dit soort dingen en als je dat niet weet, heb je in eerste instantie vooral meer kennis nodig.

Momenteel kun je voor EUR 15 CWNA op Udemy vinden. Ik zou dat zeker overwegen om beter in de materie te verdiepen.

Goede tip. Dat zal zeker helpen.

Wat is de bitrate van die livestreams? Die 30 actieve apparaten boeien weinig zolang de meeste niets doen muv af en toe een webformulier invoeren. De 5 streamers gaan je bandbreedtebehoefte bepalen.

We hebben een app die d.m.v. een socket verbonden is over het internet. Deze verbinding is optioneel. De rest gebeurd met wat HTTP calls richting een API. Dus net iets meer dan een simpel webformulier.

Zover ik het van de persoon, die de livestream beheerd, heb begrepen; 10k.

Die productiecomputer is dus bedraad aangesloten?

Ja, klopt. De opstelling die we hebben:
- Productie computer met OBS + DroidCam plugin.
- Camera's zijn telefoons die door middel van de app DroidCam de beeldingen richting het netwerk.
- Productiecomputer verwerkt het naar de stream en zend het uit.

Bestaande WiFi:
- welke WiFi-standaard?
- welke band(en)?
- welke kanaalbreedte?
- welke kanalen?
- indien te achterhalen: welk merk+type AP?

Goede vraag. Eerlijk gezegd heb ik hier geen specifieke details over. We hebben het bij de beheerder nagevraagd. De beheerder is geen techneut en die geeft aan dat 'het pand relatief oud is' en de 'huidige infra niet in de beste staat is', In de zaal zelf is het netwerk dat ze tot hun beschikking hebben met een ontvangst dat niet best is.

Dan hamvraag: heb je toestemming om een bijkomende WiFi-netwerk op te zetten van de gebouwbeheerder en zo ja, zijn daar randvoorwaarden aan gesteld? (bijvoorbeeld: "mag op geen enkele manier bestaande oplossing verstoren")

Dat hebben we niet expliciet gevraagd, maar we hebben wel toestemming om een eigen netwerk op te zetten en gebruik te maken van de patch kast, en het huidig Wifi, wat voor ons niet toereikend is in de sporthal.

Daarbij geen randvoorwaarden zover ik weet. In ons geval zijn wij gedurende het weekend de enige in het pand voor ons evenement.

Die 3-400 mensen kunnen overigens wel een uitdaging vormen: telefoons sturen regelmatig probe requests rond om actief te scannen naar WiFi-netwerken. Eentje is verwaarloosbaar. 400 is dat mogelijk niet... de meer enterprise-grade oplossingen (die nog steeds niet meer dan EUR 125 ofzo per AP hoeven te kosten) hebben opties om eea op dit vlak in te stellen.

Goed om te weten. Dit is mogelijk wel iets waar we rekening mee moeten houden.

2-3m is behoorlijk laag. Kan dat niet hoger? Ik vraag me overigens af of je meer dan een enkele AP nodig hebt voor de dekking. Vuistregel is dat WiFi ~300m kan reiken zonder obstakels, als je de AP in een hoek plaatst in een zaal van 35x35m kom je nooit verder dan 50m. Je zou dan met omnidirectionele antenne in de 5GHz uitkomen rond de -57dBm in de tegenoverliggende hoek (zendvermogen in 5GHz is 23dBm, free space path loss kun je hier berekenen en zou ~80db zijn). Voor stabiliteit heb je minimaal -67dBm nodig, en 10dB is meestal genoeg fade margin. Mogelijk heb je alsnog meer AP's nodig afhankelijkheid van de eisen qua performance. In dat geval wil je geen omnidirectionele antennes gebruiken en zul je in zo'n relatief kleine ruimte waarschijnlijk zendvermogen moeten verlagen.

Ja, ik snap dat 2 tot 3 meter behoorlijk laag is. Helaas kunnen we geen hardware ophangen of hardware installeren op hogere plaatsen. We hadden stiekem gehoopt dat de infra qua netwerk ietsjes beter zou zijn en we helemaal niet aan dit soort oplossingen hoeven te denken. Zover ik weet staat dat wel op een planning van de beheerders.

Mesh is sowieso geen goed idee voor live streaming aangezien het latency toevoegt. Maar antwoord op deze vragen hangen af van de benodigde bitrate.

Helder. Dan moeten we deze kant ook niet gaan opzoeken.

4 AP's (laat staan 5) klinkt erg riant voor zo'n kleine ruimte met slechts 5 clients die significant bandbreedte nodig hebben. Je hebt pas 1:1 AP <-> client nodig als je grootste deel van practische bandbreedte per AP per client denkt nodig te hebben, wat in de meerdere honderden Mbps zou zitten - en in dat geval raak je alsnog in de knoop omdat de clients rondlopen. Dat zou je kunnen oplossen door elk een dedicated AP en SSID te geven, maar dat begint erg vergezocht te worden...

Eens. Dat zal denk ik niet nodig zijn. We hebben eventueel ook de mogelijkheid om 1 of 2 AP's in het midden van het speelveld neer te plaatsen. Dit veranderd natuurlijk de hele situatie. Het gaat er voornamelijk om dat de camera's die bewegen op een betrouwbare manier de verbinding met de productiecomputer kunnen behouden en het beeld kunnen overbrengen.

Is dit alleen de AP's en bekabeling? Of moet je ook de clients hieruit betalen? Als het alleen de AP's zijn heb je maar een fractie hiervan nodig.

AP's en bekabeling. Clients zijn vrijwilligers. De telefoons die we daarvoor gebruiken zijn van een van de bestuursleden. Dit zijn ietsjes oudere 'flagship' telefoons. 2 tot 3 jaar oud.

Dus nee, clients hoeven niet te worden betaald. Je mag dit puur zien als een investering voor de juiste hardware.

Verder: wie gaat dit beheren. Ga jij dat altijd zijn of moeten anderen (met mogelijk minder kennis) het ook kunnen? Moet de beheersomgeving remote bereikbaar zijn? Of juist nadrukkelijk niet? Is support nodig als het mis gaat? Op basis van de antwoorden hierop kunnen we een geschikt ecosysteem aanraden, dan in combinatie met de antwoorden op de technische vragen daadwerkelijk uitkomen bij bepaalde hardware. Maar dat is dus laatste stap, niet de eerste. Beste hardware ter wereld heb je niets aan als het niet geschikt is voor de situatie of als je het niet kunt inzetten/beheren.

We proberen meedere personen de kennis onder te brengen. Voornamelijk diegene met iets meer technische achtergrond. Momenteel ben ik dat, maar we zijn hard op zoek naar meer mensen voor onze organisatie.

De beheeromgeving hoeft niet per definitie remote bereikbaar te zijn, het gaat meestal ook om een kort evenement dat twee dagen is. Daarnaast is het belangrijk dat met (met lichte aanpassingen) het 'werkt'.

Ik ben momenteel altijd wel in de loep :-)

Hopelijk beantwoord dat de vragen.

[dion_b]

pgmw schreef op maandag 25 mei 2026 @ 21:36:
[...]

Beide. In eerste instantie zal het in deze zaal gebruikt worden voor ons jaarlijkse evenement. We zijn er aardig tevreden over.

Ik sluit niet uit dat de hardware (of deels) gebruikt zal worden voor 'andere' evenementen op andere locaties en kleinere of grotere opzetten.

In dat laatste geval ga je drie extra randvoorwaarden hebben:
- grote kans dat je vroeg of laat ergens komt waar bestaande netwerk wel gevrijwaard moet worden en dan moet je oplossing technisch in staat zijn daar omheen te werken en moet de kennis aanwezig zijn om dat on-the-fly te doen.
- locaties waar je AP's kunt hangen gaan anders zijn waardoor je andere bevestigingsmogelijkheden gaat hebben en andere kabellengtes.
- uplink naar rest van internet gaat niet overal hetzelfde zijn.

Als het budgettair mogelijk is (en ik vermoed van wel als ik EUR 1000 hoor) zou ik aanraden om één installatie vast in eigen zaal te doen en een tweede om mee te nemen. Dan hoef je lokaal geen concessies te doen voor die flexibiliteit en blijft het lokaal goed werken ongeacht wat op andere locaties gebeurt (worst-case: iemand jat de apparatuur...)

[...]

Dat is fijn om te weten. Onze ambitie is om door te blijven groeien tot een europees niveau evenementen te organiseren, tegen die tijd zal er mogelijk ook meer budget zijn voor iets serieuzere oplossingen en laten we dit mogelijk ook regelen door externe partijen. We moeten ergens beginnen :-)

Juist als je opschaalt kun je kennis in-huis halen en houden. Outsourcen wil je doen met dingen die niet tot je kerncompetenties en -processen behoren. WiFi infra lijkt me bij uitstek wel daartoe behoren als je video wilt streamen, des te meer omdat je met sportevenementen vaak buiten reguliere werktijden op gekke locaties gaat zitten. Dit wil je zelf kunnen.

[...]

We hebben een app die d.m.v. een socket verbonden is over het internet. Deze verbinding is optioneel. De rest gebeurd met wat HTTP calls richting een API. Dus net iets meer dan een simpel webformulier.

Zover ik het van de persoon, die de livestream beheerd, heb begrepen; 10k.

10kbps Dat klinkt zeer beperkt. Dat is wat je vroeger aan 'streaming' video over een inbelmodem kon versturen. Denk aan postzegel van160x100 pixels, 256 kleuren en hoge compressie. Ik twijfel of je bij een balsport de bal zou kunnen zien - oftewel hier klopt niets van

Om een paar getallen te noemen:
- broadcast quality SD (720x576@50Hz) MPEG2: ~4Mbps.
- broadcast quality HD (1280x720@50Hz non-interlaced vs 1920x1080@25/50Hz interlaced) MPEG4: ~8Mbps
- BluRay 4k (1920x1080p) MPEG4: 40Mbps
- uncompressed HD: ~3Gbps
- broadcast quality 4k (3840x2160@50Hz) HEVC: ~12Mbps
- broadcast quality HDR 4k (3840x2160@50Hz HDR) HEVC: ~16Mbps
- uncompressed 4k: ~12Gbps

Als ik google op DroidCam lees ik geen concrete bitrates, wel HD en 4k resolutie opties. Ik vermoed dus dat je minimaal 8Mbps nodig hebt per streaming client, maar het is veiliger om uit te gaan van 16Mbps als je het niet weet.

Om zeker te zijn dat het goed gaat wil je zorgen dat de totale capaciteit op het netwerk zoals beschikbaar voor de client met slechtste verbinding ruim voldoende is voor alle clients. Als je dus 5x16Mbps=80Mbps totaal nodig hebt, wil je op locatie van slechtste verbinding minstens ~100Mbps ter beschikking hebben.

Stel nu dat je slechtste RSSI -57dBm is in de 5GHz. Stel nu dat je clients allemaal minimaal 2x2 MIMO en WiFi-6 ondersteunen. Als je -57dBm hebt met 2x2 MIMO en 40MHz brede WiFi-6 kanaal kom je uit op een realistische throughput van zo'n 215Mbps. Dat gaat dus lukken. Maar dit is op basis van de volgende aannames:
- je streams zijn maximaal 16Mbps.
- met een enkele AP heeft de minst gevoelige telefoon nergens in de ruimte een RSSI van minder dan -57dBm (nouja, met -67dBm zou het nog 108Mbps netto moeten kunnen leveren, maar je wilt die 10dB fade margin hebben voor stabiliteit).
- de invloed van honderden toeschouwers op beschikbare bandbreedte is verwaarloosbaar.

Voor alle verdere berekeningen is het echt noodzakelijk om een duidelijk getal te hebben voor hoe groot die streams zijn. Als degene die ze maakt dat niet weet, meet het!

Voor signaalsterkte zul je ook voordat je tot aanschaf van dingen overgaat een site survey moeten doen. Dat is zo simpel als een AP (maakt totaal niet uit welke, zolang het 5GHz ondersteunt) ophangen op plek waar je denkt een AP te hangen en dan met de telefoons in kwestie rond te lopen, met name op de meest uitdagende locaties. De AP hoeft verder nergens op aangesloten te zijn, het gaat puur om signaalsterkte van uitgezonden beacons te bepalen. Draai een app als WiFi Analyzer Open Source. En hou een tabel bij (kan op papier of in een spreadsheet): x-as is locatie AP, y-as is locatie telefoon.

Loop met de telefoon naar de vier hoeken van de zaal en noteer de RSSI per hoek. Pak ook een paar vaste locaties elders (midden van de zaal, midden van elke zijde, bijvoorbeeld, dan kom je aan negen totaal). RSSI overal >=-57dBm? Perfect. Zo niet, AP verplaatsen richting slechtste waardes en nog een keer proberen op alle locaties en noteren. Nog steeds niet? Herhaal nog een keer. Als het niet in een keer goed is, probeer de AP sowieso op alle zinnige locaties.

Lukt het om een plek te vinden waar je overal goed zit qua signaal? Mooi, dan kun je toe met een enkele AP en je weet gelijk waar hij moet hangen en hoeveel netwerkkabel je nodig gaat hebben om het daar te plaatsen.
Lukt het niet om een plek te vinden waar je overan goed zit? Kijk of je met twee AP-locaties alles dekt. Zo ja, heb je twee nodig en weet je waar ze moeten hangen. Heb je meerdere combinaties waar je alles vanuit kunt dekken? Pak dan de twee waar de verschillen verder het grootst zijn (meestal: die het verst weg van elkaar zijn).
Lukt het met twee ook niet, kijk dan naar drie. Maar eerlijk is eerlijk, ik twijfel zeer sterk of dit nodig gaat zijn voor dekking.

[...]

Ja, klopt. De opstelling die we hebben:
- Productie computer met OBS + DroidCam plugin.
- Camera's zijn telefoons die door middel van de app DroidCam de beeldingen richting het netwerk.
- Productiecomputer verwerkt het naar de stream en zend het uit.

OK, duidelijk.

[...]

Goede vraag. Eerlijk gezegd heb ik hier geen specifieke details over. We hebben het bij de beheerder nagevraagd. De beheerder is geen techneut en die geeft aan dat 'het pand relatief oud is' en de 'huidige infra niet in de beste staat is', In de zaal zelf is het netwerk dat ze tot hun beschikking hebben met een ontvangst dat niet best is.

[...]

Dat hebben we niet expliciet gevraagd, maar we hebben wel toestemming om een eigen netwerk op te zetten en gebruik te maken van de patch kast, en het huidig Wifi, wat voor ons niet toereikend is in de sporthal.

Zorg dat je dit zwart-op-wit hebt. Je wilt niet dat bij evt uitval huidige beheerder de volgende je gelijk sommeert alles los te trekken...

Zelfde geldt voor op pad te gaan: voordat je akkoord gaat met ergens streaming te verzorgen, zorg dat je zwart-op-wit hebt dat je dat mag, dat je toegang hebt tot technische ruimtes en (tijdelijk) kabels mag trekken daar vandaan, plus alle evt randvoorwaarden ook zwart-op-wit.

[...]

Goed om te weten. Dit is mogelijk wel iets waar we rekening mee moeten houden.

Mogelijke oplossing: ga voor tri-band apparatuur en werk uitsluitend in de 6GHz-band. Moeten je clients het natuurlijk wel ondersteunen...

Hier iig een paper over het probleem (stokoud, maar mechanisme is nog exact hetzelfde):
https://arxiv.org/pdf/1502.01222

[...]

Ja, ik snap dat 2 tot 3 meter behoorlijk laag is. Helaas kunnen we geen hardware ophangen of hardware installeren op hogere plaatsen. We hadden stiekem gehoopt dat de infra qua netwerk ietsjes beter zou zijn en we helemaal niet aan dit soort oplossingen hoeven te denken. Zover ik weet staat dat wel op een planning van de beheerders.

2 tot 3 meter heeft wel een voordeel: dat is vergelijkbaar met de hoogte van een kantoor. Je kunt op die hoogte zonder aanpassingen ceiling-mount APs's gebruiken.

[...]

Eens. Dat zal denk ik niet nodig zijn. We hebben eventueel ook de mogelijkheid om 1 of 2 AP's in het midden van het speelveld neer te plaatsen. Dit veranderd natuurlijk de hele situatie. Het gaat er voornamelijk om dat de camera's die bewegen op een betrouwbare manier de verbinding met de productiecomputer kunnen behouden en het beeld kunnen overbrengen.

[...]

AP's en bekabeling. Clients zijn vrijwilligers. De telefoons die we daarvoor gebruiken zijn van een van de bestuursleden. Dit zijn ietsjes oudere 'flagship' telefoons. 2 tot 3 jaar oud.

Dus nee, clients hoeven niet te worden betaald. Je mag dit puur zien als een investering voor de juiste hardware.

'Hardware' kan veel dingen voor veel mensen betekenen, incl clients. Zoals ik het hier lees gaat het dus om:
- AP('s)
- bekabeling voor AP('s)
- bevestigingsmaterialen voor AP's en bekabeling
- stroomvoorziening AP('s) (PoE switch of midspan injector(en))

[...]

We proberen meedere personen de kennis onder te brengen. Voornamelijk diegene met iets meer technische achtergrond. Momenteel ben ik dat, maar we zijn hard op zoek naar meer mensen voor onze organisatie.

De beheeromgeving hoeft niet per definitie remote bereikbaar te zijn, het gaat meestal ook om een kort evenement dat twee dagen is. Daarnaast is het belangrijk dat met (met lichte aanpassingen) het 'werkt'.

Snap ik. Vraag is alleen wat er gebeurt als het niet blijkt te werken...


Maar goed, als ik samenvat wat ik tot nu to lees is de eis qua performance nog totaal niet duidelijk. Specifieke hardware en aantallen kunnen we dus nog niets over zeggen. Wat wel duidelijk is, is de situatie qua beheer, en de uitdaging met die 400 toeschouwers.

Om met dat laatste te beginnen - clients hebben de neiging twee dingen te doen bij actieve scanning:
- wildcard probe requests ("welke netwerken zijn hier allemaal? - zeg eens 'hoi'!")
- gerichte probe requests ("kunnen de AP's voor SSID "MIJNSSID" zich graag bekend maken incl info over hoe te verbinden?")

Die tweede categorie kun je aanpakken door geen SSID te broadcasten, dus een zgn 'hidden network' aan te maken. Dat is nadrukkelijk geen beveiliging - een aanvaller kan snel genoeg zien dat er een netwerk is, hoe het heet en hoe het met de beveiliging gesteld is - maar het voorkomt dat bezoekers het netwerk zien in hun telefoons en proberen te verbinden, en het voorkomt gerichte pogingen om info te krijgen. Dus: maak je SSID hidden.

Eerste categorie is lastiger. De vraag is of een AP moet reageren op wildcards als de SSID hidden is. Uitdaging is dat hidden SSID technisch tegen 802.11 specificatie in gaat en als een vendor dus die functionaliteit levert, alles er omheen ook buiten de specificaties valt. Zie hier voor een bespreking van de situaite. TLDR:

While the correct answer to the original question “Does a hidden SSID generate a probe response to a wildcard probe (‘null’) request?” would be the classic “It depends!”, it seems that “probably not” does seem to be a more valid answer.

Concreet stuurt UniFi in ieder geval geen responses in deze situatie. Dat maakt UniFi een potentiele kandidaat. Mikrotik ook niet en is qua budget een aantrekkelijke optie, maar de leercurve van Mikrotik durf ik rustig 'extreem' te noemen en past niet bij kennisniveau die je hier schetst. Cisco, Meraki en Mist zijn allemaal veel te duur voor jullie use case.

Twee ecosystemen die ik wel zou overwegen zijn Aruba InstantOn (waar de auteur ook benieuwd naar is) en TP-Link Omada. Ik kan alleen geen concrete info vinden over hoe zij zouden reageren hierop. InstantOn zou ik mogelijk zelf kunnen testen aangezien ik hier een paar van die dingen heb hangen, maar dat ga ik vanavond niet meer doen - dan moet ik graven naar iets dat een packet capture kan doen...

Die drie ecosystemen vissen ongeveer in zelfde vijver van prosumer/kleinzakelijk gebruik. Verschil zit in de nuance, met name hoe beheer werkt:
- UniFi werkt met management app op een client PC, of standalone op een van hun routers. Dat moet dus wel dezelfde PC zijn die beheer doet _{in jullie situatie zou dat de productie computer kunnen zijn}. Dit is op GoT populairste ecosysteem. Het is goedkoop, makkelijk te installeren en werkt meestal gewoon foutloos. Grootste valkuil vind ik software updates. Dat gaat te vaak mis, met name bij mismatch tussen management app en de AP's. Als je goed thuis bent in de materie heb je het in een kwartiertje weer draaien, maar ik he b meerdere keren gehad dat dit gebeurde bij vrienden of kennissen waar ik UniFi had aangeraden en ze een week niets hadden tot ik tijd had om langs te gaan. Dat maakt me erg terughoudend om UniFi aan te raden.
- Omada is zeer vergelijkbaar. Ik heb nog niet van dezelfde upgradeperikelen gehoord. Minpunt is dat de specs van de verschillende apparaten minder goed op elkaar afgestemd zijn - je kunt bijvoorbeeld niet blind ervan uitgaan dat 5GHz DFS kanalen ondersteund zijn bij een nieuw model; soms (zoals bij de EAP610) komt het na meerdere maanden, soms helemaal niet...
- Aruba InstantOn is een poging van HPE om vanuit de enterprise-wereld toch de kleine markt te bedienen. Het is een tikje duurder dan UniFi of Omada, maar nog steeds <EUR 125, en ze zijn bewust conservatief qua ontwikkeling (geen WiFi-7 nog), maar in ruil daarvoor krijg je enerzijds de makkelijkste installatie die ik voor iets in deze categorie meegemaakt heb (exact even simpel als TP-Link's hersendode maar klantvriendelijke Deco reeks) en anderzijds onder de motorkap alle intelligentie van Aruba - inclusief een distributed controller: de controller draait op je APs, waardoor je dus geen applicatie op de PC of los controller ding nodig hebt. Ik draai hier ondertussen zelf bijna twee jaar op (2x AP22) en ben erg tevreden.

Er zijn andere opties, maar IMHO zijn ze ofwel veel duurder, danwel veel dommer, danwel van bedrijven waar ik twijfels heb over (langdurig) support - lees: zo'n beetje alles wat je op AliExpress tegenkomt.

[pgmw]

dion_b schreef op maandag 25 mei 2026 @ 23:33:
[...]

In dat laatste geval ga je drie extra randvoorwaarden hebben:
- grote kans dat je vroeg of laat ergens komt waar bestaande netwerk wel gevrijwaard moet worden en dan moet je oplossing technisch in staat zijn daar omheen te werken en moet de kennis aanwezig zijn om dat on-the-fly te doen.
- locaties waar je AP's kunt hangen gaan anders zijn waardoor je andere bevestigingsmogelijkheden gaat hebben en andere kabellengtes.
- uplink naar rest van internet gaat niet overal hetzelfde zijn.

Als het budgettair mogelijk is (en ik vermoed van wel als ik EUR 1000 hoor) zou ik aanraden om één installatie vast in eigen zaal te doen en een tweede om mee te nemen. Dan hoef je lokaal geen concessies te doen voor die flexibiliteit en blijft het lokaal goed werken ongeacht wat op andere locaties gebeurt (worst-case: iemand jat de apparatuur...)

[...]

Die kans is aanwezig. We zien dit voornamelijk als investering als we op een locatie komen waar de infra niet goed is geregeld zodat we daar zelf de controle over kunnen hebben. Op andere locaties, waar mogelijk de infra wel op orde is, hebben we onze eigen oplossing niet nodig. Dit geeft ons tevens de flexibiliteit om kleinere competities te houden met het gebruik van de hardware. Tweaks en aanpassingen in de bekabelingen zijn dan niet per definitie een groot probleem omdat we diegene met de expertise altijd wel aan zullen sluiten bij de organisatie.

Juist als je opschaalt kun je kennis in-huis halen en houden. Outsourcen wil je doen met dingen die niet tot je kerncompetenties en -processen behoren. WiFi infra lijkt me bij uitstek wel daartoe behoren als je video wilt streamen, des te meer omdat je met sportevenementen vaak buiten reguliere werktijden op gekke locaties gaat zitten. Dit wil je zelf kunnen.

[...]

Ik snap wat je bedoeld, alleen hoe groter het evenement wordt, hoe professioneler het ook moet worden. Op een gegeven moment kunnen wij deze groei niet meer bijbenen als een groep vrijwilligers, hoeveel kennis we ook hebben.

10kbps Dat klinkt zeer beperkt. Dat is wat je vroeger aan 'streaming' video over een inbelmodem kon versturen. Denk aan postzegel van160x100 pixels, 256 kleuren en hoge compressie. Ik twijfel of je bij een balsport de bal zou kunnen zien - oftewel hier klopt niets van

Om een paar getallen te noemen:
- broadcast quality SD (720x576@50Hz) MPEG2: ~4Mbps.
- broadcast quality HD (1280x720@50Hz non-interlaced vs 1920x1080@25/50Hz interlaced) MPEG4: ~8Mbps
- BluRay 4k (1920x1080p) MPEG4: 40Mbps
- uncompressed HD: ~3Gbps
- broadcast quality 4k (3840x2160@50Hz) HEVC: ~12Mbps
- broadcast quality HDR 4k (3840x2160@50Hz HDR) HEVC: ~16Mbps
- uncompressed 4k: ~12Gbps

Ja, hier hebben we het over verschillende dingen. Hij bedoelde dus10k bitrate binnen OBS.
Het doel is om primair een stream van 1920x1080p @ 60fps te produceren. Dus dan zitten we op 10 Mbps.

Als ik google op DroidCam lees ik geen concrete bitrates, wel HD en 4k resolutie opties. Ik vermoed dus dat je minimaal 8Mbps nodig hebt per streaming client, maar het is veiliger om uit te gaan van 16Mbps als je het niet weet.

Om zeker te zijn dat het goed gaat wil je zorgen dat de totale capaciteit op het netwerk zoals beschikbaar voor de client met slechtste verbinding ruim voldoende is voor alle clients. Als je dus 5x16Mbps=80Mbps totaal nodig hebt, wil je op locatie van slechtste verbinding minstens ~100Mbps ter beschikking hebben.

Je mag er van uitgaan dat het 5 camera's op max 1080p @ 60fps zullen zijn over het netwerk.

Ik ben alleen bang dat WiFi 6 een probleem gaat worden voor sommige devices.

Stel nu dat je slechtste RSSI -57dBm is in de 5GHz. Stel nu dat je clients allemaal minimaal 2x2 MIMO en WiFi-6 ondersteunen. Als je -57dBm hebt met 2x2 MIMO en 40MHz brede WiFi-6 kanaal kom je uit op een realistische throughput van zo'n 215Mbps. Dat gaat dus lukken. Maar dit is op basis van de volgende aannames:
- je streams zijn maximaal 16Mbps.
- met een enkele AP heeft de minst gevoelige telefoon nergens in de ruimte een RSSI van minder dan -57dBm (nouja, met -67dBm zou het nog 108Mbps netto moeten kunnen leveren, maar je wilt die 10dB fade margin hebben voor stabiliteit).
- de invloed van honderden toeschouwers op beschikbare bandbreedte is verwaarloosbaar.

Voor alle verdere berekeningen is het echt noodzakelijk om een duidelijk getal te hebben voor hoe groot die streams zijn. Als degene die ze maakt dat niet weet, meet het!

Voor signaalsterkte zul je ook voordat je tot aanschaf van dingen overgaat een site survey moeten doen. Dat is zo simpel als een AP (maakt totaal niet uit welke, zolang het 5GHz ondersteunt) ophangen op plek waar je denkt een AP te hangen en dan met de telefoons in kwestie rond te lopen, met name op de meest uitdagende locaties. De AP hoeft verder nergens op aangesloten te zijn, het gaat puur om signaalsterkte van uitgezonden beacons te bepalen. Draai een app als WiFi Analyzer Open Source. En hou een tabel bij (kan op papier of in een spreadsheet): x-as is locatie AP, y-as is locatie telefoon.

Loop met de telefoon naar de vier hoeken van de zaal en noteer de RSSI per hoek. Pak ook een paar vaste locaties elders (midden van de zaal, midden van elke zijde, bijvoorbeeld, dan kom je aan negen totaal). RSSI overal >=-57dBm? Perfect. Zo niet, AP verplaatsen richting slechtste waardes en nog een keer proberen op alle locaties en noteren. Nog steeds niet? Herhaal nog een keer. Als het niet in een keer goed is, probeer de AP sowieso op alle zinnige locaties.

Lukt het om een plek te vinden waar je overal goed zit qua signaal? Mooi, dan kun je toe met een enkele AP en je weet gelijk waar hij moet hangen en hoeveel netwerkkabel je nodig gaat hebben om het daar te plaatsen.
Lukt het niet om een plek te vinden waar je overan goed zit? Kijk of je met twee AP-locaties alles dekt. Zo ja, heb je twee nodig en weet je waar ze moeten hangen. Heb je meerdere combinaties waar je alles vanuit kunt dekken? Pak dan de twee waar de verschillen verder het grootst zijn (meestal: die het verst weg van elkaar zijn).
Lukt het met twee ook niet, kijk dan naar drie. Maar eerlijk is eerlijk, ik twijfel zeer sterk of dit nodig gaat zijn voor dekking.

[...]

Helder.

OK, duidelijk.

[...]

Zorg dat je dit zwart-op-wit hebt. Je wilt niet dat bij evt uitval huidige beheerder de volgende je gelijk sommeert alles los te trekken...

Dat gaat niet gebeuren, we bouwen de hardware voor en na het evenement op en af.

Zelfde geldt voor op pad te gaan: voordat je akkoord gaat met ergens streaming te verzorgen, zorg dat je zwart-op-wit hebt dat je dat mag, dat je toegang hebt tot technische ruimtes en (tijdelijk) kabels mag trekken daar vandaan, plus alle evt randvoorwaarden ook zwart-op-wit.

[...]

Dat hebben we niet zwart op wit, maar zeker wel een mondeling akkoord met de uitvoerende beheerders die op dat moment ook aanwezig zijn. Voor zowel de stream als de hardware, als de WiFI, het gebruik van alles in de zaal, attributen, ruimtes, afzet werk, opslag ect. Dat hebben we geregeld. Dat is hier geen probleem :-)

Mogelijke oplossing: ga voor tri-band apparatuur en werk uitsluitend in de 6GHz-band. Moeten je clients het natuurlijk wel ondersteunen...

Ik denk dat we dan in de problemen komen met sommige telefoons die het mogelijk niet ondersteunen? Ik snap dat 5G lastiger is met het mogelijke huidige netwerk.

Even iets breder; er bestaat mogelijk de kans dat een telefoon van de vrijwilliger (Bring your own device, eigenlijk) of een van de streaming telefoons (moet ik nachecken) geen ondersteuning heeft voor 6GHZ.
Zou de focus op 5GHZ dan niet iets safer zijn?

Hier iig een paper over het probleem (stokoud, maar mechanisme is nog exact hetzelfde):
https://arxiv.org/pdf/1502.01222

[...]

Interessant. :-)

2 tot 3 meter heeft wel een voordeel: dat is vergelijkbaar met de hoogte van een kantoor. Je kunt op die hoogte zonder aanpassingen ceiling-mount APs's gebruiken.

[...]

Helder.

'Hardware' kan veel dingen voor veel mensen betekenen, incl clients. Zoals ik het hier lees gaat het dus om:
- AP('s)
- bekabeling voor AP('s)
- bevestigingsmaterialen voor AP's en bekabeling
- stroomvoorziening AP('s) (PoE switch of midspan injector(en))

[...]

Klopt. Voor ons gaat het inderdaad over wat je zelf hier al schetst als de betekenis van 'hardware'.

Snap ik. Vraag is alleen wat er gebeurt als het niet blijkt te werken...

Dan ben ik mogelijk diegene op dit moment die naar een oplossing gaat zoeken :-)

Maar goed, als ik samenvat wat ik tot nu to lees is de eis qua performance nog totaal niet duidelijk. Specifieke hardware en aantallen kunnen we dus nog niets over zeggen. Wat wel duidelijk is, is de situatie qua beheer, en de uitdaging met die 400 toeschouwers.

Okay. Dat is ter discussie of dat inderdaad zo is. Hopelijk geeft het antwoord op de vragen hier boven daar iets meer inzagen in.

Om met dat laatste te beginnen - clients hebben de neiging twee dingen te doen bij actieve scanning:
- wildcard probe requests ("welke netwerken zijn hier allemaal? - zeg eens 'hoi'!")
- gerichte probe requests ("kunnen de AP's voor SSID "MIJNSSID" zich graag bekend maken incl info over hoe te verbinden?")

Die tweede categorie kun je aanpakken door geen SSID te broadcasten, dus een zgn 'hidden network' aan te maken. Dat is nadrukkelijk geen beveiliging - een aanvaller kan snel genoeg zien dat er een netwerk is, hoe het heet en hoe het met de beveiliging gesteld is - maar het voorkomt dat bezoekers het netwerk zien in hun telefoons en proberen te verbinden, en het voorkomt gerichte pogingen om info te krijgen. Dus: maak je SSID hidden.

Prima, dat is geen probleem. Alle telefoons, ook die van onze vrijwilligers, geven we sowieso een briefing voordat we beginnen. Hierbij valt ook het verbinden met het hidden netwerk.

Eerste categorie is lastiger. De vraag is of een AP moet reageren op wildcards als de SSID hidden is. Uitdaging is dat hidden SSID technisch tegen 802.11 specificatie in gaat en als een vendor dus die functionaliteit levert, alles er omheen ook buiten de specificaties valt. Zie hier voor een bespreking van de situaite. TLDR:

[...]

Concreet stuurt UniFi in ieder geval geen responses in deze situatie. Dat maakt UniFi een potentiele kandidaat. Mikrotik ook niet en is qua budget een aantrekkelijke optie, maar de leercurve van Mikrotik durf ik rustig 'extreem' te noemen en past niet bij kennisniveau die je hier schetst. Cisco, Meraki en Mist zijn allemaal veel te duur voor jullie use case.

Dan lijkt mij UniFi een goede kandidaat. Laten we daar dan op focussen?

Twee ecosystemen die ik wel zou overwegen zijn Aruba InstantOn (waar de auteur ook benieuwd naar is) en TP-Link Omada. Ik kan alleen geen concrete info vinden over hoe zij zouden reageren hierop. InstantOn zou ik mogelijk zelf kunnen testen aangezien ik hier een paar van die dingen heb hangen, maar dat ga ik vanavond niet meer doen - dan moet ik graven naar iets dat een packet capture kan doen...

Bespaar jezelf de moeite, zou ik zeggen. ;-)

Die drie ecosystemen vissen ongeveer in zelfde vijver van prosumer/kleinzakelijk gebruik. Verschil zit in de nuance, met name hoe beheer werkt:
- UniFi werkt met management app op een client PC, of standalone op een van hun routers. Dat moet dus wel dezelfde PC zijn die beheer doet _{in jullie situatie zou dat de productie computer kunnen zijn}. Dit is op GoT populairste ecosysteem. Het is goedkoop, makkelijk te installeren en werkt meestal gewoon foutloos. Grootste valkuil vind ik software updates. Dat gaat te vaak mis, met name bij mismatch tussen management app en de AP's. Als je goed thuis bent in de materie heb je het in een kwartiertje weer draaien, maar ik he b meerdere keren gehad dat dit gebeurde bij vrienden of kennissen waar ik UniFi had aangeraden en ze een week niets hadden tot ik tijd had om langs te gaan. Dat maakt me erg terughoudend om UniFi aan te raden.

Okay. Helder. Goed aandachtspunt. Dat moet nog wel lukken. Als ik kan ergens kan opzoeken wat compatible met elkaar is dan zie ik dat niet per definitie als probleem. Beetje RTFM dus en goed testen :-)

We hebben meerdere laptops waar we dat op kunnen installeren en configureren. Ook op de productie laptop zou dat geen probleem moeten zijn. Mijn idee is sowieso om de hardware 'thuis' voor te configureren zodat het in de basis werkt en dan op locatie op te tuigen en te finetunen. Hier nemen we de tijd voor.

- Omada is zeer vergelijkbaar. Ik heb nog niet van dezelfde upgradeperikelen gehoord. Minpunt is dat de specs van de verschillende apparaten minder goed op elkaar afgestemd zijn - je kunt bijvoorbeeld niet blind ervan uitgaan dat 5GHz DFS kanalen ondersteund zijn bij een nieuw model; soms (zoals bij de EAP610) komt het na meerdere maanden, soms helemaal niet...
- Aruba InstantOn is een poging van HPE om vanuit de enterprise-wereld toch de kleine markt te bedienen. Het is een tikje duurder dan UniFi of Omada, maar nog steeds <EUR 125, en ze zijn bewust conservatief qua ontwikkeling (geen WiFi-7 nog), maar in ruil daarvoor krijg je enerzijds de makkelijkste installatie die ik voor iets in deze categorie meegemaakt heb (exact even simpel als TP-Link's hersendode maar klantvriendelijke Deco reeks) en anderzijds onder de motorkap alle intelligentie van Aruba - inclusief een distributed controller: de controller draait op je APs, waardoor je dus geen applicatie op de PC of los controller ding nodig hebt. Ik draai hier ondertussen zelf bijna twee jaar op (2x AP22) en ben erg tevreden.

Er zijn andere opties, maar IMHO zijn ze ofwel veel duurder, danwel veel dommer, danwel van bedrijven waar ik twijfels heb over (langdurig) support - lees: zo'n beetje alles wat je op AliExpress tegenkomt.

Helder. Ik geef liever iets 'meer' uit als investering dan de AliExpress route te nemen.

Hopelijk beantwoord het e.e.a. van je vragen en ik respecteer het hele uitgebreide antwoord, ik hoop alleen dat we niet alles proberen dicht te timmeren. Ik snap het zeker van belang is, aan de andere kant is het voor ons ook een experiment en mocht het niet 'super goed' lopen dan is dat geen ramp. De livestream is echt een bonus, maar we willen wel proberen om het goed te doen.

[dion_b]

pgmw schreef op dinsdag 26 mei 2026 @ 16:41:
[...]

Die kans is aanwezig. We zien dit voornamelijk als investering als we op een locatie komen waar de infra niet goed is geregeld zodat we daar zelf de controle over kunnen hebben. Op andere locaties, waar mogelijk de infra wel op orde is, hebben we onze eigen oplossing niet nodig. Dit geeft ons tevens de flexibiliteit om kleinere competities te houden met het gebruik van de hardware. Tweaks en aanpassingen in de bekabelingen zijn dan niet per definitie een groot probleem omdat we diegene met de expertise altijd wel aan zullen sluiten bij de organisatie.


[...]

Ik snap wat je bedoeld, alleen hoe groter het evenement wordt, hoe professioneler het ook moet worden. Op een gegeven moment kunnen wij deze groei niet meer bijbenen als een groep vrijwilligers, hoeveel kennis we ook hebben.

Als het zo professioneel moet, zul je ook qua organisatie dingen moeten professionaliseren en mensen in dienst nemen. Maar goed, dat is luxeprobleem waar je nog lang niet bent.

[...]

Ja, hier hebben we het over verschillende dingen. Hij bedoelde dus10k bitrate binnen OBS.
Het doel is om primair een stream van 1920x1080p @ 60fps te produceren. Dus dan zitten we op 10 Mbps.

[...]

Je mag er van uitgaan dat het 5 camera's op max 1080p @ 60fps zullen zijn over het netwerk.

OK, duidelijk qua resolutie. Je hebt het over de output stream die 10Mbps zou zijn, betekent dat dan ook dat de Droidcam's elk ook 10Mbps verstoken, dus totale capaciteit op het draadloze stuk 50Mbps is (plus hier en daar 10kbps erbij)? Dan wil je misschien 75Mbps zeker aanwezig hebben op minst ideale plek.

Ik ben alleen bang dat WiFi 6 een probleem gaat worden voor sommige devices.

Hier kom ik straks nog op terug, het is de vraag waar je flexibiliteit wilt hebben.

[...]

Dat gaat niet gebeuren, we bouwen de hardware voor en na het evenement op en af.

Dat lijkt me uitermate onhandig. Iedere keer dat je aan dit soort spul gaat rommelen, kunnen dingen fout gaan. Connectoren hebben niet het eeuwige leven en worden niet blij met regelmatig los- en aankoppelen, kabels kunnen knikken. En mensen kunnen dingen niet helemaal goed inpluggen (of in verkeerde poort steken). Wet v Murphy zegt dat het op kritieke moment waar het het slechtst uitkomt mis zal gaan.

Als je een 'thuislocatie' hebt zou ik toch met klem aanraden daar een vaste installatie hiervoor te doen, zodat je geen onzekerheid hebt over thuiswedstrijden.

[...]

Dat hebben we niet zwart op wit, maar zeker wel een mondeling akkoord met de uitvoerende beheerders die op dat moment ook aanwezig zijn. Voor zowel de stream als de hardware, als de WiFI, het gebruik van alles in de zaal, attributen, ruimtes, afzet werk, opslag ect. Dat hebben we geregeld. Dat is hier geen probleem :-)

Ik hoop dat dit klopt, mondeling gaat goed tot het niet goed gaat. Je had het hierboven over een wens om op termijn te professionaliseren. Onderdeel daarvan gaat zeker zijn dat dit soort dingen vooraf ondubbelzinnig vastgelegd worden. Maar goed, dat is met name cruciaal voor andere locaties, daar zijn jullie nog niet.

[...]

Ik denk dat we dan in de problemen komen met sommige telefoons die het mogelijk niet ondersteunen? Ik snap dat 5G lastiger is met het mogelijke huidige netwerk.

Even iets breder; er bestaat mogelijk de kans dat een telefoon van de vrijwilliger (Bring your own device, eigenlijk) of een van de streaming telefoons (moet ik nachecken) geen ondersteuning heeft voor 6GHZ.
Zou de focus op 5GHZ dan niet iets safer zijn?

Vraag hier is welke risico's zwaarder wegen, en dit is typisch voorbeeld van waarom iets op eigen locatie anders zou kunnen liggen dan op andere locaties.

Stel dat je weet dat je op eigen locatie weet dat de bestaande WiFi enkel in 2.4GHz 'werkt' en bovendien dat er geen bezwaren zijn tegen 5GHz gebruiken voor je streams. Dan heb je die 6GHz waarschijnlijk niet nodig en kun je prima telefoons gebriuken die geen 6GHz kunnen.

Omgekeerd heb je op andere - niet op voorhand bekende - locaties al snel meer flexibiliteit nodig om storing te vermijden danwel te voldoen aan verplichtingen om specifieke kanalen en/of banden te vermijden. Ik zou dan zeker apparatuur willen aanraden dat 6GHz aankan. Als dan de conclusie is dat een willekeurige samenraapsel van telefoons daar niet mee overweg kan, dan moet je daar naar gaan kijken en overwegen om waar nodig die apparaten te vervangen.

[...]

Prima, dat is geen probleem. Alle telefoons, ook die van onze vrijwilligers, geven we sowieso een briefing voordat we beginnen. Hierbij valt ook het verbinden met het hidden netwerk.

[...]

Dan lijkt mij UniFi een goede kandidaat. Laten we daar dan op focussen?

[...]

Bespaar jezelf de moeite, zou ik zeggen. ;-)

Check. Heb genoeg op m'n bordje

[jeroen3]

Als iemand die geen ervaring heeft in zulke specifiek setups, maar wel huizen heeft voorzien van wifi.
Zou ik in dit scenario kiezen voor één van die unifi enterprise ap's die meerdere radio's bezitten.
Mogelijk op zo'n gehuurde trus-toren of speaker stand wat hoog in de lucht? Wat voor inhoud komt er eigenlijk in de zaal?

Zo heb je slechts één toestel te beheren, splits je de streaming clients over twee channels.
Het netwerk voor je non-streaming fix je dan op een andere band. Zo is streaming dedicated.
Vertraagt het netwerk niet voor een van die invoer-smartphones die mogelijk in een broekzak verdwijnt en slechte rate pakt.

Eventueel zou je nog ptp met proprietary mikrotik protocollen (eg: nv2) kunnen overwegen, maar dat zal al snel een kennis en beheerprobleem geven als het uberhaupt al toepasbaar is. Ondanks dat de harwdare daar prijstechnisch heel leuk kan zijn.

Maar zoals ik zeg, met dit specifieke concept heb ik geen ervaring, mogelijk gooien reflecties hier significant roet in het eten.

Je hebt natuurlijk de beste performance als je de streamers zo'n antenne rugzakje geeft geeft met een device bridge o.i.d ipv de built-in van de smartphones te gebruiken. Maar dat gaat misschien al weer naar een niveau te pro voor je doel.

Mogelijk kun je zo'n video stream setup ook huren?

[bakvis]

Ik denk dat @dion_b al een hele goede uitleg heeft gegeven over de setup en de mogelijkheden/beperkingen van de verschillende oplissingen. Waar ik het inderdaad mee eens ben:

• Geen mesh gebruiken, alles bekabeld aansluiten
• Gebruik enterprise grade AP's, of in ieder geval Ubiquiti/Aruba instant-on (al zou ik eerder kiezen voor Uniquiti in dit geval, kom ik zo op)
• Qua bandbreedte gaat het allemaal wel passen, zeker als je geen andere clients hebt dan degene die je in beheer hebt.

Verder zou ik 2 (of zelfs 5) verschillende Wi-Fi SSID's maken:

• Algemeen SSID voor de verwilligers toestellen
• Livestream SSID (of live-stream SSID per sectie, zie onder)

Verder ga je het algemene SSID uitzenden vanaf 1 access-point, idealiter midden boven het speeldveld. Een enkel AP op een veld van 35x35m in een open ruimte is voldoende voor de 25 toestellen, zeker als het datagebruik van deze toestellen beperkt is. Als je kijkt naar de gebruikte techniek binnen radio signalen is het niet erg als deze toestellen even moeten wachten totdat ze hun data kunnen verzenden.

Bij het livestream SSID is dit iets anders. Omdat de data througput eigenlijk real-time moet zijn richting de montage/stream pc kun je het niet echt veroorloven als 1 van de camera telefoons kortstondig geen data kan verzenden door een roaming event of omdat dit toestel moet wachten met verzenden omdat het kanaal bezet is.

Normaliter heb je bij streaming natuurlijk een client-buffer die korte onderbrekingen in de netwerk connectiviteit kan opvangen. In dit geval zijn je camera telefoons de bron van je video beeld, dit betekend dus dat ieder moment dat een camera telefoon kortstondig geen data kan verzenden richting het Wi-Fi netwerk je een zwart beeld hebt op de stream/montage PC.

Wat je dus eigenlijk wilt is dat de camera telefoons ten alle tijden direct hun data kunnen verzenden richting de stream/montage pc. Dit kun je realiseren door de beschikbare ruimte te verdelen in een aantal secties. Iedere sectie wordt bediend door een camera telefoon en deze telefoon zal ten alle tijden in die sectie blijven. Ieder sectie heeft zijn eigen AP (met eventueel zijn eigen SSID) in een eigen kanaal, dit kanaal is natuurlijk gescheiden van het algemene SSID kanaal. Verder zijn er geen devices verbonden met deze AP's, je verbind dus 1 telefoon met 1 AP. Verder "lock" je de client op een bepaald access-point, dit is bijvoorbeeld mogelijk binnen de ubiquiti beheer omgeving.

Dit zorgt dat deze telefoon ten alle tijden zijn data kan verzenden, nooit hoeft te wachten op andere devices in het netwerk en nooit zal roamen naar een ander access-point.

Dit zorgt wel dat je het volgende nodig hebt bij een Ubiquiti opstelling:

• Unifi controller (cloudkey of vergelijkbaar
• Unifi-POE switch (of inline POE injectoren)
• 4-6x Unifi AP (U6+ is je goedkoopste optie en moet al afdoende zijn)
• wat kabels

Eventueel kun je ook nog kijken naar Aruba instant on, erg goede access-points maar meer gericht op MKB die een zelf installatie uitvoert en dus qua management mogelijkheden iets gelimiteerder als de Ubiquiti setup.

[dion_b]

bakvis schreef op woensdag 27 mei 2026 @ 15:21:
[...]

Verder zou ik 2 (of zelfs 5) verschillende Wi-Fi SSID's maken:

• Algemeen SSID voor de verwilligers toestellen
• Livestream SSID (of live-stream SSID per sectie, zie onder)

Verder ga je het algemene SSID uitzenden vanaf 1 access-point, idealiter midden boven het speeldveld. Een enkel AP op een veld van 35x35m in een open ruimte is voldoende voor de 25 toestellen, zeker als het datagebruik van deze toestellen beperkt is. Als je kijkt naar de gebruikte techniek binnen radio signalen is het niet erg als deze toestellen even moeten wachten totdat ze hun data kunnen verzenden.

Bij het livestream SSID is dit iets anders. Omdat de data througput eigenlijk real-time moet zijn richting de montage/stream pc kun je het niet echt veroorloven als 1 van de camera telefoons kortstondig geen data kan verzenden door een roaming event of omdat dit toestel moet wachten met verzenden omdat het kanaal bezet is.

Normaliter heb je bij streaming natuurlijk een client-buffer die korte onderbrekingen in de netwerk connectiviteit kan opvangen. In dit geval zijn je camera telefoons de bron van je video beeld, dit betekend dus dat ieder moment dat een camera telefoon kortstondig geen data kan verzenden richting het Wi-Fi netwerk je een zwart beeld hebt op de stream/montage PC.

Wat je dus eigenlijk wilt is dat de camera telefoons ten alle tijden direct hun data kunnen verzenden richting de stream/montage pc. Dit kun je realiseren door de beschikbare ruimte te verdelen in een aantal secties. Iedere sectie wordt bediend door een camera telefoon en deze telefoon zal ten alle tijden in die sectie blijven. Ieder sectie heeft zijn eigen AP (met eventueel zijn eigen SSID) in een eigen kanaal, dit kanaal is natuurlijk gescheiden van het algemene SSID kanaal. Verder zijn er geen devices verbonden met deze AP's, je verbind dus 1 telefoon met 1 AP. Verder "lock" je de client op een bepaald access-point, dit is bijvoorbeeld mogelijk binnen de ubiquiti beheer omgeving.

Dit zorgt dat deze telefoon ten alle tijden zijn data kan verzenden, nooit hoeft te wachten op andere devices in het netwerk en nooit zal roamen naar een ander access-point.

Kan, maar je kunt hetzelfde realiseren met een enkele SSID door QoS (via WMM) te gebruiken en zorgen dat het gehonoreerd wordt. 'Video' (AC_VO) is niet voor niets een van de vier access categories die in 802.11e gedefinieerd wordt.

Vereiste is dan wel dat je bron - in dit geval de telefoons met de Droidcam app - correct de QoS instelt op de gegevens. Ik kan nergens in de (overigens opvallend summiere) Droidcam documentatie iets hierover vinden, of in die van OBS

TS, lees ik verkeerd / mis ik documentatie of wordt er nergens ook maar iets over layer 2 en 3 traffic geroepen daarover? Enige wat ik vind is summiere vermelding van SRT, RIST en WHIP protocollen, maar dat is allemaal layer 7 spul en WiFi leeft op layer 2...

Daar wordt alleen gezegd:

Streaming over WiFi

WiFi may be unstable for streaming

It's recommended to use a wired connection when streaming

No shit sherlock, maar in deze use case is dat niet mogelijk.

Als de software geen QoS flags zet, moet je inderdaad naar ranzige workarounds met dedicated SSID op dedicated band/kanaal zoals hierboven voorgesteld kijken.

Dit zorgt wel dat je het volgende nodig hebt bij een Ubiquiti opstelling:

• Unifi controller (cloudkey of vergelijkbaar
• Unifi-POE switch (of inline POE injectoren)
• 4-6x Unifi AP (U6+ is je goedkoopste optie en moet al afdoende zijn)
• wat kabels

Dit vind ik nog steeds *veel* teveel hardware. Ja, als je iedere stream een eigen kanaal wilt geven heb je inderdaad 5 AP's nodig, maar even terug naar de performance-eis: als je betrouwbaar 75Mbps op slechtste plek kunt krijgen is dat voldoende voor alle vijf de streams naast elkaar, en dat zou met een enkele AP al moeten lukken met meer dan 10dB fade margin. We hebben het hier niet over 4k content laat staan ongecomprimeerde video.

Mbt buffering is dat wel een relevate vraag: hoe 'live' moet de livestream zijn? Iedere bewerking op een digitale videostream introduceert onvermijdelijk een vertraging ten opzichte van live _{kijk voor de grap naar het verschil tussen goal bij voetbalwedstrijden tussen een analoge FM radio, linear video via DVB of satelliet, en tenslotte IPTV - je hoort ze eerst juichen op de radio, dan zie je het op DVB/satelliet en daarna pas op IPTV}. Als er de mogelijkheid is om een paar seconden de binnenkomende streams te bufferen voor bewerking en vervolgens uitzenden, dan maakt dat de eisen voor de WiFi veel lager dan als er geen dergelijke input buffering mogelijk is en alles near-real-time moet gebeuren.

De OBS website heeft ook hier geen info over, maar ik lees _{bijvoorbeeld hier} dat er instellingen zijn voor de output buffer size, maar ik vind niets over mogelijke bufferen van input streams.

TS, kun je hier specifiekere info over geven?

Eventueel kun je ook nog kijken naar Aruba instant on, erg goede access-points maar meer gericht op MKB die een zelf installatie uitvoert en dus qua management mogelijkheden iets gelimiteerder als de Ubiquiti setup.

TS heeft al aangegeven voor UniFi te gaan, maar ik ben benieuwd wat je bij InstantOn mist dat hier relevant zou zijn? Het klopt zeker dat je bij UniFi meer instellingen hebt om aan te tweaken, maar dat zijn vaak erg low-level dingen (bij UniFi kun je bijvoorbeeld per data rate instellen of ze geaccepteerd worden of niet terwijl je bij InstantOn alleen een minimale data rate in kunt stellen) - en dat lijken me niet dingen die her van belang zijn.

[laurens0619]

Ik vind @bakvis zijn idee wel goed om dedicated airtime te creeren voor de clients die video gaan streamen. Het is even een blackbox hoe die droidcam zich precies gaat gedragen maar mijn ervaring is dat een video stream behoorlijk wat airtime kan oplslokken.

Omdat de bandbreedte behoefte laag is maar airtime hoog zou ik ipv 5 accesspoints 1 (of misschien 2) accesspoints ophangen met 20mhz kanalen en aparte ssids. Dan kun je toch iedereen dedicated airtime geven maar heb je niet veel hardware nodig.

Ok dit gaat natuurlijk niet werken als er maar 1 5ghz radio in een accespoint zit nevermind.
Je zou ook ergens in het midden kunnen gaan zitten. De clients verdelen over 2 of 3 accesspoints.

[ Voor 16% gewijzigd door laurens0619 op 27-05-2026 16:34 ]

[bakvis]

dion_b schreef op woensdag 27 mei 2026 @ 16:23:
[...]

Kan, maar je kunt hetzelfde realiseren met een enkele SSID door QoS (via WMM) te gebruiken en zorgen dat het gehonoreerd wordt. 'Video' (AC_VO) is niet voor niets een van de vier access categories die in 802.11e gedefinieerd wordt.

Vereiste is dan wel dat je bron - in dit geval de telefoons met de Droidcam app - correct de QoS instelt op de gegevens. Ik kan nergens in de (overigens opvallend summiere) Droidcam documentatie iets hierover vinden, of in die van OBS

TS, lees ik verkeerd / mis ik documentatie of wordt er nergens ook maar iets over layer 2 en 3 traffic geroepen daarover? Enige wat ik vind is summiere vermelding van SRT, RIST en WHIP protocollen, maar dat is allemaal layer 7 spul en WiFi leeft op layer 2...

Daar wordt alleen gezegd:

[...]

No shit sherlock, maar in deze use case is dat niet mogelijk.

Als de software geen QoS flags zet, moet je inderdaad naar ranzige workarounds met dedicated SSID op dedicated band/kanaal zoals hierboven voorgesteld kijken.

[...]

Dit vind ik nog steeds *veel* teveel hardware. Ja, als je iedere stream een eigen kanaal wilt geven heb je inderdaad 5 AP's nodig, maar even terug naar de performance-eis: als je betrouwbaar 75Mbps op slechtste plek kunt krijgen is dat voldoende voor alle vijf de streams naast elkaar, en dat zou met een enkele AP al moeten lukken met meer dan 10dB fade margin. We hebben het hier niet over 4k content laat staan ongecomprimeerde video.

Mbt buffering is dat wel een relevate vraag: hoe 'live' moet de livestream zijn? Iedere bewerking op een digitale videostream introduceert onvermijdelijk een vertraging ten opzichte van live _{kijk voor de grap naar het verschil tussen goal bij voetbalwedstrijden tussen een analoge FM radio, linear video via DVB of satelliet, en tenslotte IPTV - je hoort ze eerst juichen op de radio, dan zie je het op DVB/satelliet en daarna pas op IPTV}. Als er de mogelijkheid is om een paar seconden de binnenkomende streams te bufferen voor bewerking en vervolgens uitzenden, dan maakt dat de eisen voor de WiFi veel lager dan als er geen dergelijke input buffering mogelijk is en alles near-real-time moet gebeuren.

De OBS website heeft ook hier geen info over, maar ik lees _{bijvoorbeeld hier} dat er instellingen zijn voor de output buffer size, maar ik vind niets over mogelijke bufferen van input streams.

TS, kun je hier specifiekere info over geven?

[...]

TS heeft al aangegeven voor UniFi te gaan, maar ik ben benieuwd wat je bij InstantOn mist dat hier relevant zou zijn? Het klopt zeker dat je bij UniFi meer instellingen hebt om aan te tweaken, maar dat zijn vaak erg low-level dingen (bij UniFi kun je bijvoorbeeld per data rate instellen of ze geaccepteerd worden of niet terwijl je bij InstantOn alleen een minimale data rate in kunt stellen) - en dat lijken me niet dingen die her van belang zijn.

Goed verhaal, ben het met je eens dat het een nasty oplossing is om het veld in secties te verdelen, maar dit garandeerd wel airtime en airtime is juist hetgeen wat belangrijk is bij real-time video/voice.

Als je meerdere devices hebt die allemaal de Video flag zetten dan zul je alsnog terugvallen op een ander selectie algoritme voor de airtime.

wil je het 100% hebben dan moet je garanderen dat een client altijd 100% airtime heeft, dat kan alleen door het over verschillende AP's te verdelen.

Ik heb zelf een Unifi omgeving draaien (op meerdere plekken) en een kleine instant-on omgeving bij mijn ouders. Bij de Unifi omgeving kun je specifiek per client aangeven op welk AP het device mag verbinden, dit kan op instant-on niet.

Je kunt bij instant-on wel een access-policy maken welke client met een SSID mag verbinden, maar dan ben je meteen gelimiteerd aan 4 (of meer) SSID's.

heel dit verhaal staat of valt inderdaad bij buffering. Zodra de camera telefoons ook maar 1 of 2 seconden bufferen voordat ze de data verzenden richting de stream/montage PC dan is er niets meer aan de hand. We hebben het tenslotte over een roaming event wat misschien 0.1 seconde duurt en betreft wachten in airtime gaat het over miliseconden bij een kanaal met wat utilizatie.

Mijn advies: koop alvast 2 access-points (die heb je toch nodig) en maak een test-setup waarbij je kunt of je de stream "stuk" kunt krijgen met bijvoorbeeld drops, blackouts of artifacts. Met het advies in dit topic kun je wel een aantal verschillende setups proberen.

[pgmw]

dion_b schreef op woensdag 27 mei 2026 @ 16:23:


Dit vind ik nog steeds *veel* teveel hardware. Ja, als je iedere stream een eigen kanaal wilt geven heb je inderdaad 5 AP's nodig, maar even terug naar de performance-eis: als je betrouwbaar 75Mbps op slechtste plek kunt krijgen is dat voldoende voor alle vijf de streams naast elkaar, en dat zou met een enkele AP al moeten lukken met meer dan 10dB fade margin. We hebben het hier niet over 4k content laat staan ongecomprimeerde video.

Klopt. Het gaat hier 'maar' om 1080p 60fps wat een camera doorgeeft.

Mbt buffering is dat wel een relevate vraag: hoe 'live' moet de livestream zijn? Iedere bewerking op een digitale videostream introduceert onvermijdelijk een vertraging ten opzichte van live _{kijk voor de grap naar het verschil tussen goal bij voetbalwedstrijden tussen een analoge FM radio, linear video via DVB of satelliet, en tenslotte IPTV - je hoort ze eerst juichen op de radio, dan zie je het op DVB/satelliet en daarna pas op IPTV}. Als er de mogelijkheid is om een paar seconden de binnenkomende streams te bufferen voor bewerking en vervolgens uitzenden, dan maakt dat de eisen voor de WiFi veel lager dan als er geen dergelijke input buffering mogelijk is en alles near-real-time moet gebeuren.

De OBS website heeft ook hier geen info over, maar ik lees _{bijvoorbeeld hier} dat er instellingen zijn voor de output buffer size, maar ik vind niets over mogelijke bufferen van input streams.

TS, kun je hier specifiekere info over geven?

Zeker mogelijk. Het is een live stream, gelukkig geen realtime stream. Er is sowieso altijd een 'regisseur' die door krijgt wat er geproduceerd en gestreamed wordt. Als daar 'wat' vertraging op zit door buffering is dat prima. Het is ook echt meer om te laten zien wat er allemaal gebeurd tijdens het evenement.

Buffering is zeker geen probleem. Als een camera even de verbinding verliest tijdens het bewegen is het ook geen grote ramp, de kans dat deze camera op dat moment zelfs niet op de stream in beeld is, is ook aanwezig. We wisselen namelijk de cameras af tussen de verschillende deelnemers, met maximaal 3 cameras van de 5 in beeld. Camera mannen krijgen de tijd om te bewegen en hebben contact met de producent/regie om zo dat een beetje proberen te stroomlijnen.

bakvis schreef op woensdag 27 mei 2026 @ 16:35:
[...]

Goed verhaal, ben het met je eens dat het een nasty oplossing is om het veld in secties te verdelen, maar dit garandeerd wel airtime en airtime is juist hetgeen wat belangrijk is bij real-time video/voice.

Als je meerdere devices hebt die allemaal de Video flag zetten dan zul je alsnog terugvallen op een ander selectie algoritme voor de airtime.

wil je het 100% hebben dan moet je garanderen dat een client altijd 100% airtime heeft, dat kan alleen door het over verschillende AP's te verdelen.

Ik heb zelf een Unifi omgeving draaien (op meerdere plekken) en een kleine instant-on omgeving bij mijn ouders. Bij de Unifi omgeving kun je specifiek per client aangeven op welk AP het device mag verbinden, dit kan op instant-on niet.

Je kunt bij instant-on wel een access-policy maken welke client met een SSID mag verbinden, maar dan ben je meteen gelimiteerd aan 4 (of meer) SSID's.

heel dit verhaal staat of valt inderdaad bij buffering. Zodra de camera telefoons ook maar 1 of 2 seconden bufferen voordat ze de data verzenden richting de stream/montage PC dan is er niets meer aan de hand. We hebben het tenslotte over een roaming event wat misschien 0.1 seconde duurt en betreft wachten in airtime gaat het over miliseconden bij een kanaal met wat utilizatie.

Mijn advies: koop alvast 2 access-points (die heb je toch nodig) en maak een test-setup waarbij je kunt of je de stream "stuk" kunt krijgen met bijvoorbeeld drops, blackouts of artifacts. Met het advies in dit topic kun je wel een aantal verschillende setups proberen.

In middels hebben we op basis van de informatie in dit topic (Bedankt mannen voor alle waardevolle informatie) en door wat in Design UI rond te spelen, wat hardware aangeschaft wat precies binnen ons budget past. We hebben het hier over twee U7 Pro XGS en een PoE switch en de bekabeling. Zover ik heb begrepen kunnen we software op een laptop installeren hebben we dan geen Cloudkey nodig.

Misschien is deze hardware al 'te' overkill voor de situatie, maar dat nemen we even voor lief.
Mogelijk is een enkele AP, zoals ik hierboven lees, al voldoende. Dat testen we daar ter plekke op Rssi en beslissen dan of we er een of twee nodig hebben en/of wat we moeten aanpassen in de instellingen.

Aangezien de plannen zijn om bij het volgende evenement nog een stukje zaal erbij te willen huren, zodat het totale oppervlakte dan een metertje of 60 bij 35 gaat worden, dan hebben we in ieder geval de hardware al.

Er bestaat altijd nog de optie, mocht het niks zijn om de hardware te retourneren en meer onderzoek te doen na het evenement naar hardware die mogelijk beter aansluit op de situatie. Dat noemen we op dit moment dan maar een 'klein' probleem. Sommige sponsoren geven ons iets meer hoofdpijn momenteel :-)

[bakvis]

Mooi! Fijn dat we konden helpen.

Ik ben wel benieuwd naar je uiteindelijke ervaring. Wil je die hier delen?

[dion_b]

pgmw schreef op donderdag 28 mei 2026 @ 22:44:
[...]

We hebben het hier over twee U7 Pro XGS en een PoE switch en de bekabeling.

Waarom in vredesnaam de XGS ipv de reguliere U7 Pro?

Enig verschil is dat ze 4x4 MIMO radio's hebbenin de 5GHz ipv 2x2, en:
1) jullie telefoons gaan nooit meer dan 2x2 ondersteunen
2) MU-MIMO (waarmee je in theorie meerdere 2x2 apparaten tegelijk kunt aansturen) is in prakijk een wassen neus

Leuk dat dit binnen budget paste, maar je had exact zelfde prestaties in jullie situaties behaald voor EUR 200 minder, die je vervolgens in bier of extra hardware voor een tweede setup (voor uitwedstrijden) had kunnen steken.

[laurens0619]

Ik begrijp m ook njet helemaal

Voor die 600 euro had ik eerder 6x een unifi 7 lite gehaald of 3x een u7 pro als 6ghz bruikbaar is. Ook overkill maar wel overkill waar je denk ik meer aan hebt (meer radios, meer rf mogelijkheden/airtime)

[ Voor 8% gewijzigd door laurens0619 op 29-05-2026 00:53 ]

[MartijnDutch]

Gebruik twee ap7 outdoor pro, deze hebben zowel een omni antenne en een directionele beam. Plaats ze tegenover elkaar, zeg maar bij de doelen. Moet echt meer dan genoeg zijn. Ga absoluut niet meshen, tenzij je niet anders kunt. Die 400 man die er zitten zorgen overigens wel voor enorme interference.

Let wel heel goed op je instellingen, kanaalbreedtes en beacons. 20 mhz kanalen, ook op de 5ghz. -knip-. Laten we geen illegale dingen adviseren.

[ Voor 12% gewijzigd door rens-br op 29-05-2026 13:48 ]

[Tarquin]

Als die 400 man op de tribune een probleem zijn... geef ze dan een eigen netwerk "Gratis Internet" op een kanaal, en draai de streaming op een heel ander kanaal.

[LucasVanDijk758]

Ik zou juist géén “gratis internet” SSID voor publiek toevoegen als het doel een stabiele stream is. Dan maak je jezelf ineens helpdesk voor 400 telefoons en je voegt extra beacons/auth/DHCP/NAT-verkeer toe dat niets met de productie te maken heeft. Als de locatie al publiek wifi heeft: prima, laat dat los van jullie set. Voor jullie eigen set zou ik hem saai houden: bekabelde uplink, één verborgen productie/vrijwilligers-SSID of desnoods twee SSID’s, vaste kanalen/20 MHz, en vooraf met de camera-telefoons een rondje RSSI + proefstream doen.

[pgmw]

bakvis schreef op donderdag 28 mei 2026 @ 23:48:
Mooi! Fijn dat we konden helpen.

Ik ben wel benieuwd naar je uiteindelijke ervaring. Wil je die hier delen?

Ja zeker!

Inmiddels is het evenement geweest en ik ben erg blij hoe het in de praktijk heeft uitgepakt. Eigenlijk is het scenario wat we op UI Design hebben uitgetekend was voldoende. Mogelijk is het niet perfect, maar heeft voor onze usecase prima voldaan.

Thuis is de hardware voorgeconfigueerd en op locatie hebben we enkel de schotels gemonteerd op uitschuifbare palen tot ongeveer 3 meter met daartussen een wired backhaul naar een PoE switch. Dit heeft gedurende de opbouw (vrijdag) en het evenement op zaterdag en zondag zich prima gedragen. Op vrijdag avond hebben we nog het e.e.a getest en aangepast in configuratie. De vrijwilligers en de camera crew hebben uiteindelijk op geen enkel moment problemen gehad of geklaagt dat het netwerk instabiel was tijdens hun werkzaamheden.

Door een schotel op te hangen in het midden van het veld hebben we uit eindelijk een voldoende reach gehad over bijna het hele veld. Uiteindelijk hebben we ook de tweede opgehangen om nog een ander deel te voorzien van een netwerk. Daarbij ook de schotels verplaatst naar 1/3 van het veld op beide kanten. Ook dat bleef prima werken.

Vervolgens, zoals geadviseerd het netwerk niet zichtbaar te zetten, en de vrijwilligers die gebruik mochten maken van het netwerk d.m.v. een WiFi QR code laten verbinden. IT en streaming uiteindelijk bekabeld op de switch.


dion_b schreef op vrijdag 29 mei 2026 @ 00:35:
[...]

Waarom in vredesnaam de XGS ipv de reguliere U7 Pro?

Enig verschil is dat ze 4x4 MIMO radio's hebbenin de 5GHz ipv 2x2, en:
1) jullie telefoons gaan nooit meer dan 2x2 ondersteunen
2) MU-MIMO (waarmee je in theorie meerdere 2x2 apparaten tegelijk kunt aansturen) is in prakijk een wassen neus

Leuk dat dit binnen budget paste, maar je had exact zelfde prestaties in jullie situaties behaald voor EUR 200 minder, die je vervolgens in bier of extra hardware voor een tweede setup (voor uitwedstrijden) had kunnen steken.

Tsja.. Waarom denk je dat ik advies over de hardware vraag? Mijn inhoudelijke kennis over verschillende series van hardware en de performance ervan houd daar al snel bij op. :) Ik denk hierbij ook een beetje dat 'goedkoop is duurkoop' is als je bekend bent met het consumenten segment. Als je daar te weinig over weet je dan kan je vaak beter voor 'iets' duurder kan gaan, toch? Dat is uiteraard hier anders, maar goed.

Op een moment moet je over op het aanschaffen van hardware omdat je geen tijd meer hebt om het tot op de millimeter uit te zoeken en we een redelijk beeld hadden wat we nodig hebben. We hebben gewoon het 'risico' genomen dat we hardware bestellen en als het niet uitpakt in de praktijk, we het achteraf zouden retourneren. Dat is echt de minste zorg voor ons geweest, we hebben vele lastigere keuzes moeten maken op andere vlakken in de afgelopen weken :-)

Dat is nu niet het geval geweest en we zijn blij met het resultaat. Als we nu in het vervolg nog wat andere camera hardware gaan gebruiken zijn we mogelijk al beter voorbereid.

laurens0619 schreef op vrijdag 29 mei 2026 @ 00:51:
Ik begrijp m ook njet helemaal

Voor die 600 euro had ik eerder 6x een unifi 7 lite gehaald of 3x een u7 pro als 6ghz bruikbaar is. Ook overkill maar wel overkill waar je denk ik meer aan hebt (meer radios, meer rf mogelijkheden/airtime)

6ghz kunnen we mogelijk bij een volgend evenement gaan gebruiken. Een 3e AP aanschaffen is dan een kleine stap. Mogelijk voldoen de twee AP's die we hebben nu ook al. Het zal hier gaan om misschien ~10 meter extra in totaal.

Tarquin schreef op vrijdag 12 juni 2026 @ 00:36:
Als die 400 man op de tribune een probleem zijn... geef ze dan een eigen netwerk "Gratis Internet" op een kanaal, en draai de streaming op een heel ander kanaal.

Misschien. We hebben vorig jaar gezien dat het weggeven van WiFi (overigens op een andere locatie en niet onze eigen hardware) het hele netwerk plat trok. - Dit was verdeeld over 3 verschillende netwerken. (Beheerder van die hal claimde dat het netwerk goed en professioneel aangelegd was, wij weten in middels dat dat niet zo het geval was). Vandaar dat we geen gratis wifi hebben aangeboden.

LucasVanDijk758 schreef op vrijdag 12 juni 2026 @ 13:27:
Ik zou juist géén “gratis internet” SSID voor publiek toevoegen als het doel een stabiele stream is. Dan maak je jezelf ineens helpdesk voor 400 telefoons en je voegt extra beacons/auth/DHCP/NAT-verkeer toe dat niets met de productie te maken heeft. Als de locatie al publiek wifi heeft: prima, laat dat los van jullie set.

Dit dus. Dat is denk ik wat vorig jaar gebeurd is.

Voor jullie eigen set zou ik hem saai houden: bekabelde uplink, één verborgen productie/vrijwilligers-SSID of desnoods twee SSID’s, vaste kanalen/20 MHz, en vooraf met de camera-telefoons een rondje RSSI + proefstream doen.

Ja precies. Dat is het advies wat we hebben opgevolgd. Dat ging prima.
Bereik was in de complete (open) hal en speelveld (vol met mensen) prima.
Buiten de hal, zoals verwacht, een stuk minder. Overigens nog steeds 'voldoende', sterker nog, beter dan het 'gratis wifi' wat ze aanboden

Als laatste de conclusie over streams met DroidCam en over een mobiele telefoons; Ja het kan. Zou ik het zelf adviseren; Nee. We kunnen beter kijken voor betere camera hardware volgend jaar, denk ik. Je merkt wel dat sommige telefoons er iets meer moeite mee hadden dan betere telefoons om de beelden door te sturen naar de productie PC). Ik weet zeker dat dit niet aan het netwerk zelf lag. Geen consistente 30fps, framedrops, battery drain. Nu is dat niet zo erg voor onze doelgroep. Uiteindelijk ging dit dan ook voornamelijk voor het netwerk :-)


Wat mij betreft kan/mag het topic gesloten worden en wederom wil ik iedereen bedanken die de moeite (en tijd) heeft genomen om ons op weg te helpen

[dion_b]

pgmw schreef op zaterdag 13 juni 2026 @ 21:10

[...]

Tsja.. Waarom denk je dat ik advies over de hardware vraag?

Geen idee. Je stelt vragen en koopt vervolgens iets dat niemand hier aangeraden heeft...

Dat is nu niet het geval geweest en we zijn blij met het resultaat. Als we nu in het vervolg nog wat andere camera hardware gaan gebruiken zijn we mogelijk al beter voorbereid.

Mooi.

Wat mij betreft kan/mag het topic gesloten worden en wederom wil ik iedereen bedanken die de moeite (en tijd) heeft genomen om ons op weg te helpen

Topics op GoT worden gesloten als ze niet voldoen aan regels of anderszins kansloos zijn. Dat lijkt me toch niet het geval...

[rens-br]

Kleine titelfix