Mobil radiobruk betyr å bevege seg ut av huset til fots eller på annet vis ta seg inn i terrenget og sette opp en radiostasjon der. Dette er hyggelig, og man får mindre bakgrunnsstøy enn hva man opplever i et boligstrøk,
(c) Anders Fongen, desember 2024
I en tidligere bloggpost demonstrerte jeg hvor mye radiostøy som finnes i et boligstrøk, og hvordan denne støyen skaper en kraftig reduksjon i mottakskvalitet. Ved å operere radioutstyret et stykke unna bebodde områder (samt høyspenningsledninger, kringkastingsmaster m.m.) kan man oppnå bedre forbindelser, kanskje med enklere utstyr med mindre strømforbuk og lavere vekt. Mobil/portabel operasjon byr på interessante tekniske utfordringer, især dersom alt utstyret skal bæres langt, dessuten vil betjening og gjennomføring av samband påvirkes av temperatur, vind, lys og nedbør. Det er f.eks. ikke enkelt å operere en morsenøkkel med frosne fingre.
Det finnes mange radiomodeller som egner seg for mobil operasjon, de har ofte lav utgangseffekt (kalles QRP), er lette og billige. Noen har innebygget ladbart batteri, andre kan koples til et lite og lett 12 volts batteri. Selv har jeg to radioer som er egnet for mobil og portabel operasjon, Yaesu FT-817 og Xiegu G90.
Antennen er den mest interessante komponenten. Den kan være en enkel ledning, eller en mer omstendelig direktiv antenne. Her spiller prisen inn, i tillegg til vekt og hvor komplisert det er å rigge den til.
En ledning er en billig og bra antenne, men du trenger festepunkter så høyt som mulig. I en skog kan du feste ledningen i høye trær, men en skog betyr også mer skjerming og dårligere utbredelse av radiobølgene. En teleskop fiskestang kan være 5 meter lang og enkel å transportere, men toppen er så fleksibel at den bare kan bære en ganske liten vekt. Den trenger en festeanordning, f.eks. et jordspyd for å kunne stå vertikalt. Evt. kan den bindes til en sykkel eller støttes opp med ski eller staver. Om du blir uavhengig av å ha trær å henge antennen i kan du dra høyt til fjells og dra nytte av åpent terreng.
På nettet fant jeg denne antennen som vekket min interesse. Jeg har ikke sett noe navn på den, men den ser slik ut og koster 25-30 euro i diverse nettbutikker:
Enkel teleskopantenne med tilhørende jordspyd
Delene som er vist er ikke i proporsjonal størrelse. Den røde boksen er kun et mekanisk feste for jordspydet (ca. 25 cm langt) , teleskopantennen (5,5 meter lang) og antennekontakten. Skjermen på antennekontakten er koplet til jordspydet og senterlederen til teleskopantennen. Det er ingen tuner eller un-un i den røde boksen. Antennen avtemmes til en frekvens ved å trekke ut teleskopantennen til riktig lengde, og den medfølgende radialen (vist nederst på bildet) festes i jordspydet og strekkes ut langs bakken.
En vertikalantenne som kan reguleres i høyden opp til 5,5 meter kan forventes å fungere godt på frekvensbåndene 14 MHz og høyere, altså 20- 18-, 15-, 12- og 10-meterbåndet, kanskje også 6-meter båndet. Vi skal måle og finne ut.
Dette er en enkel konstruksjon, og jeg likte at jordspydet også fungerer som stativ for antennen. I praksis har det vist seg at det på fjellet kan være litt vanskelig å finne jordsmonn som er fast og dypt nok for å gi en stabil plassering. En hammer el.lign. kan komme til nytte, spesielt om vinteren.
Avstemningen av antenne skjer enklest ved å kople til en antenneanalysator (jeg bruker Nano-VNA til dette formålet) og trekke antennen helt ut. Ved maskimal lengde har antennen en tydelig resonans på ca. 12 MHz, og ved trinnvis forkorting av antennen kan en brukbart lav SWR oppnås på de lavere frekvensene (14-18 MHz).
Ved høyere frekvenser er avstemningen av antenne noe mer uklar, fordi resonansområdene blir flere og tettere. Det var ikke mulig å oppnå en lav SWR på 12- og 10-meterbåndet med den ene radialen som fulgte med, men uten radialer lot dette seg gjøre. Derimot fungerer antennen dårligere uten radial på lave frekvenser.
Antennen fungerer faktisk flott, jeg oppnådde kontakt på morse med Costa Rica (9000 km unna) på 28 MHz med en utgangseffekt på kun 5 watt! Da hadde jeg plassert meg litt inne på fjellet mellom Lillehammer og Nordseter.
Flere radialer
Det ble gjennomført målinger av SWR med ulike radialer tilkoplet antennen. Som bildet viser er den medfølgende radialkabelen utstyrt med en 10mm ringkabelsko som tres over gjengene til jordspydet. En ekstra radial av samme lengde (5,5 meter) ble laget og testet uten forbedring. Derfor ble kortere radialer også laget og testet.
Det som viste seg å gi et balansert og godt resultat, dvs. lav SWR på frekvensene 14, 18, 21, 25, 28 og 50 MHz, var tre radialer på 5,5, 3,5 og 2,7 meter. En SWR-verdi under 2.0 ble oppnådd på alle de nevnte frekvensene. Her vises bilder av antenneoppsettet, og måleresultatene på hver av de seks frekvensene. Se bort fra Smit-chart mønsteret på skjermbildene, de burde ikke ha vært der.
Antennens utseendeNærbilde av antennerotenBest oppnådde SWR-verdi ved 14 MHz: 1,5Best oppnådde SWR-verdi ved 18 MHz: 1,6Best oppnådde SWR-verdi ved 21 MHz: 1,24Best oppnådde SWR-verdi ved 25 MHz: 1,2Best oppnådde SWR-verdi ved 28 MHz: 1,6Best oppnådde SWR-verdi ved 50 MHz: 1,73
Konklusjon
Denne antennen (som ikke har noe navn) finnes på diverse nettbutikker, jeg kjøpte den fra Aliexpress. Etter å ha lett etter praktiske antenner for mobil bruk en stund, har jeg nå funnet det jeg lette etter. Denne antennen fungerer godt, er enkel å bære i sekken, settes opp uten å trenge festepunkter, trenger ikke antennetuner, og er billig i innkjøp. Til min Yaesu FT-817, som har internt batteri men ikke antennetuner, er dette den perfekte antennen. Hele radioutrustningen får plass i en liten brysttaske (se bildet).
Jeg bruker mye CW (morse) og trenger derfor en morsenøkkel som er lett og som tåler transport. Det finnes mye å velge mellom på nettet, av “paddles” laget av aluminum eller plast, noen har også en magnetfot.
Disse undersøkelsene ble gjort vinterstid, og jeg liker ikke å fryse. Jeg kjørte noen tester fra bilen, som bildet under viser. Inne på fjellet var det lite bakgrunnsstøy, og jeg satt varmt og komfortabelt i bilen og kjørte sambandet derfra. Antennen ble satt opp 6-8 meter fra bilen (som ikke lager målbar bakgrunnsstøy).
Forbehold
Alminnelig antenneteori fastholder at radialer påvirker antennens ytelse og tap, men ikke dens resonansfrekvens. Målingene som jeg har gjort er altså ikke helt i tråd med teorien. Så det er med noe forbehold om mine resultater også vil gjelde all bruk av denne antennen under varierende forhold og omgivelser.
Hele radiostasjone får plass i denne tasken.Radiostasjonen inne i bilen. Høyreklikk for å se morsenøkkelen.
LoRa (Long Range) er en radioteknologi som byr på mange anvendelser for radioamatører, men den må brukes i overensstemmelse med myndighetenes regelverk. Denne artikkelen gir en teknisk forklaring på modulasjonen og protokollene brukt i LoRa, og en presentasjon av hvordan LoRa-maskinvare kan koples opp konfigureres av et program skrevet i MicroPython. Den nødvendige konfigurasjonen for å operere i tråd med regelverket blir forklart, dessuten et enkelt eksperiment for å måle rekkevidden av LoRa-signaler.
(c) Anders Fongen, november 2024
Innledning
Innen digital transmisjon er det en lovmessig sammenheng mellom bitrate, båndbredde og signal/støy-forhold (SNR), uttrykt i Shannons Lov. Dersom anvendelsen av kommunikasjonskanalen ikke trenger høy bitrate, kan man klare seg med lav effekt (lavere SNR) eller liten båndbredde. Slike anvendelser er radioamatørene kjent med gjennom FT8 og WSPR.
LoRa er en kommunikasjonsteknolog som benytter den samme lovmessigheten ved å bruke radiosignaler med lang rekkevidde (lav SNR) , lav bitrate (opptil 22 kbit/sek) og lav utstrålt effekt (lavt strømforbuk). LoRa er utviklet med tanke på Internet of Things, med trådløs kommunikasjon mellom sensorer o.l. utstyrt med batteristrøm. En LoRa-radio er en liten og billig integrert krets som konfigureres og styres av en mikrokontroller (Arduino, ESP32, Raspberry Pico eller tilsvarende).
Resten av artikkelen vil hovedsaklig ha et teknisk fokus på modulasjon som brukes i LoRa, samt forklare hvordan en LoRa-radio kan koples opp og programmeres. Underveis vil relevante myndighetskrav bli diskutert, og erfaringer noen enkle eksperimenter bli presentert.
Kommunikasjon i bredt spekter (Spread Spectrum)
Tradisjonell radioteknologi har bestrebet seg på å sende ut radioenergi i et lite frekvensområde, slik at ulike sendere kan sende “side om side” i spekteret. Modulasjonen som er brukt i slike anvendelser (f.eks. kringkastingsradio) er følsom for annen radioenergi i samme frekvensbånd (forstyrrelser). Dette forholdet krever myndighetskontroll med bruk av frekvensspekteret, og overvåking av at bestemmelsene overholdes.
En alternativ måte er å spre radioenergien over et større frekvensspekter, på en måte som gjør kommunikasjonen mer robust mot forstyrrelser fra andre radiokilder, og som lar flere kommunikasjonskanaler benytte samme frekvensområde. På engelsk kalles slik modulasjon Spread Spectrum (SS).
Sentralt i SS-modulasjon er at hver overførte bit skal være representert på flere frekvenser, slik at et forstyrrende smalbåndssignal ikke skal hindre biten å bli overført. Vi finner SS-modulasjon i Bluetooth (som benytter såkalt frekvenshopping) og 3G (som benytter CDMA).
LoRa bruker SS-modulasjon ved å sende en samling bits i et symbol som representeres ved et signal som endrer frekvens fra lav til høy over en bestemt tidsperiode. Dette kan høres ut som fuglekvitter på en vanlig SSB-mottaker og kalles for “chirp”. Offisielt kalles denne typen modulasjon for Chirp Spread Spectrum.
Illustrasjonen ovenfor viser radioenergien i et chirp med tidsaksen horisontalt og amplituden vertikalt. Et chirp har ingen fase- eller amplitudemodulasjon, og informasjonen i det overførte symbolet avgjøres av hvilken frekvens chirp’et starter og slutter på. Mer om dette siden.
Båndbredde, symbolrate, spredningsfaktor
Den fysiske utformingen av et chirp bestemmes som nevnt av informasjonsinnholdet i symbolet som overføres i chirp’et, og tidsforløpet av overføringen bestemmes av signalets båndbredde, samt en parameter som kalles spredningsfaktor.
Informasjonen som overføres i et chirp kalles et symbol, og antall chirp som sendes pr. sekund kalles Symbolraten. Symbolraten (SR) er bestemt av båndbredden (BW) og spredningsfaktor (SF) på denne måten:
F.eks. vil en båndbredde på 62,5 kHz og spredningsfaktor 8 gi:
Koderate, og overførte bits pr. sekund (bitrate)
Antall bits overført i et symbol angis av spredningsfaktoren. SF=8 betyr at hvert symbol inneholder 8 bits. Dersom, i tråd med eksemplet over, symbolraten er 244 pr. sekund, blir brutto bitrate 1952 bits pr. sekund.
Men LoRa inkluderer også noen såkalt feilkorrigerende bits i datastrømmen, for å kunne detektere og endog rette opp overføringsfeil i noen utstrekning. Jo flere slik feilkorrigerende bits som legges inn, desto større og flere bitfeil kan rettes opp. En LoRa-radio konfigureres til en koderate (code rate, forkortet CR) skrevet f.eks. 4:5, som betyr at for 5 overførte bits er 1 bit satt inn for feildeteksjon/-retting, 4 bits er nyttedata. Mulige verdier for CR er 4:5, 4:6, 4:7, 4:8.
CR=4:5 betyr at netto bitrate er 80% av brutto, og regneeksemplet ovenfor gir en netto bitrate på 1952*0.8=1562 bits pr. sekund.
Her er en online kalkulator for å beregne netto bitrate. Den følger nettopp de regnereglene som nå er forklart.
Symbolverdien
Som nevnt overføres en gruppe bits med et symbol, et antall som tilsvarer verdien av spredningsfaktoren (SF). Verdien av dette er symbolet er derfor i området 0 til 2SF-1.
Et chirp vil starte på en frekvens, gå til høyeste frekvensen i båndbredden, fortsette fra laveste frekvens og avslutte på den samme frekvensen som den startet med. Symbolverdien representeres av den frekvensen som chirp’et starter og slutter på. Dette forløpet vil bli vist med en radiomottaker litt senere i artikkelen. Figuren nedenfor viser denne modulasjonsteknikken med frekvens langs vertikalaksen og tidsforløpet langs horisontalaksen (kilde).
Frekvensområdet som rommer chirp’ens båndbredde må derfor deles opp med 2SF antall “punkter”, hver av dem vil representere en bestemt symbolverdi.
Hvordan ser/høres dette ut i praksis
Vi kan sette opp en LoRa-sender med en båndbredde og spredningsfaktor som gjør at radiosignalet blir hørbart med en SSB-mottaker, og som gir et bilde i et “vannfall” som illustrerer chirp-modulasjonen.
Vi velger å sette opp senderen (måten dette skjer på vil vises senere i artikkelen) med BW=7800 Hz, SF=12. Dette gir en SR=1,9 pr. sekund, og en sendevarighet for hvert symbol på 525 millisekunder.
Med en bredbåndsmottaker og et “vannfallsdisplay”, i dette tilfellet RTL-SDR radio og Linux-programmet Gqrx (i Windows kan programmet SDR# gjøre samme jobben), kan vi motta LoRa-sendingene og studere dem i vannfallet. Slik vises LoRa-sendingene i mottagerprogrammet:
Lydsignalet som følger med er fra Gqrx-programmet som demodulerer som et SSB-signal. Forløpet i vannfallet viser omtrent det som allerede er forklart:
Chirp’ene opptrer omtrent 1,9 ganger pr. sekund.
Bortsett fra 2 chirp’er i starten av sendingen går alle lyder fra lav til høy frekvens.
Chirp’ene starter på ulike frekvenser, de skaper ikke et regelmessig sagtakk-mønster.
For å studere signalforløpet mer nøyaktig, lar vi Gqrx-programmet demodulere som et FM-signal og lagre det demodulerte signalet som en lydfil. Da vil frekvensen omsettes direkte til en amplitude, så vi kan studere frekvensforløpet med et lydredigeringsprogram, i dette tilfellet Audacity (finnes også for Windows). Sendingen som er vist i videoen over presenteres på denne måte i Audacity:
Vertikalaksen representerer her frekvensen, og den horisontale aksen tidsforløpet. De forskjellige delene av sendingen er ikke forklart i denne artikkelen, så kun i korthet starter sendingen med et “hode” av 6 up-chirps og 2.25 down-chirps. Området som vises i lyseblått er eksempel på et symbol som starter og slutter på samme frekvens, og som alltid endrer seg fra lav til høy frekvens, men “vrenger seg” fra høyeste til laveste frekvens. Det er også mulig å se nederst i vinduet at varigheten av det lyseblå området er 523 millisekunder, meget nære den verdien som vi beregnet ovenfor.
Tilkoplingen mellom LoRa-radioen og en mikrokontroller.
Bildet under viser en LoRa-radio t.h. med kretsen Semtech SX1278. Den har ingen betjeningsfunksjoner, kun tilkoplingspunkter for en kontroller som kan konfigurere og styre radioen gjennom elektriske signaler. Normalt vil disse tilkoplingspunktene forbindes til en mikrokontroller, som er en liten datamaskin som kan knyttes til en skjerm, knapper, andre datamaskiner, og som kan programmeres. Bildet nedenfor viser disse komponentene montert på et breadboard, med nødvendige ledningsforbindelser. Et breadboard er velegnet for eksperimentering fordi det er lett å gjøre endringer underveis og mulig å demontere komponentene siden for bruk i andre eksperimenter.
Sammenkoplingen mellom mikrokontrolleren og LoRa-radioen skjer gjennom en SPI-buss, som gjør sammenkoplingen enkel og med få kontaktpunkter. En SPI-buss kan kople kontrolleren (master) til flere ytre enheter (slaver) i tillegg til LoRa-radioen, f.eks. et display eller en GPS-mottaker. Figuren under viser hvordan en slik forgrening kan gjøres. I tillegg må LoRa-radioen ha strømtilførsel og en antenne.
For å styre LoRa-radioen trenger mikrokontrolleren et program som kommuniserer med LoRa-radioen gjennom SPI-bussen. Mange slags mikrokontrollere kan brukes til dette formålet, og de programmeres med ulike verktøy og ulike programeringsspråk. Den kontrolleren som brukes i dette eksperimentet er Raspberry Pico. Den er utstyrt med støtte for SPI-buss og kan programmeres i programmeringsspråket “MicoPython”, som er mye lettere å arbeide med enn f.eks. C. Figuren under viser de nødvendige ledningsforbindelser mellom mikrokontrolleren og LoRa-modulen:
Raspberry Pico har tildels like funksjoner på flere tilkoplingspunkter, så flere muligheter finnes enn hva som vises på bildet. Det vesentlige er at de fire ledningene som hører til SPI-bussen (MISO/RX, MOSI/TX,SCK,GND), 3.3 v spenningsforsyning og avbruddsline (mellom GP20 og DIO0) er koplet til.
Programvaren i mikrokontrolleren må dessuten vite hvilke porter den skal bruke for å betjene LoRa-radioen, så det må være samsvar mellom disse opplysningene og den oppkoplingen som er valgt.
Programmet som skal utføre de ønskede sende- og mottaks-operasjoner gjennom en LoRa-kanal må skrives inn i programmeringsverktøy. Her finnes flere å velge mellom, men vi anbefaler Thonny, som er enkel i bruk og godt tilpasset mikrokontrollere som Raspberry Pico. PCen med Thonny koples til Raspberry Pico med en USB-kabel, og oppsettet av Thonny for å komme i gang med programmering er godt beskrevet på nettet, og vil ikke forklares her.
Biblioteksmodul for LoRa-programmering.
I dette eksperimentet har vi benyttet en LoRa-modul med Semtech SX1278. Programmeringseksemplet under gjelder for kretser med betegnelsen SX127X. En del LoRa-moduler benytter kretser med betegnelsen SX126X, som krever et annet programmeringsbibliotek og en litt annen programmeringsmetode.
LoRa-radioen er komplisert å sette opp, så vi overlater disse operasjonene til programvare som andre har skrevet, kalt en biblioteksmodul. Modulen som er brukt i dette eksperimentet kalles lora.py og den kan hentes herfra. Den skal lagres i mikrokontrollerens minne, det gjøres via Thonny.
Vi vil dog anbefale en liten endring i lora.py. Erstatt linje 56-57 på denne måten for å få en sikrere oppstart av LoRa-radioen:
# while self._read(REG_VERSION) != 0x12:
# time.sleep_ms(100)
# The two commented lines are changed into
v = self._read(REG_VERSION)
while v != 0x12:
sleep_ms(100)
v = self._read(REG_VERSION)
# raise Exception('Invalid version or bad SPI connection')
Programmet som vi selv vil skrive må gjøre følgende:
Beskrive hvilke tilkoplingspunkter på Raspberry Pico som skal brukes for å styre LoRa-radioen.
Sette opp LoRa-radioen med de ønskede parametrene (frekvens, båndbredde, spredningsfaktor m.m.)
Beskrive sending og mottak av brukerdata i henhold til anvendelsen av utstyret.
Under vises et bilde av Thonny som har et lite program kalt hello_send.py. Alt programmet gjør er å sende en “Hello world”-melding hvert 5. sekund.
Testprogrammets enkelte deler
Her vil testprogrammets deler vises og forklares i kommentarsetningene:
# Importere nødvendige biblioteksmoduler
from time import sleep
from lora import LoRa
from machine import Pin, SPI
# Deklarere hvilke tilkoplingspunkter for SPI
# Merk av dette er GP-tallene, ikke pin-nummer
SCK = 18
MOSI = 19
MISO = 16
# Chip select
CS = 17
# Receive IRQ
RX = 20
# Setup SPI-bussen med riktige parametre
spi = SPI(
0,
baudrate=10000000,
sck=Pin(SCK, Pin.OUT, Pin.PULL_DOWN),
mosi=Pin(MOSI, Pin.OUT, Pin.PULL_UP),
miso=Pin(MISO, Pin.IN, Pin.PULL_UP),
)
spi.init()
# Beskrivelse av LoRa-parametrene
lora = LoRa(
spi,
cs=Pin(CS, Pin.OUT),
rx=Pin(RX, Pin.IN),
frequency=433.660,
bandwidth=20800,
spreading_factor=10,
coding_rate=8,
preamble_length=4,
crc=True,
tx_power=17
)
# Nå er alt klart for sending og mottak
c = 0
while True:
print(c," Sending a message")
c = c+1
lora.send('Hello world!')
sleep(5)
For å motta meldinger gjennom lora.py må vi skrive litt ekstra kode for å håndtere det forholdet at meldinger kan mottas når som helst, og vi trenger å skrive en event handler for slike hendelser. Den viste handleren nedenfor viser kun meldingsinnholdet på konsollet, i praksis vil det være omfattende programlogikk der.
# Receive event handler
def handler(x):
print("received:",x.decode())
beep(0.2) # Metoden beep er ikke vist her
# Set handler til å kalles ved mottatte LoRa-meldinger
lora.on_recv(handler)
# Put module in recv mode
lora.recv()
# Loop forever
while True:
pass
Demonstrasjonsvideo av LoRa-kommunikasjon
I videoen nedenfor vises bruk av disse enkle programmene for å overføre meldinger gjennom LoRa. Dette er også oppsettet som er brukt for å anslå rekkevidden til signalet, som beskrevet senere i artikkelen.
Lovlig bruk av LoRa innenfor myndighetenes regelverk
Bruk av radiosendere er strengt regulert i Norge, og det er på sin plass med noen vurderinger om hvordan LoRa-sendinger kan foregå på lovlig vis. Det er to regelverk som kommer til anvendelse: Fribruksforskriften, som stiller krav til radiosendinger for allmenheten, og Forskrift om radioamatørlisens, som angir krav til radiosendinger for personer med radioamatørlisens (radioamatørlisens tildeles personer som har bestått en såkalt lisensprøve).
La oss først ta for oss vilkårene i Fribruksforskriften, siden den vedkommer alle. Kapittel IV (§11) lister opp en del frekvenser som kan brukes, med oppgitt maksimal utstrålt effekt, båndbredde og sendetid.
Seksjon (1) angir et frekvensområde med maksimal utstrålt effekt på 25 mW (14 dBm), og et minimumskrav til båndbredden på 600 kHz. Dette er større enn maksimal båndbredde for LoRa, noe som må forstås dit hen at LoRa ikke kan benyttes.
Seksjon (2) angir et frekvensområde med maksimal utstrålt effekt på 500 mW (27 dBm) en maskimal båndbredde på 200 kHz, ingen krav til minimums båndbredde. Det er derimot krav til automatisk kontroll av utstrålt effekt, og det er ikke klart om LoRa kan møte dette kravet. Med LoRas standardverdier for båndbredde vil det være 125 kHz som er maksimalt tilatt.
Seksjonene (3)-(6) Påbyr alle mobile/nomadiske stasjoner å være “under kontroll” av et aksesspunkt. Siden LoRa ikke baserer seg på bruk av aksesspunkt slik som f.eks. Wlan gjør, er dette kravet ikke mulig å etterkomme.
Med en litt “lempelig” tolkning av bestemmelsene i seksjon (2) later det til at frekvensene 865,6–865,8 MHz, 866,2–866,4 MHz, 866,8–867,0 MHz og 867,4–867,6 MHz kan benyttes med 125 kHz båndbredde, og med utstrålt effekt en del lavere enn 500 mW (for å kompensere for kravet til automatisk effektkontroll). Merk at kravet om maksimal sendetid på 2,5-10 prosent ikke kan konfigureres i LoRa-radioen, men må besørges av overføringsprotokollene i den aktuelle anvendelsen. Også at det er LoRa-radioen av betegnelsen SX1276 som kan operere i dette frekvensområdet.
For brukere med radioamatørlisens gjelder §7 i Forskrift om radioamatørlisens, som angir maksimal båndbredde og utstrålt effekt for de ulike frekvensbåndene. Det eneste aktuelle frekvensbånd for LoRa er 432-438 MHz, hvor maksimal kanabåndbredde er 30 kHz. Det er mulig å konfigurere LoRa for en båndbredde på 20,8 kHz. NRRL’s (Norsk Radio Relæ Liga, landsorganisasjonen for radioamatører) båndplan angir området 433,600-434,000 MHz som egnet for digital dataoverføring, og da med utstrålt effekt opptil 300 W.
Med en ny bestemmelse gjeldene fra 1.november 2024 tillater myndighetene nå en båndbredde på 200 kHz i dette frekvensområdet. Anbefalte frekvenser for to slike kanaler er 433,775 MHz og 433,900 MHz. Radioamatører kan derfor benytte disse to frekvensene til LoRa med en båndbredde på 125 kHz og utstrålt effekt opptil 300 watt.
Begge typene LoRa-radioer (SX1276 og SX1278) kan operere på 433 MHz. For å oppnå høyere effekt enn 100 mW må et ekstra forsterkertrinn benyttes.
Merk at det finnes LoRa-moduler som ikke tillater konfigurasjon av båndbredden, bl.a. E32-modulene fra Ebyte. Disse er fast konfigurert til 500 kHz båndbredde og er uegnet for å operere på lovlige vilkår.
Hvorfor er dette robust?
LoRa kan sende over lange distanser med relativt lav effekt fordi den sender med lav bitrate og sprer radioenergien over mange frekvenser. Dette gir mottakeren mulighet til å bruke mer tid på å analysere det mottatte signalet og eliminere bakgrunnsstøy, og forstyrrelser fra andre kilder vil ikke hindre bit-overføringen med mindre hele båndbredden blir forstyrret.
Med ulike verdier av skaleringsfaktoren SF kan det gjøres en avveining mellom rekkevidde og bitrate. En økning av SF med 1 vil halvere symbolraten og gi mottakeren dobbelt så mye tid til å analysere signalet (gi en forbedret følsomhet med 2,5 dB) , men også gi en tilnærmet halvering av bitraten.
Et praktisk eksperiment ble gjennomført hvor et 100 mW signal ble sendt ut via en enkel mobilantenne satt på husveggen, og mottageren ble plassert i en bil koplet til en mobilantenne på biltaket (se bilde). Med denne konfigurasjonen (BW=20,8 kHz, SF=10) fikk mottakeren mottatt feilfrie meldinger i kupert terreng opptil 15 km avstand. Programmene brukt til dette eksperimentet er de samme som vist i videoen tidligere i artikkelen.
Takantennen brukt av LoRa-mottakeren, ca 15 km unna senderen.
Interessante anvendelser for radioamatører
LoRa kan neppe løse andre oppgaver enn f.eks. bruk av AX.25-modulasjon (1200 bits per sekund i en smalbåndskanal) mellom UHF-radioer, men kan derimot løse oppgaver med enklere og billigere utstyr med mye lavere vekt og lavere strømforbruk.
En nærliggende LoRa-anvendelse er lokasjonstjenesten APRS, som kan vise et kart med posisjonen til APRS-sendere i et stort område. Vanligvis brukes hele VHF-radioer til dette formålet, men med LoRa blir dette utstyret så billig og lite at det kan bygges inn i halsbåndet til en jakthund, eller på et modellfly.
LoRa er også velegnet for å bygge mesh-nett (hvor LoRa-stasjonene vidersender sendinger for andre) for formidling av meldinger m.m. Prosjektet Meshtastic er et eksempel på et slikt system.
Men vel så viktig er den muligheten mikrokontrolleren og bruk av MicroPython skaper til å designe egne protokoller og egne systemer for synlighet og samarbeid. Med det programmeringsverktøyet og biblioteksmodulen som her er vist, er det relativt enkelt å eksperimentere med egendesignede protokoller for innovative og nyskapende anvendelser.
Due to planned maintenance, the electric power in my neighbourhood was disconnected for hours today. That offered the opportunity to study the effect of background noise emitted from electric appliances.
(c) Anders Fongen, Oct 2024
When listening to the radio on the HF band, one can hear a lot of background noise which reduces the clarity of the reception. The emitters of the noise can be near or far away, which is interesting to distinguish, since the sources near you can be eliminated, most easily by packing your radio gear and drive somewhere else, to your cabin or into the mountains.
The neighbourhood which I live in had a power outage today, due to planned and announced maintenance. The affected area was small and included only 32 households (see map below). This disconnection gave me an opportunity to study the effect of radio spectrum noise (particularly in the HF region) from this area. The Xiegu G90 was powered by a battery and conncted to the outdoor antenna, then tuned to the 20 meter band in USB mode.
The map showing the extent of the affected households
I enjoyed the clarity of the reception and had a few QSOs before the electric power was expected to return. The radio display was filmed that moment when these 32 households again was able to power their cable modems, dimmers, plasma TVs, routers etc., and the difference in the receiver conditions was remarkable, which can be seen in the 20 seconds clip below.
Please observe the waterfall display as the power returns, and how excellent signals become completely drowned in the elevated noise floor, totally invisible in the waterfall.
Video recording of the moment when the power returned to the neighbourhood
After the power had returned I also switched off the main circuit breaker in the house to informally identify how much of the noise was coming from my own home. Hmm, quite a lot, since I have two wireless routers, ethernet switches, and dozens of wifi-connected house appliances. They are, like appliances in my neighbours’ house, essential for the daily life of our home, and cannot be switched off anytime.
From this experiment, I now realize how much the reception quality can be improved by taking the radio gear somewhere else (my home town is surrounded by mountain areas easily accesible by car) and operate a mobile/portable configuration.
Dette blir en kort artikkel om en app (Android og IOS) som tilbyr en meldingsutveksling over alle slags radioer som har et talesamband.
(c) 2024 Anders Fongen
Appen heter Rattlegram, og gjør én eneste jobb: Konverterer tekstmeldinger til et lydsignal, og omvendt. Den enkleste måten å demonstrere appen på er å legge to enheter (Android eller IOS) side om side og la begge kjøre appen. Det som skrives inn på den ene enheten, vises på den andre, og vi hører klart lydsignalet om bærer innholdet av meldingen. Man kan også eksperimentere med ulik avstand mellom enhetene og varierende bakgrunnsstøy for å danne seg et inntrykk av hvor robust kommunikasjonen er.
Merk allerede nå at mobilenheten aldri bruker sine radiosendere: Ingen WiFi, Bluetooth eller 5G. Ingen av eksperimentene her forutsetter mobildekning på stedet.
Det neste trinnet i eksperimenteringen er å sende via to transceivere som hver er innen hørevidde for sin enhet som kjører rattlegram. Først tester vi med noen lisensfrie UHF-radioer fra Biltema, for å vise at radioamatørutstyr ikke er påkrevet for å utveksle tekstmeldinger. For å sende en melding holdes sendeknappen (PTT) på radioen inne mens sendefunksjonen på appen aktiveres. På mottagersiden ligger radioen og Andoid/IOS-enheten ved siden av hverandre og trenger ingen betjening for å motta meldinger.
Her er en video hvor dette blir demonstrert:
Siden forsøker vi det samme eksperimentet med to VHF-transceivere for amatørbåndet (144 MHz), og oppnår det samme resultatet.
Fordelen med “ubetjent” mottak av meldinger
Hva er nå fordelen med en slik meldingsutveksling fremfor ganske enkelt å sende talemeldinger? Den mest opplagte fordelen er at mottageren trenger ikke å være betjent, men kan samle opp meldinger til neste gang operatøren kommer innom og sjekker displayet. En annen er muligheten for å sende komplisert tekstinnhold, f.eks. en url, og innhold fra copy&paste uten behov for bokstavering over et talesamband. En tredje er at sendte og mottatte meldinger blir lagt i en liste som fungerer som en logg over meldingsutvekslingen.
Et tenkt brukstilfelle er slik: Operatørene har alle radioene stand by i lyttemodus, og med Rattlegram på en mobil ved siden av. Dersom operatøren må forlate radiostasjonen for et stund, vil mobilenheten i mellomtiden samle opp mottatte meldinger og vise dem i listen. En stasjon A som anroper stasjon B uten å få svar, kan derfor følge opp med en Rattlegram-melding med innholdet “Gjør et oppkall når du er tilbake” eller lignende.
Parrot-funksjonen: Digipeater
I et tredje eksperiment ble “parrot”-funksjonen i Rattlegram undersøkt. Med denne funksjonen aktivert vil mottatte meldinger sendes ut igjen etter noen sekunder. En lik funksjon forvisser avsenderen om at meldingen er korrekt mottatt, og den gjør det mulig med indirekte overføring av melding via en digipeater (på en fjelltopp el.lign) mellom parter som ikke har direkte radiokontakt.
En slik funksjon forutsetter at radiosenderen kan sende ubetjent, uten at noen trykker inn PTT-knappen. Appen har ingen mulighet for å styre en PTT-funksjon, så radioen må settes opp med VOX-kontroll (sending starter når mikrofonen detekterer lyd). Radioen kan fortsatt være akustisk koplet til mobilenheten (se bilde), men i dette eksperimentet måtte følsomheten på radiomikrofonen settes til høyest følsomhet, og mobilenheten måtte stille høyttaleren på full styrke og plasseres nærmest mulig radioens mikrofon.
Akustisk kopling mellom radio og mobilenheten. Radioen må konfigureres til VOX-kontroll av senderen.
Et annet alternativ er å kople en kabel mellom radio og mobilenheten, muligens via et eksternt lydkort som koples til mobilenhetens USB-port med en OTG-kabel. Her er det en del plunder som venter, så det kan kreve litt prøving og feiling før dette fungere som ønsket. En kablet konfigurasjon er vist i videoen nedenfor, og i dette tilfellet ble det valgt å bruke to radioer for henholdsvis sending og mottak. En opplagt fordel med en kablet forbindelse er at operasjonen blir lydløs og mindre følsom for annen støy i rommet.
Her vises en video som demonstrerer digipeater-konfigurasjon av Rattlegram:
Systemdiagram
På bildet nedenfor vises et slags systemdiagram, hentet fra Ribbit-prosjektet, som står bak Rattlegram-appen. Den viser hvordan to mobilenheter (uten bruk av 5G, WiFi eller BT) kan utveksle meldinger gjennom radioer (akustisk koplet eller kablet) med direkte link mellom seg, eller via en talerepeater eller digipeater. Skissen viser også en mulighet for å bruke mobilenhetens egen 5G-radio, men det er ikke implementert i denne versjonen av Rattlegram.
Systemskisse for ulike måter Rattlegram kan sende og motta meldinger.
Hvilke radioforbindelser virker/virker ikke?
Rattlegram benytter en såkalt OFDM-modulasjon og såkalt feilrettende koder for å gjøre overføringen robust og effektiv. Det oppnås en bitrate på noe over 2 kbit/sekund, noe er veldig bra. Men erfaringene med ulike radioer og modulasjonstyper viser at mikrofon og høyttaler bør være av god kvalitet med god lydgjengivelse.
En DMR-link er sterkt komprimert og gir kun forståelig tale med dårlig lydkvalitet, og viser seg ikke å fungere for Rattlegram, noe som ikke er overraskende.
En FM-link i VHF- (145 MHz) og UHF-båndet (433 MHz) virker, som vist i eksperimentvideoene.
En FM-link via en lokal VHF/UHF crossband-repeater fungerer fint, som ventet
En FM-link via en “offentlig” VHF-repeater fungerte ikke, skyldtes muligens for svakt signal
Overføring via en HF-link fungerer fint med FM- eller USB-modulasjon på frekvensene 7-29 MHz. De to HF-transceiverne sto like ved hverandre, så en link med “realistisk” signal-støy forhold ble ikke testet.
Har du en Raspberry Pi liggende er det en enkel jobb å lage en Internet-radio med akkurat den betjeningen du liker best. Her forklarer vi hvor enkel og grei denne oppgaven er.
(c) Anders Fongen, april 2024
Innledning
Min daglige radiolytting starter til frokosten, hvor jeg foretrekker at ett trykk skal starte radioen og gi meg morgensendingen fra NRK. Jeg har en DAB-radio som gjør dette, men jeg ønsker også å lytte på stasjoner som ikke finnes på DAB-nettverket der jeg bor, men som kun finnes som Internett-strømmer.
I noen år hadde jeg en stemmestyrt Google Nest som tok inn radiostasjoner basert på TuneIn-appen, men siden den gang har NRK sluttet å strømme via TuneIn, så da ble det en periode DAB-radio side om side med en Bluetooth-mottaker for å spille TuneIn-stasjoner.
Jeg er ingen “storbruker” av Internet-radio, og er fornøyd med 6-8 stasjoner, inkludert NRK sine. Jeg stiller heller ingen andre krav til betjeningen enn at den skal være enkel og uten krav til øyekontakt. Den skal kunne betjenes i mørke og når jeg ikke har brillene på meg. Altså ingen touch-skjerm, men heller en knapperad.
Eller enda bedre: KUN ÉN KNAPP!
Betjeningsdesign
Internet-radioen trenger egentlig bare én knapp, som slår radioen av og på, og som kan brukes til å stege gjennom listen av forhåndlagrede stasjoner.
Radio av: Ett trykk slår på radioen og spiller den første stasjonen i listen
Radio på: Ett trykk skifter avspillingen til neste stasjon i listen, eller går til toppen av listen ved siste stasjon.
Radio på: Langt trykk slår av radioen
Lydsignalet fra Internet-radioen går til en separat forsterker, der finnes volumkontrollen.
Valg av maskinvare
I denne bloggartikkelen har jeg forklart hvordan en Internett-radio kan bygges på en mikrokontroller (Raspberry Pico) og en separat MP3-dekoder. Dette var et morsomt prosjekt, men denne gangen skal jeg presentere noe enklere som lar seg realisere på én kveld:
Jeg har noen eldre Raspberry Pi versjon 3 liggende. Disse kan startes med Linux, de har programvare for å dekode MP3, og de har en analog lydutgang som kan koples til en forsterker eller et headsett. De har også WLAN-adapter som kan motta datastrømmer via hjemmenettet. I sum er Raspberry Pi noe dyrere enn de to komponentene jeg brukte i nevnte bloggartikkel, men i tillegg til en enklere konstruksjon oppnår vi også å ha hele kretsen inni et standard kabinett for Raspberry Pi.
Den ene knappen som tillater brukerbetjeningen er av den typen som ofte brukes til eksperimentering. Den koples til GPIO-bussen og limes til lokket på kabinettet.
Pin 3 og 6 på GPIO-bussen koplet til en knapp i lokket på kabinettet.
Den analoge lydporten på Raspberry Pi hadde et rykte for dårlig lydkvalitet i tidligere versjoner av maskinvaren, men i Pi versjon 3 er denne kvaliteten tilfredsstillende.
Valg og konstruksjon av programvare
Ved installasjon av den anbefalte Linux-versjonen for Raspberry Pi, kalt Raspbian, blir det også installert et avspillingsprogram som heter VLC. Dersom man kopler skjerm og tastatur til Pi er VLC egentlig alt vi trenger for å strømme radioprogrammer. Brukerdesignet som vi har bestemt, utelukker derimot denne løsningen, vi skal kun ha Rasperry Pi i en boks ved siden av forsterkeren vår.
Vi kommer derfor til å lage et enkelt Python-program som avleser tilstanden på betjeningsknappen (trykket ned eller fri), som har en liste over adresser til de lagrede radiostasjonene, og som starter og stopper VLC-programmet med den ønskede radiostasjonen. Programkoden er vist lenger ned i denne artikkelen.
La oss starte med hvordan betjeningsknappen kan avleses av Pythonprogrammet. Python på Raspberry Pi kommer med ferdiginstallerte moduler for å behandle data (sende og motta) via GPIO-bussen, som er raden med pinner langs kanten av kretskortet.
Raspberry Pi GPIO pinout
Vi kopler knappen til pin 3 (også kalt GPIO2) og pin 6, som er jordforbindelse. GPIO2 er koplet til en intern pull-up motstand, som medfører at det står en spenning på porten når knappen er fri (avlest verdi 1) og med jordkontakt når knappen er trykket ned (avlest verdi 0). Koden for å avlese verdien på pin 3 ser slik ut:
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.board)
GPIO.setup(3,GPIO.IN) # Setter pin 3 som inndata-port
verdi = GPIO.input(3) # avleser verdien på pin 3.
Når man avleser knapper på denne måten må man ta hensyn til såkalt prell (switch bouncing), og vi har i denne koden valgt å måle tilstanden over noen millisekunder for at prellet skal roe seg. Derfor er Python-koden mer omstendelig enn om prell ikke fantes.
Utenom denne koden for å avlese langt og kort trykk på betjeningsknappen finner vi også kode for å starte VLC-programmet gjennom en såkalt subprosess, som utføres i parallell med resten av Python-programmet. Dermed kan vi avlese knappetrykk også mens VLC-programmet kjøres.
Trenger ikke grafisk brukergrensesnitt
VLC kjører normalt med et grafisk brukergrensesnitt, men det er bortkastet ressursbruk i vårt tilfelle hvor ingen skjerm er tilkoplet. Vi bruker derfor programmet CVLC, som gjør det vi ønsker med konsollbetjening (kommandolinje) og mindre ressursbruk. Et eksempel på hvordan vi starter og stopper CVLC i en subprosess ser slik ut:
import subprocess,time
url = "http://lyd1.lokalradio.no/oradio_hq"
p = subprocess.Popen(['cvlc',url]) # Starter avspillng
time.sleep(5) # Venter i 5 sekunder mens cvlc spiller
p.kill() # Stopper så avspillingen
Full programkode
Denne forklaringen av virkemåten burde være dekkende for å forstå den aktuelle programkoden som brukes. Den ser slik ut:
import RPi.GPIO as GPIO
import time,subprocess
button = 3
GPIO.setmode(GPIO.BOARD)
GPIO.setup(button,GPIO.IN)
b = GPIO.input(button)
radio_urls = ["http://lyd.nrk.no/nrk_radio_p1_innlandet_mp3_m?_hdr=0",\
"http://lyd.nrk.no/nrk_radio_klassisk_mp3_m?_hdr=0",\
"http://lyd.nrk.no/nrk_radio_jazz_mp3_m?_hdr=0",\
"https://dispatcher.rndfnk.com/br/br2/live/mp3/mid",\
"http://lyd1.lokalradio.no/oradio_hq",\
"http://freshgrass.streamguys1.com/folkalley-128mp3"]
current_channel_number = 0
def start_radio_channel(url):
return subprocess.Popen(['cvlc',url])
def this_channel():
return radio_urls[current_channel_number]
def switch_channel():
global current_channel_number
global radio_urls
current_channel_number = (current_channel_number+1) % len(radio_urls)
return this_channel()
def button_switch():
global button
if GPIO.input(button) == 0:
# Debounce, wait for 100 ms
time.sleep(0.1)
if GPIO.input(button) == 0:
return 1 # True
return 0
def button_wait():
# If button already pressed, wait until released
while button_switch() == 1:
time.sleep(0.1)
while button_switch() == 0: #This call returns in 0.1s
time.sleep(0.1) # Loop consumes 0.2s per iteration
# Do not return until the button is released, but allow
# a long press to switch off the radio
loop_counter = 0
while button_switch() == 1: # returns i 0.1s
loop_counter += 1
if loop_counter == 15: # 3 seconds hold
return 2
time.sleep(0.1) # Another 0.1s
return 1
radio_process = None
while True:
c = button_wait()
if c==2 and radio_process != None:
radio_process.kill()
radio_process = None
elif c==1:
if radio_process == None:
current_channel_number = 0
radio_process = start_radio_channel(this_channel())
else:
radio_process.kill()
radio_process = start_radio_channel(switch_channel())
Demonstrasjonsvideo
Her følger en kort demonstrasjonsvideo:
Her vises hvordan Internet-radioen lar seg betjene med en enkel knapp
Oppsummering, forslag til flere funksjoner
Det finnes masse eksempler på Internet-radioer som bygges selv, denne som jeg her viser er svært enkelt og er laget for mine behov. For dine egne behov, bruk gjerne deler av denne programkoden og lag dine egne funksjoner. Eksempler på en videreutvikling kan inkludere slike funksjoner:
Flere knapper, kanskje én for hver forhåndslagrede stasjon
En roterende bryter (rotary encoder) for å velge stasjon
Et display (LED eller OLED) som viser stasjonsnavn
Et web-grensesnitt for å redigere stasjonslisten
Klokkefunksjoner for automatisk avspilling (vekkerklokke)
Bluetooth-mottaker for avspilling fra mobiltelefonen (beskrevet her)
I denne artikkelen beskriver jeg hvordan det er mulig å ta imot radiosignaler fra fly med ADS-B meldinger, og hvilken informasjon disse meldingene inneholder.
(c) Anders Fongen, februar 2024
Fly i normal trafikk sender ut radiosignaler med meldinger om flight-id., posisjon, høyde, fart og retning. Dette skjer i et meldingsformat som kalles ADS-B og er en digital transmisjon på frekvensen 1080 MHz. Dette signalet brukes av luftkontrollen som supplement til radar, og tjenester som Flightradar24 benytter også i stor grad disse radiosignalene.
Kan du ha interesse av å bruke disse signalene? Selv har jeg planer om å bruke fly som reflektorer av radiosignaler, og på den måten utvide rekkevidden av VHF/UHF-signaler over horisonten. Da trenger jeg å vite hvordan antennen skal stilles for å peke mot flyet, og jeg må derfor vite hvor det befinner seg til enhver tid.
Hva du trenger for å motta ADS-B
En SDR mottaker av typen RTL-SDR. De finnes på Ebay fra en hundrelapp og oppover. De selges ofte som utstyr for å kunne motta digital TV på PC, men egner seg til mange andre formål også.
En Linux-maskin, gjerne en Raspberry Pi. Har du en gammel PC stående som ikke brukes og som har en USB port og nettverksadapter (WLAN eller Ethernet), så bruk gjerne den. Du vil trenge litt Linux-erfaring for å gjennomføre det som blir beskrevet her.
Noe gratis programvare som lastes ned fra Internet, bl.a. dump1090.
Oversikt over konfigurasjonen som skal vises her
Radiosignalet fra fly mottas av SDR-dongelen som er koplet til en Linux-maskinens USB-port.
Fra SDR går et “råsignal” (I/Q-signalet) til Linux-maskinen (grønn pil), hvor programmet dump1090 dekoder signalet og henter ut meldingene. Disse meldingene, gjengitt på såkalt SBS-1 format, sendes ut fra Linux-maskinen med TCP-protokoll på port 30003 (rød pil).
Meldingene på SBS-1 format kan leses med et program som man kan skrive selv etter hvilke ønsker man har. Jeg har valgt å lage et Python-program for en Raspberry Pico W mikrokontroller som henter ut flyenes løpende posisjon (lengdegrad, breddegrad, høyde) og regne ut retningen til en direktiv antenne som skal følge flyet.
Raspberry Pico lager elektriske signaler for å styre to motorer på et enkel platform (blå pil) for å stille inn ønsket retning og vinkel (azimuth og elevation).
Konfigurasjon av Raspberry pi (2)
Komponent (2) skal ta imot I/Q-signaler fra SDR-dongelen, dekode ADS-B meldingene som overføres, og presentere data på SBS-1 format gjennom en TCP-forbindelse. For dette trenges en enkel Linux-maskin som må konfigureres for dette formålet. Den følgende beskrivelsen tar utgangspunkt i en Raspberry Pi v.3, men fremgangsmåten blir nokså lik også for andre type Linux. Sørg for at Linux-versjonen er nylig oppdatert.
Følgende kommandoer kan gis for å installere drivere og dump1090-programmet:
Evt. feilmeldinger følges opp og rettes. På katalogen dump1090 ligger nå programmet dump1090 som startes med kommandoen ./dump1090 --net.
SDR-dongelen kan nå koples til maskinens USB-port og en egnet antenne, slik som vist på figuren. Deretter kan dump1090-programmet startes. Det gir ingen løpende utdata til skjermen, man overvåker utdata på metoden som er vist nedenfor.
Utdata fra dump1090
Som vist på figuren over har vi satt opp dump1090 til å sende ut data i SBS-1 format til TCP-port 30003. Med programmet netcat kan vi ta en titt på hvordan dataene ser ut, og gjøre oss opp en mening om hvordan de kan behandles. Ta en titt på denne videoen:
Det er i hovedsak opplysninger om posisjon og flight-id som er at interesse for denne anvendelsen, men data om retning og fart er også tilgjengelig.
Analyse av SBS-1 data og beregning av antenneretning (3)
Figuren over viser hvordan utdata fra dump1090 overføres via TCP-protokoll til alle som ønsker det (rød pil). Figuren viser derfor at flere ulike anvendelser kan hente disse dataene fra samme dump1090-instans.
I det eksperimentet som beskrives her, skjer denne bearbeidingen i en Raspberry Pico W, som er en mikrokontroller med WLAN-grensesnitt og som kan programmeres i Micropython. Programkoden i denne mikrokontrolleren kan deles i tre deler:
Et hovedprogram som etablerer en TCP-forbindelse til dump1090-noden (2), kaller så på Python-moduler for analyse, beregning og antennestyring
En modul for å analysere SBS-1 melding for posisjon og identifikasjon av fly, og for å beregne antenneretning til flyet.
En modul som mottar opplysninger om antenneretning og styrer servomotorene på antenneplattformen i henhold til disse opplysningene.
1 – Hovedprogram
Hovedprogrammet initialiserer TCP-forbindelsen, WLAN-adapteret, I2C-bussen og oppretter nødvendige objekter for de påfølgende operasjonene. Slik ser programkoden ut:
from wlan_config import wlan_config # WLAN configuration module
from AzElPlatform import AzElPlatform # Az-El antenna control
from AzElCalculator import AzElCalculator
import socket
from machine import Pin, I2C
import ssd1306
# using default address 0x3C
# TODO change GPIO numbers if necessary
i2c = I2C(0,sda=Pin(8), scl=Pin(9))
display = ssd1306.SSD1306_I2C(128, 64, i2c)
# Configure wlan
wlan_config()
# Make network tocket and connect to ads-b listener
sock = socket.socket()
# TODO change IP address to the actual dump1090 node
sock.connect(("192.168.2.11",30003))
# Configure bearing calculator (lat,lon,alt)
# TODO Replace numbers with your own location
azelcalc = AzElCalculator(61.1353,10.4419,253)
# Initialize platform motor control
# TODO change numbers to your own use of GPIO ports
azelplat = AzElPlatform(16,17)
# Start reading ads-b messages
while True:
message = sock.readline().decode()
result = azelcalc.analyzeMessage(message)
if result != None:
print(result) # For debugging only
# If flightId is present, send to OLED display
flightId = result['flightid']
if flightId != None:
distance = int(result['distance']/1000)
display.fill(0)
display.text('%s-%d km'%(flightId,distance),5,8)
else:
display.fill(0)
display.show()
# Find azimuth and elevation from result
azimuth = float(result['azimuth'])
elevation = float(result['elevation'])
# Point antenna in that direction
azelplat.setDirection(int(azimuth),int(elevation))
Deler av programkoden styrer et OLED-display for å vise flight-id og avstand til fly som blir fulgt av antennen. Disse kan kommenteres bort om dette er uten interesse.
Modulen wlan_config som importeres her er presentert i en annen blogg-artikkel: WLAN-konfigurasjon i Raspberry Pico W. Der vises hvordan wlan-adapteret kan konfigureres uten å skrive nettverkspassordet inn i koden.
2 – Analyse og behandling av SBS-1 utdata, beregningav retning
Metoden analyzeMessage() i modulen AzElCalculator mottar en SBS-1 melding som parameter og henter ut flight-id og posisjonsdata fra den. Programmet beregner så retningen for en antenne som skal følge dette flyet, i form av horisontal og vertikal vinkel (Azimuth og Elevation). For denne beregningen brukes Python-modulen AltAzRange som kan hentes fra denne adressen. Programkoden for AzElCalculator ser slik ut (merk at noen av linjene er lange og er brukket i flere deler):
# Receive SBS-1 message, find position of aircraft and
# calculate azimuth and elevation for the direction to it
from AltAzRange import AltAzimuthRange
class AzElCalculator:
def __init__(self,myLatitude,myLongitude,myAltitude):
AltAzimuthRange.default_observer(myLatitude,myLongitude,myAltitude)
self.airplane=AltAzimuthRange()
self.flightId = [(None,None),(None,None),(None,None),(None,None),(None,None)]
def analyzeMessage(self,messageLine):
elements = messageLine.split(",")
# ES Airborne Position Message
if (elements[1] == '3'):
icao = elements[4]
altitude = elements[11]
if altitude == '': return None
latitude = elements[14]
if latitude == '': return None
longitude = elements[15]
if longitude == '': return None
self.airplane.target(float(latitude),float(longitude),float(altitude)*0.3048)
# Observe that the position is not returned, only the direction
result = self.airplane.calculate()
result['icao'] = icao
result['flightid'] = self.getFlightId(icao)
return result
# ES Identification and Category
elif (elements[1] == '1'):
icao = elements[4]
flightid = elements[10].strip()
if flightid == '': return None
self.storeFlightId(icao,flightid)
return None
# ES Airborne Velocity Message
elif (elements[1] == '4'):
result = dict()
result['icao'] = elements[4]
result['groundspeed'] = elements[12]
result['track'] = elements[13]
result['flightid'] = self.getFlightId(result['icao'])
# We can return the "result" object, but choose not to
# return result # is this data is needed
return None
def storeFlightId(self,icao,flightId):
if self.getFlightId(icao) == None:
# Add flight id to list
self.flightId.insert(0,(icao,flightId))
self.flightId.pop() # Kill the oldest entry
def getFlightId(self,icao):
for (i,f) in self.flightId:
if i == icao: return f
return None
3- Styre en direktiv antenne mot flyet
Oppgaven med programmering av to servomotorer for å styre en antenne i to akser (horisontalt og vertikalt) skjer med modulen AzElPlatform som er presentert i en tidligere blogg-artikkel: Styring av servomotor fra Raspberry Pico og Micropython. For ordens skyld gjengis programkoden er:
# Python class to control a simple Azimuth-Elevation
# platform. It uses two SG90 servo motors for the two
# axes. Since they only rotate 180 degrees, the 180
# degree range of the elevation rotor is used to cover
# the left half (180-359 degrees) of the azimuth
from machine import Pin, PWM
class AzElPlatform:
def __init__(self,azrotor, elrotor):
self.azport = PWM(Pin(azrotor))
self.elport = PWM(Pin(elrotor))
self.azport.freq(50)
self.elport.freq(50)
def setDirection(self,az,el): # Angle in degrees
# Check parameters: 0-359 and 0-90 allowed
if not az in range(0,360): return
if not el in range(0,91): return
if az>180:
az = az-180
el = 180-el # Bend elevation backwards for left half
# Experimentally established values for
# Calculation of duty cycles corresponding
# to rotor angles
dutyAz = 7800 - az * 6600/180
dutyEl = el * 7000/180 + 1200
self.azport.duty_u16(int(dutyAz))
self.elport.duty_u16(int(dutyEl))
Raspberry Pico W med OLED display viser flight-id NOZ191 med avstand 78 km og følger dette flyet med en direktiv antenne.
Oppsummering
I denne blogg-artikkelen har jeg presentert noen aktiviteter som inkluderer bruk av Software Defined Radio, avansert digital dekoding av radiosignaler fra fly, noe programmering og beregninger på posisjonsdata, og styring av servomotorer for antenner.
Mange av disse emnene vil være av interesse i andre anvendelser enn akkurat den som her er presentert. Bruk gjerne delløsningene i denne artikkelen til dine egne prosjekter, og send meg en melding om resultatene blir interessante.
Her følger en enkel veiledning i hvordan man kan styre en servomotor fra Raspberry Pico. En servomotor lar deg stille rotoren i bestemte posisjoner, og kan brukes til å f.eks. styre et kamera eller en antenne.
(c) Anders Fongen, februar 2024
Innledning
Akslingen på en servomotor skal ikke snurre rundt og rundt, men stille seg i besteme posisjoner. Den egner seg derfor til å stille roret på en modellbåt, eller la et kamera eller en antenne følge et bevegelig objekt. Servomotoren SG90 er billig og lett, bruker lite strøm og er relativt sterk.
Servomotoren SG90
Vi skal i den følgende teksten viser hvordan vi kan styre SG90 fra Micropython på en Raspberry Pico, men løsningen blir veldig lik for andre kontrollere, f.eks. en ESP32.
Pulsbreddemodulasjon
SG90 har tre tilkoplingsledninger. To er for strømtilførsel (spenning+ og jord-), den tredje er for å stille rotoren i ønsket posisjon. Måten dette gjøres på er med såkalt pulsbreddemodulasjon.
En firkantpuls med en bestemt frekvens veksler mellom to spenningsnivåer, f.eks. 5 volt og 0 volt et visst antall ganger i sekundet, men ikke nødvendigvis med like lang tid på hver av spenningsnivåene. Den brøkdelen av tiden hvor spenningen er høy (f.eks. 5 volt) kaller vi duty cycle (av og til kalt arbeidssyklus på norsk), og illustrasjonen nedenfor viser tre firkantpulser med henholdsvis 50%, 75% og 25% duty cycle.
Tre ulike verdier av duty cycle for en firkantpuls. Kilde: wikipedia.org
PWM-signal i Micropython
Pulsbreddemodulasjon, heretter kalt PWM, er innebygget i Micropython og det er lett å sette en GPIO-port til å sende en firkantpuls med varierende duty cycle. Et eksempel på programsetninger som skaper en slik firkantpuls ser slik ut:
# Testkode for WPM-signal
from machine import PWM, Pin
import time
gpioport = 28 # Settes etter behov
pwmpin = PWM(Pin(gpioport, Pin.OUT))
pwmpin.freq(500)
while True:
for x in range(0,5):
pwmpin.duty_u16(16384*x)
time.sleep(1)
Som det fremgår av programkoden over styres duty cycle med metodekallet duty_u16(verdi), hvor parameterverdien kan variere mellom 0 og 65353 (som er den høyeste verdien for et usignert 16-bits tall). Under vises hvordan det avgitte signalet ser ut på et oscilloskop:
PWM-signal med varierende duty cycle, vist på et oscilloskop.
Oppkopling av SG90
Som tidligere nevnt, SG90 har tre tilkoplingsledninger: Rød ledning for forsyningsspenning koples til pin 40 (VBUS), evt. 39 (VSYS) på Raspberry Pico. Brun ledning koples til jord, f.eks. på pin 38. Orange ledning skal ha PWM-signalet, og du må velge en GPIO-port til dette formålet. I programeksemplet over er GPIO nr. 28 valgt, den finnes på pin 34. En såkalt “pinout” for Raspberry Pico er vist under.
Pinout for Raspberry Pico
Her følger en kort video for å vise effekten av varierende duty-cycle i PWM-signalet:
Her vises hvordan Raspberry Pico koples til en SG90 servomotor
Kalibrering av duty cycle
Når oppkoplingen er gjort kan du teste at motoren reagerer på ulike duty cycle-verdier ved å stille seg i en bestemt posisjon. Nå kan du kalibrere disse verdiene, ved at du noterer hvilke verdier som tilsvarer de posisjonene du ønsker å stille rotoren i. Min erfaring er at forholdet mellom rotorvinkel og duty cycle-verdier er noenlunde lineært, så du kan skrive kode som interpolerer mellom de observerte verdiene. Programmet som kjøres i videoen ovenfor ser slik ut:
from machine import Pin, PWM
import time
gpioport = 28 # Settes etter behov
pwmpin = PWM(Pin(gpioport, Pin.OUT))
pwmpin.freq(50) # Firkanpulsen har 50 Hz
for x in range(2000,7000,100):
pwmpin.duty_u16(x)
time.sleep(0.2)
I dette bestemte eksperimentet finner jeg ut at rotoren beveger seg en halv omdreining (180 grader) med duty cycle-verdier mellom 1150 og 7600, altså med et intervall på 7600-1150=6450. Dersom jeg antar at det er et lineært forhold mellom rotorvinkelen og duty cycle-verdier kan jeg lage en funksjon for å stille rotoren i en bestemt vinkel med denne programfunksjonen:
En forbedring av programmet ovenfor er derfor slik:
# Testkode for WPM-signal
from machine import Pin, PWM
import time
def setRotorAngle(pwmpin,degrees):
dcvalue = int(degrees*6450/180+1150)
# For rotating clockwise, change the previous line to:
#dcvalue = int(7600-degrees*6450/180)
pwmpin.duty_u16(dcvalue)
gpioport = 28 # Settes etter behov
pwmpin = PWM(Pin(gpioport, Pin.OUT))
pwmpin.freq(50) # Firkantpulsen har 50 Hz
for x in range(0,181,10):
setRotorAngle(pwmpin,x)
time.sleep(0.8)
Her beveger rotoren seg mot klokken med økende gradtall, om du ønsker bevegelsen slik gradtallet brukes på et kompass, altså med klokken må dcvalue kalkuleres slik:
dcvalue = int(7600-degrees*6450/180)
Eksempel på kamerastyring i to akser
En anvendelse av SG90 som jeg har selv har fattet interesse for er å styre et kamera eller en antenne i to akser for å kunne peke på et punkt oppe i luften eller verdensrommet. Et punkt på himmelrommet kan beskrives med to vinkler: Azimuth, som er vinkelen i horisontalplanet relativt til nord, og Elevation, som angir den vertikale vinkelen relativt til horisonten (les her for flere detaljer). En slik innretning kalles en Azimuth-Elevation rotor. Disse finnes i alle størrelser, er bygget for utendørs bruk og er ganske dyre. For eksperimentformål finnes det enkle konstruksjoner som benytter to SG90-motorer for det samme formålet. Søk etter “2 Axis Pan Tilt Mounting Kit” på Ebay: Her vises et bilde av en slik enhet:
Enkel Azimuth Elevation rotor basert på to SG90 motorer
For å styre denne enheten til et punkt på himmelen må du kople begge motorene til Raspberry Pico med felles spenning og jord, men med de orange ledningene til hver sin GPIO-port som du styrer med programsetningene vist ovenfor.
Rekkevidden til en SG90-motor er 180 grader. Skal du rekke over hele himmelkulen trenger du en rekkevidde for Azimuth på 360 grader, og 90 grader for Elevation. Et lite knep kan allikevel gi deg full dekning av himmelkulen over deg:
Dersom Azimuth er 0-179 grader, skal den horisontale rotoren stilles til denne vinkelen, og den vertikale rotoren (Elevation) stilles til den ønskede vinkelen 0-90 grader.
Dersom Azimuth er 180-359 grader, skal den horisontale rotoren stilles til Azimuth-180 grader, og den vertikale skal stilles til 180-Elevation grader. Dvs, at den vertikale rotoren legger seg “bakover” for å dekke den venstre delen av kompassrosen. Dersom det er et kamera på denne plattformen må du ta hensyn til at bildene da blir opp-ned.
Når du skriver kode for en slik innretning må du dessuten ta hensyn til at azimuth-rotoren går “mot klokka” med økende duty cycle-verdi, og du må snu litt om på regnestykket, som vist over.
Python-klasse for styring av en Az-El plattform
Nå setter vi sammen tidligere detaljer, inkludert observerte verdier for 0 og 180 graders rotasjon, til en Python-klasse som styrer begge aksene under ett:
# Python class to control a simple Azimuth-Elevation
# platform. It uses two SG90 servo motors for the two
# axes. Since they only rotate 180 degrees, the 180
# degree range of the elevation rotor is used to cover
# the left half (180-359 degrees) of the azimuth
from machine import Pin, PWM
class AzElPlatform:
def __init__(self,azrotor, elrotor):
self.azport = PWM(Pin(azrotor))
self.elport = PWM(Pin(elrotor))
self.azport.freq(50)
self.elport.freq(50)
def setDirection(self,az,el): # Angle in degrees
# Check parameters: 0-359 and 0-90 allowed
if not az in range(0,360): return
if not el in range(0,91): return
if az>180:
az = az-180
el = 180-el # Bend elevation backwards for left half
# Experimentally established values for
# Calculation of duty cycles corresponding
# to rotor angles
dutyAz = 7800 - az * 6600/180
#dutyAz = ((180-az)/180*6600) + 1200
dutyEl = el * 7000/180 + 1200
self.azport.duty_u16(int(dutyAz))
self.elport.duty_u16(int(dutyEl))
Demonstrasjonsvideo
Her følger en video hvor denne Python-klassen blir demonstrert med følgende testprogram:
from AzElPlatform import AzElPlatform
import time
azel = AzElPlatform(16,17) # GPIO-porter for Az og El
el = 20
for az in range(90,271,10):
azel.setDirection(az,el)
time.sleep(0.5)
Denne programkoden beveger plattformen fra 90 til 270 grader i horisontalplanet, og må derfor skifte mellom innstilling nr.1 og 2 fra diskusjonen ovenfor. Legg derfor merke til på videoen hvordan Elevation-rotoren snur seg rundt samtidig som Azimuth-rotoren vrir seg en halv omdreining. Videoen demonstrerer altså hvordan vi dekker hele himmelkuppelen med to rotorer med rekkevidde 180 grader.
Demonstrasjon av Azimuth-Elevation platform med to SG90 servomotorer.
Visst har vi Teams og andre skybaserte systemer for å samarbeide gjennom nettet, men vi har også behov for noe enklere for små grupper med veldefinerte samarbeidsmodeller. Vi skal vise et slikt system her, og påpeke hvilke fordeler som følger av et kompakt og fokusert system.
CMS-demonstratoren kan kjøres fra adressen http://hos.fongen.no/cms Kildekoden i arkivform kan lastes ned fra denne lenken
(c) Anders Fongen, 2024
Innledning
Se for deg en gruppe med noen titalls medlemmer, som skal samarbeide om en fokusert og veldefinert oppgave. F.eks planlegging og utforming av et undervisningsfag, en leteoperasjon etter savnede personer, en oppgave knyttet til kartlegging og etterretning, skriving av sakprosa, en chat.
Slike oppgaver er kjennetegnet ved visse egenskaper og behov:
Enkle behov for typografisk formatering av tekst
Behov for enkelt å opprette nye dokumenter, og endre på eksisterende
Høy tillit mellom deltakerne, med felles fokus og nødvendig kompetanse
Behov for raskt å gjøre seg kjent med andres bidrag til en aktivitet
Enkelt å fjerne utdatert, irrelevant og distraherende innhold
For slike oppgaver er det kanskje fristende å ta frem et generisk samarbeidverktøy med stort behov for styring og konfigurasjon, med høye kapasitetskrav til utstyr og kommunikasjonskanaler. F.eks. Teams, DocuLive, Itslearning, Canvas, Google Disk. Disse dekker muligens behovet, men ikke nødvendigvis på den mest effektive måte, de kan nelig fremstå som en “skyte spurv med kanoner”-løsning. Dessuten trenger de en internett-forbindelse til en skytjeneste, bare så det er sagt.
Vi skal i denne artikkelen presentere et enkelt samarbeidssystem kalt CMS – Content Management System. CMS kjennetegnes ved følgende egenskaper:
Minimalt med programkode, < 300 linjer i Python
Bruker markdown syntaks for tekstformatering
Web brukergrensesnitt (krever kun en web-leser)
Dokumentlås som virker
Enkel mekanisme for adgangskontroll
Dokumenter kan “oppfriskes” automatisk av web-leseren
Dokumenter kan opprettes og redigeres gjennom MQTT-protokoll
OpenSource, enkel kode for enkel utvidelse og endring
La oss i resten av dette dokumentet presentere disse egenskapene enkeltvis, og forklare hvordan de støtter aktuelle brukstilfeller. En grundigere presentasjon ligger i selve CMS-systemets demonstrasjonstjener på http://hos.fongen.no/cms.
Agil utviklingsmetodikk og Wiki
Behovene som ble listet opp i innledningen minner mye om egenskaper ved moderne system- og programutvikling, kjent som “agile development”. Gå gjerne via denne lenken for å lese litt om “agile” metoder (“agil” har i mellomtiden rukket å bli et norsk ord med norsk uttale).
For å støtte agilt samarbeid utviklet Ward Cunningham i 1995 en dokumentlagringstjeneste kalt Wiki. Med en Wiki kan enhver bruker opprette, redigere og slette dokumenter, altså et fravær av adgangskontroll som kun fungerer i grupper med felles mål og metode. En Wiki kan skrives kompakt med kun noen titalls programlinjer, men uten en redaktør som kan jobbe som “husmor” er de fleste erfaringer den at dokumentsamlingen med tiden blir en uhåndterlig blanding av nyttige, feilaktige, overlappende og utdaterte dokumenter. Wiki-prinsippet finnes også i Wikipedia, men her er det ansatt husmødre som overvåker redigeringen og opprettelsen av nye sider.
Den positive erfaringen med Wiki-prinsippet at en “90%”-løsning, dvs. 90% av behovene til en samarbeidsgruppe, lar seg løse med enkel og kompakt programmering, mens en 99%-løsning er kanskje 100 ganger større og dyrere. Såkalt “feature creep” i systemspesifikasjonene, dvs. at stadig nye funksjonskrav blir lagt til underveis, er en svært dyr uvane, og en fokusert og nøktern “90%”-løsning kan gi mye bedre effekt av innsatsen.
Overordnet beskrivelse av CMS
Dette er en web-tjeneste programmert i Python over rammeverket web.py, og som lar en gruppe av brukere søke, opprette og redigere dokumenter direkte fra sin web-leser. Den skiller mellom “lese”- og “redigere”-brukere slik at kun sistnevnte kan endre innholdet av dokumentsamlingen.
Brukerkontroll
Skillet mellom de to brukergruppene (“lese” og “redigere”) kan gjøres på mange måter, men for å unngå egne tabeller over brukernavn og passord (vi har nok av passord å huske på allerede) har jeg testet ut to metoder: IP-adresser eller klient-sertifikater:
IP-adresser: Bare klienter med IP-adresser som brukes bak brannveggen gir redigeringstillatelse, f.eks. IP-adresser som begynner med 192.168.x.x. Klienter forespørsler fra Internet vil aldri bruke disse adressene. Klienter tilkoplet via Virtuelle Private Nett (VPN) vil derimot kunne bruke adresser som gir redigeringstillatelse.
Klient-sertifikater: Der hvor det benyttes TLS (https:…) protokoll mellom klienten og tjeneneren kan TLS også sørge for at klientmaskinen må fremvise et nøkkelsertifikat og demonstrere sin private nøkkel for å autentisere seg. Kun de klientene som gjennomfører autentisering får redigeringstillatelse, alle andre kun lesetillatelse. Bruk av klient-sertifikater har den fordel at brukerne blir identifisert individuelt og man kan loggføre den enkelte brukers aktiviteter.
Dokumentorganisering
Dokumentene i CMS er hierarkisk organisert omtrent slik som i et filsystem, men istedetfor filkataloger brukes “mor-dokumenter”. Ethvert dokument kan være “mor” til et antall underordnete dokumenter. De underordnete dokumentene med felles mor kalles “søsken”. Når et dokument vises på skjermen vil både de underordnede dokumentene og søsken-dokumentene vises på et sidepanel. CMS inneholder også en enkel søkefunksjon hvor det kan søkes etter ordforekomster i tittel og innhold.
Dokumentene i CMS ligger lagret i en database, ikke som separate filer. Det åpner for en rekke muligheter for å sortere og søke i dokumenter, etablere reasjoner mellom dokumenter, låse dokumenter under redigering osv. Det åpner også for muligheten for andre programmer å skrive direkte til databasen for f.eks. å opprette dokumenter automatisk. Dette er en viktig egenskap ved CMS som vi skal omtale senere.
Redigering med MarkDown
De fleste er vant til å se en ferdig layout når dokumentet redigeres, på den fom det vil bli presentert for en som leser det. Det finnes andre måter å redigere på hvor layout påføres dokumentet som instruksjoner i tekstformat. Hypertext Markup Language (HTML) er det mest kjente eksemplet, hvor f.eks. teksten “<h2>” ikke vises i web-leseren, men indikerer at påfølgende tekst skal vises som en overskrift. Latex er et velkjent system for fremstilling av vitenskapelige artikler som benytter det samme prinsippet.
En av fordelene med markup er at instruksjonene indikerer intensjonen til forfatteren, ikke nøyaktig hvordan utseendet skal bli. “<h2>” kan resultere i ulik utseende, men alltid i form som indikerer en overskrift. En fargeskriver kan gi overskriften en annen uforming enn en svart-hvitt skriver f.eks.
Markdown er et “slenguttrykk” for et markup-språk som produserer HTML-kodet innhold. Markdown er ofte et enkelt sett av instruksjoner i en kort og enkel form, som f.eks. _underlinjert_ eller **uthevet** skrift. Når dokumentet blir presentert vil disse kodene være erstattet av den ønskede layouten. Wiki-systemene har ofte benyttet en form for markdown ved redigering.
Den viktigste egenskapen ved markdown er derimot at et slikt manuskript føles enkelt og naturlig å lese, også uten omforming av instruksjonene. Her er noen eksempler på tekst skrevet med HTML, Latex og Markdown, for å vise at sistnevnte er lettest å lese. Et dokument som ser slik ut:
Kan skrives med henholdsvis HTML, Latex og Markdown på denne måten:
Det er lett å konstatere fra dette eksemplet at Markdown er lettere å skrive inn, og lettere å lese i manuskriptform. I andre enden finner vi Latex, med kraftige mekanismer for å organisere layout og struktur på dokumentet, men som også er tung å skrive inn og vanskelig å lese i manuskriptform.
Markdown kan behandles av programkode for å f.eks. fremstille HTML kode for fremvisning i en web-leser. Med enkle regler kan Markdown behandles med såkalt regulære uttrykk i mange programmeringsspråk, men det finnes også egne programbiblioteker og ferdige programmer som kan gjøre dette. Dette er “kjedelig” programmeringsarbeid og en jobb som er godt å slippe.
Programmet heter pandoc, og finnes i versjoner for Mac, Linux og Windows. Det finnes også et Python-bibliotek kalt pypandoc som tilbyr et utvalg av pandoc’s muligheter gjort tilgjengelig for et Python-program.
Låsing av dokumenter under redigering
Kan flere brukere redigere samme dokument samtidig? I prinsippet ja, og Google Drive tillater nettopp det, men da må de i fellesskap sørge for at dokumentets innhold forblir meningsfylt og sammenhengende. I de fleste tilfellene er det tilstrekkelig løsning å la kun én bruker redigere, og andre som også ønsker dette, må vente på tur. Microsoft Word har lenge hatt en slik “lås”, som åpnes først når dokumentet lukkes etter bruk.
Dette har aldri fungert godt! Alle som har redigert med Word eller Excel har opplevd at en kollega har gått hjem for dagen uten å lukke dokumentet, som da forblir låst inntil neste dag.
I CMS er det valgt en låsemekanisme som automatisk åpner seg etter en viss tid (5 minutter), eller når dokumentet lukkes etter redigering. Dette er et kompromiss: Det løser problemet med gjenglemte låser, men gir brukeren 5 minutter på å fullføre redigeringen (må da gå ut av redigeringen og inn igjen). Dette skjer ved et triks i databasen som også sikrer at flere ikke kan låse et dokument samtidig. Sjekk kildekoden for å se hvilken SQL-syntaks som brukes.
Overvåking av dokumenter
Alle dokumenter i databasen er påført en “refresh rate”, dvs. et tidsrom mellom hver gang dokumentet skal hentes på nytt av web-leseren. Om “refresh rate” er satt til 10 sekunder, vil endringer i dokumentet (gjort av andre) vises frem i alle web-lesere som ser på dette dokumentet senest etter 10 sekunder. Slik kan f.eks. en situasjonsrapport alltid bli vist med de siste oppdateringene uten at brukerne på gjøre en “reload” av dokumentet.
Denne mekanismen introduserer en nødvendig balanse mellom akseptabel forsinkelse i oppdateringen av andre klienter, og den nettverkstrafikken som oppstår knyttet til den stadige hentingen av dokumenttdata. Settes “refresh rate” til 0 skjer ingen slik oppdatering automatisk.
Bruk av bilder
Bilder kan settes inn i dokumentene som redigeres ved å skrive inn en instruksjon i den løpende teksten: <img src=Pictures/filnavn.jpg>. Dette er den vanlige HTML-kommandoen som brukes for dette formålet, og ekstra parametre for å justere størrelse kan også brukes.
Alle bilder legges på samme katalog (Pictures) på CMS-tjenerens filområde, og nye bilder kan lastes opp i PNG eller JPG-format ved å klikke på en knapp i det høyre sidepanelet. Pass på at bildene får unike filnavn, og bilder som ligger der kan inkluderes i mange dokumenter.
Automatiske dokumenter – Internet of things
Automatiske dokumenter betegner dokumenter som legges inn i databasen uten medvirkning fra brukerne av systemet. Disse dokumentene vises frem som andre dokumenter, og egner seg for å vise data fra miljøsensorer, web-kameraer, mashup fra internettkilder (værmelding, trafikkrapporter, børsdata) osv. Et automatisk dokument kombinert med bruk av “refresh rate” kan vise et situasjonsbilde eller en operasjonell status i tilnærmet sann tid, og oppdateres automatisk.
Dokumenter som legges inn av brukere kan ikke overskrives eller endres av denne automatiske prosessen.
Automatiske dokumenter kan ikke redigeres eller slettes av brukere
Automatiske dokumenter utvider bruksområdet til CMS kraftig, utover det å være en interaktivt dokumentarkiv. CMS kan dermed inkludere og vise tilstanden i omgivelsene. Dette er en kopling til det som kalles Internet-of-things.
I den foreliggende programkoden finnes modulen PubSubAdapter.py som kopler automatiske dokumenter til Publish-Subscribe distribusjon og MQTT-protokoll. På denne måten kan CMS være en del av et større nettverk av noder som samarbeider om å behandle sensor-information. Modulen createCMS doc.py gir et eksempel på hvordan MQTT-protokollen kan brukes for å opprette eller endre et CMS-dokument.
Legg merke til at programkoden i PubSubAdapter.py også tillater at tekst bli lagt til i eksisterende dokumenter, ved å søke etter tegnstrengen <!-- Insert --> i det eksisterende dokumentet. Denne tegnstrengen blir da erstattet med det nye innholdet, og dokumentet forøvrig blir bevart.
Egen kjøring, videre utvidelser og eksperimentering
Linken øverst i artikkelen laster ned et tar-arkiv av kildeteksten. Jeg anbefaler å kjøre CMS-tjeneren på en Linux-maskin, da den ikke er testet under Windows.
Last ned kildekoden i tar-format fra lenken i toppen av artikkelen, og hent frem cms.py i en editor. Du må se over definisjonene i begynnelsen av filen, spesielt om verdien av innerIP svarer til IP-adressene i ditt lokalnett.
Om du vil at CMS skal være tilgjengelig for omverdenen må du konfigurere routeren din med port forwarding, og kanskje satt opp dynamisk dns-navn. Dette omtales ikke her.
Før du starter CMS må disse programmene være installert:
Programmene pandoc, sqlite3
Python-bibliotekene web.py, pypandoc, paho-mqtt
Start så det hele med kommandoen
python3 cms.py 8080
8080 betegner TCP-porten som CMS skal bruke, om du endrer denne til 80 må du huske på å være root-bruker.
CMS har muligens ingen funksjoner som ikke finnes i andre samarbeidssystemer, men har det fortrinn at det er enkelt og kompakt, med kun noen hundre programsetninger. Systemets konstruksjon er dermed lett å forstå, utvide og endre. Det er derfor mitt ønske at de som laster ned og starter opp CMS vurderer utvidelser og nye funksjoner.
Her har jeg laget et verktøy for betjening og konfigurasjon av en enkel Internetradio basert på mikrokontolleren Raspberry Pico (tidligere presentert i denne artikkelen). Det hele blir presentert i denne videoen. Ta kontakt med meg om du ønsker å se programkoden (MikroPython)
En mikrokontroller med WLAN-kretser kan betjenes via nettet, og trenger derfor mindre knapper og lamper for betjening og konfigurasjon. Det mest nærliggende er å lage et web-grensesnitt, selv om andre protokoller også kan brukes. Men det å kople seg til et nytt WLAN-nettverk uten å legge navn og passord inn i programkoden krever noen knep som jeg skal beskrive her. Programmeringsspråket som brukes er MicroPython.
Anders Fongen, juni 2023
Innledning
Problemstillingen er som følger: Du har programmert en slik mikrokontroller til å bruke WLAN-forbindelsen for brukerbetjening, hente data fra Internet, eller kommunisere med andre maskiner. WLAN-adapteret må programmeres til å kople seg til et trådløst nettverk innen rekkevidde, og må kjenne navnet og passordet til det.
Det enkleste er å skrive nettverksnavnet (SSID) og passordet inn som verdier i programkoden, Men om du gir fra deg programkoden til andre er disse opplysningene til liten hjelp. Dessuten er det sjelden lurt å skrive passord direkte inn i programkoden.
Denne artikkelen løser dette problemet: Hvordan konfiguere en slik mikrokontroller for å kople seg til det stedlige trådløse nettverket?
For en raskere innføring, gå til slutten av artikkelen for å se et demonstrasjonsvideo.
Overordnet metode
Kontrolleren har en liste over kjente nettverk, med navn og passord, lagret på en fil. Når kontrolleren starter, vil den gå gjennom listen og forsøke å kople seg til ett av nettverkene på denne listen.
Dersom intet nettverk lar seg kople til (kanskje fordi listen er tom) vil kontrolleren sette opp sitt eget WLAN-nettverk med kjent navn og passord. Andre maskiner kan nå kople seg til dette nettverket.
I tilfelle punkt 2, vil kontrolleren også starte opp en web-tjener for å bli konfigurert gjennom en web-leser. Eieren kan så skrive inn navn og passord på WLAN-nettverk som kontrolleren skal kunne kople seg til.
Denne listen av kjente nettverk bli så lagret til en fil og blir hentet frem neste gang kontrolleren startes (punkt 1).
I resten av denne artikkelen vil jeg gå gjennom enkeltdelene i programmet som bruker denne metoden. Den fulle programkoden kan lastes ned og kjøres i kontrolleren for demonstrasjonsformål, men du vil trolig ønske å gjøre dine egne endringer.
Metoden del for del
I de følgende avsnittene vises ikke programmet i sin helhet, men kun de enkeltsetningene som knytter seg til hver enkelt delfunksjon. Du må selv finne ut hvordan disse delene settes sammen, men du kan også laste inn den komplette programkoden og studere den.
Starte WLAN-adaperet og observere eksisterende WLAN
import network
net = network.WLAN(network.STA_IF)
net.deinit() # Found to be useful
net.active(True)
observed_networks = net.scan()
Denne koden setter WLAN-adapteret i “station”-modus, som lar den kople seg til eksisterende nettverk. Den siste setningen scanner omgivelsene og bygger opp en liste med nettverk innen rekkevidde. Denne listen inneholder navn, mac-addresse, beskyttelse, signalstyrke, radiokanal m.m. for hvert av dem.
Lage en liste over aktuelle WLAN
Programkoden vil så finne ut hvilke av de observerte nettverkene den har navn og passord til (kalt kjente nettverk), og sortere dem etter synkende signalstyrke, slik at den siden kan velge det nettverket med best radiosignal. Listen over kjente nettverk ligger på såkalt JSON-format, og leses inn i en dictionary-variabel med disse setningene:
import json
def load_json(filename):
f = open(filename,"r")
d = json.load(f)
f.close()
return d
Listen over nettverk som både er observert og kjent, sortert etter synkende signalstyrke, lages med disse programsetningene:
# Merge the list of observed network and known networks,
# the resulting list will contain the known networks which
# are observed at the moment, sorted by descending rssi
def merge(known_list,observed_list):
new_list = list()
for (ssid,pw) in known_list:
for obs in observed_list:
if ssid == obs[0].decode(): # Network name
rssi = obs[3] # Signal strength (RSSI)
new_list.append((rssi,ssid,pw))
break # Out of inner for loop
new_list.sort(reverse=True)
return new_list
Tilkoplingsprosedyre
Resultatet av funksjonen merge() er en liste over nettverk som det er aktuelt å kople seg til. Programmet vil forsøke det sterkeste nettverket først. Programkoden ser slik ut:
import network, time
# Merge the two lists
interesting_networks = merge(known_networks,observed_networks)
for (rssi,ssid,pw) in interesting_networks:
net.deinit() # Form of reset
net.active(True)
attempts = 1
net.connect(ssid,pw)
status = net.status()
if status in [network.STAT_NO_AP_FOUND, \
network.STAT_WRONG_PASSWORD]:
print("Rejected from ", ssid, "reason=",status)
break
else:
while status != network.STAT_GOT_IP:
time.sleep_ms(500)
attempts += 1
if attempts > 20: # More than 10 seconds?
print("Give up ", ssid, "reason=",status)
break # Out of while loop
status = net.status()
if status == network.STAT_GOT_IP:
print("Successful connection to ",ssid)
return True # Successful connect
# else iterate in the for loop
return False
Denne koden er litt omstendelig. Fordi det tar litt tid å kople seg til et WLAN, bør du sette en tidsgrense for hvor lenge du vil vente før du gir opp og forsøker neste nettverk på listen. Denne koden sjekker to ganger i sekundet om forbindelsen er opprettet, og gir opp etter 10 sekunder.En tilkopling vil også kreve at nettverket tildeler en IP-adresse, noe som vises med verdien network.STAT_GOT_IP. Kodesetningene er en del av en funksjon som returnerer True dersom en forbindelse ble opprettet, False ellers.
Dersom forbindelsen ble opprettet, er alt bra. Programmet kan nå fortsette sin utføring av anvenderprogrammet, sette opp socket og forbindelser etc. Dette ligger bak horisonten for denne artikkelen.
Sette opp en konfigurasjonstjener
Dersom det ikke lot seg gjøre å kople seg til et WLAN, kan programmet nå starte en konfigurasjonstjener som gjøre det mulig å redigere listen over kjente nettverk. Det krever at vi lar mikrokontrolleren sette opp sitt eget WLAN med kjent navn og passord, og starter en web-tjener med en brukerdialog for dette formålet.
Opprette et WLAN er enkelt, det skjer med disse programsetningene:
import network
def make_ap(ssid="RPico-config",pw="123456789"):
net = network.WLAN(network.AP_IF)
net.deinit() # Form of reset
net.config(essid=ssid,password=pw)
net.active(True)
while not self.sta_if.active():
time.sleep_ms(500)
# Access point now active
print("Access point active")
Når dette er utført, kan programmet sette opp en socket som tillater at en web-leser kopler seg til. Dette gjøres i det web-tjeneren startes. Her vises programsetningene som setter opp en tjener-socket (sock.bind() og sock.listen()), og lar en web-leser kople seg til (sock.accept()). Deretter leser programmet inn de dataene som web-leseren sender, og nå er vi inne i HTTP-protokollen.
def start_web_server(self,port=80):
sock = socket.socket()
sock.bind(('0.0.0.0',port))
sock.listen() # Accepting at most one pending connection
print('listening on port', port)
# Now enter main loop. Accept connections and process http requests
while True:
try:
print("Waiting for incoming connection")
client_socket, cl_addr = sock.accept()
print('Client connection from', cl_addr)
client_socket.settimeout(1) # Set socket timeout 1 sec
request = ''
try:
while True:
buf = client_socket.recv(1024).decode()
request = request + buf
except OSError:
pass
if request.startswith("GET / "):
response = self.get_response()
response_code = "200 OK"
elif request.startswith("POST / "):
print(request) # Just for debugging
# Find where the html body starts (two newline chars
ix = request.find('\r\n\r\n')
if ix==-1: return # Garbage, quit
post_parameters = self._parse_parameters(request[ix+4:])
# Send the post parameters to a HANDLER, which returns
# a response message
response = self.post_handler(post_parameters)
response_code = "200 OK"
else:
response_code = "404 Not Found"
response = '<h1>404 Not Found</h1>'
except Exception as e:
response_code = "500 Internal Server Error"
response = "<h1>500 Internal Server Error</h1>"
finally:
client_socket.send('HTTP/1.0 %s \r\nContent-type:
text/html\r\n\r\n'%response_code)
client_socket.send(response)
client_socket.close()
HTTP-protokollen er et kapittel for seg, i korthet starter en forespørsel med ordet GET eller POST, etterfulgt av et stinavn til den ressursen som adresseres. I dette tilfellet tillater vi kun adressen “/”, alt annet ignoreres. På de påfølgende linjene i forespørselen kommer mer opplysninger om web-tjeneren og hva den ønsker. De skal vi også se bort fra. Denne delen av forespørselen slutter med en blank linje, uttrykt som '\r\n\r\n'. Etter dette kan det komme opplysninger knyttet til selve web-tjenesten, f.eks. data som legges inn i et skjema, men dette begrenser seg til POST-forespørsel.
Programkoden over viser hvordan den ved en POST-forespørsel trekker ut dataene som knytter seg til web-tjenesten, og leverer dem til en annen funksjon for behandling.
En web-tjener vil behandle forespørselen og sende en respons til web-leseren ved å skrive dataene til en socket. Dette er hva som vises på web-leserens skjerm etter at forespørselen er behandlet, og vil normalt være et resultat av noe databehandling. I dette tilfellet gir GET-operasjonen en respons som er gitt i variabelen get_response, og POST-operasjonen det som returneres fra metoden post_handler(..). Det vil fremgå av den komplette programkoden at get_response inneholder et HTML-skjema som lar brukeren skrive inn data for de kjente WLAN-nettverkene, og post_handler(..) vil produsere en form for bekreftelse på at dataene er blitt lagret på en fil.
Slik vises resultatet av en GET-operasjon: et skjema som skal fylles ut med WLAN-opplysninger
Når brukeren fyller inn det skjemaet som blir vist og sender det med SAVE-knappen vil innholdet sendes til web-tjeneren i form av en POST-operasjon, og dataene vil hentes ut av datastrømmen med funksjonen parse_parameters(). Koden til denne funksjonen, og hjelpefunksjonen unescape() er vist nedenfor:
# Parse a http query string and return named values as a dictionary
def parse_parameters(par_string):
params = dict()
for element in par_string.split('&'):
nv = element.split('=')
# Unescape %hex coded characters
unesc = unescape(nv[1])
params[nv[0]] = unesc
return params
# Replace e.g. %2f with /
def unescape(s):
b = bytes(s,'utf-8')
ix = 0
ix = b.find(b'%',ix)
while (ix != -1):
hx = b[ix+1:ix+3]
bt = bytes.fromhex(hx)
b = b.replace(b[ix:ix+3],bt)
ix = b.find(b'%',ix+1)
return b.decode()
Resultatet av å trykke “Save” er en POST-operasjon som har dette bildet som resultat.
Jeg tror ikke det er nødvendig med en full beskrivelse av hvordan data fra HTML-skjemaer blir overført, men forsøk gjerne å sette inn noen print-setninger for å studere koden mens den kjører.
Slik programkoden er skrevet vil dataene fra det utfylte skjemaet lagres på en fil i JSON-format. Siden, når mikrokontrolleren starter på nytt, vil den lese innholdet av denne filen og bygge opp en tabell over kjente nettverk som brukes slik det ble beskrevet innledningsvis i denne artikkelen.
Hvilken adresse skal brukes for å kople seg til konfigurasjonstjeneren?
Når din maskin kopler seg til kontrollerens WLAN, bruk disse adressene:
Nettverkets navn er “RPico-config” og passordet er “123456789”. Med mindre du skriver noe annet inn i programkoden.
Maskinen din får tildelt en IP-adresse ved tilkoplingen, den kan du se i Windows med ipconfig-kommandoen (se bildet nedenfor). Se etter IPv4-adressen som er tildelt ditt trådløse adapter. Noter også IPv4-adressen til “Default Gateway”. Den er sannsynligvis 192.168.4.1, så eksemplet som følger vil vise denne adressen.
I web-leseren får du nå kontakt med konfigurasjonstjeneren med URL’en http://192.168.4.1/
Utskriften av “ipconfig” viser at kontrollerens IP-adresse er 192.168.4.1
Single-threaded server
Slik denne programkoden er laget ser du lett at den tar i mot en forbindelse og forespørsel med sock.accept(), og behandler denne forespørselen helt og fullt før neste forbindelse blir akseptert. Dette prinsippet kalles single-threading, og medfører at web-tjeneren gir dårlig ytelse når flere web-lesere bruker tjeneren samtidig. Det har liten betydning i dette tilfellet, fordi det WLAN’et som skapes av mikrokontrolleren kun tillater et par samtidige forbindelser.
Noen kommentarer til det fulle programmet
I denne artikkelen har jeg vist forenklede utdrag av et fullt program, som kan lastes ned herfra. Det kan kjøres slik som beskrevet, men koplingen til et anvenderprogram som vil bruke WLAN-adapteret for sin kommunikasjon må settes inn i programmets linje 210.
Ved å studere programmet i sin helhet kan du få bedre inntrykk av hvordan de enkeltdelene som tidligere er beskrevet, blir knyttet sammen i en samlet kontrollflyt. Dessuten er programmet utformet objekt-orientert, som er en nyttig programmeringsteknikk å beherske.
Programkoden er laget for Raspberry Pico W. Dersom du vil bruke den på en ESP32 krever 5 små endringer i koden, disse er angitt i kommentarsetninger. Søk etter “ESP32” og du finner dem. Send meg en melding om du ikke får det til.
Dersom det er aktuelt å konfigurere andre programparametre, f.eks. nettadresser til bestemte tjenester i Internet, kan de gis verdier med et tilsvarende web-grensesnitt. Jeg anbefaler ikke å bruke denne konfigurasjonskoden til andre formål enn for WLAN-opplysninger. Lag heller en separat web-tjener for de andre parametrene, laget på tilsvarende vis. Python-klassen web-config kan brukes til dette uten endringer.
Heller bruke ferdige biblioteker?
Det finnes ferdige Python-moduler på nettet som gjør deler av denne jobben for oss. Når jeg har valgt å presentere en metode som bare bruker de grunnleggende standardbibliotekene i Python, er det for (1) at denne prosessen skal skape læring, ikke bare en løsning, og (2) standardbiblioteker er skrevet for mange slags anvendelser og tar mye mer plass i minnet enn en skreddesydd løsning slik som denne.
Demonstrasjonsvideo
Her vises hvordan denne konfigurasjonsmetoden fungerer i praksis.
Full programlisting
Den fulle programlistingen for dette eksperimentet kan lastes ned fra denne linken.
