LoRa-radioer brukt på radioamatørbåndene

 61 total views,  2 views today

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. 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.

Mikrokontrolleren Raspberry Pico (til venstre) koplet til LoRa-radioen SX1278 (til høyre)

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.

Ledningsnettet i en SPI-buss. Kilde: https://electrosome.com/spi/

Det finnes også enheter hvor mikrokontrolleren er fabrikert sammen med en LoRa-radio, da er det enklere å sette opp et eksperiment eller en prototyp.

Oppsett for programmering

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.

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:

  1. Beskrive hvilke tilkoplingspunkter på Raspberry Pico som skal brukes for å styre LoRa-radioen.
  2. Sette opp LoRa-radioen med de ønskede parametrene (frekvens, båndbredde, spredningsfaktor m.m.)
  3. 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.

Neighbourhood noise in the radio spectrum

 182 total views,  1 views today

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.

Rattlegram: Enkel meldingstjeneste for mange typer radioer

 170 total views,  1 views today

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.

Raspberry Pi som Internett-radio og Bluetooth-mottaker

 255 total views,  2 views today

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.

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)

Mottak og bruk av ADS-B signaler fra fly

 356 total views,  2 views today

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

  1. Radiosignalet fra fly mottas av SDR-dongelen som er koplet til en Linux-maskinens USB-port.
  2. 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).
  3. 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.
  4. 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:

$ sudo apt update
$ sudo apt upgrade
$ sudo apt install librtlsdr-dev
$ sudo apt install rtl-sdr
$ git clone https://github.com/antirez/dump1090.git dump1090
$ cd dump1090
$ make

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:

  1. Et hovedprogram som etablerer en TCP-forbindelse til dump1090-noden (2), kaller så på Python-moduler for analyse, beregning og antennestyring
  2. En modul for å analysere SBS-1 melding for posisjon og identifikasjon av fly, og for å beregne antenneretning til flyet.
  3. 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.

Styring av servomotor fra Raspberry Pico og Micropython

 246 total views,  1 views today

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:

def setRotorAngle(pwmpin,degrees):
    dcvalue = int(degrees*6450/180+1150)
    pwmpin.duty_u16(dcvalue)

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:

  1. 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.
  2. 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.

CMS – Et lettvekts samarbeidssystem for mindre brukergrupper

 265 total views,  1 views today

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.

Konfigurering av mikrokontroller med WLAN (Raspberry Pico W, ESP32)

 517 total views,  2 views today

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Nettradio og MP3-spiller med Raspberry Pico

 432 total views,  1 views today

Ved hjelp av et kretskort som dekoder MP3 til lydsignaler kan vi lage en MP3-spiller eller en Internet-radio. Alt som trengs er litt programmering i Rasberry Pico. Her brukes programmeringsspråket MicroPython.

Anders Fongen, mai 2023

Lyd lagret som MP3 må dekodes før det kan sendes som lydsignaler til en høyttaler. En slik dekoder kan lages i programvare, dersom prosessoren er kraftig nok. Dette går greit i en PC, men en mikrokontroller (f.eks. Arduino, EPS8266, Raspberry Pico) kan ikke påregnes å ha tilstrekkelig datakraft for dette formålet.

Det finnes egne integrerte kretser som utfører MP3-dekoding i maskinvaren, uavhengig av prosessorkraften i kontrolleren, og som lar oss lage en MP3-spiller med billige og strømsparende komponenter. Denne bloggartikkelen vil vise hvordan slike komponenter koples sammen og hvordan programmeringen gjøres.

Komponenter som kan brukes

Mange komponenter kan brukes for et eksperiment likt det som presenteres her. De valgte komponentene er en Raspberry Pico (heretter kalt RPico) og en dekoderkrets kalt VS1053 fra VLSI Solutions.

Oppsett og programmering av RPico blir ikke gjennomgått her, det finnes mange hjelperessurser for dette formålet på nettet. Her vil det vises hvordan RPico og VS1053 koples sammen, og den programmeringskoden som kjører i RPico for å oppnå ønsket virkemåte.

En VS1053 er kun en liten brikke/chip, så for eksperimentformål er det vanlig å bruke et kretskort som også inkluderer støttekretser og tilkoplingspunkter. Som vist på bildet under er det utstyrt med koplingspinner som passer ned i et vanlig prototyp-brett (“breadboard”).

Et eksperimentkort for VS1053

VS1053 er en ganske avansert brikke som i tillegg til å dekode MP3 også dekoder lyd kodet med WAV, WMA, OGG, eller MIDI. Den kan ta opp lyd gjennom en mikrofonport (evt. linjeport) og kode den til OGG m.m. (dog ikke til MP3). Kretskortet som er brukt i denne artikkelen har også en SD-kortleser.

For å ta kretskortet i bruk koples en høyttaler til den ene minijack-porten, mens tilkoplingspinnene koples til pinner på RPico. Gjennom disse ledningene går det signaler for å konfigurere VS1053 for det foreliggende formålet, og for å overføre digitale lydsignaler som skal dekodes.

I ledningene mellom VS1053 og RPico benyttes en overføringsmetode som kalles Serial Peripheral Interface (SPI). Dette er en såkalt seriell metode hvor én og en bit overføres i høyt tempo over en enkel ledning. Fordelen med å benytte en “standardisert” metode er at den kan styres fra maskinvaren slik at det krever mindre programmering, og belaster hovedprosessoren mindre. Dessuten er SPI utformet slik at kontrolleren kan snakke med flere enheter gjennom samme ledning (som vi da kaller en buss). I dette tilfellet kan både SD-kortleseren og dekoderen bruke samme ledningssett.

Ledningsnettet

Tegningen nedenfor viser hvordan RPico og VS1053 kan koples sammen. Her er det mange valgmuligheter, men det må være samsvar mellom hvilke pinner på kontrolleren som brukes, og programvaren som skal styre dem. Det er altså mulig å velge andre pinner på RPico enn hva som foreslås her.

Tilkoplingspunkter på VS1053 og RPico

Bildet over viser navnene som er gitt til pinnene på VS1053. De avviker noe fra de navnene som brukes på databladet, så her kreves litt utprøving for å fortstå hvilke funksjoner de har. Her er fasiten:

VS1053 påtrykkBeskrivelseKoples til
RPico pin
Navn på
RPico
5VDriftsspenning40VBUS
GNDJordforbindelse38GND
CSChip select for SD-kortleseren2GPIO 1
MISOSPI datalinje fra VS10536GPIO 4
SISPI datalinje til VS10535GPIO 3
SCKSPI klokkesignal4GPIO 2
XCSChip select for MP3-dekoderen9GPIO 6
XRESHard reset (aktiv lav)1GPIO 0
XDCSData select (RPico->VS1053)10GPIO 7
DREQData request (VS1053->RPico)11GPIO 8
Sammenkoplingen av VS1053 og RPico

Merk at pinnene CS, XCS, XRES, XDCS er alle “aktiv lav”, dvs. at de skal ha 0 volt for å gi effekt. Dette fremgår også fra programkoden.

Bildet over til høyre viser bruken av en flatkabel med ledninger i forskjellige farger for å gjøre denne sammenkoplingen. Det er lett å gjøre feil i denne prosessen, og fargene var til stor hjelp. Et bilde over pinnene på RPico vises på bildet under. Legg merke til at pinnene MISO, SI og SCK er koplet til RPico på pinnene 4-6, som alle er benevnet SPI0. Om andre pinner brukes til dette formålet er det nødvendig at de koples til samme SPI-kanal (0 eller 1) med betegnelsene RX, TX og SCK.

Kommunikasjon med VS1053

RPico kommuniserer med VS1053 på en av fire måter:

  1. Skriv til et register. Verdiene i registrene konfigurerer VS1053. Programkoden viser hvilke verdier som er nødvendig for eksperimentet i denne artikkelen. Full oversikt over registerverdier finnes i databladet.
  2. Les verdien av et register. Ikke strengt nødvendig i denne artikkelen, men nyttig for å kontrollere at en skriveoperasjon er vellykket.
  3. Sende data. I denne artikkelen vil vi sende MP3-kodet lyd til dekoderen, og det skjer på denne måten.
  4. Motta data. VS1053 kan også kode lyd til digital form, som da kan mottas av RPico. Ikke brukt i denne artikkelen.

Skrive til et register

For å skrive en registerverdi må RPico gjøre følgende:

  • Sette XCS=0, XDCS=1
  • Vente til DREQ==1
  • Bygge en 4 byte streng som starter på x02, deretter fulgt av adressen til registeret, og to bytes med den 16-bits verdien som skal skrives dit.
  • Sende strengen til SPI-kanalen
  • Sette XCS=1

Her ser du Python-koden for funksjonen write_command:

    def write_command(self, address_byte, data_byte1, data_byte2):
        # Set the control pins to indicate a command
        self.xcs.value(0)
        self.xdcs.value(1)

        while not self.dreq.value():
            pass

        # Send the address and data bytes over SPI
        ba = (bytearray([0x02, address_byte, data_byte1, data_byte2]))
        self.spi.write(ba)

        # Turn off XCS signals
        self.xcs.value(1)

Lese en registerverdi

For å lese verdien lagret i et register må RPico gjøre dette:

  • Sette XCS=0, XDCS=1
  • Vente til DREQ==1
  • Bygge en 2 byte streng som starter på x03, deretter følger adressen til registeret.
  • Sende strengen til SPI-kanalen
  • Lese to bytes fra SPI-kanalen, som inneholder verdien av registeret.

Slik:

    def read_register(self, address_byte):
        # Set the control pins to indicate a command
        self.xcs.value(0)
        self.xdcs.value(1)
        while not self.dreq.value():
            pass
        self.spi.write(bytearray([0x03, address_byte]))

        resp = self.spi.read(2)

        self.xcs.value(1)
        return resp

Sende data

Disse stegene er nødvendige:

  • Sette XCS=1, XDCS=0
  • Vente til DREQ==1
  • Sende maksimalt 32 bytes til SPI-kanalen
  • Sette XDCS=1

Slik:

    def write_data(self, data):
        # Set the control pins to indicate data
        self.xcs.value(1)
        self.xdcs.value(0)

        while not self.dreq.value():
            pass
        self.spi.write(data)
        self.xdcs.value(1)

Nødvendige deklarasjoner

Noen programsetninger er nødvendige for å deklarere og initialisere portene, samt importere noen nødvendige biblioteker:

from machine import Pin, SPI
import time
spi_mosi = Pin(3)
spi_miso = Pin(4)
spi_sck = Pin(2)

# Define the pins for the VS1053 module
vs1053_xcs = Pin(6)
vs1053_xdcs = Pin(7)
vs1053_dreq = Pin(8)
vs1053_reset = Pin(0)

# Initialize the SPI bus for the mp3 decoder 
co_spi = SPI(0, baudrate=1000000, polarity=0, phase=0, sck=spi_sck,\\
   mosi=spi_mosi, miso=spi_miso)

Jeg har valgt å legge all håndteringen av VS1053 inn som en klasse i Python, og den blir initialisert med denne koden:

class VS1053:
    def __init__(self, spi, xcs, xdcs, dreq, reset):
        self.xcs = xcs
        self.xdcs = xdcs
        self.dreq = dreq
        self.reset = reset
        self.spi = spi

    def init(self):
        self.xcs.init(Pin.OUT, value=1)
        self.xdcs.init(Pin.OUT, value=1)
        self.dreq.init(Pin.IN)
        self.reset.init(Pin.OUT, value=1)

        # Reset the VS1053 module
        self.reset(vs1053_reset)
        self.write_command(0x0, 0x8, 0x4)
        self.write_command(0x3, 0xe0, 0)    # Clock multiplier
        self.write_command(0xb, 0x30, 0x30) # Volume control, 0-loudest	

    def reset(self,pin_reset): # Hardware reset of VS1053
        self.reset.value(0)
        time.sleep_ms(1)
        self.reset.value(1)

Utover det å opprette instansvariabler, vil koden initialisere GPIO-portene med riktig tilstand, resette VS1053 og så skrive inn noen nødvendige registerverdier. Se seksjon 9.6 i databladet for en full beskrivelse av disse.

Full operasjon av VS1053

Etter konfigurasjon slik som beskrevet over og med de funksjonene for lesing og skriving til VS1053 kan vi nå finne frem MP3-data for å teste at vi får avspilt lyd. MP3-data kan finnes fra mange kilder, men i denne artikkelen vil to muligheter belyses nærmere: (1) Hente MP3-filer fra et SD-minnekort, dvs. filer som du har kjøpt på nettet eller hentet fra CD-plater (kalt “ripping”). (2) Hente MP3-data fra nettet med såkalt “strømming”, som innebærer at lyden spilles av etter hvert som de hentes. Begge alternativer vil bli demonstrert, men metoden med å hente data fra nettet er den enkleste og vil bli vist først.

Internet radio

Raspberry Pico finnes i en “W”-versjon (kalt RPicoW heretter), og den har kretser som kan koples til et trådløst nett og videre til Internet. Med denne versjonen brukt i dette eksperimentet er det relativt enkelt å bruke denne muligheten til å spille av radiostasjoner på Internet.

Her viser vi først programsetningene for å kople RPicoW til et trådløst nett (connect_wifi). Vi trenger som vanlig SSID (nettets navn) og et passord som må legges inn i programmet. Funksjonen connect setter opp en forbindelse til en web-tjener. For det formålet trenger vi en URL som inneholder web -tjenerens navn og angivelse av den MP3-strømmen som ønsket mottatt. MicroPython inneholder ikke ferdiglaget kode for HTTP-protokollen, så funksjonen inneholder også noen kodesetninger som starter den faktiske dataoverføringen.

class netradio:
    def connect_wifi(self,ssid,password):
        self.sta_if = network.WLAN(network.STA_IF)
        self.sta_if.active(True)
        self.sta_if.connect(ssid,password)
        while not self.sta_if.isconnected():
            time.sleep_ms(500)

    def connect(self,radio_IP,radio_URL,tcp_port=80):
        self.sock = socket.socket()
        addr = socket.getaddrinfo(radioIP, tcp_port)[0][-1]
        self.sock.connect(addr)
        request = "GET %s HTTP/1.0\r\nHost: %s\r\n\r\n" % (radioURL,radioIP)
        self.sock.send(request)
        return self.sock
    
    def read_data(self,numbytes):
        return sock.recv(numbytes)

Funksjonen read_data returnerer en såkalt socket, som er en “brønn” som vi kan øse data fra. Den kan brukes som en parameter i VS1053-klassens funksjoner for å hente MP3-data i 32-bytes porsjoner og sende til dekoderen med funksjonen write_data. Funksjonen for å oppnå dette ligger i VS1053-klassen og kalles play_stream. Koden ser slik ut:

    def play_stream(self,socket):
        while True:
            soundpacket = socket.recv(32)
            if soundpacket:
                self.write_data(soundpacket)
            else:
                break
        socket.close()

Hva vi nå trenger for å starte nettradioen er en høyttaler koplet til minijack-utgangen på VS1053, og følgende initialiseringskode i RPicoW:

# Initialize the VS1053 module
vs1053 = VS1053(co_spi, vs1053_xcs, vs1053_xdcs, vs1053_dreq, vs1053_reset)
vs1053.init()

# Start netradio
radioIP = "lyd.nrk.no"
radioURL= "/nrk_radio_klassisk_mp3_h?_hdr=0"

nradio = netradio()
nradio.connect_wifi("WiFi-navn","WiFi-passord")
vs1053.play_stream(nradio.connect(radioIP,radioURL))

Avspilling av MP3 fra SD-kort

Dette kretskortet med VS1053 inneholder også en SD kortleser (ikke alle gjør det), og en tilkoplet RPico (trenger ikke være en RPicoW) kan lese og skrive data til et minnekort. Minnekortet blir en del av filsystemet til RPico, og data leses og skrives gjennom ordinære metoder for filbehandling.

Tilkoplingen av en kortleser bruker også SPI-grensesnittet, og er litt mer omstendelig enn WiFi, så denne delen er spart til slutt, da selve dekoderen nå er testet og kjent.

Kortleseren bruker de samme ledningene til SPI-kommunikasjonen, men trenger sitt eget Chip Select signal. Den finner vi på pinnen CS på kretskortet, og koples til pin 2 (GPIO 1) på RPico. Se illustrasjonen under som viser hvordan SPI-ledningene kan deles av flere tilkoplede enheter.

Deling av SPI-buss på flere enheter. Merk av de har separate SS (Chip select) linjer

Kanaler på samme SPI-buss må initialiseres hver for seg, men en ny deklarasjon trenger ingen parametre når den bruker det samme bussnummeret. Altså slik:

import sdcard, os
# Initialize the SPI bus for the mp3 decoder and the sd card reader
co_spi = SPI(0, baudrate=1000000, polarity=0, phase=0, sck=spi_sck, \\
     mosi=spi_mosi, miso=spi_miso)
sd_spi = SPI(0)

# Chip select for SD card reader
sd_cs = Pin(1, Pin.OUT, value=1)

# Init SD card reader interface
card = sdcard.SDCard(sd_spi, sd_cs)
os.mount(card, '/sd')
print(os.listdir('/sd')) # Prints the files on the root directory

Modulen sdcard blir importert, dette er koden for å styre lesing og skriving på SD-kortet. Kildekoden kan lastes ned via lenken nedenfor, og må plasseres i filsystemet på RPico, f.eks. på /lib-katalogen.

Koden vist ovenfor gjør at filene på SD-kortet er gjort tilgjengelig fra katalogen /sd. Filer med MP3-innhold kan nå spilles av med en ny funksjon som vi legger til VS1053-klassen. Slik:

def play_file(self, filename):
        # Open the file and read the data
        chunk = 8192
        with open(filename, "rb") as f:
            data = f.read(chunk)

            # Loop through the file and send the data to the VS1053
            while data:
                idx = 0
                while True:
                    if idx+32 > len(data):
                        self.write_data(data[idx:])
                        break
                    else:
                        self.write_data(data[idx:idx+32])
                        idx += 32
                data = f.read(chunk)
    

Koden i funksjonen over kan trenge en forklaring: Her leses MP3-dataene i porsjoner på 8192 bytes, som deles opp i pakker på 32 bytes som sendes til VS1053 med write_data-funksjonen. Lesing av 8192 bytes tar mindre tid enn det å spille av 32 bytes, så det oppstår ikke hakking i lyden, noe som skjer dersom dette tallet settes mye høyere. Avspilling av filen /sd/andrea.mp3 kan nå skje med programsetningen

vs1053.play_file("/sd/andrea.mp3")

Brukergrensesnitt, sier du?

Denne artikkelen har som mål å vise hvilken Python-kode som kreves for å spille MP3-data fra nettet eller fra et SD-kort. Dette kan være til hjelp for dem som kjenner til MicroPython-programmering og kan inkludere disse programsetningene i sin egen kode. Den viste programkoden kan i sin helhet lastes ned herfra:

(Filene lastes ned med .pyx på slutten av filnavnet. Endre navnet til .py før bruk)

Skal denne koden brukes i egne programmer bør disse funksjonene legges til:

  1. Feilhåndtering. Alt som kan gå galt, vil trenge kode som fanger opp og behandler feilsituasjonen.
  2. Brukergrensesnitt. Start/stopp/pause i avspilling. Valg av katalog eller spilleliste for serieavspilling. Visning av tittel i et display m.m.

Anders håper at denne artikkelen kan være til nytte, skriv gjerne en kommentar om feil og mulige forbedringer.