RMSG Raspberry Pi modul (elektronik)

[lath]

Indledning

Jeg vil her løseligt beskrive noget elektronik jeg lige er færdig med at designe for raket foreningen RMSG (http://rmsg.dk/), som jeg er medlem af, og som hjælper Raket Madsen (http://raketmadsen.dk/) med hans raketter til bemandet rumfart (en såkaldt suborbital tur til rummet). Peter Madsen er astronauten.
Raketten er en hybrid-raket der bruger Træ som brændstof, og rocketgrade H2O2 (brintoverilte) som iltningsmiddel/oxidationsmiddel.

Det jeg har lavet er et strømforsynings- og kommunikations- modul til en Raspberry Pi B+ computer. Modulet strømforsyner en Raspberry Pi med strøm via GPIO pin 2, P1 headeren. Vi bruger en Raspberry Pi B+ til at kommunikere med andre moduler der enten foretager fysiske målinger (kompasmåling, og GPS) og/eller har 2 aktuatorer (styring af 2 mortorer) på en antennerotor og/eller en propeller der roterer den flere tons tung raket-bøje til at pege i den rigtige retning.

Årsagen til at vi har brug for en Raspbbery Pi B+ med tilhørende modul er at vi skal etablere et 100 Mbit/s (upload og download) internet ca 30 km fra Bornholm ude i Østersøen i det millitære testområde ES D 139, som vi lånes af flåden/NATO.
Internet opkoblingen ude i Østersøen bruges til live streaming af opsendelsen ikke ulig Copenhagen Suborbitals som Peter Madsen er en af de 2 stiftere af, men senere forlod for at gå solo: https://www.youtube.com/watch?v=kcF5xNrb3HA&t=14m32s
Video: Opsendelse af raket, luftrummet såvel som farvandet er spærret af via ordre fra ATC Sweden og farvandsmyndighederne. Raketten kom op i en højde svarende til Mount Everest minus 300 meter på under 30 sekunder.

Schematic
Et schematic er hvordan de elektriske komponenter er forbundet.

Download fra mit website:

• PDF http://larsth.dk/rmsg/rmsg_rpi_module.pdf
• Raspberry Pi modulet, kommunikationsdelen som SVG billede: http://larsth.dk/rmsg/rmsg_rpi_module.svg
• PSU som SVG billede: http://larsth.dk/rmsg/psu.svg

Forklaring af hvad det er du kigger på.

• Raspberry Pi modulet, kommunikationsdelen:
  
  • Øverst til venstre ser du 2 parallel-forbundne RJ45 konnektorer. RJ45 konnektorer bruges normalt til Ethernet kablede internetforbindelser, men her bruges de til en full-duplex RS422 netværk/bus. Brugen af RJ45 gør det muligt at bruge COTS (Commercial Off The Shelf=kommercielt-lige-ned-fra-hylden) straight-through Ethernet kabler til forbindelsen imellem 2 eller flere moduler.
  • Jumpers, JP1,JP2, JP3, JP4 lige før 75176 RS422 transceiverne er til terminering af RS422 bussen - bruges til at få signalerne på RS422 bussen til blive bedre (modvirker f.eks. ringing, og reflektioner. Termineringen foretages ved modtageren i hver ende af kablet.
  • 100 ohms modstanden (R5) imellem RS422 ground og ground referencen til +5 volt er til udligning af spændingspotentialer på ground imellem moduler.
  • IC1, og IC2 er de nævnte RS422 transceivere. IC1 er hard-wired til at være en modtager, og IC2 er hard-wired til at være en sender. IC1 oversætter diffenrentialsignalerne på en RS422 bus til digitale +5 volt TTL logisk niveau signal. IC2 gør det samme, men i modsat retning.
  • IC3 og IC4 er optokoblere. En optokobler bruger lys til at overføre et signal. Lyset adskiller sender delen elektrisk fra modtager delen, sådan at sender og modtager kan bruge forskellige elektriske spændinger, hvilket er heldigt da en Raspberry Pi har +3,3 volt CMOS logik indgange, der ikke er +5 volt tolerant.
    
  • Lige efter optokobleren på +3,3 volt siden er der 2 schmitt-trigger invertere koblet i serie. De har flere formål. Schmitt-triggeren på indgangen af inverteren er mindre støj-følsom, og den strøm-forstærker også signalet. Udgangssignalet kan umiddelbart bruges af Raspberry Piens mikroprocessor. Modstanden (R11 på 2K2 ohm) imellem udgangen og hen til GPIO headeren er til en fejl 40 konfiguration, hvor den pin bliver bliver konfigureret som udangsport, hvilket er en regulær kortslutning der brænder Raspberry Pi processoren af!
    Modstanden begrænser strømmen til: (U/R=I) => 3,3/2200 = 1,5 milli-ampere (mA) , hvis det skulle ske, og så sker der ikke andet at det bare ikke rigtig virker.
• PSU, strømforsyningerne
  
  • Jeg har fået et vide at strømforsyningerne (Øverst: +5 volt, 3 A) og Nederst: (+12 volt, 3 A.) strømforsynes med enten vekselstrøm via en 230 VAC, 50 Hz transformator, 24 VDC fra en bly akkumulator, eller 36 VDC fra 3 seriekoblede 12 volt blyakkumulatorer.
  • +5 volt, 3 A. strømforsyningen er til strømforsyning af en Raspberry Pi, og 12 volt, 3 A. strømforsyningen er til strømforsyning af andre moduler.
  • Det hele starter midt imellem de 2 strømforsyninger ved konnektoren P2 - her går strømmen ind i kredsløbet.
  • Lige efter P2 er der en modstand og så 2 lysdioder der er parallelkoblet sådan at den enes anode er forbundet til den andens katode. De gør at en af de 2 lysdioder lyser. Ved vekselstrøm skiftes de til at lyse hver gang strømmen vender. Ved jævnstrøm er det kun den en af dem der lyser. De 2 lysdioer bruges til at se om der er strøm tilsuttet strømforsyningen.
  • Hver strømforsyning har derefter en træge (T.) 4 ampere (A.) sikring.
  • Derefter følger en Graetz bro der uanset hvilken polaritet indgangsspændingen har sender strømmen i kun 1 retning.
  • Straks efter Graetz broen er der en 100 nF (nano farahd) kodensator til at æde/dræbe RF energi fra mobiltelefoner og andre radiosignaler.
  • Så er der et "Undervoltage lock-out circuit" der forhindrer at en switch-mode strømforsyning tænder, hvis spændingen er for lav.
  • IC7 og IC8 er selve switch mode strømforsyningen. Den arbejder ved 52 KHz.
  • Swich mode strømforsyninger er et komplekst emne så jeg undlader at beskrive hvad der foregår. De nysgerrige kan læse op på emnet "buck switch-mode power supply". Alle skrå linier i schematic angiver at komponenten skal være tær på ICen, og dermed placeringen af komponenten er meget kritisk for om switch-mode strømforsyningen kommer til at virke korrekt.
  • Før sikringen har vi en gul (yellow) lysdiode til at forælle om switch-mode strømforsyningen laver strøm til os.
  • Så er der en 3 ampere træge sikring efterfulgt af et ripple filter, der fjerne 52 KHz brummen fra udgangsspændingen. Dette er vigtigt for digital elektronik der ikke kan lide knas i strømmen.
  • Så er der en grøn (green) lysdiode til at fortælle os om strømmen har passeret sikringen.
  • Tilbage på Raspberry Pi modulet finder vi +5 volt der går ind i en P-type enhancement MOSFET transistor der er styret af 2 komplementære PNP bipolar transistorer. Det lille kredsløb: Q2, IC6, R12, og R13 er en ideel diode med ca 0 volt spændingsfald over sig, når den leder strømmen fra anode til katode. Den ideelle diode forhindrer strøm tilsuttet via en strømforsyning på Raspberry Pi i at gå ind i Raspberry Pi modulet, men tillader samtidigt også at Raspberry Pi modulet kan strømforsyne Raspberry Pi computeren.

/Lars

[lath]

Jeg har opdaget at hardwaren vil være begrænset af hastighederne, der er nævnt i header filen termios.h
Det vidste jeg godt før jeg startede, og projektet ikke brug for store hastigheder - endnu.

Med cfsetspeed funktionen kan vi sætte hastigheden til maximum 230.400 baud - macroen B230400, og ikke højere.

Et sted på SO (Stack Overflow) har jeg læst om at der findes uofficiel funktionalitet der kan give højere hastigheder (det lyder næsten som Windows, ikk?), men det giver dog ikke drastisk meget højere hastighed.

Da jeg har designet min hardware til at kunne full-duplex 10 Mbit/s (der kan opgraderes til 25 Mbit/s), så kræver det ganske enkelt en RS485/RS422 device driver i kernel space, og dens implementering prøver jeg at få hul på i efteråret 2015.

Heldigvis har jeg allerede lavet 2 kernel space character device driver før - og også til ARM arkitektur - bare ikke lige Raspberry Pi som ikke fandtes på det tidspunkt, så helt fremmed er det ikke for mig. Linux var iøvrigt et af de fag, hvor jeg fik en 12´er fra Ingeniørhøjskolen.

Omskrivningen af den eksisterende driver er i praksis noget med at omskrive den nuværende low-level character device driver med flere tilstande, der aktiveres via ioctl systemkald fra user space.
Det kunne for eksempel være en ny brugervenlig superbruger kommando, der laver ioctl(2) systemkald med de parametre min device driver forventer.

Hvorfor vil jeg så lave det, når det nu ikke er strengt nødvendigt?
Af samme årsag som jeg deltager i et projekt der laver bemandet rumfart: Fordi man kan - og så er det iøvrigt sjovt at være med på vejen til at opnå målet: En astronaut i rummet + lille Danmark bliver den 4. rumfartsnation.

/Lars