Opened 13 years ago
Closed 13 years ago
#100 closed defect (fixed)
compass variabele in wleiden.yaml niet correct
| Reported by: | huub | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | WL-9.0-RELEASE |
| Keywords: | gformat | Cc: | |
| Resource needed to fix: |
Description
Ik krijg de indruk dat de nieuwe 'compass' variabele in wleiden.yaml automatisch wordt afgeleid uit de naam van de interlink. Dat gaat niet goed voor de station-kant van de interlink. De ssid bevat de richting van de interlink gezien vanaf de ap-kant. Dus 180 graden verkeerd.
Change History (5)
comment:1 by , 13 years ago
| Keywords: | gformat added |
|---|
comment:2 by , 13 years ago
Wat heel goed kan en correcte waarde geeft is: kompaskoers uitrekenen uit de X,Y coordinaten van de nodes. "compass"=arctan((rdnap_y1-rdnap_y2)/(rdnap_x1-rdnap_x2)). "compass" is dan in graden en geen windrichting, wat me wel zo handig lijkt voor de nodebouwers.
Ook de lengte van de interlink zou je m.b.v. deze coordinaten uit kunnen rekenen (voor het instellen van de ACK waarde in de nanostation configuratie).
comment:3 by , 13 years ago
Over de door Huub voorgestelde methode om de kompaskoers uit te rekenen: Hoe ga je dan om met point-multipoint configuraties, d.w.z. die gevallen waar een nano in AP mode verbinding maakt met meer dan 1 nano in station mode? (Voor de lengte van de interlink zou in zo'n geval de afstand tussen de AP nano en de verst verwijderde station nano moeten nemen).
comment:4 by , 13 years ago
De 'compass' variabele slaat op de interlink en is onderdeel van de configuratie van een (1) interlink in de yaml-file. Dus bij multipoint configuraties heb je verschillende 'compass' waarden: voor elke interlink eentje. Mag de nodebouwer kiezen wat hem/haar de beste richting lijkt om de nanostation heen te zetten. Idem voor de lengte van de interlink. Mag de nodebouwer de langste kiezen. Niet dat dat erg kritisch is, we zetten de nano's toch op 'auto adjustment' van de ACK?
comment:5 by , 13 years ago
| Milestone: | → WL-9.0-RELEASE |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
Alle compass richtingen van items met een ns_ip key. Draaien van ./gformat.py cleanup zal eventuele missende compass richhtingen later fixen.
Ik ben er nog niet helemaal uit wat ik met de compass variable moet doen. Orgineel heb ik hem van de ESSID gehaald, maar dat is zoals je zegt interdaad niet correct.
Ik zal de huidige wel verbeteren, er is echter een maar... het is een verzonnen waarde en je kan hem/het dus niet als feit (de antenne kan in het echt een heel andere kant op staat).