Archives

SITRAP fra ødemarka

I dag er det 4 måneder siden jeg forlot alle sosiale media og tok steget ut i den digitale ødemarka. Hvis noen skulle være i tvil så definerer jeg ikke Rosabloggen som SoMe (sosiale media) da den er en monologisk kommunikasjonsplattform. Ja, man kan vel heller kategorisere den som «uSoMe» – usosiale media. Så hvordan har det gått? Det har vært helt strålende! Jeg har ikke savnet Face, Snap eller Insta i det hele tatt. En bieffekt av å droppe SoMe er at volumet på innlegg på Rosabloggen har økt en del ettersom den blir eneste utløpsted for GPP (Generelt Pisspreik). Jeg hadde et par forbehold når jeg vurderte om jeg skulle droppe SoMe eller ikke, og de var: 1. jeg går glipp av for mye. Med det mener jeg arrangementer og invitasjoner. 2. utfordringer relatert til logistikk. Skoler, speider osv. poster en del praktisk informasjon på Facebook-grupper. Jeg har ikke opplevd at de to har vært et spesielt stort problem. Jeg har faktisk ikke gått glipp av noe som jeg vet om. Det er i seg selv en ganske befriende tanke; å slippe å ta stilling til ting hele tiden. Skolen kommuniserer nå og spesielt i disse koronatider bedre på andre plattformer som e-post og applikasjoner som skolen bruker i undervisningen (f.eks. Microsoft Teams og Showbie). Digitaliseringen i skolen har tatt et kvantesteg i riktig retning. I de tilfeller det er noe spesielt som skjer på Facebook så fanger fruen det opp, men det er det lite av. En liten kuriositet ved å droppe Facebook er at det er forbausende få som husker å sende deg bursdagshilsen, men den så jeg vel komme. Konklusjonen er at jeg i skrivende stund ikke har noen planer om å forlate den digitale ødemarka og returnere til SoMe.

Relasjoner – OSS

Etter at jeg la ut serien med innlegg om relasjonsdatabaser her på Rosabloggen har jeg fått en del spørsmål, og jeg tenkte at det kunne være greit å samle de ofte stilte spørsmåla i et eget innlegg.

«Hva hvis en pasient har flere leger?». Det det spørres om her kalles en mange-til-mange-relasjon. I praksis betyr det at en lege kan ha mange pasienter, og en pasient kan ha mange leger. Jeg skal nå vise hvordan dette kan løses i lege/pasient-databasen vår. For at man skal ivareta normaliseringen må det innføres det som kalles en koblingstabell. For å gjøre det oversiktlig for meg selv så pleier jeg å navngi koblingstabellene med et navn som viser hvilke to tabeller jeg knytter sammen. I dette tilfellet er det tabellene «lege» og «pasient» som skal knyttes sammen i en koblingstabell, og gir den derfor enkelt og greit navnet: «lege_pasient». Koblingstabellen «lege_pasient» har det som kalles en sammensatt primærnøkkel. Den består av de to primærnøklene til tabellene «lege» og «pasient». Siden man nå ikke lenger trenger fremmednøkkelen «l_id» i tabellen «pasient» så kan denne slettes. Denne ble kun brukt til å knytte en pasient til en lege, og har derfor ingen funksjon lenger. De 3 involverte tabellene i databasen ser nå slik ut:

Under er SQL-spørringa for å hente ute en liste som viser pasienter knyttet mot leger.

SELECT pasient.navn AS pasient,
       lege.navn AS lege
  FROM pasient
  INNER JOIN lege_pasient on lege_pasient.personnr = pasient.personnr
  INNER JOIN lege on lege.l_id = lege_pasient.l_id;

Resultatet av spørringa ser slik ut:

Ser man på tabellen over så har hver lege 2 pasienter hver, og «Gunnar Åm» han har 2 leger. Nå kan det kanskje virke litt søkt at en pasient har flere leger, men mange-til-mange-relasjoner er ganske vanlig. La oss ta et enkelt ordresystem. Vi har en ordretabell og en produkttabell. Dette er en mange-til-mange-relasjon da en ordre kan inneholde mange produkter, og et produkt kan være på mange ordrer. Koblingstabellen «ordre_produkt» (et bedre navn hadde kanskje vært «ordrelinjer») vil også gjerne inneholde antallet av de respektive produktene.

«Hvordan legger jeg inn leder til en ansatt?». Der er flere måter å løse dette på. Man kunne brukt en avdelingstabell som de ansatte knyttes mot, og de ulike avdelingene har en leder knyttet mot seg. Men nå skal vi gjøre ting enklere enn som så. Problemet kan løses ved hjelp av rekursive forhold. Enkelt forklart så har man en fremmednøkkel som peker til primærnøkkelen i en og samme tabell. Jeg har laget et enkelt organisasjonskart med 10 ansatte for den fiktive bedriften Rakett AS.

Jeg har laget en enkel tabell «ansatt» for alle de ansatte. Ansattnummeret er unikt for alle ansatte i bedriften og blir primærnøkkelen «ansattnr» i tabellen «ansatt». Videre så har vi navnet og stillingen til de ansatte, og til slutt fremmednøkkelen «leder» som peker til primærnøkkelen «ansattnr» i samme tabell. Tabellen ser slik ut:

Som man ser av tabellen (og av organisasjonskart) så har alle en leder bortsett fra daglig leder. Verdien NULL betyr at der ikke eksisterer en fremmednøkkel. Skal man hente ut en liste over ledere og sine ansatte så kan SQL-spørringa skrives slik:

SELECT leder.navn AS leder,
       medarbeider.navn AS ansatt 
FROM ansatt medarbeider
INNER JOIN ansatt leder ON leder.ansattnr = medarbeider.leder;

SQL-spørringa over kalles gjerne en «self join». Man kan se på en «self join» som om at man slår sammen to kopier av samme tabell, men tabellen er selvsagt ikke kopiert. «medarbeider» og «leder» er alias til tabellen «ansatt» og navnene på de to «kopiene». Resultatet av spørringa blir som dette:

Relasjoner – SQL

Når man skal hente, legge til, oppdatere eller slette data fra en relasjonsdatabase så er det naturlig å snakke om SQL. SQL står for Structured Query Language og er et spørrespråk for databaser. Nå skal ikke dette innlegget være noe SQL-kurs for sånt finner man mye bra av på nett. Jeg tenkte heller at jeg skulle vise hvordan noe spørringer vil se ut mot en SQLite-versjon av lege/pasient-databasen fra innlegget «Relasjoner – Normalisering«. Jeg brukte forresten SQLiteStudio til å opprette databasen, til å legge data inn i tabellene og for å kjøre de aktuelle spørringene. Her er den første og den enkleste SQL-spørringa:

SELECT navn, tlf FROM pasient;

SQL-spørringa over henter enkelt og greit navnet og telefonnummeret til alle pasientene. SQL-spørringer avsluttes med semikolon. Resultatet er som følger:

Vi skal nå kikke på en mer avansert spørring hvor vi henter data fra flere tabeller.

SELECT pasient.personnr AS personnr,
       pasient.navn AS navn,
       pasient.adresse AS adresse,
       pasient.postnr AS postnr,
       poststed.poststed AS poststed,
       pasient.tlf AS telefon,
       lege.navn AS lege
  FROM pasient
  INNER JOIN poststed on poststed.postnr = pasient.postnr
  INNER JOIN lege on lege.l_id = pasient.l_id;

Vi tar en stegvis gjennomgang av SQL-spørringa over.

  1. «SELECT pasient.personnr AS personnr,» betyr hent personnummeret til pasienten. I spørringer som dette som involverer flere tabeller (her: pasient, lege og poststed) så spesifiserer man gjerne tabellnavnet for feltet. Altså betyr «pasient.personnr» personnr-feltet fra tabellen pasient. «AS» betyr gi kolonneoverskrifta i utlistingen navnet «personnr».
  2. «pasient.navn AS navn,» er en fortsettelse fra linja før (legg merke til kommaet i slutten av linje 1) og betyr hent navnet til pasienten og kall kolonna «navn».
  3. «pasient.postnr AS postnr,» er postnummeret til pasienten og kall kolonnna «postnr».
  4. «poststed.poststed AS poststed,». Her henter man poststedet fra tabellen «poststed» og kaller kolonna ikke uventet «poststed».
  5. «pasient.tlf AS telefon,» som betyr telefonnummeret til pasienten og kall kolonna «telefon».
  6. «lege.navn AS lege» gir navnet til legen fra tabellen «lege» og kolonneoverskrifta blir «lege».
  7. «FROM pasient» betyr at dataene hentes fra tabellen «pasient».
  8. «INNER JOIN poststed on poststed.postnr = pasient.postnr» betyr at man henter data fra tabellen «poststed» hvor postnummeret (postnr) er likt i tabellene «poststed» og «pasient». Til informasjon så finnes flere typer med «JOINs». «poststed.postnr» er primærnøkkel i tabellen «poststed» og «pasient.postnr» er fremmednøkkel i tabellen «pasient».
  9. «INNER JOIN lege on lege.l_id = pasient.l_id;» henter data fra tabellen «lege» hvor ID-nummeret (l_id) er likt i tabellene «lege» og «pasient». «lege.l_id» er primærnøkkel i tabellen «lege» og «pasient.l_id» er fremmednøkkel i tabellen «pasient». SQL-spørringa avsluttes med et semikolon.

Resultatet som listes ut av spørringa blir slik:

Spørring nummer 3 skal hente ute en adresseliste, som inneholder navn, adresse, postnummer og poststed, for alle pasientene til legen «Petter Olsen».

SELECT pasient.navn AS navn,
       pasient.adresse AS adresse,
       pasient.postnr AS postnr,
       poststed.poststed AS poststed
  FROM pasient
  INNER JOIN poststed on poststed.postnr = pasient.postnr
  INNER JOIN lege on lege.l_id = pasient.l_id
  WHERE lege.navn = 'Petter Olsen';

SQL-spørringa over er ganske lik spørring nummer 2 så jeg går ikke i detalj gjennom hver linje, men den har fått en ny linje på slutten av spørringa. «WHERE lege.navn = ‘Petter Olsen’;» betyr enkelt og greit at spørringa skal begrenses til bare å inneholde pasientene til legen «Petter Olsen».

Legg merke til at navnet til legen ikke er med i utlistinga. Skulle det vært med så måtte man lagt «lege.navn AS lege» til i spørringa før «FROM pasient». Pass på at man har kommaene på rett plass. For de som nå fikk litt panikk så finnes det verktøy med fine grafiske grensesnitt hvor man kan bruke mer eller mindre «dra og slipp»-funksjoner (f.eks. Microsoft Access) for å generere SQL-spørringene.

Relasjoner – Verktøy

I innlegget «Relasjoner – Normalisering» gikk jeg gjennom en del av teorien bak design av en relasjonsdatabase. Vi skal nå kjapt kikke på noen systemer og applikasjoner man gjerne kommer borti i forbindelse med relasjonsdatabaser. Vi begynner med en applikasjon som kanskje mange allerede har på PCen gjennom Office-pakken. Microsoft Access er en applikasjon hvor det er mulig å lage relasjonsdatabaser. Microsoft Access har veldig mange muligheter og en del av de overlapper med Excel. Det er vanlig å bruke Access-databaser som datakilder til Excel, Power BI og for den del Word (f.eks. en adressedatabase for fletting av brev). Microsoft Access har noen begrensninger (maksgrense på 2GB og 32.768 objekter i databasen.), men for de fleste er dette ikke noe problem. De som er vant til Office-pakken og klassiske Microsoft arbeidsflater vil kjenne seg godt igjen. Applikasjonen har gode veivisere og designverktøy. Som sagt for de som allerede har denne applikasjonen så er dette et bra sted å begynne. Siden vi snakker om Micrsoft så må man nevne Microsoft SQL Server Express. Systemet som kjører som en egen tjeneste har en begrensning på databasen på 10GB, maksimalt minne på 1.4GB og kjører på 1 socket eller 4 kjerner. Det kan være at noen allerede har en Microsoft SQL Server Express installert da den gjerne installeres som databasesystem i andre applikasjoner. Det finnes en rekke andre versjoner av Microsoft SQL Server men de blir gjerne altfor kostbare for privat bruk. Det er komplett umulig å ikke nevne MySQL (uttalt ˌmaɪˌɛsˌkjuːˈɛl) når man snakker om databasesystemer. MySQL er lisensiert som åpen kildekode (GPL-lisens). Det skal sies at det har vært en del diskusjon rundt lisensieringen og Oracle som vedlikeholder MySQL i dag. Dette resulterte i 2009 at kodegrunnlaget til MySQL ble tatt videre til MariaDB i bekymring av at Oracle kjøpte Sun Microsystems som eide MySQL. MySQL er svært utbredt og brukes av veldig mange også store selskaper som Airbnb, Uber, Netflix og Dropbox. Rosabloggen kjører WordPress med nettopp MySQL i bunnen. Personlig så er dette det databasesystemet jeg har mest kunnskaper om utenom Microsoft SQL Server. Hvis man ikke har noen spesielle preferanser til MySQL så anbefaler jeg at man kikker på MariaDB som på mange måter er lik MySQL, men er gratis og garantert å forbli åpen kildekode. Selskap som Google, Wikipedia og WordPress.com bruker MariaDB. Jeg nevnte selskapet Oracle (egentlig heter det Oracle Corporation). Oracle er et gammelt selskap (grunnlagt i 1977) med titusenvis av ansatte. Selskapet er regnet som en kjempe i databasemiljøene med sitt system som har det ikke overraskende navnet Oracle Database eller bare Oracle. Det er lite trolig at man kommer borti Oracle systemer uten at man er del av et større driftsmiljø. Det er også en kjensgjerning at en del firma migrerer til andre systemer pga. kostnadene knyttet til det å ha en Oracle installasjon. Videre må jeg også nevne PostgreSQL. Utvikligen av dette systemet startet på 1980-tallet og er i dag et åpen kildekode-prosjekt, med en svært liberal lisens. Denne gjør at PostgreSQL kan brukes, modifiseres og distribueres av såvel private som kommersielle foretak uten noen som helst økonomisk kompensasjon til de originale utviklerne. Til slutt skal jeg si noen ord om SQLite. SQLite er kanskje verdens mest utbredte databasemotor. Den kjører på de fleste mobiler og datamaskiner. Den er del av utallige apper/applikasjoner som folk bruker hver dag. Vi snakker om hundrevis av milliarder av SQLite databaser i verden. Dette burde være en indikasjon på at kanskje SQLite er en god plass å begynne. Nå er ikke SQLite direkte sammenlignbart med klient/server systemer som MySQL, MarieDB, Oracle, PostgreSQL, Microsoft SQL Server osv. som egentlig skal løse litt andre problemstillinger, men for «hjemmebruk» er SQLite helt genialt. Når man laster ned SQLite fra nettsiden så bør man også laste ned pakken med kommandolinje-verktøy hvis man ikke velger et tredjepartsverktøy som SQLiteStudio. Jeg bruker selv SQLiteStudio og er veldig godt fornøyd med det. Jeg oppfordrer å donere noen kroner til utvikleren hvis man bestemmer seg for å bruke programmet. Noe av det fine med SQLite er at man kan flytte databasen mellom ulike datamaskinarkitekturer. Jeg har f.eks. tatt en SQLite database fra en Raspberry Pi og jobbet med den på en Microsoft Windows PC. Da er det bare å bestemme seg for hvilket teknisk nivå man vil legge seg på og laste ned et databasesystem.

Relasjoner – Normalisering

I innlegget «Relasjoner – Intro» ble ordet «normaliseringsformer» brukt i forbindelse med databasedesign. Teorien og spesielt ordlyden bak normalisering kan fort bli tung og vanskelig å forstå så jeg vil i dette innlegget forklare hva det er gjennom bruk av eksempler. Dessverre så vil der være noen ord og uttrykk vi ikke kommer rundt så det er bare å bite tenna sammen. Vi begynner med noen data i en tabell. Vi kaller den «universalrelasjonen». Universalrelasjonen har ingen spesielle regler utover at man har rader og kolonner. Under har jeg et eksempel på en universalrelasjon. På grunn av plassmangel har jeg brukt en del forkortelser i kolonnene overskriftene. «l_» står for «lege_». «l_navn» blir da «lege_navn». «p_» står for «pasient_» og da er f.eks. «p_navn» det samme som «pasient_navn». Til informasjon så er primærnøkler merket med grønt i kolonneoverskrifta. Universalrelasjonen viser 2 leger som har 3 pasienter og en del annen informasjon.

For å oppfylle 1. normalform (1NF) så kan tabellen ikke inneholde ikke-atomære verdier eller repeterende grupper. Med «ikke-atomære verdier» menes verdier som inneholder flere delverdier. Tabellen inneholder ikke-atomære verdier i feltene «l_adr» og «p_adr» som består av gateadresse, postnr og poststed. Med «repeterende grupper» menes at det finnes mer enn en verdi i krysset mellom rad og kolonne. De repeterende gruppene i tabellen er: «p_personnr», «p_navn», «p_adr» og «p_tlf». Når man deler opp «l_adr» og «p_adr» i sine respektive kolonner («l_adr», «l_postnr», «l_poststed» og «p_adr», «p_postnr», «p_poststed»), og legger den ekstra pasienten i den repeterende gruppa på en egen rad så oppfyller man 1NF. Tabellen under viser hvordan det vil se ut. Legg merke til at «l_id» og «p_personnr» nå er primærnøkkel siden man ikke unikt kan identifisere den riktige raden for en pasient basert på «l_id» alene.

I 2. normalform (2NF) må alle verdier være fullt funksjonelt avhengig av primærnøkkelen. Med «full funksjonell avhengighet» menes at man ikke har noen partielle avhengigheter. Partiell avhengighet betyr at en verdi er avhengig av kun deler av primærnøkkelen (i tabellen over består primærnøkkelen i grønt av «l_id» og «p_personnummer»). «l_navn» er partiell avhengig av «l_id», men ikke «p_personnummer». På samme måte er «p_navn» partiell avhengig av «p_personnummer», men ikke «l_id». For å fikse dette må tabellen splittes i to. Jeg har kalt tabellene «lege» og «pasient». Legg merke til kolonnen «l_id» i tabellen «pasient». Dette er en fremmednøkkel og brukes til å koble pasientene mot riktig lege.

For at en tabell skal kunne være i 3. normalform (3NF) så kan man ikke ha noen transitive avhengigheter. Transitiv avhengighet betyr at en verdi er avhengig av en annen ikke-primærnøkkel-verdi. I de to tabellene over så er «l_poststed» transitivt avhengig av «l_postnr» og «p_poststed» transitivt avhengig av «p_postnr», men verken «l_postnr» eller «p_postnr» er noen primærnøkkel. For å fikse dette så flyttes poststedene ut i en egen tabell (poststed) hvor postnr er primærnøkkelen. Tabellene under oppfyller nå 3NF.

Til slutt skal vi se på Boyce-Codd normalform som også omtales som BCNF eller 3.5NF. For at en tabell skal kunne være i Boyse-Codd normalform, må alle determinanter være kandidatnøkler. En determinant er en attributt eller gruppe attributter som en annen attributt er fullt funksjonelt avhengig av. Et eller flere attributter som sammen identifiserer en entitet unikt kalles en «supernøkkel». Minimalistiske supernøkler, dvs. at man kan fjerne et attributt fra en supernøkkel og så er det fortsatt unikt kalles en kandidatnøkkel. Kandidatnøkler er sikre identifikatorer for en rad, og kan brukes som primærnøkler og som referanser for fremmednøkler. I vår tabell er det ingen brudd på Boyce-Codd normalform. Determinantene er: personnr(pasient), postnr(poststed) og l_id(lege). Kandidatnøklene er: personnr(pasient), postnr(poststed) og l_id(lege). Dersom en tabell er normalisert til 3NF, vil den i de fleste tilfeller også innfri kravene til BCNF. Brudd på BCNF er sjeldne og litt vanskelige å håndtere på en god måte, så derfor stopper man ofte normaliseringen når tabellen er på 3NF. Da har vi vært gjennom den tyngste og viktigste teorien når man skal lage en relasjonsdatabase. Men hvor skal man lage en relasjonsdatabase? Innlegget «Relasjoner – Verktøy» vil kunne gi noen svar på det.

 

Relasjoner – Intro

Som min del av det kollektive ansvaret med å gjøre verden en bedre plass å være så tenkte jeg å slå et slag for relasjonsdatabaser. Jaja, kanskje ikke bedre for de aller fleste andre mennesker, men det kan gjøre hverdagen betydelig bedre for deg selv. Til informasjon så blir ikke dette noe omfattende kurs i databasedesign for det finnes det allerede mye av på nett, skrevet av folk som er langt flinkere enn meg på dette området. Så hva er en relasjonsdatabase? Relasjonsdatabaser bygger på relasjonsmodellen som ble utviklet av Edgar Frank Codd på 1960-tallet og presentert i den banebrytende artikkelen «A Relational Model of Data for Large Shared Data Banks» tidlig på 1970-tallet. Oppsummert så handler relasjonsmodellen om at data er lagret i tabeller eller relasjoner, og det er satt opp regler for hvordan relasjoner kan utformes. I en relasjonsdatabase som følger normaliseringsformene (se innlegget «Relasjoner – Normalisering» for mer informasjon) så bidrar unike identifikatorer til å beskytte dataene, og de sikrer at ingen to rader (eller poster) inneholder de samme dataene i en tabell. Du kan også bruke disse identifikatorene til å relatere poster i en tabell til en eller flere poster i en annen tabell. En relasjonsdatabase kan kreve at nye poster i en tabell har en eksisterende og tilsvarende verdi i en annen tabell. F.eks. så kan man ikke opprette en ny ordre i en ordretabell uten at det finnes en tilsvarende kunde i en kundetabell. Vi snakker om referanseintegritet. Neste innlegg handler om normalisering og det innlegget finner du her.

Velkommen

Jeg går ut i fra at du aldri har vært her før siden du leser dette. Jeg setter selvsagt umåtelig stor pris på at du velger å bruke av din tildelte tid på denne planeten til å lese bloggen min. Når jeg tenker meg om så er det kanskje litt snevert å skrive «planeten». Det kan jo være at en astronaut og/eller en av de andre nautene leser bloggen og de er jo teknisk sett ikke på planeten. Tror jeg endrer teksten til: «Jeg setter selvsagt umåtelig stor pris på at du velger å bruke av din tildelte tid i dette universet til å lese bloggen min.». Vent nå litt! Universet blir kanskje også for snevert for denne bloggen. Hva med alle multiversa!? Hmm… nok om det. Jeg får til stadighet spørsmål om hvorfor en gammal gris som meg har en «rosablogg» gjerne etterfulgt av hånlatter eller mistro. Jo, nå skal jeg fortelle om akkurat det. Man må helt tilbake til 21. januar 2015. Ja, i gamle dager før ungdommen fant ut at ho mor posta festligheter og strikkeoppskrifter på SoMe (sosiale media) og bytta fra Face til Snap og Insta i ei snøkave. Når folk flest posta middag og dobesøk på Facebook så posta jeg gjerne lange avhandlinger om mer eller mindre helt uvesentlige ting, kidnappa tråder, høvla ned skrytemeldinger og en og annen hypokonder. Jeg tvang informasjon på andre i den ene posten etter den andre. Dette genererte selvsagt en del støy blant middag- og lunsjbilde puristene. Det hele kulminerte i det ei ung og matlei kvinne forslo at jeg burde poste mer matoppskrifter på en egen «rosablogg». Selvsagt må jeg ha en «rosablogg», og et par timer senere så var Rosabloggen slik vi kjenner den i dag kreert. Rosabloggen er med andre ord en monologisk kommunikasjonsplattform etablert av allmenne hensyn. Legg merke til ordet «monologisk», for her på bloggen har du nemlig ikke muligheten til å kommentere noe som helst. Enjoy!

This entry was posted on 25. mai 2020, in Blogg.

Pimm´s

Siden det er vår (i alle fall på kalenderen) og sommer snart så tenkte jeg at jeg skulle legge ut en real britisk drink til å ha i solveggen. Jeg kaller den bare «Pimm´s» for den er basert på Pimm´s No. 1 Cup. Pimm´s er en gin-basert likør på 25%. Pimm´s er ikke noe nymotens greier må du tro. Pimm´s ble laget av James Pimm (1798–1866) første gang i 1823. «Pollista» skriver følgende om smaken: «Søtlig drikk med fint preg av sitrus og krydder, bitter ettersmak. Middels fylde.». Der er mange oppskrifter på en Pimm´s men min er som følger. Jeg har ikke noen eksakt oppskrift her, så jeg anbefaler at man prøver seg litt fram med mengden Pimm’s. Jeg bruker en god «dæsj». I en oppskift jeg fant på nett så opererer de med 4 cl Pimm’s og 12 cl sitronbrus, altså et blandingsforhold på 1:3, men man kan godt prøve seg med 1:4 først. Jeg har enda ikke klart å rote dette til for har man for lite så tilsetter man mer Pimm’s og har man for mye så kjører man på med mer sitronbrus.

  1. Mugge med en del is.
  2. Tilsett en «dæsj» Pimm’s.
  3. Skivet agurk (pass på mengden hvis man ikke er glad i agurk for det setter mye mer smak enn man skulle tro)
  4. Skivet jordbær. Ofte brukes appelsinskiver eller gjerne begge deler.
  5. Mynte
  6. Fyll på med sitronbrus (bruker ofte Sprite selv)
  7. Rør om

Pimm´s er sammen med champagne en av de to offisielle drinkene ved Wimbledon. Det selges faktisk 80.000 pints (1 imperial pint (Storbritannia) = 20 UK fluid ounces ≈ 568 milliliter) på Wimbledon hvert år. Hvis noen er skikkelig fine på det så kan man jo prøve seg på en «Pimm’s Royal Cup» hvor man blander Pimm´s og champagne. Skål!

Spektrum data – Python

Jeg pleier ikke legge ut kildekode for de prosjektene jeg lager. Hovedgrunnen til dette er at jeg sjelden skriver kommentarer i koden og programmeringen kan være litt vel røff (les: komplett blottet for exception handling). Denne gangen gjør jeg et lite unntak siden jeg har fått en del spørsmål om hvordan jeg håndterte pakken med spektrum data som FM24-NP100-modulen sender. Her er Python-koden som kjøres på Raspberry Pien. Bruk den på eget ansvar!

This entry was posted on 22. mai 2020, in Blogg and tagged .

Spektrum data – Errata

I innlegget «Spektrum data» snakket jeg om hvordan bruke spektrum dataene fra FMCW radaren til å detektere flere objekter. Innlegget hadde en del beregninger basert på en λ (bølgelengde) på 0,126 m. Dette tallet fant jeg etter mange timer med søk på nettet. Det var brukt i kildekoden til et Arduino-prosjekt som nettopp involverte FM24-NP100-modulen. Jeg må innrømme at de teoretiske beregningene jeg gjorde ved å bruke den omtale bølgelengden ikke fikk noen bjeller til å ringe hos meg. Ting så egentlig helt greit ut. Det var ikke før jeg gjennomførte praktiske tester med FMCW radar HATen at jeg så at noe var veldig galt. Eksperimentet var veldig enkelt og bestod av HATen og en metallplate. Helt tilfeldig satt jeg metallplaten 75 cm fra radaren. Radaren målte nøyaktig 75 cm, men beregningene basert på tilsvarende spektrale linje var helt feil. Tar man bølgelengden (0,126 m) og ganger med nummeret til den sprektrale linjen (her 10) så får jeg 126 cm. Det var ikke tvil om at det var rett spektrale linje da amplituden var 43 (spektrum dataene har en maksimal amplitude på 44). Det var da jeg skjønte at bølgelengden var feil. Deler jeg 0,75 m på 10 (spektral linjenummeret) så får jeg en bølgelengde på 0,075 m. Så hvor kommer da 0,126 m fra? Denne FMCW radar-modulen opererer på 24 GHz (24 til 24.250 GHz). For å finne bølgelengden til 24 GHz så deler man 300 000 000 m/s (lysets hastighet er egentlig 299 792 458 m/s men det rundes veldig ofte opp til 300 000 km/s) på 24 GHz. Man får da en bølgelengde på 0,0125 m (legg merke til antall desimaler). En bølgelengde på 0,125 gir en frekvens på 2,4 GHz som er 10-ganger mindre enn 24 GHz. Man kan jo bare spekulere i hva som er skjedd her, men skal jeg tippe så har de hatt en null for mye i lysets hastighet (les: 3 milliarder og ikke 300 millioner m/s). Hvor 6-tallet i 0,126 kommer fra skjønner jeg heller ikke for det krever en frekvens på 2 380 952 380.95 Hz som ikke akkurat ligner på 2 400 000 000 Hz. Alt tyder på at de har to betydelige skrivefeil i beregningene sine, men den største glippen er at de har tenkt helt feil når gjelder hvilke frekvens å bruke som grunnlag. Eksperimentet mitt viste en bølgelengde på 0,075 m er rett, men hva frekvens er så dette? Deler man 300 000 000 m/s med en bølgelengde på 0,075 m får man en frekvens på nøyaktig 4 GHz. Dette kan umulig være en tilfeldighet. Radaren «jobber» med andre ord ikke på 24 GHz men på tilsynelatende 4 GHz (som er 1/6-del av 24 GHz). Nå har jeg veldig lite peiling på beregninger med radar og riktig bruk av radarterminologi så jeg slår meg til ro med at det bare er slik. Med en bølgelengde på 0,075 m så er første spektrale linje 7,5 cm fra radaren og siste (126) spektrale linje 9,45 m fra den. De spektrale linjene vil ikke alltid gi helt nøyaktige avstander da hver spektrale linje har en bølgelengde på 7,5 cm. Jeg målte f.eks. 43 cm nøyaktig og fikk utslag på spektral linje 6 som gir 45 cm. Forskjellen mellom de to er 2 cm men det kan jeg leve med. Til slutt må jeg bare beklage at jeg ikke kvalitetssjekket beregningene til andre før jeg tok de i bruk, og nei jeg har ikke tenkt å fortelle dem den rette bølgelengden.

This entry was posted on 21. mai 2020, in Blogg and tagged .