NO173799B - Datastyringssystem for generelle formaal - Google Patents
Datastyringssystem for generelle formaal Download PDFInfo
- Publication number
- NO173799B NO173799B NO84841207A NO841207A NO173799B NO 173799 B NO173799 B NO 173799B NO 84841207 A NO84841207 A NO 84841207A NO 841207 A NO841207 A NO 841207A NO 173799 B NO173799 B NO 173799B
- Authority
- NO
- Norway
- Prior art keywords
- station
- address
- block
- status
- indicated
- Prior art date
Links
- 238000013523 data management Methods 0.000 title description 7
- 230000005540 biological transmission Effects 0.000 claims description 86
- 238000004891 communication Methods 0.000 claims description 43
- 230000004044 response Effects 0.000 claims description 17
- 230000004913 activation Effects 0.000 claims description 8
- 230000000977 initiatory effect Effects 0.000 claims description 7
- 238000003860 storage Methods 0.000 claims description 4
- 238000012545 processing Methods 0.000 claims description 3
- 230000003213 activating effect Effects 0.000 claims 1
- 210000000056 organ Anatomy 0.000 claims 1
- 238000012360 testing method Methods 0.000 description 105
- 108091006146 Channels Proteins 0.000 description 48
- 230000006870 function Effects 0.000 description 42
- 238000012546 transfer Methods 0.000 description 42
- 238000004590 computer program Methods 0.000 description 32
- 238000013461 design Methods 0.000 description 23
- 238000012544 monitoring process Methods 0.000 description 18
- 239000002131 composite material Substances 0.000 description 16
- 238000012790 confirmation Methods 0.000 description 13
- 238000000034 method Methods 0.000 description 11
- 230000008859 change Effects 0.000 description 9
- 238000001514 detection method Methods 0.000 description 9
- 230000001934 delay Effects 0.000 description 8
- 230000000694 effects Effects 0.000 description 8
- 238000010586 diagram Methods 0.000 description 7
- 230000009471 action Effects 0.000 description 5
- 230000001976 improved effect Effects 0.000 description 5
- 230000008569 process Effects 0.000 description 5
- 230000011664 signaling Effects 0.000 description 5
- 238000007726 management method Methods 0.000 description 4
- 230000001052 transient effect Effects 0.000 description 4
- 230000000903 blocking effect Effects 0.000 description 3
- 125000004122 cyclic group Chemical group 0.000 description 3
- 238000013016 damping Methods 0.000 description 3
- 230000035945 sensitivity Effects 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- 230000003321 amplification Effects 0.000 description 2
- 230000001427 coherent effect Effects 0.000 description 2
- 150000001875 compounds Chemical class 0.000 description 2
- 239000013078 crystal Substances 0.000 description 2
- 238000013479 data entry Methods 0.000 description 2
- 238000002405 diagnostic procedure Methods 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000003199 nucleic acid amplification method Methods 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000003825 pressing Methods 0.000 description 2
- 230000005236 sound signal Effects 0.000 description 2
- 239000000725 suspension Substances 0.000 description 2
- 101100185024 Mus musculus Mslnl gene Proteins 0.000 description 1
- 108010001267 Protein Subunits Proteins 0.000 description 1
- 230000004888 barrier function Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 239000000969 carrier Substances 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 239000000446 fuel Substances 0.000 description 1
- 238000011835 investigation Methods 0.000 description 1
- PWPJGUXAGUPAHP-UHFFFAOYSA-N lufenuron Chemical compound C1=C(Cl)C(OC(F)(F)C(C(F)(F)F)F)=CC(Cl)=C1NC(=O)NC(=O)C1=C(F)C=CC=C1F PWPJGUXAGUPAHP-UHFFFAOYSA-N 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000010355 oscillation Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000008092 positive effect Effects 0.000 description 1
- 238000007639 printing Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000003252 repetitive effect Effects 0.000 description 1
- 230000009131 signaling function Effects 0.000 description 1
- 230000008093 supporting effect Effects 0.000 description 1
- 238000004804 winding Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
- H04W84/04—Large scale networks; Deep hierarchical networks
- H04W84/042—Public Land Mobile systems, e.g. cellular systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K13/00—Conveying record carriers from one station to another, e.g. from stack to punching mechanism
- G06K13/02—Conveying record carriers from one station to another, e.g. from stack to punching mechanism the record carrier having longitudinal dimension comparable with transverse dimension, e.g. punched card
- G06K13/08—Feeding or discharging cards
- G06K13/0806—Feeding or discharging cards using an arrangement for ejection of an inserted card
- G06K13/0825—Feeding or discharging cards using an arrangement for ejection of an inserted card the ejection arrangement being of the push-push kind
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Mobile Radio Communication Systems (AREA)
- Selective Calling Equipment (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
- Circuits Of Receivers In General (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
Datastyringsystem for generelle formål.
Denne oppfinnelsen vedrører generelt datakommun-ikasjonssystemer, og spesielt et forbedret datastyringssystem som er spesielt godt tilpasset bruk i sammensatte radiokommunikasjonssystemer som kan brukes til lyd- og datakommunikas jon.
I kjent teknikk benytter sammensatte radiokommun-ikas jonssystemer komplekse signaliseringssystemer for å fremskaffe muligheter til både lyd- og datakommunikasjon.
Noen har muligheter til enveis statusinkikasjon og har
svært lite fleksible formater, hvilket begrenser brukbar-heten. I tillegg benytter eksisterende systemer strukturer som er svært kostbare å framstille og gir begrenset følsom-het i de fleste RF-miljøer. Videre har tidligere systemer blitt organisert rundt en kodestruktur som betraktet term-inalutstyret som noe som reagerte på et vilkårlig sett av diskrete kommandoer. Terminalen var utformet for å utføre et vilkårlig sett av operasjoner når en bestemt kommando-
kode aktiverte den. Dette resulterte i et lite fleksibelt system.
Det er derfor et formål med oppfinnelsen å fremskaffe et forbedret datastyringssystem som er spesielt godt tilpasset til overføring av data over en lydkanal i et sammensatt radiokommunikasjonssystem.
Det er et annet formål med oppfinnelsen å fremskaffe et forbedret datastyringssystem som er med lydbånd,
og som gir muligheter til adressering samtidig med data-overføring.
Det er enda et formål med oppfinnelsen å frem-
skaffe et forbedret datastyringssysten som har flere egen-skaper slik som selektivt sammensatt status, nødovervåking og styring av overføring, og som er forenlig med en lang rekke kommunikasjonssystemer.
I samsvar med oppfinnelsen er det kort fortalt fremskaffet et kommunikasjonssystem tilpasset til lyd- og datakommunikasjon over et kommunikasjonsmedium. Systemet omfatter minst en primær stasjon og en antall sekundære stasjoner, der hver sekundære stasjon har en forutbestemt stasjonsadresse lagert, et stasjonsadresseregister og tilpasset til å overføre en kommandodatapakke av fast lengde. Systemet omfatter på hver primære stasjon kretser for å overføre en kommandodatapakke av fast lengde, inneholdende en operasjonskode, et argument og en stasjonsadresse, og den primære stasjonen omfatter kretser for å generere et aktiveringssignal som reaksjon på mottak av en kommandodatapakke fra en sekundær stasjon, og kretser for å generere et aktiveringssignal som reaksjon på oppstarting av en lydoverføring til en sekundær stasjon. Hver sekundære stasjon omfatter kretser for å overføre en kommandodatapakke av fast lengde, inneholdende en operasjonskode, et argument og en stasjonsadresse, til en primær stasjon som reaksjon på et aktiveringssignal. De sekundære stasjonene omfatter også kretser for å generere et aktiveringssignal som reaksjon på mottak av en kommandodatapakke fra den primære stasjonen, og kretser for å generere et aktiveringssignal som reaksjon på oppstarting av en lydoverføring til en primær stasjon.
De særtrekkene i den foreliggende oppfinnelsen som anses for å være nye, er framsatt spesielt i de vedlagte patentkravene. Oppfinnelsen, sammen med videre formål og fordeler med den, kan forstås best med henvisning til den følgende beskrivelsen i forbindelse med de vedlagte tegn-ingene . Fig. 1 viser et blokkdiagram av et sammensatt radiokommunikasjonssystem i samsvar med foreliggende opp-finnelse. Fig. 2 viser et diagram av den foretrukne datapakkestrukturen som oppfinnelsen utnytter. Fig. 3 viser et diagram av den foretrukne inn-kodete datapakkestrukturen i samsvar med oppfinnelsen. Fig. 4 viser et blokkdiagram av en ny kontroller for baseenheten i samsvar med oppfinnelsen. Figur 5 viser et blokkdiagram av en styrekrets for en mobil enhet mp(3 oppfinnelsen. Fig. 6 viser et flytskjema av RESTART-rutinen baseenhetens - dataprogram ifølge oppfinnelsen. Figur 7 viser et flytskjema av PSK RECEIVE-rutinen til •* baseenhetens - dataprogram ifølge oppfinnelsen. Figur 8A og 8B viser et flytdiagram av PACKET PARSING-rutinen til baseenhetens dataprogram ifølge oppfinnelsen. Figur 9A, 9B og 9C viser et flytskjema av KEYBOARD HANDLER-rutinen til baseenhetens dataprogram ifølge oppfinnelsen. Figur 10A, 10B og 10C viser et flytskjema av COMMAND-rutinen til ■ baseenhetens dataprogram ifølge oppfinnelsen. Figur 11A og 11B viser et flytskjema av COMMAND TRANSMIT-rutinen til baseenhetens dataprogram ifølge oppfinnelsen. Figur 12 viser et flytskjema av
RETRANSMISSION-rutinen til baseenhetens dataprogram ifølge oppfinnelsen. Figur 13 viser et flytskjema av POLL EXIT-rutinen til 'baseenhetens dataprogram if iiinelsen» Figur 14 viser et flytskjema av DATA TRANSMIT-subrutinen til oaseenneten dataprogram ifølge oppfinnelsen. Figur 15 viser et flytskjema av PROM PROGRAMMER HANDLER-rutinen til baseenheten dataprogram ifølge oppfinnelsen. Figur 16 viser et flytskjema av START-rutinen til den mobile enhetens dataprogram ifølge oppfinnelsen. Figur 17 viser et flytskjema av EXT-rutinen til den mobile enhetens dataprogram ifølge oppfinnelsen. Figur 18 viser et flytskjema av TRANS EMERG-rutinen til den mobile enhetens dataprogram ifølge oppfinnelsen. Figur 19 viser et flytskjema av
PICHK-HUBCK-rutinen til den mobile enhetens dataprogram ifølge oppfinnelsen. Figur 20 viser et flytskjema av TlMCHK-rutinen til den mobile enhetens dataprogram ifølge oppfinnelsen. Figur 21 viser et flytskjema av EMRMON-rutinen til den mobile enhetens dataprogram ifølge oppfinnelsen. Figur 22 viser et flytskjema av TONES-rutinen til den mobile enhetens dataprogram ifølge oppfinnelsen.
I figur 1 er det illustrert den foretrukne utformingen av et sammensatt radiokommunikasjonssystem som kommuniserer både med datasignaler og lydsignaler mellom sendere på de primære stasjonene 50,52 (dvs basestasjoner) og sekundære radioer (dvs mobile i den foretrukne utformingen)
ifølge oppfinnelsen. Radiosystemet som er illustrert gir forsterkning til RF-systemer for normal stemme, men oppfinnelsen er ikke begrenset til RF-systemer. Systemet er prosessorbasert slik at alle styringsoperasjonene og signaliseringen utføres i software, og tillater et bærbart og modulært system som er fleksibelt, pålitelig og rimelig å produsere.
Som illustrert i den foretrukne utformingen i figur 1, er systemets utforming svært fleksibel. Hver stasjon har en senderstyringskonsoll 44,46,48, og en databasestyring 40,38,36 og 34, der hver har et tastatur med 12 taster og et display med fire siffer (ikke vist). En datakontroller 40,38,36,34 er koplet til hver konsoll-enhet 44,46,48,32 som vist. Data- og lydsignaler koples fra konsollen 44,46,48,32 til en basestasjon 50,52 over telefonlinjer. Basestasjon 50,52 omfatter hver en radio-sender og mottaker for kommunikasjon via en radiofrekvens-kanal (RF) til sekundære (mobile) radioer 60,62 og 64. Den mobile radioen 60,62 og 64 kan være enhver passende konvensjonell radio slik som en FM-radio i kommunikasjon med en mobil datastyringsenhet (ikke vist) ifølge oppfinnelsen.
Lydkommunikasjon med de mobile radioene 60,62,64 opprettes ved hjelp av senderkonsollen 44,46,48,32, mens datakommunikasjon opprettes ved hjelp av data<ontrolleren
(databasestyringsenheten) 40,38,36,34. Mottatte datasignaler kan vises på displayet med fire siffer på datafcontrolleren. Datasignaler som sendes fra dataKOn-rclleren
,-. 40,38,36 og 32 kan skrives inn fra tastaturet og
kan genereres automatisk, f.eks. i tilfellet med auto-
matiske mottakssignaler.
Databasestyringsenheten kan benyttes i tallrike utforminger. Som vist er datastyringsenheten 40 koplet til den andre datastyringen 38, som er individuelt koplet til en senderkonsoll 44 og 46. Konsollene 44,46 er begge koplet som vist, til basestasjonen 50. Således kan flere database-styringer fungere i en utforming med flere konsollenheter ved bruk av en enkelt basestasjon. En alternativ utforming er vist med databasestyringen 36 koplet til en enkelt konsoll 48 som er koplet til en basestasjon 42. Alle tre datastyringsenhetene 40,38,36 er koplet via ei samleskinne 12, som vist, til en hovedkonsoll 32 som tillater at hver databasestyring (baseenhet) og basestasjon overvåkes av hovedkonsollen 32 og en databasestyring 34 koplet til den.
En konvensjonell skriver 30 er medtatt for å tillate
skriving av enhver ønsket datainformasjon.
Radiokommunikasjonssystemet i figur 1 er spesielt godt tilpasset til sendertypeanvendelser, der en sender på
en basestasjon kommuniserer med operatører på en flåte-
styrke med mobile radioer. I slike kommunikasjonssystemer med radiosendere kan det være en eller flere RF-kanaler som deles av flere hundre mobile radioer. Derfor er det ønskelig at noen av kommunikasjonene mellom senderen på en sentral stasjon og operatørene på de mobile radioene utføres ved hjelp av datakommunikasjon, slik at bruk av hver'RF-kanal er mer effektiv.
Datasignalene som føres mellom basestasjonene 50
og 52 og den mobile radioen 60,62,64 omfatter en siffer-synkroniseringsdel, et synkroniseringsord og et inform-asjonsord. Siffersynkroniseringsdelen kan bestå av et 1,0 vekslende mønster for å tillate at en mottaker oppnår klokkesynkronisering. Synkroniseringsordet kan bestå av
ethvert passende samsvarende siffermønster. Informasjonsordet kan bestå av en adresse, kommandoer og/eller statusinformasjon. Kodeteknikker brukes for feilkorreksjoner og deteksjoner for å gi lav feilprosent og høy følsomhet. Signal-iseringssystejnet benytter PSK-modulasjon ved 600 bits pr.
sek. med en 1500 Hz bærebølge som bruker koherent deteksjon. Dataoverføringen utføres ved å bruke en 32 bits datapakke, som illustrert i figur 2. Den 32 bits datapakken kodes til en 176 bits kodet datapakke før utsending, som vist i figur 3. Denne kodete datapakken omfatter 24 bits av data som er modulert å tillate klokkegjenvinnings-synkronisering som vist i blokk 74 i figur 3, og består vekselvis av 1 og 0. I tillegg er et 40 bits fast kodeord for synkroniseringen tilføyd som vist i blokk 74 i figur 3. Den 32 bits datapakken er kodet ved først å generere et 48 bits indre kodeord ved å tilføye en 16 bits syklisk over-skytende sjekk-kode til den 32 bits datapakken, som vist ved 72 i figur 3. Dette 48 bits indre kodeordet kodes videre ved å bruke en vindingskoder med halv hastighet.
Denne lager et 122 bits kodet ord. Således genereres en 176 bits kodet datapakke som illustrert i figur 3.
Etter mottak utvinnes det en nøyaktig kopi av den originale 32 bits datapakken fra den 176 bits kodete datapakken ved bruk av konvensjonelle dakodingsmetoder. Struk-turen av kodene sikrer at informasjonen kan utvinnes korrekt selv om noe av den kodete datapakken har blitt øde-lagt av kanalforstyrrelser.Bitsynkronisering oppnås ved bruk av 24 bits innledning som gir et mønster for å tillate utvinning av bitklokkeinformasjon. Ordsynkroniseringen ut-føres ved sammenhengende sammenlikning av de siste 4 0 mottatte synkroniseringsbitene med et fast synkroniserings-kodeord, og når et forutbestemt tall (35 i den foretrukne utformingen) av biter svarer til synkroniseringskodeordet, detekteres bitsynkronisering. Deteksjon av synkroniseringsordet indikerer at de 112 bitene i det kodete dataordet følger umiddelbart. De neste 112 bitene til de kodete data lagres og dakodes. Overføringstida for den grunnleggende 176 bits kodete datapakken er 290 millisekunder i den foretrukne utformingen.
Det generelle formatet av informasjonsordet (dvs kommandodatapakken) er vist i figur 2 og omfatter en generell beskrivelse av hvert felt. Den grunnleggende kommandodatapakken er bare en av flere formater som kan brukes, f.eks. en enkel datablokk er et annet mulig format, der de første 31 bitene er av fritt format. I kommandodatapakke-bitet 31 (se figur 2) er det brukt et kommandoindikatorbit for å identifisere pakken som en kommando eller kontroll-format eller en datapakke av fritt format. Hvis bitet er null, anses pakken å være en kommando- eller kontrollpakke og følger formatet i figur 2. Hvis bitet er 1, er pakken av fritt format. Datapakker av fritt format kommer etter en "hovedpakke" av kommandotypen som identifiserer kilden eller bestemmelsesstedet til pakken av fritt format og inneholder den egentlige OP-koden og formatet for pakkene som følger. Således kan datapakker med 31 databiter kjedes sammen for intens overføring av informasjon, slik som tekst.
Bitet som er indikert som bit 30 i figur 2 er et bit for mottak/ikke mottak. Dette bitet brukes av bestemmelsesstedsenheten til mottaksformål og er avhengig av OP-kode. Hvis bitet for mottak/ikke mottak er lik null, vil bestemmelsesstedsenheten ikke motta kommandoen, men hvis bitet er 1, bør enheten motta medmindre OP-koden indikerer en kommando av typen anmodning eller spørsmål. Således blir visse kommandoer som overføres fra enten basen eller den mobile enheten i den foretrukne utformingen automatisk mottatt av mottakerenheten. I den foretrukne utformingen blir det i tillegg sørget for automatisk gjenoverføring for et programmert antall ganger i situasjoner der det ikke er bekreftet mottak.
Det neste indikatorbitet, vist i figur 2 som bit 19, er det utgående/inngående bitet (outbond/inbound bit, O/I) som brukes til å sende datapakker. Hvis O/I-bitet er 1, er datapakken utgående. Både de mobile enhetene og baseenhetene i den foretrukne utformingen benytter begge til-standene til O/I-bitet.
OP-kodefeltet til kommandopakken, vist som bit 24 til 28 i figur 2, brukes til å adressere et spesielt internt register i bestemmelsesstedets adresse og derved gjøre det mulig å spesifisere en særskilt kommando eller styringsoperasjon. Ethvert spesielt sett av instruksjoner kan defineres opp til 64. I den foretrukne utformingen er det flere kommandoinstruksjoner definert og flere datatype-koder.
Hver kommandodatapakke inneholder også et argumentfelt, vist i figur 2 ved bit 16 til 23 og brukt først og fremst til dataoverføring. For eksempel, i den foretrukne utformingen overføres status-, data- eller styringsinformasjon i argumentfeltet. Det brukes også som en spesiell kommando/styringsoperasjon når det er kombinert med OP-kodefeltet, slik at opp til 256 unike kommandoer kan gjennomføres med hver OP-kode.
De resterende 16 bitene i kommandodatapakken, bit 0 til 15 i figur 2, er adressefeltet til den 32 bits pakken. Adressefeltet deles i våre heksadesimale tall, som vist. Dette gir opp til 65536 adresser, og identifiserer bestemmelsesstedets enhet for inngående pakker. I den foretrukne utformingen brukes 10000 unike identifikasjonskoder som tillater at systemet blir delt i 10 flåtestyrker med opp til 100 unike koder pr. flåtestyrke. Hver mobile enhet forprogrammmeres til å inneholde en identifikasjonskode for en unik enhet, gruppe og flåtestyrke.
En utgående vilkårlig modus for adressering tillater et fleksibelt system av grupper og flåtestyrker, og all adressering som kan være dynamisk utformet. I denne modusen, brukes den heksadesimale F i enhver adressedel for å uttrykke en sammenlikning eller vilkårlig melding.Når en vilkårlig melding påstøtes i en av de fire heksadesimale posisjonene, vil enhetsdekoderen sammenlikne den posisjonen med den samme posisjonen til den på forhånd anviste enhets-identifikasjonsadressen. Således ville f.eks. en adresse med zFFFvære en melding til flåtestyrke 2, og FFFF ville være på alle meldinger.
En utgående direkte adresserende modus tillater adressering til grupper og flåtestyrker mens den tillater at enheter blir deler av grupper eller flåtestyrker.
I denne bølgtypen er den heksadesimale E plassert i den mest betydelige sifferposisjonen til adressefeltet (siffer 3), og flåtestyrkens adresse plasseres i den neste tall-posisjonen (siffer 2) fulgt av et to siffers BCD-gruppe-nummer for å adressere en gruppe. Den heksadesimale F kan plasseres i gruppeposisjonen for å adressere en flåtestyrke, og FFFF kan brukes for å adressere alle flåte-styrkene.
I den foretrukne utformingen har baseenheten evnen til å gjengruppere mobile enheter til alle tider slik at gruppekoden faktisk blir et mykt identifikasjonsnummer. Anta f.eks. at senderen vil ha en samtale med en spesiell gruppe, men at det er et medlem av gruppa han vil utelukke. Han kan midlertidig flytte det medlemmet til ei annen gruppe, fortsette med samtalen, og så returnere individet til gruppa. Hver mobile enhet kan utebli fra den faste forprogrammerte gruppekoden med krafttilførselen stående på.
I den foretrukne utformingen brukes argumentfeltet ofte til overføring av statusinformasjon der det brukes to statusnivåer. Det første nivået kalles operatørstatus, siden det vanligvis forbindes med operatøren på den mobile enheten. Det andre nivået kalles vekslende status og krever en valgfri interfacekrets i den mobile enheten. Operatør-status kan startes fra den mobile enheten ved forskjellige metoder. En forandring i et sett av statusbrytere kan starte overføringen av status i tilfeller når statusbryterne er eksklusive og sperret. Fortløpende status sendes også med hver lydoverføring og overføring av prioritert alarm. Hver baseenhet er utstyrt med status-nøkling, som tillater display- og lydselektivitet basert på den mottatte status til en mobil enhet. Nøkkelen kan utformes dynamisk av baseoperatøren, slik at f.eks. baselyden kan velges til å ikke dempe ved en spesiell mobil status. Statusbryterne kan også representere overføring av meldinger der slik overføring bruker momentane brytere for å indikere et forbigående forhold mens statusoverføring bruker sperrebrytere for å indikere et konstant forhold. Baseoperatøren kan også utspørre enhver mobil enhet for kretsoperatørstatus.
Totalt åtte uavhengige statusbiter er tilgjengelige for hver mobile enhet. Slik tillates totalt 128 operatørstatustilstander. Det vekslende statusvalget gir opp til 7 biter av uavhengig vekslende status som er lese-lig og stillbar fra baseenheten.
Systemet gir også økt selektiv oppkalling og paginering, som kan være automatisk. Med dette særtrekket inneholder hver oppkalling til en enhet, gruppe eller flåtestyrke en inngangs- og en utgangskode for å ikke dempe eller dempe. Baseoperatøren slår derfor enkelt inn en identifikasjonskode og snakker så normalt til den mobile enheten som vil stille seg automatisk tilbake etter samtalen. Eller en mobil operatør kan overføre en lydmelding som vil vise enhetsnummeret på konsollen der baseoperatøren trykker på overf©ringsbryteren for å selektivt reagere på den mobile oppkallingen. Denne drifts modusen refereres til som AUTO SEL CALL. Paginering aktiverer interne og eksterne alarmer på den mobile enheten slik som lys, horn og toner.
Det fins en mulighet til prioritert alarm der den mobile enheten kan aktiveres til den prioriterte alarmen ved en ekstern bryter som har prioritet over alle andre radiofunksjoner. Prioritert alarm vil overføres umiddelbart uten hensyn til aktivitet på kanalen, og opp til 20 data-pakkeoverføringer vil oppstå hvis den mobile enheten ikke bekrefter mottak. Baseenheten vil gi spesiell behandling til denne prioriterte alarmoverføringen. Når det oppstår en prioritert alarmoverføring, sendes den aktuelle operatør-statusen til den innledende enheten automatisk til baseenheten. Det er i tillegg to mulige mottakspakker som kan brukes ved prioritert alarm. Den første er det normale mot-taket som ganske enkelt "håndhilser" på den opprinnelige enheten. Den andre "håndhilser" også på den opprinnelige enheten, men kopler også inn den mobile senderen i en for-utinnstilt tidsperiode og tillater at baseoperatøren overvåker den enheten.Dette særtrekket referes til som nødover-våking. Et nødovervåkingsmottak gjør også alle andre mobile enheter på kanalen ubrukbare for lydoverføring så lenge som den forhåndsinnstilte perioden varer.
Det er et antall hovedvalg og utforminger som er mulige i den foretrukne utformingen. Disse valg og utforminger velges ut ved hjelp av en PROM kodeplugg som er både i baseenheten og de mobile enhetene. Forskjellige system-perimetre ligger også i kodepluggen.
Med henvisning til figur 4 er det vist en foretrukken utforming av baseenhetens datakontroller. . Denne baseenheten på figur 4 benytter et mikrocomputersystem (MPU) i forbindelse med sentralt og perifert utstyr for å fremskaffe et terminalsystem for mobile og bærbare anvendelser. Mikrocomputeren 100 utfører all den nødvendige styrings- og interface-logikken så vel som alle signalfunksjonene omfattende modulasjon og demodulasjon, koding og dekoding, displaystyring, tastatur-behandling, skriverinterfacing og mobil kodepluggprogrammering.
Som vist i figur 4 omfatter baseenheten en MPU 100, som i den foretrukne utformingen er en åtte bits mikrocomputer (en Motorola MC6803). Internt i MPU 100 er ei klokke som benytter en krystall 120, koplet som vist til MPU 100 for å produsere en klokkefrekvens i systemet på 4,9152 megahertz i den foretrukne utformingen, og som er delt internt for å gi en MPU-frekvens på 1,2288 megahertz. Et tastatursystem er koplet til MPU 100 som består av et 12 tasters tastatur 102 koplet til en tastekoder 104 som er koplet, som vist, til adresse-samleskinna 108 og data-samleskinna 106. Tastekoderen 104 omfatter en lager-funksjon og gir forstyrrelser i prosessoren. Systemets fastvare består av all mykvaren som er nødvendig for drift av systemet som er lagret i en "read only memory" (ROM) 112 som er koplet til adresse-samleskinna 108 og data-samleskinna 106, som vist. En "random access memory"
(RAM) 114 er koplet til MPU 100 via data-samleskinna 106 og adresse-samleskinna 108, som vist, for bruk som en serie-interface buffer og for identifikasjons-minne. En systemplugg 110 er koplet til MPU 100 via
adresse-samleskinna 108 og data-samleskinna 106 for å lagre systemvariable og spesielle og operasjonelle karakter-istikker og valg av individuelle enheter. Ei klokke 86 sammen med krystall 88 er koplet til utgangsportene 96,92 og til inngangsporten 94, som vist, primært for å gi tids-informasjon for logging. Interface-kretsen bestående av et PSK båndpass-filter 126, en begrenser 124, lyddempende rele 132, micdempende rele 134, lydalarmgenerator 136, multi-terminal styringslogikk 14 0 og ekstern inter-facelogikk er koplet, som vist, til MPU 100. Ekstra interface-krets skaffes av RS 232 serie-interface 84 koplet til spenningsomformer 82 og kraftforsyning 80 til MPU 100, som vist. Et PROM programmer-interface 90 er medtatt for å tillate programmeringsidentifikasjonskoder av mobile enheter og er koplet, som vist, til utgangsporten 92 og inngangsporten 94. Det er også medtatt displaykrets 98 som består av en displaystyring for syv segmenters LED-displayer og åtte LED statusindikatorer (ikke vist). Denne base-enhetstrukturen som vist i figur 4, fremskaffer evnen til direkte interface til en stor variasjon av
RF-kommunikas jonssystemer.
Displaysystemet 98 består av et fire siffers LED-display og åtte individuelle LED-indikatorer. Displayet brukes til datadisplay av alle inngående og utgående identifikasjonskoder omfattende enhet, gruppe og flåtestyrke. Displayet brukes også til redigering, datainngang, kodepluggprogrammering, statusgjenvinning og innstilling så vel som framvisning av alle inngående data. Displayet drives fra mikroprosessorsystemet og vil romme sammensatte kontrollere for konsollanvendelser.
Tastatursystemet brukes til datainngang, display-redigering, kommandoinngang og eksekusjon. All terminal-styring utfores gjennom tastatursystemet og mikrofon-trykkknappen til talebryteren. Tastaturet 102 har to hovedmåter for tastaturinngang: øvre og nedre tilfelle. Det nedre tilfellet brukes til å skrive inn identifika-sjonskodenummer og kommandodata. Det øvre tilfellet brukes i kommandoinngang og eventuell eksekusjon. Baseoperatøren har full kontroll med datasystemet gjennom tastatursystemet.
Ei sanntids dataklokke 86 frambringer tid og dato for å tillate display av tid og dato for alle handlinger som oppstår i systemet. Den brukes først og fremst i loggingssystemet, men kan også brukes som klokke eller tabell over hendelser. Et særskilt program som er nødvendig for å definere de spesielle karakteristika for hvert individuelle system ligger i en PROM kodeplugg 90. Det er mange variable som står i forhold til et spesielt system som defineres av data i denne kodepluggen. Alle nøkkel-kommandodefinisjonene som skal brukes i systemet er definert ved dataene i kodepluggen som må programmeres før bruken. Funksjonen definert av kodepluggdataene vil bli omtalt i nærmere detalj heretter.
Datasquelch fremskaffes for systemet for å slette ut lyden av dataoverføringer. Datadempingsfunksjonen fremskaffes av mykvaren i MPU 100 og av lyddempingsreleet 132.
I tillegg til datasquelch, brukes lyddempingsreleet 132 til å utføre konvensjonell lyddemping. Dempings- og ikke-dempingsfunksjonen kan kodes fra en spesiell status- eller identifikasjonskode.
Hver baseenhet er i stand til å adressere ID-koder fra 0 til 9999. I tillegg kan det konstrueres et delt system der området er fra 0 til 999 og det viktigste sifferet brukes som identifikasjon av en flåtestyrke og tillater således opp til 10 flåtestyrker eller en signal-kanal. I systemer som benytter sammensatte baseenheter for å romme sammensatte sendere, kan hver baseenhet på tastaturet ha programmerbare øvre og nedre grenser for tilgjengelige ID-koder, og området av koder kan allokeres dynamisk. Baseoperatøren ville således ikke tillates å få adgang til noen koder innenfor det gyldige innstilte området. I tillegg kan lyddemping brukes slik at en spesiell operatør bare vil høre overføringer med ID-koder innenfor det utvalgte området.
Mange kommunikasjonssystemer med sammensatte enheter har sammensatte sendere som ikke alltid er anbragt på samme sted. Baseenheten frambringer PTT-identifikasjon i begynnelsen og/eller slutten av enten en lyd- eller data-overføring. Systemkodepluggen bestemmer den ønskede bølge-typen og inneholder også den fire siffers ID-koden. Således kan en spesiell baseenhet identifisere alle mobile og base-overføringer, og ID-koden kan brukes i logging for å indikere når enheten mottok eller overførte data. I systemer der sammensatte enheter brukes på den samme RF-kanalen, sørges det for styring ved hjelp av kodepluggdata for å forhindre samtidige overføringer av mottaksbekrefteiser til mobile enheter. En enhet er betegnet som hovedenheten, og de resterende enhetene betegnes som under-enheter, slik at hovedenheten programmeres til å overføre alle datapakker med mottaksbekrefteiser. De bekreftede overføringene kan også programmeres til å være avhengige av tastaturets definerte enhetskodegrense og statusnøkkel. Den normale driftbølgetype for baseenhetkommandoer benytter det automatiske særtrekket for mottaksbekrefteiser med tilbake-overføringer. Imidlertid kan systemet også brukes med enveis bølgetyper der baseenheten utformes av kodepluggen for å overføre kommandoer bare en gang og ikke forvente en mottaksbekreftelse når de mobile enhetene i systemet er opprettet i den samme bølgetypen.
Overføringsdata til en basedatapakke er tilnærmet 325 millisekunder som sørger for radiosendersvingning ved forsinkelser. Imidlertid har de fleste systemer innbygde forsinkelser forbundet med repeterende fjernstyrte toner og andre som må medregnes før den aktuelle datapakken kan overføres. For å tillate disse variable forsinkelsene, vil baseenheten, basert på kodeplugginformasjonen, generere forsinkelser i overføringen på 100 til 1500 millisekunder i 100 millisekunders sprang. Senderen vil sende lydløse bære-bølger under forsinkelsen for å minimalisere datastøy på kanalen og tillate enkel interfacing i systemer med fjernstyrte toner. Alle mobile og baseenheter i et gitt system må ha den samme forsinkelsen.
Baseenheten vil vise alle innkommende PTT-identifikasjonskoder og statusindikasjoner. Status-indikasjonene vil avspeile den aktuelle statusen til den aktuelle enheten. PTT ID-overføringen har displayprioritet over alle kommandoene som er i gang. Hvis for eksempel baseoperatøren er i gang med å slå inn et tall og enn PTT ID mottas, vil displayet vise denne ID. Det samme er tilfellet for kommandoer. Enhver kommando som er i gang vil bli stanset hvis en PTT ID blir mottatt. Dette driftstil-fellet vil bare oppstå hvis et PTT ID mottaksvalg utvelges i kodepluggen. Når en ID mottas og dekodes riktig, testes den mot de aktuelle grensene. Hvis koden faller innenfor grensene, vil ID bli vist fram og lagt inn i minnet for videre behandling og sendt til loggingssystemet for utskrift.
Det er sørget for en prioritert bølgetype for alarmoverføring, som har absolutt prioritet over alle handlinger på terminalene. Baseenheten vil vise fram enhetskoden til den mobile enheten som genererer alarmen. Displayet vil blinke med ID-koden og alle statusindikasjoner samt gi en hørbar tone. For å nulle ut systemet med en prioritert kode, må operatørene trykke på "clear"-bryteren. Prioritert alarm kan settes inn i et LIFO-minne og kalles tilbake med en tilbakekallingskommando slik at alarmer med sammensatte prioriteter kan oppstå samtidig uten tap av data. Hvis imidlertid baseenheten er fortløpende i den nye bølgetypen og en ny prioritet mottas, vil den nye prioriterte ID ta over displayet. Den foregående prioriteten kan seinere kalles tilbake fra minnet. Selv.om en prioritert alarm vil utelukke displayet fra enhver annen bruk, kan datapakker fortsatt mottas og bekreftes. Alle data vil også fortsette å bli sendt til loggingssystemet.
Baseenheten kan også omfatte nødovervåkning som er valgbar med kodeplugg. Når en prioritert alarmpakke mottas, vil baseenheten øyeblikkelig gå inn i en prioritert bølge-type og bekrefte mottak fra den mobile enheten og avslutte enhver tilbakesendingssekvens. Baseoperatøren kan så aktivere en nødovervåkingssekvens som vil overføre en datapakke til den mobile enheten, som kopler inn radiosenderen i ti sekunder. På slutten av de ti sekundene vil den mobile enheten sende enda en pakke med prioritert alarm. Basen vil fortsette å sende en pakke med mottaksbekreftelse som vil kople inn senderen. Syklusen vil fortsette inntil operatøren ved basen nuller ut nødovervåkningen med "clear"-bryteren. Således kan baseoperatøren overvåke tale-aktiviteten til den mobile enheten i den prioriterte bølge-typen .
Baseenheten er i stand til å lagre opp til 64 mobile innledete inngående datapakker. Når inngående datapakker mottas og dekodes riktig, plasseres enhetskoden og statusinformasjonen i minnet. Metoden for lagring er sist inn, først ut (last in, first out, LIFO), som er hovedsaklig en stablingsoperasjon. Når en ny ID mottas, plasseres den på toppen av stabelen, og ID-kodene i minnet skyves fortløpende nedover stabelen. Operatøren kan bruke en tilbakekallingstast for å rykke fram stabelanviseren og vise fram den neste inngangen. En klareringstast brukes for å anbringe anviseren på toppen av stabelen, som viser den sist inntrufne ID og status. Dette særtrekket besørges som en granskingsmekanisme i situasjoner der flere datapakker mottas i rask rekkefølge for å holde rede på alle enhets-numrene.
Baseenheten sørger også for minnemuligheter for å stille opp operatørstatuspakkene i kø etter hvert som de ankommer i tid, opp til 128 operatøstatuspakker. Metoden for lagring er hovedsaklig en køoperasjon av typen først inn, først ut (FIFO). Hvis det er noen datapakker i køen, kan operatøren vise den neste ID-koden og statusen og fjerne det foregående displayet. En av de åtte statusindikatorer brukes for å vise en aktiv eller inaktiv kø. Hvis køen er aktiv, kan operatøren også, ved å trykke ned en klareringstast, vise fram den første pakken i køen. I tillegg tillater en statuskøstyring at terminaloperatøren kan åpne eller stenge innganger til køen. Bare operatør-status stilles i kø. PTT ID overføringer og prioriterte alarmer vil bli vist når de oppstår, men vil ikke påvirke driften av køen. Hvis køen stenges, vil alle mottatte operatørstatuser straks vises, eller hvis terminalen inneholder en LIFO-stabel vil den anbringes på LIFO-stabelen. Hvis køstyringen åpnes, vil en operatørstatuspakke bli
stilt i kø uten å påvirke terminaloperasjoner inkludert displayet. Imidlertid vil et kort "bipp" høres for å informere operatøren om en kommende status.
Utvelging av et begrenset antall av mobile enheter for operatørstatus og skiftende status besørges av baseenheten. Dette særtrekket tillater at operatøren kan avsøke systemet og lage ei statusliste av ei utvalgt gruppe av mobile enheter. Operatøren kan også velge ut en særskilt enhet ved å slå inn et begynnende enhetsnummer fra tastaturet og så starte utvelgingen og inntastingen av en unik status der utvelgingen skal stoppe. Utvelgingen vil starte ved det inntastede tallet og i rekkefølge utspørre de mobile enhetene om status. Hver gang statuspakken mottas, vil enheten foreta en sammenlikningsoperasjon, og hvis det finnes en sammenlikning, vil utvelgingen stoppe. Hvis det ikke er noen sammenlikning, vil utvelgingen fortsette til den øvre ID-grensa er nådd, eller til tellingen av utvelginger, som er forprogrammert til en ønsket verdi, som f.eks. 10, er oppbrukt.
Alle baseenhetene er utstyrt med styringslogikk
for å forhindre samtidig adgang til kanalen fra sammensatte enheter koplet i parallell. Den samme logikken brukes for å sperre inngående overføringer når RF-kanalen er opptatt. Hver enhet har en opptatt utgang og en sperreinngang som normalt er koplet sammen og utgjør en enkelt enhet koplet til det ytre interface 130, som blir både ei detekterings- og styringslinje. Før noen kommandoer utføres av enheten, testes sperrelinja for aktivitet. Hvis linja er klar, overføres kommandoen og enheten hevder et høyt nivå
på den opptatte linja og indikerer bruk av kanalen. Linja vil forbli opptatt inntil en mottaksbekreftelse mottas
eller gjenoverføringsperioden er komplett. Hvis kanalen er opptatt i kommandotidspunktet, vil enheten vente inntil ei linje blir klar, og dette vil vises ved at det indikeres for operatøren at linja er opptatt. Når sperrelinja klareres, vil enheten ikke sende øyeblikkelig. Hver terminal i et sammensatt terminalsystem inneholder et prioritetsnummer fra 0 til 254 i sin kodeplugg. Dette nummeret brukes til å generere en forsinkelse proporsjonal med prioritetsnummeret. Terminalen vil vente ut denne forsinkelsen og så ta en ny prøve av sperrelinja. Hvis linja enda er opptatt, vil venteprosessen fortsette inntil adgang kan oppnås. En tilfeldig forsinkelsesperiode brukes også i forsinkelsesprosessen hvis en enkelt datakommando utføres. Hvis linja er klar, overfører enheten som beskrevet ovenfor. Sperreinngangslinja kan forbindes med den opptatte utgangslinja fordi hver enhet vet om den er opptatt eller ikke. Dermed er et enkelt tvinnet par alt som trengs for å forbinde sammensatte terminaler. Et annet særtrekk ved sammensatte terminaler i den samme kanalen vedrører kommandooverlapping. Enhver kommando som utføres av en spesiell enhet vil påvirke bare den enheten. Hvis en enhet for eksempel utspør en spesiell mobil enhet om status, vil statuspakken som den mobile enheten returnerer bli vist bare på den enheten og vil ikke påvirke andre enheter på kanalen. Dette særtrekket tillater uavhengig styring ved sammensatte operatører, men gjelder bare for
utgående kommandoer. Alle inngående data slik som operatør-status og prioritert alarm vil bli vist på alle terminalene på den kanalen. Dette kan overvinnes ved å bruke teknikkene for statussammenlikning eller utvelging av dynamisk område som omtalt ovenfor, eller ganske enkelt ved å overvinne den spesielle mottakerfunksjonen via kodepluggen.
En modus for selektiv lydoppkalling (AUTO SEL CALL) er tilgjengelig på alle baseenhetene som kan velges ut ved å kode kodepluggen. Dette særtrekket tillater enkel sending på en selektiv måte. Operatøren slår inn den ønskede ID-koden, og systemet vil vente på at mirofon-PTT-bryteren skal trykkes inn. Når dette gjøres, vil en ikke-dempende datapakke bli overført og signalisere til de mobile enhetene at de ikke skal dempe mottakerlyden. Når PTT-bryteren utløses, sendes en dempe-datapakke. I løpet av denne perioden med overføring av selektiv lydoppkalling (AUTO SEL CALL), vil baseenhetens display lese CALL og indikere for operatøren at det lages en SEL CALL. Ved hjelp av tastaturet kan AUTO SEL CALL bølgetypen koples inn eller ut. Hvis den er utkoplet, vil ingen selektiv oppkalling bli gjort når mikrofon-PTT-bryteren trykkes inn. Loggingssystemet kan registrere både SEL CALL og normale lydoverføringer. Hvis en mobil enhet foretar en lydover-føring til basen, vil enhetens ID-kode bli vist på baseenheten. Baseoperatøren kan ganske enkelt trykke inn mikrofon-PTT-bryteren og snakke. Ingen andre inntastinger er nødvendige, og den mobile enheten vil bli selektivt oppkalt.
Hver gang en kommandooverføring utføres av base-operatøren, kan den mottakende mobile enheten sende en mottaksbekreftende pakke. Hvis de dekodete datapakkene er korrekte og indikerer at "håndhilsingen" er vellykket, vil baseenheten ved en mottaksbekreftende indikasjon vise at den mobile enheten mottok kommandoen. Hvis kommandoen viser seg å være en utspørring etter data, slik som operatør-status, og "håndhilsingen" er vellykket, vil displayet vise de mottatte data og ingen mottaksbekreftelse vil bli vist. Hvis "håndhilsingen" ikke ble fullført ved den første over-føringen, vil enheten automatisk gjenoverføre kommandoen på en tilfeldig måte et antall ganger bestemt av kodepluggen medmindre en mottaksbekreftende pakke mottas innenfor dette intervallet. En mottaksbekreftelse vil avslutte sekvensen. Hvis ingen mottaksbekreftelse mottas etter at det totale antallet av tillatte overføringer har inntruffet, vil displayet vise en feilindikasjon, og operatøren kan gjenoppstarte kommandoen. Kodepluggen på baseenheten kan programmeres slik at kanalens følsomhet brukes til å automatisk overvåke kanalen før overføringer og gjenover-føringer. Den samme sperrestyringslinja brukes slik som den som brukes til styring av sammensatte terminaler. Hvis kanalen er opptatt, sperres dataene. Men når kanalen klareres, vil ei tilfeldig klokke begynne å teste kanalen for aktivitet når klokka går ut. Hvis kanalen enda er opptatt, vil den tilfeldige prosessen med periode/testing fortsette. Men hvis kanalen er klar, vil kommandodatapakken bli sendt til den mobile enheten og en mottaksbekreftelse vil bli mottatt.
Et signaliseringssystem med testing over lukkede sløyfer kan utføres på utvalgte mobile enheter fra alle baseenheter. Testen utfører en serie av
radiosjekk-kommandoer som omfatter mobil mottaksbekreftelse. Den brukes normalt ved oppstart av systemet, men kan også brukes i diagnosetester av systemet. Når operatøren aktiverer bølgetypen for testing, vil terminalen vise operatøren ID-koden til den mobile enheten som skal testes og et antall individuelle tester som skal utføres (maksimalt 9999). Når testen er fullført, vil displayet indikere antall vellykte tester over lukkede sløyfer. Loggingssystemet vil også bli brukt til å vise alle data vedrørende hver individuelle serie av tester. Resultatene av testene vil avspeile statistikken til
RF-overf©ringsveiene, baseradioene etc. og kan brukes til å korrigere alle slags problemer i systemet.
En valgfri kodepluggmodul er tilgjengelig for baseenheten for å tillate programmering av mobil enhet, gruppe og flåtestyrkenes ID-koder, dempende bølgetyper for selektiv oppkalling og forsinkelser i systemet. Forsinkelsene til systemet i baseenhetens kodeplugg settes automatisk inn for alle mobile enheter uten hensyn til delte eller tilegnede konfigurasjoner. Når modulen forbindes med baseenheten, anbringes enheten automatisk i program modusen • Programmereren sørger for både en lese- og programkommando. Hvis lesekommandoen utføres, vil terminalen vise alle relevante data til operatøren. Feilkontroll fremskaffes for å teste ID-kodene for riktige verdier og informere operatøren om en uriktig kodeplugg. Hvis programkommandoen utføres, vil terminalen vise opera-tøren de nødvendige data, prøve å programmere kodepluggen og så vise innholdet. Feilkontroll er også fremskaffet i programbølgetypen for å forhindre programmering av ugyldige koder.
Baseenheten utfører en begrenset diagnosetest av fastvare- og mykvaresystemet. Sanntidsklokke, minne med tilfeldig adgang, kodeplugg, styreporter og andre forskjellige kretser testes, og alle feil rapporteres via displaysystemet og lydalarmen. En kommandotast er også tilgjengelig for å teste det fire siffers displayet og de åtte statusindikatorene.
Med henvisning til figur 5 er det vist et blokkdiagram av en styrekrets for en mobil enhet for bruk i forbindelse med en mobil sender-mottaker, mpfl i foreliggende oppfinnelsen. Den mobile enheten i figur 5 består først og fremst av av en mikrocomputer 150 (f.eks. Motorola MC3870) og tilhørende peri-ferisk krets. Prosessoren utfører all PSK-modulasjon, demodulasjon, koding og dekoding av signaliseringssystemet. Den utfører også all kontrollogikk og styrefunksjoner i det mobile systemet.
Inndommende data føres fra en mottaksdetektor i analog form til diskriminatorinngangen 186. De blir så båndpassfiltrert av båndpassfilter 190 for å fjerne uønskede signaler og mottakerstøy. Signalet begrenses så gjennom en begrenser 192 og bearbeides av MPU 150. Computeren utfører koherent deteksjon av signalet som resulterer i forskjellige datapakker som fremskaffer kommando- og styringsinformasjon for enheten.
Data som skal overføres behandles i datapakker i MPU 150 og presenteres som PSK-modulerte pakker på utgangen 178. Datapakken blir så filtrert ved bruk av det samme båndpassfilteret 190 som i den mottakende bølgetypen for å fjerne uønsket lavfrekvent energi fra PSK-dataene. Signalet koples så til mikrofonutgangen 188 til radiosenderen. Mikrofonen dempes under dataoverføringer for å forhindre enhver lydforstyrrelse. All senderstyring, lyddemping, tonegenerering og kanaldeteksjon utføres av MPU 150. En kodeplugg 152 er koplet som vist til MPU 150 og inneholder all systeminformas jon og valgbarheter til enheten. Dataene i kodepluggen 152 leses av prosessoren 150 og brukes så i driftsstyringen av enheten. En overvåkningsbryter 156 er koplet til MPU 150 for å overvåke et kjent signal ut av prosessoren og stille tilbake maskinen i tilfelle prosessorfeil eller forbigående forhold. En nedbryter 158 er koplet direkte til MPU 150 som vist og er et sett av åtte statusbrytere 162. Et antall inngangs- og utgangs-brytere og indikatorer, slik som horn og lys, er koplet til MPU 150, via interfacekretsen 164 og iederen 172, som vist. En datasyklusutgang 160, en dempende inngang og to tone-utganger er også medtatt, som vist. Det mobile enhets-systemet krever også en fem volts kraftforsyning 170 og en 9,6 volts kraftforsyning 168.
Enhetens, gruppas og flåtestyrkens ID-kode til hver enhet er lagret i kodepluggen så vel som individuelle systemfunksjoner slik som ID, status, prioritert alarm og selektiv oppkalling.
En unik enhetsidentifikasjonskode overfores med hver lydoverføring og utløses utenfor mikrofon-PTT-bryteren som er inngang til MPU 150 på inngang 180 i figur 5. Systemet kan programmeres slik at ID sendes ved opptasting eller nedtasting eller begge deler, eller ID kan også være meldingsorientert hvor bare en enkelt overforing oppstår etter f.eks. fjerningen av mikrofonen fra opphenget. Over-føringstida til en mobil datapakke er tilnærmet 325 millisekunder omfattende radiosenderens retning ved forsinkelser. For å tillata variable systemforsinkelser, genererer den mobile enheten imidlertid også, basert på kodepluggdata, overføringsforsinkelsen for systemet. PTT lD-over-føringen kan også programmeres via kodepluggen for å sende start/slutt-status med lydoverføringer slik at baseenheten vil sørge for automatisk ikke-demping av lyd og styring av demping, indikasjon av en aktiv overføring og logging av overføringenes varighet.
Et meget fleksibelt statusvalg kan programmeres inn i systemet via kodepluggen som tillater at forskjellige oppstillinger av status og meldinger kan ligge i systemet. To statusnivåer er tilgjengelige, operatørstatus og vekslende status. Den vekslende statusen krever et valgfritt eksternt interfacekort 154 i figur 5 som er koplet via ei ekstern samleskinne til kodepluggen 152.
Det er tre forskjellige typer av operatørstatus som er tilgjengelige i den mobile enheten: ny operatør-status, fortløpende operatøstatus og meldinger. Ny operatørstatus krever en positiv handling av den mobile operatøren. Dette kan være en forandring i status, i hvilket tilfelle operatøren fysisk vil forandre et sett av bryterinnstiIlinger og sende avgårde den nye statusen til basen. Den mobile enheten kan ha opp til ni brytere som kan være momentane, av typen trykk-trykk, sperret eller av tommelhjultypen, avhengig av kravene i det spesielle systemet. Fortløpende operatørstatus avspeiler alltid den nyeste innstillingen av statusbryterne, men krever ikke noen handling av den mobile operatøren. Baseenheten er i stand til å oppnå den aktuelle operatørstatusen til enhver mobil enhet uten noen handling av den mobile operatøren. Og i tillegg kan aktuell status automatisk overføres til basen på hver PTT ID-overføring. Meldinger er status av transient natur. For å sende en melding, må den mobile operatøren aktivere en bryter og baseenheten vil automatisk vise meldingen hver gang den sendes. Imidlertid er baseenheten ikke i stand til å oppnå meldinger fra en mobil enhet, og heller ikke vil noen meldinger bli sendt avgårde med lydoverføringer. Ny operatørstatus og overføringer av meldinger kan sendes manuelt ved at operatøren overvåker den mottatte kanalen før overføring, eller kan bli sendt automatisk ved at kanalen undersøkes for trafikk før overføring.
Manuelle statusoverføringer innebærer en sekvens med enkle operasjoner. Denne typen status brukes i systemer der kanaldetektering er upraktisk eller umulig slik som i radiosystemer der ingen radiosignaler er tilgjengelige for detektering av kanalaktivitet. Når den mobile operatøren beslutter å overføre en status til baseenheten, innstiller han de riktige statusbryterne, og radioen anbringes automatisk i bølgetypen for overvåking. Han venter på at kanalen skal bli klar hvis den er opptatt, trykker så på en momentan sendebryter, og på det tidspunktet vil datapakken med statusinformasjonen bli overført straks, og baseenheten vil bekrefte mottak. Det er sørget for låsing slik at sammensatte sekvenser ikke vil oppstå hvis sendebryteren ikke er utløst.
Med automatisk status er ingen kanalovervåking fra operatøren nødvendig siden kanalen detekteres for pågående trafikk, data eller lyd. Hvis kanalen er opptatt, er data-overføringen sperret inntil kanalen klareres, når ei tilfeldig klokke vil starte og kanalen vil bli undersøkt for aktivitet når klokka går ut. Hvis kanalen fortsatt er opptatt, vil den tilfeldige klokkeperioden fortsette. Hvis kanalen er klar, vil datapakken med statusen bli overført til baseenheten, og en mottaksbekreftelse vil bli sendt tilbake til den mobile enheten. Dette forhindrer over-lapping av flere enheter som venter på overføring. Den valgfrie automatiske modusen for overvåking kan brukes i enhver statuskonfigurasjon. Meldinger sendes på den samme måten som operatørstatus unntatt når det brukes momentane brytere.
Det er tre modi for valgbar
status/melding-overføring med kodeplugg som er tilgjengelige i den mobile enheten: enkel uten mottaksbekreftelse, enkel med mottaksbekreftelse og sammensatt med mottaks-bekref telse. Den enkle uten mottaksbekreftelse er tiltenkt for enveissystemer uten muligheter for mottak. Hver gang en status eller meldingsoverføring startes av den mobile operatøren, overføres datapakken en gang, og det er ingen overføring av mottaksbekreftelse fra baseenheten.Dette er en global modus som er anvendelig på alle valg i den mobile enheten. Hvis ingen mottaksbekreftelse velges ut for statusmodusen , vil det således ikke bli mottaksbekreft-elser for noen datapakker. Siden det ikke blir sendt noen mottaksbekrefteiser for datatransaksjoner, kan det ikke bli noen tilbakemelding fra operatøren om den følgende over-føringen .
Den enkle modusen med mottaksbekreftelse tillater at alle status- og meldingsoverf«ringer blir bekreftet. Hvis "håndhilsingen" er vellykket, vil den mobile enheten lage en kort hørbar tone og indikere at statusen eller meldingen ble mottatt ved basen. Hvis "håndhilsingen" ikke var fullstendig, hvilket betyr at den mobile enheten ikke mottok bekreftelsen, vil en ikke-bekreftende indikator blinke og indikere for den mobile operatøren en dårlig overføringssekvens og tillate at operatøren gjenoppstarter en ny sekvens. Den mobile operatøren får således både positiv tilbakemelding og negativ tilbakemelding ved status- og meldingsoverføringer.
Den sammensatte enheten med modus for mottaksbekreftelse er identisk med den enkle med modus for mottaksbekreftelse unntatt at gjenoverføringer vil oppstå automatisk hvis den innledende overføringen var mislykket. Dette er en ytterst pålitelig driftsmåte. Hvis en mottaksbekreftelse fra baseenheten ikke mottas innenfor et tilfeldig tidsintervall, vil den mobile enheten automatisk detektere og gjenutsende statusdatapakken. Denne prosessen vil fortsette inntil en mottaksbekreftelse mottas eller et programmert antall gjenutsendinger har foregått. Som i den enkle enheten med modus for mottaksbekreftelse vil en kort hørbar tone alarmere den mobile operatøren om en vellykket sekvens.
Det er åtte mulige statusbryterinnganger for en mobil enhet. En vanlig konfigurasjon ville være et status-system med syv knapper der alle de syv statusbryterne er mekanisk låst. Hver gang en statusforandring er ønsket, trykker operatøren på den ønskede bryteren som vil låse seg i posisjonen og fjerne all foregående innstilling. Statusen kan bli automatisk overført ved det tidspunktet eller bli oppstartet av en niende bryter, den momentane sender-bryteren. For å sende den samme statusen, må operatøren bruke sendebryteren uavhengig av manuell eller automatisk overføring. Mange andre konfigurasjoner er mulige inkludert forskjellige kombinasjoner av valgbare oppkallingsbrytere med status. Statussystemet er også i stand til å støtte momentane meldingsbrytere sammen med låsende statusbrytere. Da meldingsbryteren er momentan, vil den overføre en forbigående melding. Hvis et system som innebærer mer enn en meldingsbryter er nødvendig, kan den mobile enheten ha opp til åtte unike meldinger. Meldingsbryterne er alle momentane brytere, og sendebryteren er derfor unødvendig. Et viktig særtrekk med statussystemet til de mobile enhetene er at hver av statusposisjonene er uavhengige.
Et annet viktig særtrekk med statussystemet til den mobile enheten i figur 5 er muligheten som operatøren på baseenheten har til å be den mobile operatøren om å oppdatere sin operatørstatus. Dette gjøres ved bruk av en kommando i baseenheten, hvilket vil få den ikke-mottaksbekreftende indikatoren til å bli aktivert ved den mobile enheten og signalisere til den mobile operatøren at han skal oppdatere sine operatørstatusbrytere.
Vekslende status er en statusfunksjon for generelle formål som gir et alternativ til eller en utvid-else av operatørstatusen. Dens drift er forskjellig fra operatørstatus ved at den mobile operatøren ikke kan starte opp en vekslende statusoverføring i grunnsystemet. I et system som inneholder det prioriterte alarmvalget, vil dataoverføringen av prioritert alarm også sende den aktuelle vekslende statusen. Da den vekslende statusen sendes sammen med prioritert alarm, kan statusen brukes som stedsinformasjon, utvidete prioritetsnivåer, trafikkbrytere osv. I disse situasjonene kan den vekslende statusen startes opp ved den mobile enheten. Det vekslende statusvalget krever det valgbare interface 154 i figur 5. Den mobile kodepluggen fjernes fra den mobile enheten og settes inn på det ytre interface 154. En stikkontakt med båndkabel plasseres mellom kodepluggsokkelen på den mobile enheten og en tilsvarende sokkel på interfacekortet. Data- og adresse-samleskinna på kodepluggen blir så multiplekset med vekslende status. Syv parallelle innganger og syv uavhengige parallelle utganger er fremskaffet med det vekslende statusvalget.
Baseenheten kan utspørre enhver mobil enhet om vekslende status. Basen er også i stand til å innstille enhver kombinasjon av mobile vekslende statusutganger. De syv statusinngangene kan forbindes til brytere som i operatørstatus og derved sørge for utvidete status-muligheter. I en konfigurasjon som bruker syv statusbrytere og syv meldingsbrytere, er meldingsbryterne momentane og statusbryterne er trykknapp-type eller låste. Når en melding overføres, blir statusen ikke sendt samtidig. Istedet vil baseoperatøren manuelt utspørre den mobile enheten, eller baseenheten kan programmeres til automatisk å gjenvinne den vekslende statusen når en melding er mottatt. Hvis de vekslende statusutgangene brukes som indikatorer i det samme systemet, kan indikatorene brukes som basestatus. Hvis vekslende status brukes til å representere fartøystatus, kan de syv inngangene forbindes med sensorer i fartøyet, f.eks. oljetrykk, drivstoff, temperatur osv.
Det prioriterte alarmvalget er uavhengig av de andre valgene og kan aktiveres i enhver mobil systemkonfigurasjon. Den prioriterte alarmen skal normalt aktiveres av en ytre bryter slik som nødbryter 158 i figur 5. Når den er aktivert, vil den normalt stengte bryteren utløse en sekvens av spesielle datapakkeoverføringer som har absolutt prioritet over alle andre funksjoner til mobile enheter. Den innledende prioriterte datapakken overføres øyeblikkelig uten hensyn til noen kanaldetekterende logikk. Hvis en mottaksbekreftelse ikke mottas innen et tilfeldig tidsintervall, vil den mobile enheten automatisk gjenutsende den prioriterte datapakken. Totalt 20 overføringer vil oppstå hvis ikke en mottaksbekreftelse mottas, i hvilket tilfelle operatøren kan gjenoppstarte en ny sekvens. En sekvens av overføringer vil stoppe straks ved mottak av mottaksbekreftelse. For sikkerhetsformål blir den mobile operatøren ikke opplyst om positiv eller negativ mottaksbekreftelse. Aktivering av den prioriterte alarmen vil utelukke alle andre datafunksjoner inntil en mottaks-bekref telse mottas eller sekvensen avsluttes. Når en prioritert alarm mottas ved baseenheten, vil displayet som indikerer det mobile enhetsnummeret blinke, og en alarm vil lyde. Baseenheten vil overføre hvilken som helst av to typer av mottaksbekreftende pakker bestemt ved programmer-ingen av kodepluggen. Den første typen er en normal mottaksbekreftelse som avslutter den prioriterte sekvensen i den mobile enheten. Den andre typen er en nødover-våkningspakke som vil avslutte den prioriterte sekvensen i den mobile enheten og vil så taste opp radiosenderen i en fast tidsperiode (10 sekunder i den foretrukne utformingen). Ved slutten av denne tidsperioden vil den mobile enheten sende enda en prioritert datapakke til basen og så slå over til den mottakende modusen . Baseenheten vil fortsette å sende datapakker med nødovervåking på denne periodiske måten inntil en klareringsoperasjon utføres av operatøren på baseenheten. Dette tillater at baseoperatøren kan lydovervåke aktiviteten på det mobile fartøyet i tilfelle en prioritert alarm. Den samme nødovervåkende datapakken som brukes til å aktivere senderen på en mobil enhet i modusen med prioritert alarm brukes til å inaktivere alle andre mobile sendere i systemet utstyrt med de mobile styringssystemene. Dette særtrekket sørger for en klareringskanal til enheten i den prioriterte modusen Hvis den mobile enheten i tillegg har operatørstatus, vil den statusen bli sendt til baseenheten sammen med prioritetstilstanden, med prioritetspakken inneholdende operatørstatusen. Hvis den mobile enheten har vekslende status, blir den statusen også sendt. Med denne egenskapen kan forskjellige prioritetsnivåer etableres innenfor et system. I tillegg vil den mobile enheten reagere på en unik kommando for å innlede en sekvens med prioritert alarm. Denne kommandoen kan sendes ut av baseenheten eller av en bærbar sender og således tillate sekundære nødsystemer der den mobile enheten brukes som en forsterker.
En valgbar oppkalling er tilgjengelig med den mobile enheten og er totalt uavhengig i drift og utvalg fra andre særtrekk. Hensikten med det valgbare oppkallings-systemet er å tillate private og/eller sikre lydover-føringer og pagineringsoperasjoner. Selektiv lydoppkalling utføres i den mobile enheten ved demping og ikkedemping av den mobile radiolyden. Disse operasjonene styres av forskjellige datapakker som har sin opprinnelse i den mobile enheten og baseenhetene. Baseenheten er i stand til å støtte flere samtidige modusen ved lydoppkalling.
Det er sørget for en driftsbølgetype med automatisk valgbar oppkalling, hvorved operatøren på baseenheten ganske enkelt slår inn enhetens, gruppas eller flåtestyrkens identifikasjonskode på terminalen og bruker mikrofonen som normalt. Den utvalgte enheten, gruppa eller flåtestyrken av mobile enheter vil automatisk ikke dempe lyden så lenge lydoverføringen varer og så dempe igjen.
Modusen for automatisk selektiv oppkalling sørger ikke for mottaksbekreftelse på grunn av at lyden følger den ikkedempende datapakken mens sendetasten holdes inne. Systemet er automatisk ved at baseoperatøren ikke trenger å trykke på en oppkallingsbryter for hver overføring.
En konfigurasjon med hovedbryter for en mobil enhet for selektiv oppkalling ville omfatte et oppkallingslys brukt i lydoppkalling og paginering for å indikere at baseenheten har signalisert til den enheten, unntatt i bølgetypen AUTO SEL CALL der oppkallingslyset ikke ville bli påvirket. En tilbakestillingsbryter, som ville være en bryter av momentan type, kan besørges for å slukke oppkallingslyset og igjen dempe lyden hvis den automatiske dempingen svikter. Det er sørget for en horn- og lysbryter av typen trykk-trykk som brukes til å kople inn hornet og lysene for eksterne alarmer. Det kan sørges for en bryte<r >for base, gruppe og flåtestyrke for å tillate innkodings-muligheter til den mobile enheten, og som er en del av modusen AUTO SEL CALL. Bryterne er fortrinnsvis mekanisk låst. Med disse tre bryterne kan den mobile operatøren selektivt med stemmen kalle opp basen, andre medlemmer av sin aktuelle gruppe, eller sin flåtestyrke. Hvis bryteren på basen velges ut, vil alle lydoverføringer fra den enheten bli dirigert til baseenheten. Baseenheten vil vise fram enhetsidentifikasjonskoden som i PTT ID valget, og ingen andre mobile enheter i systemet vil høre over-føringen. Hvis gruppebryteren velges, vil alle lydover-føringer fra den enheten bli hørt bare av medlemmer i den samme gruppa. Baseenheten vil vise fram gruppeidenti-fikasjonskoden, og ingen andre mobile enheter i systemet vil høre overføringen. Hvis bryteren for flåtestyrke velges, vil alle lydoverføringer fra den enheten bli hørt av medlemmer i den samme flåtestyrken, og baseenheten vil vise fram flåtestyrkens identifikasjonskode. Hvis bryteren for gruppe eller flåtestyrke velges, vil en lydoverføring fra den mobile operatøren vise fram gruppas eller flåtestyrkens ID-kode ved baseenheten. Imidlertid kan den mobile enhetens kodeplugg programmeres slik at sammenhengende datapakker sendes på slutten av hver gruppes eller flåtestyrkes lydoverføring for å tillate at baseenheten kan vise enhetskoden til den mobile enheten som sender. Med denne egenskapen programmert inn i kodepluggen, vil baseenheten sekvensielt vise gruppas eller flåtens kode fulgt av enhetskoden. En modus med mottaksbekreftelse ved lydoppkalling er tilgjengelig for operatøren på baseenheten som vil slå inn enhetens, gruppas eller flåtestyrkens identifikasjonskode til enhetene som skal kalles opp.Han vil så trykke inn en oppkallingsbryter, og en tilsvarende mobil enhet vil forsterke radiolyden, tenne oppkallings-lampa og aktivere enhver ekstern alarm, alarmere den mobile operatøren med en kort hørbar tone og sende en mottaks-bekref tende pakke til basen. Ingen mottaksbekreftende pakke vil bli sendt til ei gruppe eller en flåtestyrke. Denne modusen sørger ikke for automatisk gjendemping av lyden. Den mobile operatøren må manuelt gjeninnstille dempingen ved å trykke på en gjeninnstillingsbryter, ved å hekte av mikrofonen, eller ved å innlede en lydoverføring.
Når den valgbare oppkallingen til den mobile enheten brukes i et privat linjesystem, er tre viktige modi for demping tilgjengelige: AND, OR og ingen. Med DPL eller PL demping brukt i systemet og den mobile enheten i AND dempingsbølgetype, må både den riktige PL eller DPL koden og den korrekte identifikasjonskoden være til stede for å ikke dempe mottakerlyden. Når mikrofonen fjernes fra opphengsboksen eller overvåkingsbryteren er anbragt i over-våkingsstillingen, er all demping umuliggjort. Men hvis en individuell eller gruppekalling er ønsket fra basen til den mobile enheten uten å forstyrre andre mobile enheter i systemet mens en holder tilbake en PL-operasjon for generell kommunikasjon fra mobil til mobil enhet og mobil enhet til base, kan demping velges som en OR bølgetype. I OR bølgetypen vil lyden reagere på enten en valgbar oppkalling eller en riktig PL eller DPL kode. Hvis systemet skal brukes til eksterne alarmer og oppkallingslys, og alle enhetene skal høre alle overføringene med den riktige PL eller DPL koden, blir ingen demping utvalgt.
Det er to modi for paginering som er tilgjengelige for baseoperatøren som den mobile enheten kan reagere på. Den første modusen alarmerer ganske enkelt den mobile operatøren med en serie av hørbare toner, aktiverer hvilke som helst eksterne alarmer eller opp-kallingslampa. Ingen lyddemping eller ikkedemping blir utført. Baseoperatøren slår inn enhetens, gruppas eller flåtestyrkens identifikasjonskode til enhetene som skal pagineres. Han trykker så på en sidebryter, og den adresserte mobile enheten vil utføre den førnevnte handlingen og sende mottaksbekreftelse tilbake til basen. Pagineringsoperasjoner for gruppe og flåtestyrke vil ikke bli mottaksbekreftet. En andre modus for paginering er identisk i operasjon med den første bortsett fra at ingen hørbare toner vil bli laget.
Alle mobile enheter sørger for ny gruppetildeling ved en baseenhetoperatør. Baseoperatøren kan utspørre en hvilken som helst enhet om dens aktuelle gruppe-identifikasjonskode og kan også forandre den koden dynamisk. Da gruppekoden kan forandres dynamisk, kan gruppekoden brukes i noen systemer som en variabel identifikasjonskode. Når en mobil enhets gruppe-ID har blitt for-andret, vil enhver gruppeadressering av den enheten bli utført av det nye ID-nummeret.Når en mobil enhet forsterkes opp, anbringes gruppe-ID i enhetens kodeplugg i et minne med tilfeldig adgang. Baseenheten kan forandre denne koden i RAM ved bruk av en regrupperingskommando. Den mobile enheten vil alltid bruke den aktuelle gruppekoden i RAM for gruppeoperasjoner.
Alle mobile enheter er utstyrt med en "radiosjekk-funksjon". Denne aktiveres av baseoperatøren som slår inn ID-koden til den mobile enheten som skal sjekkes fulgt av en radiosjekkommando. Den mobile enheten vil så svare med en normal mottaksbekreftelse. Denne egenskapen kan brukes i systemdiagnoser eller for å teste tilgjengeligheten til den mobile operatøren.
En del av egenskapen med valgbar oppkalling tillater at baseenheten selektivt kan muliggjøre eller umulig-gjøre styring av lydoverføring til mobile enheter. Base-operatøren kan slå inn gruppas eller flåtestyrkens identifikasjonskode til enheten som skal koples inn eller ut. Han utfører så utkoplingskommandoen, og den utvalgte enheten eller enhetene vil bli sperret for videre lydoverføringer. Kommandoen har ingen innvirkning på dataoverføringer.
Det valgbare eksterne interface 154 sørger for all logikk og interfacing for å muliggjøre egenskapen med vekslende status og datakanalens utvelgingslogikk. Datakanalens utvelgingslogikk vil sette en mobil enhet i stand til å overføre alle data på spesielle utpekte kanaler. Dette gjøres ved hjelp av frekvensvalgbryteren på den mobile enhetens kontrollpanel. Det er sørget for en hørbar alarmmekanisme for å alarmere operatøren om et ugyldig kanalvalg hvis noen dataoverføringer innledes på en ugyldig kanal. Logikken kan være i stand til automatisk å gå tilbake til en utvalgt datakanal.
Figur 6 viser et flytskjema av RESTART-rutinen til baseenhetens dataprogram for mikrocomputeren 100 i figur 4 for utføring av oppfinnelsen. Programmet tastes inn på blokk 200 etter forsterkning, og oppstarting oppstår som illustrert ved 202. RAM, klokke, port og kodeplugg testes ved 204, og hvis en feil detekteres, vil en feilkode bli vist, som illustrert ved 206, hvoretter systemet venter på at gjenoppstaring skal innledes av operatøren som indikert ved 208. Hvis ingen feil detekteres, fortsetter rutinen isteden til blokk 210 og viser en startmelding på displayet 98 og går videre til 212 for å teste nærværet av programmodulen. Hvis valget av programmodulen eksisterer, går programflyten videre til blokk 214 og så til PROM PROGRAMMER HANDLER rutinen. Hvis det ikke ekstisterer noe PROM programmervalg, går rutinen videre til blokk 216 og 218 for å aktivere skriveren til å skrive en forutbestemt herald og logge informasjon. Rutinen overfører deretter styring til PSK RECEIVE rutinen.
Et flytskjema av PSK RECEIVE rutinen er vist i figur 7, som viser inngang til rutinen ved blokk 230. PSK demodulatoren slår øyeblikkelig inn på 232. PSK demodulatoren er en separat rutine for demodulasjon og deteksjon av det PSK modulerte signalet som beskrevet i en patent-anmeldt søknad innsendt av Timothy Burke og Scott Noble 7. des 1981 med serienummer 328,332 og overlatt til Motorola Inc. Hvis det genereres en forstyrrelse på et tastatur, fortsetter programflyten som indikert ved blokk 234 til KEYBOARD HANDLER rutinen vist ved 236. Ellers vil rutinen fortsette til blokk 238 for å teste eksistensen av PROM modulen, som hvis den er til stede, får programflyten til å fortsette til blokk 240 til PROM programmereren. Hvis ikke, fortsetter programflyten til blokk 242 for å teste sendebryteren PTT (push-to-talk). Hvis PTT-bryteren aktiveres, fortsetter programflyten til TRANSMIT HANDLER rutinen som indikert ved 244, og hvis den ikke aktiveres, fortsetter programflyten til blokk 246 for å teste den tilpassede retningen. Hvis resultatet av testen ved 246 er positivt, fortsetter programflyten til blokk 248 for å få utgangs-vektoren og så til 250 til den retningsangitte rutinen, ellers vil programflyten fortsette som vist til blokk 252 for å bestemme hvorvidt det har blitt detektert 112 bits og indikert en komplett datapakke. Hvis det ikke er 112 bits program, vil flyten fortsette til blokk 254 og returnere til PSK RECEIVE ved blokk 230. Hvis de 112 bitene har blitt detektert, fortsetter programflyten til blokk 256 til vindingsdetektoren for dekoding av det 112 bits kodete signalet og så til blokk 258 der den sykliske overskudds-sjekkoden beregnes og til 260 der den beregnede CRC sammenlignes med den detekterte CRC. Hvis resultatene av CRC-sjekken er negative, vil programflyten fortsette fra blokk 262 til 264 til begynnelsen av PSK RECEIVE rutinen ved 230. Hvis CRC-sjekken er positiv, fortsetter program-flyten som vist ved 266 til PACKET PARSING rutinen.
PACKET PARSING rutinen går inn i blokk 270 i figur 8A, og programflyten fortsetter til blokk 272 for å teste grensene til ID-adressene. Hvis adressen er utenfor grensene, fortsetter programflyten som vist ved 274 tilbake til PSK RECEIVE rutinen. Men hvis ID-adressen er innenfor de forutbestemte grensene lagret i minnet, vil program-flyten fortsette til blokk 276 der programmet vil teste for en gyldig operasjonskode (OP-kode), og hvis koden ikke er gyldig, vil rutinen returnere til PSK RECEIVE rutinen som vist ved 278. Hvis operasjonskoden er gyldig, fortsetter programmet til blokk 280 der programmet vil fortsette til den riktige modusen som bestemt ved operasjonskoden.Hvis OP-koden adresserer en modus for selektiv oppkalling, fortsetter programflyten til blokk 282, og så overføres programmet, som vist ved 284, til PSK RECEIVE rutinen. Hvis en modus for prioritert alarm adresseres av OP-koden, vil programmet fortsette til blokk 286 der funksjonen for prioritert alarm aktiveres, og som indikert ved 288, ut-føres sammenligningstesten for statusnøkkel. Hvis det ikke er noen sammenligning av statusnøkkel, fortsetter programmet til PSK RECEIVE rutinen som indikert ved 290, og hvis statusnøkkelen passer sammen, utføres funksjonen for prioritert alarm som vist ved 292, og rutinen fortsetter for å overføre styring tilbake til PSK RECEIVE rutinen som indikert ved 294. En mottaksbekreftende OP-kode vil få programmet til å fortsette til blokk 296 for å utføre den mottaksbekreftende funksjonen. Programflyten vil fortsette til 298 der programmet vil teste for å bestemme om det venter på en mottaksbekreftelse, og hvis ikke, fortsetter rutinen straks å overføre til PSK RECEIVE rutinen som vist ved 300, men hvis den venter på en mottaksbekreftelse, fortsetter programmet til blokk 302. I blokk 302 utføres mottaksbekreftende funksjoner og styring og overføres til PSK RECEIVE rutinen som vist ved 304. En aktuell gruppe-IP-kode vil få programflyten til å fortsette til 306, og som vist ved 308 utføres det igjen en test for venting, og hvis det er ingen venting, overføres program-flyten direkte til PSK RECEIVE rutinen som indikert ved 310. Ellers fortsetter programflyten til blokk 312 som ut-fører gruppefunksjonene og så overfører styring til PSK RECEIVE rutinen som vist ved 314. PACKET PARSING rutinen fortsetter fra figur 8A til figur 8B ved 316. Figur 8B indikerer ved 318 at hvis en PTT ID funksjon adresseres av OP-koden, vil programflyten fortsette fra 318 til 320 for å stoppe utvelging hvis utvelging oppstår og så til blokk 322 for å teste statusnøkkelen for en sammenlikning. Hvis ingen sammenlikning finnes, fortsetter programflyten straks til PSK RECEIVE rutinen som vist ved 324, og hvis en sammenlikning oppstår, utføres ID-funksjonene ved 326, og programmet overføres til PSK RECEIVE rutinen som vist ved 328. Hvis en vekslende statusfunksjon adresseres av OP-koden, fortsetter programmet til blokk 330 og så til 332 for å teste om programmet venter, og hvis det ikke oppstår noen venting, fortsetter programmet direkte til PSK RECEIVE rutinen som vist ved 334 og fortsetter ellers til blokk 336 for å teste om en utvelging er i gang. Hvis en utvelging er i gang, fortsetter programmet til POLL EXIT rutinen som indikert ved 338 og fortsetter ellers til blokk 340 for å utføre den vekslende statusfunksjonen, og fra det punktet overføres programstyringen til PSK RECEIVE rutinen som indikert ved 342. Hvis OP-koden adresserer en aktuell operatørstatusfunksjon, fortsetter programflyten direkte til blokk 344 og derifra til blokk 346 for å teste og bestemme om programmet venter. Hvis ingen venting oppstår, fortsetter programmet til PSK RECEIVE rutinen som indikert ved 348 og fortsetter ellers til blokk 350 for å teste og bestemme om en utvelging er igang. Hvis en utvelging er i gang, overføres programflyten til POLL EXIT rutinen som indikert ved 352 og fortsetter ellers til blokk 354 for å utføre den aktuelle operatørstatusfunksjonen, og overfører så programstyring tilbake til PSK RECEIVE rutinen som indikert ved 356. Til slutt vil en OP-kode som ber om en ny operatørstatusfunksjon (eller melding) overføre styring direkte til blokk 358 og så til blokk 360 der utvelgingen stoppes hvis det oppstår utvelging. Programflyten fortsetter da til blokk 362 der statusnøkkelen testes for sammenlikning. Hvis det ikke er noen statussammenlikning, overføres programflyten til PSK RECEIVE rutinen som indikert ved 368, og hvis en sammenlikning oppstår, utføres operatørstatusfunksjonen som vist ved 366, hvoretter programstyringen overføres til PSK RECEIVE rutinen som indikert ved 364.
KEYBOARD HANDLER rutinen er vist i figur 9A, 9B og 9C og slås inn ved hjelp av en avbrytelse på tastaturet som indikert ved blokk 370. KEYBOARD HANDLER rutinen ved 372 fortsetter straks for å få tak i nøkkelen som ble aktivert som indikert ved 374 og fortsetter å teste for PROM programmereren ved 376. Hvis svaret er ja, fortsetter programflyten å returnere fra avbrytelsen som indikert ved 382. I tillegg fortsetter programflyten fra 396 hvis resultatet er negativt ved 378 for å teste for klokke-oppstarting, og hvis det er positivt, fortsetter programflyten igjen å returnere fra avbrytelsen som indikert ved 382. Hvis resultatet av testen ved 378 er negativt, fortsetter programflyten til 380 der "system-testfunksjonen" undersøkes. Hvis resultatet er positivt, returnerer programflyten igjen fra avbrytelsen som indikert ved 382 og fortsetter ellers til blokk 384 for å bestemme den aktiverte nøkkelen som indikert ved blokk 384. Ved blokk 386 testes klareringsnøkkelen, og hvis den er positiv, klareres displayet som indikert ved 388, og programstyringen overføres til PSK RECEIVE rutinen som indikert ved 390. Ellers fortsetter programflyten til blokk 392. På dette punktet utføres en displayawentende test, og hvis den er positiv, overføres programstyringen til PSK RECEIVE rutinen som vist ved 394 og fortsetter ellers til blokk 396 for å teste om en PTT-kommando er i gang. Hvis den er positiv, returnerer rutinen til PSK RECEIVE rutinen som indikert ved 398 og fortsetter ellers til blokk 400 for å bestemme om en utvelging er i gang. Hvis en utvelging er i gang, overfører rutinen styring til PSK RECEIVE rutinen som indikert ved blokk 4 02, og ellers fortsetter program-flyten til blokk 404 og derfra til blokk 406 som indikert i figur 9B. Ved blokk 406 tester programmet for å se om en "systemtest" er i gang, og hvis resultatet er positivt, overføres programflyten til PSK RECEIVE rutinen som indikert ved 408, og ellers fortsetter programmet til blokk 410. Ved 410 tester programmet som indikert for en prioritert alarm i gang, og hvis resultatet er positivt, fortsetter programflyten til blokk 412 for å teste og bestemme om en funksjonstast hadde blitt aktivert. Hvis resultatet er negativt, overføres programflyten til PSK RECEIVE rutinen som indikert ved 414, og hvis det er positivt, fortsetter programflyten til blokk 416. Ved blokk 416 tester programmet for nødovervåkningsvalget, og hvis resultatet er negativt, overføres programstyringen til PSK RECEIVE rutinen som vist ved 418 og fortsetter ellers til blokk 420 der en test for den andre funksjonstasten utføres (to funksjonstaster er påkrevet for å aktivere en nødover-våkingskommando). Hvis resultatet er negativt, fortsetter programmet til blokk 422 der opptellingen av nødover-våkingen økes og så til PSK RECEIVE rutinen som indikert ved 424. Hvis resultatet av testen ved 420 er positivt, fortsetter programmet til nødovervåkingsoverføringen og overfører nødovervåkingspakken som indikert ved 426. Hvis testen av prioriteten i gang er negativ ved blokk 410, fortsetter programflyten direkte til blokk 428 der programtesten til terminalen venter på en mottaksbekreftende pakke. Hvis terminalen venter, fortsetter programmet til PSK RECEIVE rutinen som indikert ved 430 og fortsette<r >ellers, som vist ved 432, til blokk 434 vist i figur 9C. Ved blokk 4 34 tester programmet for en kommando i gang, og hvis det er en kommando i gang, fortsetter programmet nå til 448 der testen for en funksjonstast (som brukes til kommandoutførelse) utføres. Hvis resultatet av testen er negativt, overføres programflyten direkte til PSK RECEIVE rutinen som indikert ved 450 og fortsetter ellers til blokk 452 for å bestemme om systemet venter på utvelging. Hvis resultatet er positivt, fortsetter programflyten til blokk 454 for å overføre starten av utvelgingssekvensen og fortsetter ellers til blokk 456 for å bestemme om en "systemtest" er i gang. Hvis en "systemtestkommando" eksisterer, fortsetter programflyten til blokk 458 og forårsaker start av en "systemtest", og fortsetter ellers til en normal kommandooverføring som indikert ved blokk 460. Hvis testen av kommando i gang ved blokk 434 er negativ, vil program-flyten fortsette til blokk 436 og teste for en avventende funksjon. Hvis resultatet er positivt, indikeres programtesten for styreretningen ved 438, og hvis resultatet er positivt, henter programmet vektoren som indikert ved 440 og går så ut til den retningsbestemte adressen som indikert ved 442. Ellers, ved blokk 438, fortsetter programflyten til blokk 444 for å oversette den aktiverte tasten til en kommandovektor og går så ut av programmet gjennom kommando-vektoren som indikert ved 446. Hvis den funksjonsawentende testen ved 436 er negativ, vil programflyten fortsette til blokk 462 der tasten blir testet for en funksjonsnøkkel, og hvis den er positiv, vil programmet stille det funksjonsav-ventende flagget som indikert ved 464. Funksjonen vil bli vist ved 466, og så returnerer programflyten til PSK RECEIVE rutinen som indikert ved 468. Hvis resultatet av testen ved 462 er negativt, vil programflyten fortsette til blokk 470 der displaybufferen vil oppnås (siden nøkkelen på dette punktet er en numerisk inngang), og en ny nøkkel vil bli rotert i displaybufferen som indikert ved 474. Programmet fortsetter til 476 for å teste for en 3 siffers systemkonfigurasjon, og hvis den 3 siffers bølgetypen er til stede, fortsetter programflyten til 478 for å flytte koden inn i flåtestyrkens kodedisplaybuffer, til 480 for å skjule det viktigste sifferet fra displaybufferen, og så for å blokkere 482 for å klarere avventende flagg. Program-flyten fortsetter så til 484 der displayet oppdateres og overfører programstyring til PSK RECEIVE rutinen som indikert ved 486.
Figurene 10A, 10B og 10C viser et flytskjema ov COMMAND rutinen for baseenhetens dataprogram, og som indikert ved 492, føres det inn via en kommandovektor ved 490. Fra inngangspunktet 490 fortsetter så programflyten som indikert til en av flere mulige kommando modi .Hvis kommandoen er en kommando for grupperte modi , fortsetter programflyten til utvelgingen av grupperte bølge-typer ved 494 og oppnår displaybufferen som indikert ved 496. Programflyten fortsetter så til 498 der displaybufferen testes for gyldige grupper, og hvis resultatet er negativt, utfører den en feilutgang som indikert ved 500. Ellers innstilles en gruppert modus som vist ved 502, og programflyten fortsetter til PSK RECEIVE rutinen som indikert ved 504. Hvis en flåtestyrkes utvalgte bølgetype blir oppkalt, fortsetter programflyten direkte til 506 og så til blokk 508 for å oppnå bufferdisplayet, og så til blokk 510 for å teste for en gyldig flåtestyrkekode. Hvis resultatene av testen er negative, lager programmet en feilutgang som indikert ved 512 og fortsetter ellers til blokk 514 for å innstille flåtestyrkens modus °9 over-fører deretter programstyring til PSK RECEIVE rutinen som indikert ved 516. En overføringskommando vil få programstyringen til å fortsette direkte til blokk 518 og derfra til 520 der displaybufferen oppnås og testes for gyldig 1° som indikert ved 522.Hvis resultatene av testen er negative, utføres en feilutgang som indikert ved 524, og ellers fortsetter programflyten til blokk 526 for å få tak i hjelpedata. Programmet fortsetter så til blokk 528 for å oppnå kommandokoden, og til 530 for å forene OP-koden og dataene, og fortsetter så for å lagre resultatene i en overføringspakkebuffer som vist ved 532. Systemflaggene stilles inn eller klares ut som påkrevet som vist ved 534, og PL eller DPL og lyddemping utkoples som indikert ved 536. Kommandoordet blir så vist på displayet som indikert ved 538, og programflyten fortsetter til PSK RECEIVE rutinen som indikert ved 540 (venter på kommandoutførelse).
Kommando-subrutinen fortsetter fra figur 10A til figur 10B som indikert ved blokk 542. Hvis en gjenopp-kalling eller den neste kommandoen i køen oppstår, fortsetter programflyten til 546 for å få tak i den neste minneadressen som indikert ved blokk 544 og 548. Når den neste minneadressen er oppnådd, fortsetter programmet til 550 for å teste slutten av minnet. Hvis resultatet er negativt, fortsetter programmet til blokk 554 for å vise stabel- eller køposisjonen, og så til 556 for å få en returadresse. Programflyten fortsetter så til blokk 558 for tilpasning av retningen og går så til PSK RECEIVE rutinen som vist ved 560. Hvis resultatet av testen ved 550 er positivt, sørger programmet for at intet blir vist som indikert ved 552 og fortsetter som vist til blokk 566. Blokk 566 kan også koples inn ved en vektorretur som indikert ved 562, hvoretter det følger et display av enhetens ID indikert ved 564. I tillegg kan blokk 566 koples inn som et resultat av en først inn, først ut køkontroll bryterkommando som indikert ved 578, hvilket resulterer i bryting av styringsflagget som indikert ved 580 og et dsiplay av flaggets tilstand som indikert ved 582 fulgt av overføring til blokk 566 for å få en returadresse. Program-flyten fortsetter så til blokk 568 for tilpasset retning og overfører så programstyring til PSK RECEIVE rutinen som indikert ved 570. Kommandorutinen fortsettes i figur 10C som indikert ved blokk 584, der i fall en sekundær kommando oppstår, inngangen er ved 586, og programmet fortsetter for å vise FNC 2 som indikert ved 588, og innstiller så tastaturets vektorflagg som indikert ved blokk 590. Deretter oppnås returadressen ved 592 og venter på inntastingen ved hjelp av en utilpasset vektor ved 594. Når inntastingen har skjedd, overføres programflyt til PSK RECEIVE rutinen som indikert ved 596. Blokk 598 koples inn via vektorretur, og programflyten fortsetter til blokk 600 for å få tak i og overføre den inntastede nøkkelverdien, og fortsetter så til blokk 602 for å dirigere den sekundære kommanoen og så til 604 for å utføre den sekundære kommandoen eller funksjonen som er påkrevet. Programflyten overføres så til PSK RECEIVE rutinen som indikert ved 608.
Et flytskjema av kommandooverføringsrutinen for baseenhetens dataprogram er illustrert i figur 11A og 11B. Programmet går inn ved 610 og fortsetter til blokk 612 der lyd og PL og DPL koples ut. Programflyten fortsetter til en systemtest for å bestemme om den er opptatt som indikert ved 614, og hvis resultatet er positivt, viser program-displayet "hold" på displayet som indikert ved 616 og regner så ut en tilfeldig forsinkelse ved 618 og venter på at den opptatte skal bli klar som indikert ved 620. Programflyten fortsetter til blokk 620 for å få en opptatt returadresse og så til 624 for tilpasset retning, og fortsetter for å overføre programstyring til PSK RECEIVE
rutinen som indikert ved 626. Hvis resultatet av testen ved blokk 614 er negativt, går programflyten fram til blokk 628 for å innstille den opptatte linja og displayet. Programflyten fortsetter så til blokk 630 og kopler ut displayet og kopler inn overføringslinja og venter på den forprogrammerte systemforsinkelsen som indikert ved 632. Programflyten fortsetter så til blokk 640 der TRANSMIT subrutinen kalles opp og så til 642 for å logge over-føringen på skriveren og klare ut den opptatte linja. En test for utvelging utføres deretter ved blokk 644, og hvis resultatet er negativt, utføres en test for mottaksbekreftelse som indikert ved 646. Hvis resultatet av den testen er negativt, fortsetter programflyten til blokk 648 og klarer ut overføringsflaggene, og deretter, som indikert ved blokk 660 og 668 i figur 11B, overføres dataflyten til PSK
RECEIVE rutinen. Men hvis resultatet av testen for mottaksbekreftelse ved blokk 646 er positivt, fortsetter program-flyten til blokk 650 for å teste om dette er den første overføringen. Det bør også bemerkes at hvis testen ved 644 er positiv, fortsetter programflyten til blokk 650. Hvis resultatet av testen ved blokk 650 er negativt, går programflyten fram til 654 og forminsker en opptelling av gjenoverføringer og innstiller systemflaggene som indikert ved 656. Hvis resultatet av testen ved blokk 650 er positivt, vil opptellingen av gjenoverf©ringer bli for-håndsinnstilt som indikert ved 652. Programflyten vil så fortsette til blokk 656 for å innstille systemflaggene og derfra for å blokkere 662 som indikert ved blokk 658. En tilfeldig forsinkelse regnes ut ved blokk 662, og da oppnås returadressen som indikert ved 664. Programflyten fortsetter så til blokk 666 for tilpasset retning og til blokk 668, der programstyringen overføres til PSK RECEIVE rutinen.
Figur 12 viser et flytskjema av RETRANSMISSION rutinen til baseenhetens dataprogram. RETRANSMISSION rutinen går inn på 670, der returadressen oppnås, og fortsetter til blokk 672 for å teste opptellingen av gjen-overf©ringer som er lik null. Hvis den ikke er lik null» går programstyringen fram til 674 der opptellingen av gjen-overf©ringer minskes, og programflyten overføres da til COMMAND TRANSMIT rutinen som indikert ved 676. Men hvis resultatet av testen ved 672 er positivt, overføres programstyring til blokk 678 der det ikke-mottaksbekreftende flagget og systemflaggene innstilles, og til blokk 680 der "feilindikasjonen" blir vist. Programflyten fortsetter til blokk 682, der ikke-mottaksbekreftelse logges på skriveren og programmet fortsetter til blokk 684 for å teste og se om en utvelging er i gang. Hvis resultatet er negativt, overføres programflyt og fortsetter til PSK RECEIVE rutinen som indikert ved 690. Hvis resultatet av testen ved 684 er positivt, går opptellingen av utvelginger framover som indikert ved 686, og en utgang til POLL EXIT rutinen utføres som indikert ved 688.
Et flytskjema av POLL EXIT rutinen for baseenhetens dataprogram er vist i figur 13. POLL EXIT rutinen føres inn, som vist, ved 692 og programflyten fortsetter straks til blokk 694, der opptellingen av utvelginger testes for å bestemme om den er lik den forprogrammerte maksimale verdien. Hvis resultatet er positivt, stoppes utvelgingen som indikert ved 696 og programstyring over-føres til PSK RECEIVE rutinen som indikert ved 698. Hvis resultatet av utvelgingstesten ved 694 er negativt, fortsetter programflyten til blokk 700 og flytter fram ut-velgingens ID-nummer og fortsetter til blokk 7 02 for å sette opp datapakken og til 704 for å innstille systemflaggene. Programflyten fortsetter så til blokk 706 eller den tilpassede retningen og går ut til COMMAND TRANSMIT rutinen som indikert ved 708.
DATA TRANSMIT subrutinens flytskjema er vist i figur 14, og som indikert, føres subrutinen inn i blokk 710. Programflyten fortsetter straks til blokk 712 der den 32 bits datapakken oppnås, og da regnes CRC-koden ut ved blokk 714. Datapakken kodes så inn i overføringsbufferen som vist ved 716. Programflyten fortsetter så til blokk 718 der innledningskoden og synkronkoden oppnås og tilføyes til overføringsbufferen som indikert ved blokk 720. Hele datapakken overføres fra senderen ved bruk av PSK-modulasjon som indikert ved 722, og programstyringen returnerer fra subrutinen som indikert ved 724.
Figur 15 viser et flytskjema av PROM PROGRAMMER HANDLER rutinen for baseenhetens dataprogram. PROM PROGRAMMER HANDLER rutinen føres inn, som vist ved 730, og programstyringen fortsetter straks til 732 for å teste det indikerte valget. Hvis resultatet er negativt, utføres en feilutgang som indikert ved 734, og hvis resultatet av testen er positivt, går programflyten fram til blokk 736 for å få tastaturets nøkkel. Programflyten fortsetter så til blokk 738 der en test utføres for å bestemme om programmereren er tilkoplet, og hvis resultatet er negativt, overføres programstyringen til PSK RECEIVE rutinen som indikert ved 740. Men hvis resultatet er positivt, fortsetter programflyten til 742 der nøkkelen testes for å bestemme om det var en klareringsnøkkel. Hvis resultatet er positivt, klares displayet som indikert ved 744 og programstyringen overføres tilbake til blokk 736. Men hvis resultatet av testen ved 742 er negativt, vil programflyten fortsette til blokk 746 der nøkkelen testes for å bestemme om det er en funksjonsnøkkel. Hvis resultatet er at det er en funksjonsnøkkel, går program-flyten fram til blokk 748 der funksjonsbølgetypen innstilles og til 750 der PNC 3 indikasjon blir vist.
Program-flyten overføres så tilbake til 736. Hvis resultatet av funksjonsnøkkeltesten er negativt,fortsetter programmet til blokk 752 for å teste og bestemme hvorvidt en eller tre nøkler ble aktivert. Hvis resultatet er negativt, vises en feilindikasjon som indikert ved 754, og programflyten over- føres tilbake til blokk 736 som vist. Hvis resultatet av testen ved 7 52 er positivt, utføres en test ved 756 for å bestemme om den ene nøkkelen har blitt aktivert, og hvis resultatet er negativt, blir kodepluggen programmert som indikert ved 758, og programflyten fortsetter til blokk 760 for å lese og vise kodepluggen. Hvis resultatet av testen ved 756 er positivt, leses kodepluggen som indikert ved 760, og programflyten fortsetter tilbake til blokk 736.
Med henvisning til figur 16 er det vist et flytskjema av START-rutinen til den mobile enhetens dataprogram. Det bør straks bemerkes at START-rutinen kan tastes inn på fire inngangspunkter indikert som START ved blokk 780, PSKREC ved blokk 784, PSK ved blokk 788 og MAIN ved blokk 792. Ved inntasting av START-rutinen ved blokk
780 fortsetter programflyten direkte til 782 der portene og den eksterne samleskinna klares ut og kodepluggen leses. På dette punktet tillater PSK REC inngangspunktet ved 784 inngang til blokk 786 der programflyten fortsetter for å
stille inn den nødvendige dempingen. Etter blokk 786 tillater inngangspunktet PSK indikert ved 788 inngang til den neste posisjonen ved 790 som stiller inn PSK RECEIVER og START forstyrrelsene. Programflyten fortsetter så til blokk 794 som også kan tastes inn fra MAIN inngangspunktet indikert ved 792, der kanalovervåkingen utføres ved bruk av PSK RECEIVE rutinen. Programflyten fortsetter til blokk 796 der PTT-bryteren sjekkes for å bestemme om den er på, og hvis resultatet er positivt, går programmet ut til EXT-rutinen som indikert ved 798. Hvis testen ved 796 er negativ, går programflyten fram til blokk 800 der programmet tester for et bryterskift og får programstyringen til å overføre til TRANS-rutinen, EMERG-rutinen, PICHK-rutinen eller HUBCHK-rutinen, bestemt av hvilken type bryterskift som har
foregått, som indikert ved blokk 802. Hvis testen viser at ingen bryterskift er foretatt, sjekkes stoppeuret for å se om det har gått ut, som indikert ved 804, og hvis resultatet er positivt, overføres programstyringen til TlMCHK-rutinen som indikert ved 806. Hvis stoppeuret ikke har gått ut, fortsetter programflyten til 808 der en test for ordsynkrinisering utføres. Hvis ordsynkronisering eksisterer, fortsetter programflyten til blokk 812 der fasetvetydighet korrigeres i en databuffer. Programflyten vil da fortsette til blokk 814 der det mottatte dataordet sjekkes for å bestemme om alle de 112 bits er mottatt, og hvis resultatet er negativt, fortsetter programflyten til blokk 820 der den dataopererte squelchen sørger for demping. I tillegg, hvis testresultatet ved blokk 8 08 var negativt, ville programflyten fortsette til blokk 800 der en dataoperert squelch (slik som beskrevet i en patent-anmeldt søknad sendt 7. des 1981 av Scott Noble med serienummer 328,359 og overlatt til Motorola, Inc.) tester for nærvær av data, og hvis data detekteres, fortsetter programflyten til blokk 820 for å dempe lyden og overføre styring tilbake til blokk 792 som er MAIN inngangspunktet til rutinen. Hvis resultatet av testen ved 810 er negativt, vil programflyten fortsette direkte til blokk 792 og så direkte til blokk 794 som vist. Et positivt resultat i testen av blokk 814 vil resultere i at programflyten dirigeres til blokk 822 til dekodingsseksjonen av rutinen. Programflyten går så direkte fram til blokk 824 der alle forstyrrelser gjøres ugyldige og de 112 bits dataene dekodes. Programflyten fortsetter da til 826 der den sykliske overskuddssjekken bestemmer gyldigheten av dataene. Og hvis resultatet er negativt, overføres programstyringen fra blokk 827 til PSK-inngangen til rutinen ved 788. Hvis resultatet av testen ved 826 er positivt, fortsetter programstyringen til 828 der en test utføres for å bestemme om systemet er i nødbølgetypen. Hvis svaret er ja, fortsetter programflyten til blokk 830 der en sjekk utføres for nødovervåkingens OP-kode. Hvis resultatet er positivt, overføres programstyringen til EMRMON-rutinen som indikert ved 834 og ellers til PSK-inngangen til rutinen som indikert ved 832. Hvis resultatet av sjekken ved blokk 828 er negativt, overføres programflyten til blokk 836 der ID-adressen sjekkes for gyldighet, og et negativt resultat får programflyten til å bli overført til PSK-inngangen til rutinen, som indikert ved blokk 838. Hvis resultatet av testen ved 836 er positivt, fortsetter programflyten til blokk 840 der en sjekk utføres av OP-koden og argumentesjon mot kodepluggen for å bekrefte at enheten er programmert for å behandle det indikerte valget. Ved blokk 842 sjekker programmet for å bestemme om den indikerte funksjonen er mulig, og hvis resultatet er negativt, dirigeres program-flyten til PSK-inngangen til rutinen som indikert ved 844. Hvis resultatet er positivt, fortsetter programflyten til blokk 846 der funksjonen utføres og behov for mottaks-bekref telse av data sjekkes, som vist i blokk 848. Hvis resultatet er negativt ved blokk 848, går programflyten til blokk 852 der programstyringen vil bli overført enten til PSK eller PSK REC inngangen til rutinen avhengig av demping, som indikert. Hvis resultatet av testen ved 848 er positivt, vil et kvart sekunds venting oppstå før en over-føring av mottaksbekreftelse eller data tilbake til basen, som vist ved 850.
Figur 17 viser et flytskjema av EXT-rutinen til den mobile enhetens dataprogram og føres inn som vist ved 834. Programflyten fortsetter direkte til 856 der forstyrrelsene gjøres ugyldige og kodepluggen leses, og deretter tester programmet kodepluggdata ved 858 for å bestemme om enheten har PTT-styring. Hvis resultatet er positivt, fortsetter programflyten til 860 der PTT slås på, og så til blokk 862. Hvis resultatet av testen ved 858 er negativt, går programflyten direkte fram til blokk 862 der en omtrent 36 millisekunders venting oppstår for å tillate en sjekk av datasperrelinja. Datasperrelinja blir da sjekket som indikert ved 864, og hvis resultatet er positivt, overføres programflyten til blokk 882 som vist, der programmet venter på et PTT-signal i 180 millisekunder mens mottakeren dempes. Men hvis resultatet av sjekken ved blokk 864 er negativt, vil det lages en sjekk for tale-valget som vist ved blokk 870. Hvis resultatet av testen ved 870 er negativt, vil programflyten fortsette til blokk 868 og 872 der PTT vil bli sjekket for å bestemme om den er innstilt, og hvis resultatet er positivt, vil programflyten fortsette til blokk 882 som vist. Hvis resultatet er negativt, vil programflyten fortsette til blokk 874 der kodepluggen vil bli testet for å bestemme om en PTT ID skal genereres i begynnelsen, og hvis resultatet er positivt, oppnås de nødvendige statusbryterne og systemforsinkelsen startes, hvoretter ID sendes i begynnelsen av hver over-føring som indikert ved 876. Programflyten vil da fortsette til blokk 878 der kodepluggen sjekkes for å bestemme om en PTT ID skal sendes ved slutten av overføringen. I tillegg, hvis resultatet ved blokk 874 er negativt, vil program-flyten fortsette til blokk 878, og hvis resultatet av testen ved blokk 878 er positivt, vil bryterverdiene bli bestemt og systemet vil vente på at PTT-bryteren skal bli deaktivert, og slutten av overføringens ID vil bli sendt som indikert ned 880. Programflyten vil da gå fram, som vist, til blokk 882, hvoretter programflyten vil returnere til PSK REC inngangen av START-rutinen. Hvis resultatet av testen ved blokk 870 er positivt, sjekkes basens, gruppens og flåtestyrkens ID og brytere og systemforsinkelsen til-føyes ved 880, fulgt av sending av pakken og venting på et signal fra PTT om slutt på overføring. Programflyten fortsetter da til blokk 890 der dempepakken sendes uten system-forsinkelse fulgt av en test for oppkalling av gruppe eller flåtestyrke som indikert ved 892. Hvis resultatet ved 892 er negativt, vil programflyten gå direkte fram til blokk 882 som indikert, og hvis resultatet er positivt, vil programflyten overføres til blokk 878 for å bestemme om en ID for slutt på overføring bør sendes. Programflyten over-føres deretter fra blokk 882 til PSK REC inngangspunktet til START-rutinen som indikert ved 884.
Et flytskjema av TRANS/EMERG rutinen til den mobile enhetens dataprogram er vist i figur 18. Denne rutinen kan føres inn på fire punkter indikert som TRANS ved 894, EMERG ved 924, RETRAN ved 904 og EMREPT ved 932. Ved innføring av programmet ved TRANS indikert ved 894, fortsetter programflyten direkte til blokk 896 der forstyrrelsene gjøres ugyldige og kodepluggdataene leses, hvorpå en test utføres for å bestemme hvorvidt statusvalget er tillatt som indikert ved 898. Hvis resultatet er negativt, overføres programflyten til PSK-inngangen av START-rutinen som indikert ved 900, og hvis resultatet er positivt, går programflyten fram til 902. Ved 902 startes datasyklusen der et lavnivå settes inn på datasykluslinja for å indikere at status sendes, og opptellingen av over-føringer innstilles eller en venteperiode opprettes for å tillate kanalavsøking. Deretter vil programflyten fortsette til blokk 906, som kan føres inn fra blokk 904 i RETRAN inngangspunktet. Ved blokk 906 testes opptellingen for å bestemme om den er lik null, og hvis resultatet er positivt, vil lampa for ikke-mottaksbekreftelse bli aktivert som indikert ved 908, og programflyten vil over-føres til PSKREC-inngangen til START-rutinen som indikert ved 910. Hvis resultatet av testen ved 906 er negativt, hentes en tilfeldig tidsperiode som indikert ved 912 fulgt av en test av datasperrelinja ved 914. Hvis datasperrelinja er på, vil programflyten bli overført til PSK-inngangen til START-rutinen som indikert ved 916, og hvis linja ikke er på, vil statuspakken innstilles som indikert ved blokk 918. Programflyten vil da fortsette til blokk 920, der opptellingen vil bli minsket og pakken overført, og program-flyten vil bli overført til PSK REC inngangen til START-rutinen som indikert ved 922. Men hvis rutinen føres inn til EMERG inngangspunktet indikert ved 924, fortsetter programflyten direkte til blokk 926 der forstyrrelsene blir gjort ugyldige og kodepluggen leses. Programmet fortsetter da til blokk 928 der den prioriterte bølgetypen startes fulgt av start av datasyklusen og innstilling av opptellingen av overføringer ved oppretting av den påkrevde venteperioden som indikert ved 930. Programflyten går da fram til blokk 934, og dette punktet i programmet kan føres inn på inngangspunktet EMREPT som indikert ved 932. Ved blokk 934 vil opptellingen bli testet for å bestemme om den er lik null, og hvis den er det, vil den prioriterte bølge-typen bli stoppet som vist ved 936, og programflyten vil bli overført til PSK REC inngangen til START-rutinen som indikert ved 910. Hvis opptellingen ikke er lik null, vil programflyten gå fram til blokk 938 der den tilfeldige tidsperioden hentes fram fulgt av innstilling av den prioriterte pakken som indikert ved 940. Programflyten vil da fortsette til blokk 920 der opptellingen vil bli minsket og pakken overført fulgt av en overføring av programstyring til PSK REC inngangen på START-rutinen som indikert ved 922.
Med referanse til figur 19 er det vist et flytskjema av P1CHK/HUBCHK rutinen til den mobile enhetens dataprogram. Denne rutinen kan føres inn på to punkter: P1CHK inngangspunktet indikert ved 942 og HUBCHK inngangspunktet indikert ved 966. Hvis rutinen føres inn ved 942, vil programflyten fortsette direkte til blokk 944 og 946 der bryteren vil bli testet for å bestemme om den har skiftet fra null til en. Hvis resultatet av testen av bryteren ved 946 er negativ, vil programflyten overføres til MAIN-inngangen til START-rutinen som indikert ved 948, og hvis resultatet av testen er positivt, vil programflyten gå fram til blokk 950 der forstyrrelsene vil bli gjort ugyldige og kodepluggen vil bli lest. Programflyten vil da fortsette til blokk 952 der bryteren for gjeninnstilling av oppkalling vil bli sjekket for å bestemme om den er på. Hvis bryteren er på, vil releer og oppkallingslys bli klaret ut som indikert ved 974, og programstyringen vil bli overført til PSK REC inngangen til START-rutinen som indikert ved 976. Men hvis resultatet av testen ved 952 er negativt, vil programflyten fortsette til blokk 954 og 95<6 >der statusbryterne vil bli sjekket for å bestemme om det har vært en skifting. Hvis ingen skifting har oppstått, vil programflyten overføres som indikert til 964, der en test utføres for å bestemme om autostatusvalget er tilgjengelig-Hvis resultatet er positivt, overføres programstyring til TRANS-rutinen som indikert ved 960. Hvis resultatet av testen ved 958 er negativt, vil programstyringen fortsette til blokk 962 der demping vil bli åpnet for å tillate kanalovervåking. Programflyten vil da bli overført til PSK-inngangen til START-rutinen som indikert ved 964. Hvis rutinen føres inn på HUBCHK inngangspunktet indikert ved 966, fortsetter programflyten direkte til 968 der forstyrrelsene gjøres ugyldige. Opphengsboksen vil da bli sjekket for å bestemme om den er tatt av kroken som indikert ved 972. Hvis resultatet av testen ved 972 er negativt, vil programflyten fortsette direkte til 976, og hvis resultatet er bekreftende, vil releene og oppkallings-lysene bli klaret ut som indikert ved 974. Programstyringen vil da overføres til PSK REC inngangen til START-rutinen 976.
Figur 20 viser et flytskjema av TlMCHK-rutinen til den mobile enhetens dataprogram og føres inn som vist ved 978. Programflyten fortsetter til blokk 980 der forstyrrelsene blir gjort ugyldige, og programmet dirigerer programstyring til den riktige rutinen som indikert ved blokk 982,984,986 og 988. Figur 21 viser flytskjemaet av EMR MON rutinen til den mobile enhetens dataprogram, og denne rutinen føres som indikert inn til blokk 990. Programflyten fortsetter direkte til blokk 992 der argumentet sjekkes for å bestemme om det er lik null, og hvis resultatet er positivt, fortsetter programflyten direkte til blokk 994 der den prioriterte bølgetypen stoppes hvis den er på, og så til blokk 996 der programstyringen overføres til PSK REC inngangen til START-rutinen. Hvis resultatet av testen ved 992 er negativt, sjekkes den prioriterte modusen for å bestemme om den er på som indikert ved 998. Hvis den prioriterte bølgetypen ikke er på, blir PTT utkoplet som indikert ved 1202, og hvis den er på, blir PTT slått på som indikert ved 1000. Programstyringen går da fram til blokk 1004 der den variable COUNT innstilles til å bli lik argumentet, hvoretter opptellingen minskes ved 1008. I tillegg kan rutinen føres inn på dette punktet ved inngangspunktet MONRPT vist ved blokk 1006. Programflyten vil gå fram fra blokk 1008 til blokk 1010 der opptellingen vil bli testet for å bestemme om den er lik null. Hvis den ikke er lik null, vil programflyten overføres direkte til blokk 1014, og hvis den er lik null, vil programflyten fortsette til blokk 1012 der PTT blir slått av. Programstyringen vil da overføres til PSK-inngangen til START-rutinen som indikert ved blokk 1014.
Et flytskjema av TONES-rutinen til den mobile enhetens dataprogram er vist i figur 22. Rutinen føres inn ved blokk 1020 som indikert, og programflyten fortsetter direkte til blokk 1022 der toneopptellingen minskes. COUNT sjekkes deretter for å bestemme om den er lik null ved 1024, og hvis resultatet er positivt, overføres programstyringen til PSK-inngangen til START-rutinen som indikert ved 1026. Hvis testen ved 1024 er negativ, fortsetter programflyten til blokk 1028 der stoppuret stilles inn, hvoretter alarmtonen genereres, som indikert ved 1030. Programflyten fortsetter da til blokk 1032 der overføringsbryteren sjekkes for å bestemme om den er på, og hvis den er det, hopper programflyten tilbake til blokk 1030 der en tone blir generert. Hvis overføringsbryteren ikke er på, fortsetter programflyten til blokk 1034 der en venting på 300 millisekunder oppstår før retur til START-rutinen på enten PSK eller PSK REC inngangen.
Til oppsummering er det blitt beskrevet en forbedret datastyringssvstsr! for generelle formål, som er spesielt tilpasset for bruk i radiokommunikasjonssystemer med sammensatte enheter og har muligheter til både lyd- og datakommunikas jon.
Mens ei foretrukken utførelsesform av oppfinnelsen har blitt beskrevet i detalj, bør det gå fram at mange modifikasjoner og variasjoner er mulige, hvorav alle faller innenfor rammene til oppfinnelsen.
APPENDIX I
Det følgende er et minnelager for dataprogrammet for baseenheten MC6803 mikrocomputer i samsvar med oppfinnelsen.
APPENDIX II
Det følgende er et minnelager for dataprogrammet for den mobile enheten MC3870 i samsvar med oppfinnelsen.
Claims (16)
1. Kommunikasjonssystem for kommunikasjon over et kommunikasjonsmedium, med i det minste en primærstasjon (50, 52) og et flertall av fjerne stasjoner (60, 62, 64); hver fjerne stasjon har en forhåndsbestemt stasjonsadresse lagret i et stasjonsadresseregister (152), og er anordnet for å sende et komandosignal, der
hver primærstasjon omfatter: organ for utsending av et kommandosignal til de fjerne stasjonene i respons til et aktiveringssignal, som inneholder en operasjonskode (24-28) og en stasjonsadresse; genereringsorgan for et aktiveringssignal i respons til mottak av et kommandosignal fra en fjern stasjon; og genereringsorgan for et aktiveringssignal i respons til start av en transmisjon til en fjern stasjon; og der hver fjerne stasjon omfatter:
organ for utsending av et kommandosignal som inneholder en operasjonskode og en stasjonsadresse til den primære stasjonen i respons til et aktiveringssignal,
genereringsorgan for et aktiveringssignal i respons til mottak av et kommandosignal fra den primære stasjonen;
genereringsmidler for et aktiveringssignal i respons til start av en transmisjon til den primære stasjonen,
karakterisert ved at:
stasjonsadressen inneholdt i kommandosignalet som blir utsendt av den primære stasjonen omfatter et adressefelt som i sin helhet er anvendt til individuell adressering av hver fjerne stasjon og en indikasjon på hvor mye av adressefeltet som skal sammenliknes, og den fjerne stasjonen har videre: organ for sammenligning av tilsvarende deler av dens egen adresse (152) med så mye av adressefeltet som indikert, og organ for utføring av den mottatte operasjonskoden dersom de sammenliknede delene passer, idet både den primære stasjonen og den fjerne stasjonen, samt grupper av stasjoner er adressert via samme adressefelt.
2. Kommunikasjonssystem i samsvar med krav 1,
karakterisert ved at enhetene er adressert
på basis av BCD-sifre (24-28).
3. Kommunikasjonssystem i samsvar med krav 1-2, karakterisert ved at indikasjonen viser mest eller minst signifikante bits for sammenligning.
4. Kommunikasjonssystem i samsvar med krav 1-3,
karakterisert ved at adressefeltet omfatter deler (24-28) som betegner flåte, hhv. gruppe av stasjoner.
5. Kommunikasjonssystem i samsvar med krav 1-4,
karakterisert ved at sammenlikningen blir utført med deler som ikke inneholder et reservert jokertegn.
6 Kommunikasjonssystem i samsvar med noe foregående krav, karakterisert ved at kommandosignalet som utsendes ved den primære stasjonen videre inneholder et argument (16-23) som i samband med operasjonskoden definerer en kommando.
7. Kommunikasjonssystem i samsvar med noe foregående krav, karakterisert ved at den fjerne stasjonen videre omfatter: et stasjonsadresseregister for lagring av en variabel adresse; behandlingsorgan for detektering av når et adressesiffer i adressen i det mottatte kommandosignalet er en reservert karakter, og organet for sammenlikning som sammenlikner adressedelen i det mottatte kommandosignalet med tilsvarende deler av den tidligere etablerte adressen lagret i stasjonadresseregistret når adressesifret er den reserverte karakteren og sammenlikner adressedelene i det mottatte kommandosignalet til den variable adressen lagret i stasjonsadresse-registret når adressesifret ikke er den reserverte karakteren.
8. Kommunikasjonssystem i samsvar med noe foregående krav, karakterisert ved videre å omfatte: ved den primære stasjonen organ for automatisk utsending av et første kommandosignal som inneholder en forhåndsbestemt operasjonskode og adressen av den ønskede mottaksenheten i respons til start av en taleoverføring, ved den fjerne stasjonen organ for mottak av det utsendte første kommandosignalet; og organ for detektering av når adressedelen inneholdt i mottatte første kommandosignal er samme som den på forhånd etablerte adressen lagret i
stasjonsadresseregistret og øker mottakerens styrke som respons til dette.
9. Kommunikasjonssystem i samsvar med krav 8,
karakterisert ved videre å omfatte: ved den primære stasjonen organ for automatisk utsending av et andre kommandosignal som inneholder en andre operasjonskode i respons til avslutningen av taletransmisjonen; ved den fjerne stasjonen organ for mottak av det utsendte andre kommandosignalet; og organ for å øke styrken på mottakeren i respons til dette.
10. Kommunikasjonssystem i samsvar med noe av foregående krav, karakterisert ved videre å omfatte: ved den utsendende stasjonen organ for utsending av et kommandosignal som inneholder en på forhånd etablert alarmkode, og adressen til mottaksstasjonen; ved den mottagende stasjonen organ for å motta det utsendte kommandosignalet og sende en kvitteringskommandopakke i respons til dette, med en på forhånd etablert operasjonskode og den utsendte stasjonens adresse; organ for aktivering av en alarm ved den mottatte stasjonen i respons til mottak av det utsendte kommando-signalet.
11. Kommunikasjonssystem i samsvar med krav 10,
karakterisert ved videre å omfatte ved den utsendende stasjonen, organ for retransmisjon av kommandopakken et forhåndsbestemt antall ganger til kvitteringspakken blir mottatt.
12. Kommunikasjonssystem i samsvar med noe foregående krav, karakterisert ved at kommandosignalet videre inneholder en synkroniseringsdel.
13. Kommunikasjonssystem i samsvar med noe foregående krav, karakterisert ved at et flertall av sentrale primær-stasjoner deler opp sitt kontroll-ansvar ved oppdeling av adresseområdet.
14. Kommunikasjonssystem i samsvar med noe foregående krav, karakterisert ved at den fjerne stasjonen videre omfatter organ for inngivelse av statusdata ved den fjerne stasjonen og generering av en kommandopakke med statusargument som inneholder de inngitte data, og organ for generering av et aktiveringssignal, idet et kommandosignal som inneholder kommandopakkestatusargumentet blir utsendt.
15. Kommunikasjonssystem i samsvar med krav 14,
karakterisert ved at hver primære stasjon videre omfatter et lagerorgan for lagring av hver av statusargumentene etter hvert som de mottas fra de fjerne stasjonene.
16. Kommunikasjonssystem i samsvar med noe foregående krav, karakterisert ved at primære og fjerne stasjoner videre omfatter organ for utsending av datapakker som inneholder en pakkeidentifikasjonsliste og uformaterte data etter utsending av et kommandosignal.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US40268982A | 1982-07-28 | 1982-07-28 | |
| PCT/US1983/000976 WO1984000655A1 (en) | 1982-07-28 | 1983-06-24 | General purpose data control system |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| NO841207L NO841207L (no) | 1984-03-27 |
| NO173799B true NO173799B (no) | 1993-10-25 |
| NO173799C NO173799C (no) | 1994-02-02 |
Family
ID=23592958
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| NO841207A NO173799C (no) | 1982-07-28 | 1984-03-27 | Datastyringssystem for generelle formaal |
Country Status (13)
| Country | Link |
|---|---|
| EP (1) | EP0115507B1 (no) |
| JP (1) | JPS59501527A (no) |
| KR (1) | KR890000104B1 (no) |
| AU (1) | AU559854B2 (no) |
| CA (1) | CA1214219A (no) |
| DE (1) | DE3382094D1 (no) |
| DK (1) | DK175019B1 (no) |
| IL (1) | IL68988A (no) |
| IT (1) | IT1168620B (no) |
| MX (1) | MX153264A (no) |
| MY (1) | MY103541A (no) |
| NO (1) | NO173799C (no) |
| WO (1) | WO1984000655A1 (no) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA1230648A (en) * | 1984-07-13 | 1987-12-22 | Gerald P. Labedz | Cellular voice and data radiotelephone system |
| DE3436696A1 (de) * | 1984-10-06 | 1986-04-10 | Robert Bosch Gmbh, 7000 Stuttgart | Fertigungsverfahren fuer aus einem basisteil und einem oder mehreren loesbar damit verbundenen geraeteteilen bestehende elektrische geraete |
| US4943978A (en) * | 1985-11-27 | 1990-07-24 | Hughes Aircraft Company | Digital interface unit |
| EP0247144A1 (en) * | 1985-11-27 | 1987-12-02 | Hughes Aircraft Company | Digital data interface unit |
| AU5589086A (en) * | 1986-03-25 | 1987-10-20 | Motorola, Inc. | Method and apparatus for controlling a tdm communication device |
| JPS6399662A (ja) * | 1986-10-16 | 1988-04-30 | Oki Electric Ind Co Ltd | 自動車電話装置の回線切替制御方式 |
| US5142693A (en) * | 1988-08-22 | 1992-08-25 | Motorola, Inc. | Data capable radio communication console |
| EP0435582A3 (en) * | 1989-12-29 | 1992-07-15 | Motorola, Inc. | Supervisory control allocation method and apparatus |
| JPH09501030A (ja) * | 1993-08-02 | 1997-01-28 | インターナショナル・スタンダード・エレクトリック・コーポレーション | ダイナミック無線通信システム |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4027243A (en) * | 1975-05-12 | 1977-05-31 | General Electric Company | Message generator for a controlled radio transmitter and receiver |
| JPS5287904A (en) * | 1976-01-19 | 1977-07-22 | Nippon Telegr & Teleph Corp <Ntt> | Moving communication circuit assignment system |
| NL7607300A (nl) * | 1976-07-02 | 1978-01-04 | Philips Nv | Automatisch radio-telefoniesysteem. |
| US4131849A (en) * | 1976-10-21 | 1978-12-26 | Motorola, Inc. | Two-way mobile radio voice/data shared communications system |
| US4161718A (en) * | 1977-06-20 | 1979-07-17 | Motorola Israel Ltd. | Supervisory control system |
| US4251865A (en) * | 1978-12-08 | 1981-02-17 | Motorola, Inc. | Polling system for a duplex communications link |
| US4399555A (en) * | 1980-04-28 | 1983-08-16 | Bell Telephone Laboratories, Incorporated | Cellular high capacity mobile radiotelephone system with fleet-calling arrangement for dispatch service |
-
1983
- 1983-06-14 IL IL68988A patent/IL68988A/xx not_active IP Right Cessation
- 1983-06-24 EP EP83902482A patent/EP0115507B1/en not_active Expired - Lifetime
- 1983-06-24 WO PCT/US1983/000976 patent/WO1984000655A1/en not_active Application Discontinuation
- 1983-06-24 DE DE8383902482T patent/DE3382094D1/de not_active Expired - Lifetime
- 1983-06-24 JP JP58502547A patent/JPS59501527A/ja active Granted
- 1983-06-24 AU AU18219/83A patent/AU559854B2/en not_active Expired
- 1983-07-05 CA CA000431838A patent/CA1214219A/en not_active Expired
- 1983-07-26 IT IT48751/83A patent/IT1168620B/it active
- 1983-07-27 MX MX198181A patent/MX153264A/es unknown
- 1983-07-28 KR KR1019830003561A patent/KR890000104B1/ko not_active IP Right Cessation
-
1984
- 1984-02-29 DK DK198401298A patent/DK175019B1/da not_active IP Right Cessation
- 1984-03-27 NO NO841207A patent/NO173799C/no unknown
-
1988
- 1988-07-15 MY MYPI88000785A patent/MY103541A/en unknown
Also Published As
| Publication number | Publication date |
|---|---|
| AU559854B2 (en) | 1987-03-19 |
| EP0115507A1 (en) | 1984-08-15 |
| MX153264A (es) | 1986-09-02 |
| JPH0515089B2 (no) | 1993-02-26 |
| KR840005631A (ko) | 1984-11-14 |
| EP0115507A4 (en) | 1985-04-03 |
| DK175019B1 (da) | 2004-04-26 |
| AU1821983A (en) | 1984-02-23 |
| JPS59501527A (ja) | 1984-08-23 |
| KR890000104B1 (ko) | 1989-03-07 |
| CA1214219A (en) | 1986-11-18 |
| NO173799C (no) | 1994-02-02 |
| DK129884A (da) | 1984-03-27 |
| DE3382094D1 (de) | 1991-02-07 |
| IT8348751A0 (it) | 1983-07-26 |
| IT1168620B (it) | 1987-05-20 |
| DK129884D0 (da) | 1984-02-29 |
| WO1984000655A1 (en) | 1984-02-16 |
| IL68988A0 (en) | 1983-10-31 |
| EP0115507B1 (en) | 1990-12-27 |
| MY103541A (en) | 1993-07-31 |
| NO841207L (no) | 1984-03-27 |
| IL68988A (en) | 1986-08-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| NO169415B (no) | Datasignaliseringssystem | |
| DK170085B1 (da) | Fremgangsmåde til nødopkald i et kommunikationssystem | |
| US4636791A (en) | Data signalling system | |
| US4594591A (en) | General purpose data control terminal | |
| WO1990011654A1 (en) | Paging terminal apparatus with user selectable page forwarding capability and methodology therefor | |
| NO173799B (no) | Datastyringssystem for generelle formaal | |
| NO169416B (no) | Datastyringsterminal for generelle formaal | |
| NO168079B (no) | Fremgangsmaate for noedoppkall i et kommunikasjonssystem for talekommunikasjon over et kommunikasjonmedium. | |
| US4591851A (en) | General purpose data control system | |
| JPH06189028A (ja) | トーン信号受信装置 |