Beste mensen,
Nog even wil ik terugkomen op de fout mbt de BaseID's. Ik sprak namelijk iemand en die had een ander stukje software (ben de naam even kwijt) en die gaf warempel dezelfde ID's aan als PDW in eerste instantie, de FOUTE dus.
Dat maakt mijn sprong misschien wat twijfelachtiger, maar ik zal even uitleggen waar het fout is gegaan. Misschien dat niet iedereen het begrijpt, maargoed ik probeer het in elk geval.
Mobitex werkt net als P2000 met zogenaamde frames (datablokken). Elk frame heeft een 56-bit header, bestaande uit :
Frame Sync (16 bits)
Bit Sync (16 bits)
BaseID (6 bits)
AreaID (6 bits)
Control Flags (4 bits)
Parity (8 bits)
Wat die Control Flags doen weet ik niet precies, maar dat doet ook even niet zoveel ter zake.
De Frame (Network) Sync is bij ons EB90 en de Bit Sync is CCCC voor basis 3333 voor mobiel.
Goed, ik begon weliswaar op de juiste plek met inlezen, maar ik deed (door een stomme, niet nader uit te leggen fout) het volgende :
BaseID (5 bits)
AreaID (6 bits)
Control Flags (4 bits)
Parity (9 bits)
Ik begin met een bit te weinig en had op het einde 1 bit teveel in de Parity. Dat betekent dus dat het laatste bitje van de BaseID ineens het MSB (het belangrijste/hoogste bitje) van de AreaID werd. Daarom zag je soms ineens hele rare/hoge AreaID's, paar voorbeelden :
0001=Utrecht-Uithof
0103=Gouda
020B=Scheveningen
2019=Amersfoort
2100=Alkmaar
220A=Leidschendam
2319=Maastricht
Of Area 00 daadwerkelijk bestaat, dat zou misschien nog wel kunnen, maar die sprong naar 20 vond ik al zo vreemd. Maar als je nu die fout ernaast legt dan is een AreaID van 100000 (binair) waarbij de 1 eigenlijk bij het BaseID hoort, hexadecimaal 20, dus dat klopt exact!!!
Zo kun je verder door gaan met rekenen en valt alles in elkaar.
Hoe het dan in godsnaam kan dat iemand anders blijkbaar exact dezelfde fout maakt weet ik niet, toeval bestaat niet zou je bijna zeggen, maar wat hij nu laat zien is ook vele malen logischer. Ik heb tot dusver alleen nog ID's gezien waarvan het AreaID met 02/03/04 begint en dat is mijns inziens een stuk aannemelijker dan die rare +20 sprongen.
Kijk nog even naar Rotterdam (oud) :
010A=Rotterdam-Oost
010C=Rotterdam-West
2106=Rotterdam-Centrum
210B=Rotterdam-Feijenoord
210C=Rotterdam-Noord
2119=Rotterdam-IJsselmonde
En Rotterdam (nieuw) :
030D=Rotterdam-Centrum
0314=Rotterdam-Oost
0317=Rotterdam-Feijenoord
0318=Rotterdam-West
0319=Rotterdam-Noord
0333=Rotterdam-IJsselmonde
Als dat er niet veel beter uit ziet dan weet ik het ook niet.
Dan nog even wat antwoorden :
Ik ben voor NwHex, dan zie je in 1 getal de area en Base.
Die mag je even uitleggen, want dat zie je toch ook in de oude situatie en ook als NwDec?
Zelf geef ik ook de voorkeur aan NwHex.
Ik heb een paar programma's die oa trunking kunnen volgen geven het ook in hexadecimaal weer.
Ja dat had ik vroeger ook volgens mij bij Etrunker (EDACS). Ik heb ook niet voor niets in eerste instantie voor HEX gekozen, aangezien de bitsync (CCCC/3333) en network/framesync (EB90) eveneens HEX zijn. Maarja de 'nummering' van sites is toch iets anders en de lengte verandert niet ineens (3F3F of 6363), in tegenstelling tot de weergave als totaal, daarbij zijn de verschillen een stuk groter. Zelf twijfel ik tussen NwDec en NwHex waarbij ik zelf denk dat decimaal voor het grote publiek begrijpelijker is, hoewel het natuurlijk weinig uitmaakt of je nu 021A of 0226 te zien krijgt en eventueel opneemt in de base-ids.txt.
Groeten, Peter.