Testbaarheid van een draadloze stack.

[djteddy]

Ik ben nu al een tijdje bezig met een draadloze stack te schrijven in C. Deze stack draaid op een Atmega328p icm een RFM-12B 868 MHz radio. (en nee, ik gebruik geen Arduino, gewoon een custom PCB )
De stack is volledig opgezet dmv. TDD (TestDrivenDevelopment). Ik ontwikkel de stack in C en kan hem compileren voor mijn AVR en voor een OSX target, waar ik wat debug informatie zoals message-queues en retries etc kan zien.



Maar dat is allemaal niet zo interessant.

Met name de netwerklaag van de stack begint nu aardig wat intelligentie te krijgen, omdat hij volledig meshing is. Dit gedrag wil ik graag lokaal op mijn PCtje kunnen testen. Om dit meshing gedrag goed in kaart te krijgen wil ik 100+ instanties van een node die mijn stack gebruikt emuleren.

Nu heb ik 2 problemen:

Welke communicatie techniek benaderd een radio spectrum het beste?
Ik zit te denken over het mechanisme dat ik ga gebruiken om de verschillende 'stack-instanties' (lees applicaties) met elkaar te laten praten. Een UDP broadcast server is het eerste wat in mij opkwam en het dit emuleert mijn radio spectrum ook het beste. Echter weet ik niet of het mogelijk is om onder OSX een re-use van een UDP server poort te doen? Ik heb hier nog maar weinig over kunnen vinden, en de udp broadcast servercode die ik tot nu toe heb gebruikt werkt wel, maar geen meerdere instanties van dezelfde server op 1 pc. Dit is echter wel vereist, omdat ik straks gewoon 100x mijn test applicatie wil spawnen en zo hoop ik dus een netwerk met 100 nodes te simuleren.

Hoe kan ik snel meerdere instanties van mijn stack maken?
Aangezien ik C gebruik en dit dus geen OO taal is, word het wat lastiger voor mij om meerdere instanties van mijn stack te creeeren. Ik heb niet echt veel globale variabelen, dus wat ik nog zou kunnen doen is alle globalen in een struct mikken en deze telkes bij elke functie meegeven. Zo kan ik meerdere instanties van mijn stack in 1 applicatie maken. Echter lijkt mij dit niet echt de manier... Als ik een UDP broadcast server heb kan ik gewoon 100 instanties van mijn applicatie spawnen, dit lijkt vooralsnog het makkelijkste, hebben jullie nog goede ideeen verder?

Ik heb dus al wel aardig een idee hoe ik het op kan lossen, echter is het allemaal nog een beetje hobby en voordat ik een hoop tijd in een oplossing ga stoppen wilde ik even een second opinion

[.oisyn]

dus wat ik nog zou kunnen doen is alle globalen in een struct mikken en deze telkes bij elke functie meegeven. Zo kan ik meerdere instanties van mijn stack in 1 applicatie maken.

Dit is precies hoe OO geïmplementeerd wordt. Het feit dat C geen OO taal is wil niet zeggen dat je het OO paradigma niet aan kunt houden

[djteddy]

Hey sylvester, klopt klopt. Echter ga ik dan in elke functie signature een extra pointer opnemen naar een structure. Ik ga dan dus mijn code aanpassen voor testbaardheid (wat overigens voor TDD niet echt een schande is) en dan heb ik tot nu toe nog niet (bewust) hoeven doen.

Misschien was er een andere (makkelijkere) manier, wat vind je van het idee om gewoon meerdere processen te spwanen icm een UDP broadcast server?

[ Voor 21% gewijzigd door djteddy op 29-03-2010 12:59 ]

[eghie]

Kun je niet via virtualisatie iets proberen om meerdere clients te spawnen? Zo emuleer je echt meerdere clients en kun je ook eventueel individueel testen. Zo zwaar hoeft virtualisatie niet te zijn.

[djteddy]

Ik dacht al dat er iets over virtualisatie zou gaan komen

Ik denk dat het een beetje overkill is om een stack van <2K te gaan virtualiseren. Plus als ik mijn volledige address-space wil gaan testen dan zou ik 65535x een virtual image van de stack moeten gaan draaien...

Maar misschien is er een lichte manier om virtualisatie te doen? Ik neem aan dat je geen vmware/parallels/virtualbox/qemu etc bedoelt?

[eghie]

djteddy schreef op maandag 29 maart 2010 @ 15:57:
Ik dacht al dat er iets over virtualisatie zou gaan komen

Ik denk dat het een beetje overkill is om een stack van <2K te gaan virtualiseren. Plus als ik mijn volledige address-space wil gaan testen dan zou ik 65535x een virtual image van de stack moeten gaan draaien...

Maar misschien is er een lichte manier om virtualisatie te doen? Ik neem aan dat je geen vmware/parallels/virtualbox/qemu etc bedoelt?

Nee die variant bedoelde ik inderdaad niet, zou wel erge overkill zijn. Nee soort van OpenVZ of BSD Jail achtig iets. Eigenlijk gewoon een vorm van chroot + eigen netwerk interfaceje op de al draaiende kernel. Zodat ze allemaal gescheiden zijn qua interface, waardoor je ook geen poort hoeft te delen. Volgens mij is hier wel een simpel scriptje omheen te bakken die zoiets een tig duizend keer start.

Of creer gewoon een zooi interfaces. Ik weet niet of OSX dat ondersteund. maar iets als ifconfig eth0:1 tot en met ifconfig eth0:255 ofzo. en laat ze specifiek op een bepaalde interface luisteren. Dan hoef je ook geen poorten te delen.

[ Voor 12% gewijzigd door eghie op 30-03-2010 10:20 ]

[djteddy]

Dat zou inderdaad kunnen werken, echter was ik op zoek naar een meer software achtige oplossing... het moet toch mogelijk zijn om makkelijk interprocess communicatie te doen mbv named pipes of een udp broadcast server?

Er zullen toch al wel meer mensen zijn geweest die een PHY layer van een stack hebben geemuleerd? Ik ben een beetje op zoek naar deze oplossingen, puur software dus.

[Soultaker]

Er zijn in principe al software tools om netwerken te emuleren. Bijvoorbeeld ns-2 wordt veel gebruikt in de academische wereld. Bijna niemand zal from scratch een simulator implementeren.

ns-2 biedt een framework om protocollen en devices te simuleren aan de hand van een implementatie in Tcl of in C/C++. Tcl is meestal simpeler om te schrijven, maar C/C++ heeft als voordeel dat je je bestaande netwerkcode ten dele kunt hergebruiken. Ten dele, want je moet je code wel in het framework inpassen. Er is dus wel enig werk vereist.

Kun je aangeven in hoeverre dit aan je eisen voldoet?

[djteddy]

Dit is dus precies wat ik zocht!
Ik heb even snel door de "NS for beginners" link heen gebrowsed en wat ik zag ziet er erg goed uit.

Ik was zelf al begonnen met een simpele implementatie van mijn PHY layer door shared memmory. Dit werkt ook wel, echter wil ik ook graag simuleren dat sommige nodes wel in elkaar radio-range liggen en andere niet. Ook wil ik crosstalk gaan emuleren en dat krijg ik met shared memmory moeilijk voor elkaar.

NS2 ziet er goed uit, ik zou hier inderdaad een goed beeld van mijn meshing gedrag kunnen krijgen. Wat ik nu echter moet gaan doen is een PHY layer schrijven die 'connect' op ns2, maar ik zag dat deze applicatie vrij goed beschreven is, dus dat mag niet zo'n probleem gaan geven!

Ik zag overigens ook dat de tool voor research en educatie doeleinden gratis is, dus ik kan aan de slag

[alienfruit]

Ik vind dit wel een interessant onderwerp en vraag mij af hoe het zit met afstandsbepaling dmv. een eigen stack. Als je kijkt naar Bluetooth verschilt de signaalsterkte waardes sterk die worden vrijgegeven door APIs/stack. Als je zelf iets maakt is het dan betrouwbaarder en kan je nog wel afstandbepalen tussen twee punten? Bijv. is iets een halve meter hier vandaan of niet?

[djteddy]

Afstandsbepaling via RSSI (signaal sterkte) is altijd lastig. Denk bijvoorbeeld aan reflecties tegen muren of stoorbronnen.

Op het moment dat je erg veel nodes hebt (en dus meetpunten) word het wel wat nauwkeuriger, dit zie je bv in grotere ZigBee netwerken waar wel plaatsbepaling gedaan word dmv RSSI. Sterker nog, er zijn zigbee chips die hiervoor al ondersteuning in de chip hebben zitten. (Dit noemen ze een location engine en deze zit bv in de TI CC2431).

Ik gebruik RSSI enkel tijdens associatie om er zo voor te zorgen dat nodes altijd associeren bij de meest sterke buurman. Daarna gooi ik er nog een slag overeen om mijn routes zo klein mogelijk te maken. Een trade-off tussen RSSI en pathcost dus.

Dat is eigenlijk het enigste waar ik signaalsterktes voor gebruik... Met twee nodes afstand bepalen dmv RSSI is dus niet echt aan te raden...

[ Voor 7% gewijzigd door djteddy op 20-04-2010 12:49 ]