-
GAMEPOD.hu
Amit érdemes tudni a Raspberry Pi-kről:
A legelső változat 2012-ben jelent meg. Pici, olcsó és nagyon alacsony fogyasztású, hobby-célú kártyagép. Felépítése ARM alapú, nem PC-architektúra, hanem kb. egy régi mobilhoz hasonló. Nagyon sok mindenre használható! A Linux-nak és a magas eladási mennyiségnek köszönhetően jelentős fejlesztőtáborral rendelkezik.
Új hozzászólás Aktív témák
-
atesss
addikt
Hát a kártyákból nagyobb részt a meglévőimet használnám.
Elég vegyes, de biztos akad közte amin élettartam garancia is volt. Van közte V30-as sebességű is.
1-2 újat is lehet venni akár, de HW szinten túl sokat nem akarnék eszközre költeni. Nem tudom mennyivel drágábbak az élettartam garisok.
Ipari kártyára tudsz példát mutatni ?Ha kezd elromlani, azt miből fogom észrevenni ?
A legfontosabb kérdés, hogy van-e valamilyen előjele. Vagy van-e valamilyen teszt, amit távolról (=nem szedem szét a helyet ahova be van építve az eszköz) pl. 3-4 havonta lefuttatva meg tudok bizonyosodni hogy még nincs komolyabb probléma.- ramdrive nem biztos hogy megfelelő. Sajnos pl. egy hiba esetén lehet az lesz az "automatikus" a használatban, hogy áramtalanítják. Na és ugye akkor lehet pont arról nem lesz meg a logom, hogy mi okozta a hibát...
- Pendrive: mindegyikhez rakni az azért már plusz költség. Meg van ahol hely se lesz neki. De az egyszerre több mindent csináló (pl. az adott játékelem funkción felül MQTT broker, "Okosotthon" szerver, VOIP szerver) játékelemnél megfontolandó.
- Hálózati meghajtóra min. naponta egyszer terveztem átmenteni a logokat.
De lehet azt is hogy folyamatosan oda menti csak. Ha meg épp nem tudja elérni akkor menti helyben. Annyi a szépséghiba, hogy a hálózati meghajtó is biztosan egy Raspberry lesz. Sőt, még az se biztos hogy lesz neki külön (=játékelemként nem működő).Hát a felhasználását nézve ez igazából nem hobby projekt lesz...
zsolt_64
Hát 4-es nem valószínű hogy lesz. A 3B+-al és a 3B-vel is megy az USB boot ?
USB 2-vel persze biztos lassabb, de a cellavédelemben viszont segíthet.
Ehhez milyen olcsóbb pendrive-ot tudsz ajánlani ?
USB2-es külső házban egy régebbi 2,5" HDD kb. mennyit fogyaszt ? Felpörgés/írás-olvasás/idle ?[ Szerkesztve ]
-
atesss
addikt
válasz
zsolt_64
#38040
üzenetére
Az egyik RPI-re akkor meg lehetne lépni hogy rakok rá egy használt 32GB/64GB SSD-t.
Az RPI4-nek gyorsabb az USB-je a 3B+-nál, hogy ha csak USB 2.0-s eszközzel használom (ha az SSD egy USB2-es házba kerülne csak) ?Hát igen, az egyik helyre nem lenne rossz egy 4-es RPI.
Végül is maga az alaplap ft-ban (nem arányában...) nem olyan sokkal drágább még egy használt 3B+-nál sem.
Az SD ugyanaz, a tápból meg a sínes biztos elbírná a 4-est is a kiegészítőkkel együtt.
Még a hűtés ami gond a 4-esnél, hogy sajnos kell neki...
Illetve ami még probléma, hogy a 4-eshez nem tudok olcsó sínre pattintható házat.
Van valakinek erre tippje ?
3-ashoz ezt szoktam: [link]
A gyártó már rég kiadta a 4-eshez valót is, de sajnos sehol sem lehet kapni külföldön sem.A tápellátás úgy lenne, hogy az UTP kábelen az adat mellett 12V-os táp is megy (passzív POE). Egy ilyesmi szettel: [link]
Abból pedig az egyes RPI-knél galvanikusan leválasztott DC-DC konverterek csinálnak 5V-ot, és a GPIO-n kötöm be az úgyis mindenhol meglévő perifériás nyák-panelről.
Vagy nyákba szerelős: [link] (1,6A) vagy [link] (2,4A), esetleg ha nagyon kell a nagy áram akkor [link] (4A).
Vagy sínre pattinthatós: [link] (3A)
De felmerült az is, hogy az egyik helyen (amelyik a legkevésbé fontos megbízhatóságban, illetve a legkevesebbet fogyasztja) kipróbálnék egy nem leválasztott konvertert is, pl.: [link][ Szerkesztve ]
-
atesss
addikt
válasz
zsolt_64
#38045
üzenetére
egy bevált külső ház: axagon ee25-xa6
Na mondjuk 2500-ért nem drága. Régen vettem már, azt hittem még mindig 4-5e+-os kategóriában vannak a használhatók (=tud Smart-ot, nem esik szét magától, stb.).
Én eredetileg az egyik régi külső vinyómnak akartam egy új USB3-as házat venni, és a megmaradó USB2-est adtam volna annak az RPI-nek
Keem1
Mondjuk nekem nagyon nem asztali gép jelleggel lenne használva, így a sebesség nem különösebben számít. Csak amíg programozom-beállítom-tesztelem(újraprogramozom).[ Szerkesztve ]
-
#38056
atesss
addikt
wassermann
#38051
atesss
addikt
válasz
wassermann
#38051
üzenetére
Ez nem növelheti az instabilitás kockázatát ?
Van amúgy teszt erről, hogy a gyakorlatban mennyit gyorsít (megfelelő kártya esetén) ?
És melyik PI-k esetében működik ? 3B, 3B+, vagy a 4-es is ?
[ Szerkesztve ]
-
atesss
addikt
válasz
BalanceR
#38047
üzenetére
A pi4-el érkezett VLC már úgy rémlik tudja. Legalábbis mintha ezt reklámozták volna róla mikor megjelent.
De az x265-öt még szerintem nem tudja.
Nekem egyszer 4db, kb. 720p-s x264 RTSP stream-et vitt párhuzamosan 4db VLC ablak egy PI4-esen, és nem volt jelentősebb prociterhelés.
De ha megmondod milyen példa fájlal próbáljam (nco**-ról is ok amihez van sample), letesztelem, mert én is kíváncsi vagyok. -
atesss
addikt
válasz
BalanceR
#38060
üzenetére
Ja hogy 4K...
Hát, azzal még asztali gépnél is van gond.
Okés, tényleg sokkal erősebb lett a PI4 mint a korábbiak, de ezt még így is túlzás lenne elvárni tőle, főleg az árkategóriáját nézve.
Én azt se tudtam hogy a H265 1080p megy rajta.
Ami fura, hogy az elvileg régebbi H264 meg nem megy. De mondjuk nem tudom a "HEVEC" mit jelent pontosan, utánanézek.
Kipróbáltam amúgy a PI4-en a fájlt, VLC-vel. Hát nem teljes képernyőn eléggé akad, teljes képernyőn már be se jön (fekete a képernyő). -
atesss
addikt
-
atesss
addikt
Láttam egy érdekes kialakítású SSD "foglalatot" Raspberry-hez: [link]
Itt van róla több infó meg képek a főnyákra felszerelve is: [link] (középtájon).
Nagyon kompakt, egy darab mSata SSD-t lehet bele tenni, USB 3.0-n csatlakozik, de úgy hogy nem lóg ki, hanem van egy külön kis "USB átvezető" nyákocska. Az RPI gyári csavarozási pontjaira csatlakozik. És nem blokkolja a GPIO-t sem, sőt igazából semmit, csak felfele foglal helyet. Talán a kamerakábel bedugáshoz kellene egyedül leszerelni.
Egy USB-s házhoz képest drágább, de az egyedi kialakításhoz képest nem tűnik vészesnek ~5000Ft-ért. -
atesss
addikt
válasz
BalanceR
#38063
üzenetére
Na most én is érdekes problémába futottam bele a video-dekodolást tekintve.
Adott egy USB-s endoszkóp kamera (olcsó kinai cucc, de ahhoz képest amúgy annyira nem is rossz a képe meg egész erős a ledlámpa rajta). 640*480-as (VGA) valós felbontással (dobozon 2 mpixelt reklámoznak...). RPI simán felismeri /dev/video0-ként.
Ennek a képét jeleníteném meg a PI-vel. Teljes képernyőn, automatikusan ez indulna a rendszerrel bekapcsoláskor.
Majd a terv szerint egy 3" körüli (vagy amit lehet minél olcsóbban kapni) LCD lehetne rajta, de most a HDMI-s max. 1920*1200 pixeles monitorommal tesztelem.
Hát RPI3B+-on VLC playerrel akad...
320*240 ablakban még "csak" 80%proci. 640*480 ablakban már 100%, és érezhetően akad. 1280*960 teljes képernyő: nagyon akad és majdnem lefagy.
VLC-t direkt frissítettem előtte (3.10), de a Raspbian nem a legújabb (kb. 1-1,5 éves kiadás lehet).
RPI4 4GB-al viszont tökéletesen megy 1920*1200 teljes képernyőben is (20% alatti proci).
Pedig én eredetileg azt terveztem hogy egy régi RPI2-est raknék be ennek... -
atesss
addikt
Raspbian verzióját mivel tudhatom meg ?
uname -aahogy látom csak max. közvetve mondhatná meg.
Azt sejtem, hogy még egy 9-es (Stretch) lehet rajta, és nem 10-es (Buster).
Ilyen szintű változásnál egy sudo apt-get upgrade-es frissítés működhet rendesen, vagy telepítsem újra nulláról, image-ből ? -
atesss
addikt
Hát most hirtelen nem tudom mi van a rendszeren. Program ugyan nem sok, de lehet benne olyan ami kell (pl. Python HW-kezelő library-k, amit már egyszer kikísérleteztem hogy pontosan melyik a megfelelő).
Úgyhogy akkor asszem inkább lemásolom az SD-kártyát PC-n, dd-vel.
És csinálok egy fresh install-t.
Ha meg nincs különbség a VLC-ben, lehet vissza is másolom a régi image-et...
Amúgy a dd-vel hogyan lehetne kiíratni valami státuszt (pl. %) ? -
atesss
addikt
válasz
atesss
#38098
üzenetére
Megcsináltam a teljes újratelepítést.
És most már nem akad !
Most 1920*1200 képernyővel, 640*480 ablakban 10-15% a prociterhelés a 3B+-on.
Teljes képernyőn se lehet sokkal több, de ezt ugye csak visszanézni tudom a CPU Usage Monitor Panel Appletben, és az nem annyira pontos.Hát ahhoz képest, hogy elvileg alig egy hete jelent meg ez a legújabb image (Version:May 2020, Release date:2020-05-27, Kernel version:4.19, Size:2523 MB), eltartott neki egy darabig a frissítés. GUI-ból, az indításkori kezdőlépésekkel csináltam. Az SD kártya itt csak V10-es 16GB Adata, de azért ez is egy gyorsabb darab.
Erre a legfrissebbre most ezt írja:pi@raspberrypi:~ $ uname -aLinux raspberrypi 4.19.118-v7+ #1311 SMP Mon Apr 27 14:21:24 BST 2020 armv7l GNU/Linuxpi@raspberrypi:~ $ cat /etc/issueRaspbian GNU/Linux 10 \n \lMielőtt újrahúztam, megnéztem a régit is amiről frissítettem:
pi@RPI_CSI_VideoP:~ $ uname -aLinux RPI_CSI_VideoP 4.19.42-v7+ #1219 SMP Tue May 14 21:20:58 BST 2019 armv7l GNU/Linuxpi@RPI_CSI_VideoP:~ $ cat /etc/issueRaspbian GNU/Linux 9 \n \l
Ebben amúgy annyi a fura, hogy a Wikipedia alapján [link] 4.19-es kernellel már csak a Raspbian 10-es (Buster) volt.Amúgy nem túl up-to-date ez a Wikipedia oldal, 2020-02-13 a legújabb szerinte. Mindezt úgy, hogy viszont már "Raspberry Pi OS" néven írják...
Ami viszont tudtommal csak a 8GB-os verzió megjelenésével egy időben változott meg úgy egy hete [link][ Szerkesztve ]
-
atesss
addikt
válasz
vpleft
#38107
üzenetére
Ez kicsit off lesz, mert én ezt PC-n csináltam (Ubuntu 14.04).
Én végül addigra már innen kinéztem meg az opciókat: [link]
A status=progress nem működött, mert csak 16.04-estől van, így én pv-vel csináltam:sudo dd if=/dev/sdb | pv -s 2G | dd of=DriveCopy1.dd bs=4096
Méretnek 16G-t írtam, ami miatt a % nem volt teljesen pontos (91% volt a vége).
A cat amúgy miért gyorsabb ?
Hogy ne csak off legyek, ezt a dd-s mentést mondjuk lehet kényelmesebb lenne az aktuális Raspbian alól csinálnom. PI4-esen főleg, úgy hogy ott van már USB3.0 is.
Van bármi akadálya a futó Rasbian DD-zésének ?
Ha a tárhely ahova DD-zném egy külső HDD, akkor lehet probléma (vagy jelentősebb lassulás), ha az NTFS fájlrendszerű ?
Régebbi PI-ken (leginkább 3B+) csak annyi hogy az USB2.0 (meg persze a forrás, a fő SD kártya) sebessége limitál, vagy ott már ez sokkal lassabb lenne ?
Visszaállítani image fájlból a futó rendszernek az SD-kártyájára esélytelen ?
És azt hogyan tudnám megoldani, hogy csak annyi helyet foglaljon egy-egy ilyen image, ami tényleg a foglalt hely volt a partíciókon ?
Lehetőleg úgy hogy nem utólagos ZIP-eléssel (bár amúgy úgy láttam most hogy a Balena Etcher ZIP-fájból közvetlenül is ki tudott írni a kártyára). -
atesss
addikt
No, asszem most Raspberry-s hetet tartok
Adott egy Raspberry Pi 3B, amit egy szabadulós játékban használnak játékelemként, én csináltam kb. 3 éve. Eddig hiba nélkül üzemelt. De vidéken van, úgyhogy egyelőre csak távolról látok rá (RealVNC) + segítenek a helyben dolgozók.
Gyakorlatilag egy videolejátszó, pipresents-en keresztül GPIO pinek "nyomkodására" videófájlokat játszik le.
A gombok és a "virtuális gombok" kezelésére egy 40p szallagkábelen csatlakozó panel van.
De most úgy néz ki HW-es probléma lehet vele, a videók maguktól indulnak el. A fizikai gombokból pedig csak egy megy (és amúgy az se azt indítja amit kellene).
A pipresent logja:3.40871691704 PiPresents_1967234192: event received: tavgomb2_Stop from GPIO3.40894603729 PiPresents_1967234192: event received: tavgomb3_Stop from GPIO3.40907907486 PiPresents_1967234192: event received: button2 from GPIO3.40920805931 PiPresents_1967234192: event received: button3 from GPIO3.40932798386 PiPresents_1967234192: event received: tavgomb4_Stop from GPIO3.40944194794 PiPresents_1967234192: event received: tavgomb6_Stop from GPIO3.40955901146 PiPresents_1967234192: event received: tavgomb7_Stop from GPIO3.40967297554 PiPresents_1967234192: event received: tavgomb8_Stop from GPIO
Na de akkor is ilyesmi a log, ha a szalagkábel le van húzva róla !
wiringpi gpio utility ezt mondja rá - úgy hogy most semmi nincs rádugva a szalagkábelre ! :pi@B_MediaPlayer:~ $ gpio readall+-----+-----+---------+------+---+---Pi 3---+---+------+---------+-----+-----+| BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM |+-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+| | | 3.3v | | | 1 || 2 | | | 5v | | || 2 | 8 | SDA.1 | IN | 1 | 3 || 4 | | | 5V | | || 3 | 9 | SCL.1 | IN | 1 | 5 || 6 | | | 0v | | || 4 | 7 | GPIO. 7 | IN | 1 | 7 || 8 | 0 | IN | TxD | 15 | 14 || | | 0v | | | 9 || 10 | 0 | IN | RxD | 16 | 15 || 17 | 0 | GPIO. 0 | IN | 0 | 11 || 12 | 0 | IN | GPIO. 1 | 1 | 18 || 27 | 2 | GPIO. 2 | IN | 0 | 13 || 14 | | | 0v | | || 22 | 3 | GPIO. 3 | IN | 0 | 15 || 16 | 0 | IN | GPIO. 4 | 4 | 23 || | | 3.3v | | | 17 || 18 | 0 | IN | GPIO. 5 | 5 | 24 || 10 | 12 | MOSI | IN | 1 | 19 || 20 | | | 0v | | || 9 | 13 | MISO | IN | 0 | 21 || 22 | 0 | IN | GPIO. 6 | 6 | 25 || 11 | 14 | SCLK | IN | 0 | 23 || 24 | 1 | IN | CE0 | 10 | 8 || | | 0v | | | 25 || 26 | 1 | IN | CE1 | 11 | 7 || 0 | 30 | SDA.0 | IN | 1 | 27 || 28 | 1 | IN | SCL.0 | 31 | 1 || 5 | 21 | GPIO.21 | IN | 1 | 29 || 30 | | | 0v | | || 6 | 22 | GPIO.22 | IN | 1 | 31 || 32 | 0 | IN | GPIO.26 | 26 | 12 || 13 | 23 | GPIO.23 | IN | 0 | 33 || 34 | | | 0v | | || 19 | 24 | GPIO.24 | IN | 0 | 35 || 36 | 0 | IN | GPIO.27 | 27 | 16 || 26 | 25 | GPIO.25 | IN | 0 | 37 || 38 | 0 | IN | GPIO.28 | 28 | 20 || | | 0v | | | 39 || 40 | 0 | IN | GPIO.29 | 29 | 21 |+-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+| BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM |+-----+-----+---------+------+---+---Pi 3---+---+------+---------+-----+-----+Mi szállhatott el ennyire, hogy a GPIO pinek maguktól magasban vannak (illetve úgy néz ki még változnak is) ?
RPI3B, gyári táp, gyári ház, egy 16GB gyorsabb fajta Sandisk microSD. 3 éve lett beüzemelve.
Zárt helyen volt (de nem melegben, mert egy kb. 50x30x20cm térben van), a fizikai piszkálás (=pin rövidrezárás vagy ilyesmi) kizárt. Nyitva-tartástól függően volt bekapcsolva, éves átlagban kb. max. napi 3 órát mehetett.[ Szerkesztve ]
-
atesss
addikt
válasz
azbest
#38129
üzenetére
Hát a fő kérdés, hogy megoldható-e általuk, anélkül hogy én leutaznék.
Ha már le kell mennem, én egy nap (-5h utazás...) alatt biztos megoldom, gyakorlatilag bármi is a lenne hiba. A nekem meglévő elég nagy PI-s és elektronikai alkatrészpakkból. Aztán majd utólag pótlom magamnak ami ténylegesen el lett használva.Annyi hogy pont sima 3B-m az nincsen, csak 2B vagy 3B+.
A 3B+-on alapból nem indul el a 3B-ről (és egy abban az időben kiadott raspbian-ról) mentett image. Elvileg mint kiderült, az a konkrét ok, hogy a kernel nem támogatja az újabb HW-t. Ezt ugye lehetne megbízhatóan frissíteni újratelepítés nélkül (egy régebbi HW-el, pl. a 2B-vel elindítva) ?Viszont boltban kapható 3B-t, újként én már sehol sem találtam.
Csak nem láttam még ilyet, azért fura.
A GPIO azért nincs olyan messzire kivezetve. A PI saját belső 3,3V-jára egy ellenállás, onnan sorkapocs, kb. 40cm MTL kábel, gomb (csatlakozó forrasztva-zsugorcsövezve), MTL kábelen vissza, sorkapocs, és megy a bemenetre kapcsolt GPIO-ra. Mindez egy nagyobb, csapatok elől jól zárt helyen. Tehát ez egy eléggé zárt rendszer.
Annyi hogy a gombok világítós vandálbiztos gombok. A világítása teljesen külön tápegységről megy, a gombba külön pineken bekötve, asszem 12VDC. Elsőre arra gondoltam hogy valaki dugdosta a dolgokat belül, véletlen összecserélte a gombvilágítást, és azon keresztül 12V-ot kapott a GPIO (bár ugye még plusz annak a tápnak a földjét is meg kellett volna valahol kapnia).
De azt mondják hogy biztos nem. És szerintem én is úgy csináltam annó, hogy ez eléggé nehéz legyen (pl. ha bontható sorkapocsra kötök ilyesmit, akkor az egyik tápos dolgok 2 pólusú, másik tápos dolgok 3 pólusú csatlakozókon vannak)
Tápot tesztelik egy másikkal."vagy egy vihar során villámlástól kapott a gpio-kon át kapott valami lökést"
Mivel a GPIO ugyanarra a PI-tápra van kötve, szerintem ilyenkor a PI már azelőtt meghalt volna, hogy a GPIO-ig eljut a túlfesz."De lehet kapni sokféle kiegészítőt, amit a védi és akár 5v toleránsá is teszi."
Most már én is állt. ilyen megoldásokat csinálok, külön galvanikusan leválasztott (földjében is független) tápról mennek a problémásabb perifériák, pl. relék is. De egy 40cm kábelen ülő egyszerű nyomógombot még azért most se biztos hogy így csinálnék.SD-kártya hiba lehet bármi esélye hogy egy ilyet valahogy okozzon ?
[ Szerkesztve ]
-
atesss
addikt
Közben még egy régóta fennálló Raspberry-s problémámat szeretném megoldani.
Távoli asztalnak én VNC-t szoktam használni (az úgymond "gyári", RealVNC).
Ingyenes, működik a PI-n helyi hálózatból is meg Cloud-ban is (ingyenes reggel max. 5 eszköz/fiók, de plusz e-mailcímet regisztrálva ez sem gond).
Kevés erőforrást eszik, amit kell azt tudja, egyszóval nekem bevált.Ha egy éppen headless-ként használt PI-t szeretnék elérni grafikus felülettel - és egy kényelmesen nagy felbontással - akkor én úgy látom két opcióm lenne:
1.) A config.txt-behdmi_force_mode=1, és beírom a kért módot a kért felbontáshoz.
De ez ilyenkor fix, ha épp nem érem el hálózatban, és egy másik monitort dugok rá (ami meg nem tudja azt a - célszerűen viszonylag nagyobb - felbontást), akkor nem lesz képem, és nem érem el sehogy a PI-t az SD-kártyának egy Linuxos/EXT4-et látó gépben való fizikai átszerkesztése nélkül.
2.) A RealVNC-nek lenne erre megoldása, virtual desktop: [link]
Ha a headless indított PI-re egy SSH-n belépek, akkor onnan indítva avncserver -randr=1920x1200parancsra tökéletesen működik, és onnantól már elérem a Viewer-ből 192.168.0.222:1-n (amíg nem indítom újra a PI-t).
Viszont nem ssh-n belépve ez nem működik, pl. autostart-ba beírva sem. A start fájlból külön terminal ablakot nyitva:lxterminal -e vncserversem működik.
Mi lehet a baja, miért csak SSH konzolból fut le, illetve hozza létre a virtual desktop-ot ?[ Szerkesztve ]
-
atesss
addikt
válasz
atesss
#38132
üzenetére
Közben sikerült megoldanom, de nem volt egyszerű...
Leírom részletesen, hátha esetleg másnak is segít.Úgy használom mindig a Raspberry-jeimet, hogy az
/etc/xdg/lxsession/LXDE-pi/autostartfáljba beírok egylxterminal -e /home/pi/Desktop/start.shparancsot. És az asztalon van ez a start.sh fájlom, amibe beírom mindig amit automatikusan indítani szeretnék az adott rendszerrel.Ezt a vncserver parancsot is az indításkor lefutó script-csomagomba raktam bele (és újraindításokkal teszteltem), mert az volt a tapasztalat hogyha van fizikai képernyőm a PI-n, akkor mégis lefut egy a fizikai képernyőn megjelent terminalból indított
vncserverparancs.
Míg a start.sh-ból pedig nem ment csatlakozott képernyővel indítva se. Azaz ahhoz hasonlóan mint ha nincs is csatlakoztatva képernyő.Volt egy olyan ötletem, hogy ha SSH-val megy, akkor írok egy scriptet, ami be ssh-zik a PI-n a localhost-ra, és onnan indítja a vncserver-t.
SSH-keygen-el megoldottam hogy ne kérjen jelszót az ssh-ba való belépésnél: [link]
De hiába, ez nem indult el.
Utána megpróbáltam screen-el indítani.
Ez olyan jól sikerült, hogy végtelen ciklusban futott az indulás, és hozta létre a virtual desktopokat (rájuk is tudtam csatlakozni VNC Viewerben az IP:2, IP:3 stb. címeken), míg el nem fogyott a memória és teljesen leterhelődött a CPU. Sajnos elég gyorsan eljutott ide indulás után.
SSH-n, nano-val nagy nehezen vissza tudtam írni elég gyorsan.Végül megtaláltam ezt a fórumtémát: [link] ,és az itt linkelt további hasonlót: [link]
Ez alapján sikerült, az/etc/rc.localfájlba kellett beírni a következőt:#Start RealVNC in virtual mode with resolution 1920x1200 pxsudo -u pi vncserver -randr=1920x1200
Fontos pont, hogy pi userként kell indítani a vncservert, valószínű ez volt kezdetben a probléma a start.sh-ba beírt vncserver parancsommal.
Írja még ezt is:
"1) Do not enable VNC in raspi-config! If already done then go back and change to NOT enabled."
Ezt viszont nekem nem kellett megcsinálni, meg úgy is ha be van kapcsolva a VNC alapból.A többszörös indítást úgy néz ki nem a screen csinálta, hanem közvetve a VNCServer Virtual Desktop-jának elindítása. Ha a start.sh-ba írtam be a
sudo -u pi vncserver -randr=1920x1200parancsot, akkor is elindult, de ugyanúgy végtelen ciklusba került.
Azt sejtem hogy egy Virtual Desktop létrehozáskor ez az új desktop ismét pi userként jelentkezik be, és lefuttatja a/etc/xdg/lxsession/LXDE-pi/autostart-ot, és így az abba írt start.sh-t is.
Míg a /etc/rc.local csak a rendszerindításkor fut le, egyszer.[ Szerkesztve ]
-
atesss
addikt
válasz
atesss
#38113
üzenetére
Ezzel sajnos még akadt problémám.
Mint írtam, HDMI display-el tökéletesen megy a 3B+-al is, alacsony prociterheléssel.
Rádugtam viszont a PI-re a HDMI monitor helyett ezt a DSI-s, 800x480 felbontású, gyári képernyőt: [link]
Mivel terv szerint egy kis LCD-vel lenne majd használva (persze egy ennél kisebbel és jóval olcsóbbal). Bár azt nem tudom hogy az olcsóbb képernyő is DSI-s lenne, és nem-e már SPI-os.
Amíg nem rakom teljes képernyőbe, addig megy teljesen jól.
Teljes képernyőn viszont fekete képet ad.
Mindegy hogy alapból --fullscreen kapcsolóval indítom shell-ből, vagy megnyitom shell-ből pl. 320x240-be és utólag méretezem át dupla klikkel, vagy GUI-ból indított VLC-ben GUI-ból nyitom meg a /dev/video0-s eszközt; ugyanez.
VLC-ben és CVLC-ben is. -
atesss
addikt
Sajnos élőben még sosem láttam Zero-t, úgyhogy kerestem róla nagyobb felbontású képet: [link]
Ez alapján látom hogy jól sejtettem, hogy furatgalvános, azaz a furatban "belül" végig fém van (érdekes viszont, hogy a szín alapján elvileg valami réz vagy réz-szerű, és nem ón).
Így - ha mechanikailag eléggé szorul mindegyik tüske a furatba - elvileg érintkezhet rendesen.
De gyakorlati tapasztalatom sajnos nincsen.Mechanikai rögzítésnek, hogy ne tudjon kimozdulni, megcsinálhatod azt hogy összesen 2db tüskét beforrasztasz, a két átellenes sarokban. Ez meg tudja tartani az egész tüskesort (mivel az egy darabban van). És ennyit később egyszerűbben ki lehet forrasztani.
Mivel furatgalvános a lap, jogos a félelmed hogy a kiforrasztás - főleg 40db tüske esetén - nem lehet olyan egyszerű.[ Szerkesztve ]
-
atesss
addikt
válasz
azbest
#38143
üzenetére
Még egy kiegészítés az előző leírásomhoz:
"Ez alapján sikerült, az /etc/rc.local fájlba kellett beírni a következőt:
#Start RealVNC in virtual mode with resolution 1920x1200 px
sudo -u pi vncserver -randr=1920x1200"
Ezt - ahogy a linkelt fórumon is írják - az utolsóexit 0sor elé kell ezt behelyezni.
Igen, én csak nagyjából értettem meg, de akkor megerősítettél, köszi.
lxsession start:
No, ezt nem tudtam, pedig adott esetben lényeges tud lenni.
Mondjuk eddig azért nem jött elő ez, mert csak egyszer indult el a grafikus felület.
De innentől, hogyha virtual desktop-ot is használok (márpedig mért ne indítanám el automatikusan akár minden rendszeremen fixen, mivel csak kb. 25-35MB ramot eszik, procit meg kb. semmit), akkor úgy néz ki hogy a/etc/xdg/lxsession/LXDE-pi/autostart-ból való indítás helyett át kell térnem a/etc/rc.local-ból való indításra.
Ide ugyanúgy be fogom tudni tenni alxterminal -e /home/pi/Desktop/start.shsort, ami indítja ezt, a pi user ezen mappájában szereplő shell script fájlt ?
Így a jogosultságok ugyanazok, mint az lxsession-os megoldásnál ?
Illetve ilyenkor az elvileg egy külön terminalban elinduló start.sh "kimenetét" mégsem fogom látni az elsődleges képernyőnek a grafikus felületén ?
Milyen megoldás lehetne, hogy ott rendszerindításkor elinduljon, lássam is az elsődleges képernyőn, de a virtual desktop-al már ne induljon el még egy példányban ?
Amúgy a virtual desktop indításakor mindig kapok egy hibaüzenetet is a desktop-on:
"No session for pid 617"
Mint kiderült ez a PID az lxpolkit-é:pi@raspberrypi:~ $ ps -efUID PID PPID C STIME TTY TIME CMDpi 617 544 0 16:50 ? 00:00:00lxpolkit
"csak akkor a kompozit kimenet az alapértelmezett"
Hát ez fura, akkor meg miért nem jön létre az X ilyenkor ?
Azaz miért mutatja a VNC amikor megnyitom a fő desktop-ot, hogy "Cannot currently show desktop" ?
És a TV-kimenet alapértelmezett felbontásával (720*576 ?) kellene létrejönnie. -
atesss
addikt
válasz
azbest
#38141
üzenetére
Hát egy Raspberry alaplapot azért ki tudnának cserélni, ha csak ennyit kellene.
Viszont közben most egy másik játékelemmel is gond van lent. Még tesztelik hogy melyik részének (nem-e a - kvázi boltban kapható - erősítője vagy tápegysége), de így egyre inkább esélyesnek tűnik hogy le kell mennem."Egyébként remélem van backup a rendszerről, rá telepített programokról, kofigjukról."
A teljes rendszerről image formában nem volt (de amúgy ezt elküldték nekem, az SD-t Win32 DiskImage-el beolvasva másik gépbe).
A lényeges beállításokról, file-okról viszont csináltam annó.Hát ha már cserélni kell, én inkább 3B+-ra cserélnék (vagy ha kapható újonnan, vagy az egyik sajátot használva, amik közül van ami kb. újnak mondható).
4-esre csere már bonyolultabb és költségesebb, új ház (lehet új rögzítési megoldás is kell), új táp, hűtés(akár aktív is), mHDMI-HDMI átalakító, stb.
A 3B+-ra cserének viszont lenne olyan hátránya, hogy onnantól két különböző eszköz lenne a két ugyanolyan pályán (a másikon nem romlott el a 3B, ott az maradna). Ok, nem nagy különbség, de akkor sem ideális."de ha amúgy a szoftver nem épít kivejezetten valami régebbi megoldásra, akkor jó eséllyel kompatibilis maradt vele az új rendszer egy legújabb pi-vel is. "
Hát a pipresents újabb verziói úgy láttam szoktak építeni az újabb Raspbianokra.
És itt már lehet 2 főverziónyi ugrás is volt azóta, kicsi az esélye hogy menne a régi. De ennek utána kell néznem: [link]
Amúgy az a része amit gyakorlatban használnék, jó eséllyel nem változott nagyon, de végig kell nézni a dokumentációt meg tesztelni kell hogy kiderüljön.Viszont van egy része a video-kezelő rendszernek, amit nem én csináltam.
Nem bonyolult, viszont nem tudom 100%-ra hogy mi minden kell hozzá hogy menjen.
A - nem általam csinált PC-programból (Debian, GUI-s) - is be lehet küldeni videók lejátszását.
Biztonság kedvéért ezt úgy csináltuk meg még annó, hogy HW-esen vezérel. Azaz az RPI-n futó egyszerű scriptet vezérli SSH-n keresztül a PC, az RPI script pedig egy GPIO pin-t magasba emel. Ez a pin össze van forrasztva(persze egy ellenálláson keresztül) egy másik GPIO pinnel, aminek a magasba váltását érzékeli a pipresents, és arra indítja a videót.
Az rémlik, hogy a PC-program alapvetően SSH alapon kommunikál a raspberry-vel.
Talán van egy config fájl is, ahova a Raspberry IP-t be kell írni.
Az IP-cím ugyan most MAC alapon fixálódik a routerben, de ezt átírom, és akkor az IP marad ugyanaz.
Viszont ahhoz hogy "ne kérjen be jelszót" az a minimum, hogy ssh-keygen-el új kulcsot kell generálnom és azt bemásolni. De annyira nem ismerem ezt, milyen beállítások lehetnek még SSH kapcsolatnál, ami kellhet ahhoz hogy működjön így automatikusan a kommunikáció ?Pl. az úgy oké, ha az RPI-n lévő scriptfájl tulajdonosa a pi user ?
Valami visudo beállítás is rémlik, hogy van amit hozzá kellett adni az automatikusan sudo joggal futó alkalmazások/scriptek listájához. De aztán ez lehet már a PC-n van (Debian).[ Szerkesztve ]
-
atesss
addikt
Átnéztem, de sajnos nem értem teljesen.
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
Nekem ebből az jött le, hogy ez a vncserver indítása előtt lelövi a futó példányokat.ExecStart=/usr/bin/vncserver -geometry 1800x1000 -depth 16 -dpi 120 -alwaysshared -localhost %i
Majd az utána következő sor újra elindítja a vncserver virtual desktopot-ot, majd így ezzel a/etc/xdg/lxsession/LXDE-pi/autostart-ot, amiben ha benne van a vncserver indítása, így ez végül ugyanúgy egy végtelen ciklust jelentene, mindig elindulna-leállna.
Bár van deamon is írva, de sajnos nem világos hogy az pontosan hogyan működik, illetve én hogyan indítanám, és miért csak egyszer futna le.[ Szerkesztve ]
-
atesss
addikt
Okés, átnéztem még egyszer, és most már világos, ez akkor service-ként fog futni.
És az X indulással mindig leálló-elinduló problémát is gondolom ez megoldja (mivel a service gondolom nem az X-hez kötött)."át kell térnem a
/etc/rc.local-ból való indításra.
Még mielőtt, áttérsz, felejtsd is el! A systemd-s init rendszer csak kompatibilitási okokból hagyta meg ezt a régi init rendszer emulációját."
Viszont ez a dolog akkor felveti az egész autostart megoldásomnak a problémáját.
Amiben adott esetben ezen a VNC indításon felül még egy csomó minden más is van.
Hogyan tudnám megoldani, hogy a start.sh fájlom (vagy az /etc/xdg/lxsession/LXDE-pi/autostart) pontosan egyszer fusson le ?
Tehát hogy a rendszerindításkor lefusson, de a virtual desktop-okkal induló újabb X indulásával pedig már nem.
Ellenőrizzem, hogy mi a kijelzőm tulajdonsága ?
Vagy ellenőrizzem hogy nem fut-e már egy realvnc virtual desktop ?
Ezt talán valahogyps -ef | grep vncalapon lehetne ?
(Csak itt ugye ki kell deríteni hogy miből látom pontosan hogy a kijelzője az egy virtual példány.)[ Szerkesztve ]
-
atesss
addikt
válasz
Márton
#38182
üzenetére
Sajnos úgy tudom az omxplayert-t már nem fejlesztik tovább...
Most kipróbáltam, a VLC is lejátssza a youtube videókat (3B+, friss Raspbian és VLC).
És én annó RPI-n VLC-vel és CVLC-vel is csináltam olyat, hogy helyi hálózatos RTSP stream-eket nyitottam meg, nagyon hosszúra állítva a buffert (ami működött is, hirtelen kihúzva a forrás eszközt még ment a PI-n a lejátszás tovább a beállított kb. 3 másodpercig).
De úgy rémlik hogy utána bezáródni az is bezáródott (lltetve a VLC a GUI-n is hibaüzenetet írt ki), bár ez talán kikapcsolható.[ Szerkesztve ]
-
atesss
addikt
A GPIO pineket a használat után ajánlott lenne felszabadítani (alapra állítani).
Úgy emlékszem ezt egy egyszerű shell script paranccsal meg is lehetett tenni (egy adott pinre).
A GPIO utility (WiringPI) leírásban viszont hiába keresem.
Vagy az ponthogy egy másik utility amiben ez a funkció van ?
Vagy rosszul rémlik, és Python alól működik csak ez ?MOD:
Ezt a régi scriptet szeretném továbbfejleszteni (amúgy 8db case van, csak a többit kiszedtem hogy rövidebben írjam be ide):#!/bin/shv1() {echo "1";gpio -g mode 3 outgpio -g write 3 0sleep 1gpio -g write 3 1}v2() {echo "2";gpio -g mode 27 outgpio -g write 27 0sleep 1gpio -g write 27 1}case "$1" inv1)v1;;v2)v2;;*)echo "Usage: $0 v1-v2| KillRemote | KillAll}"esac[ Szerkesztve ]
-
atesss
addikt
Valamiért nem tudom sehogy sem kikapcsolni az inaktivitás utáni képernyő-kikapcsolást (Screen blanking).
Teljesképernyős alkalmazásban nem kapcsol ki a képernyő (a pipresents-et --noblank paraméterrel indítva), de az asztalon kikapcsol.
RPI 3B+, frissen telepített legújabb Rasbian. Frissítettem, beállítottam mindent a rendszeren, majd a végén a Raspi-configban a Screen Blanking-ot Disable-re állítottam, majd restart.
De még mindig ment.
Utána sudo-apt-get install xscreensaver
Ott beállítottam: mode: Disable Scrensaver (tooltip szövege: "Disable screensaver and never black screen").
De még így is kikapcsol...[ Szerkesztve ]
-
atesss
addikt
válasz
vpleft
#38123
üzenetére
No most másik SD-vel, egy másik hdd-re mentve tényleg neked lett igazad, és itt a cat sokkal gyorsabb volt.
Ez most két ugyanolyan, 16GB Sandisk MicroSD volt.
Illetve a HDD pedig most nem USB3.0-s, hanem a laptopomba épített (van SSD is meg HDD is benne), aminek egy maradék partícióját csináltam meg. NTFS-re, és valami nem oké vele, többek közt indokolatlanul belassul.
Na itt, ilyen feltételekkel (a dd-nél ugyanúgy BS=1M-el) többszörösen gyorsabb volt nála a cat.
dd-vel elég gyakran pár MB/s-es sebességre ment le (míg a max. sebesség a cat-hoz hasonló volt). Tehát kb. az van amit írtál. Csak nem gondoltam hogy ennek ilyen durva eredménye lehet (bár a HDD-s particiós probléma most még rájátszhatott). -
atesss
addikt
válasz
Laszlo733
#38222
üzenetére
Az etc/xdg/lxsession/LXDE-pi/autostart -ben első körben ez a 3 sor is benne voltak (ez régóta része a telepítéskor beállítottaknak, egyszer kikísérleteztem annó, azóta csak mindig bemásolom a telepített rendszereimre).
Na most így aktív volt a screen blanking.
Második körben csináltam egy teljes újratelepítést (nem csak emiatt), akkor már nem másoltam ezeket be, csak GU-ból állítottam (ahogy írtam az előbb).
De még így is aktív volt a blanking.
Akkor úgy néz ki a etc/lightdm/lightdm.conf lesz a ludas.
Ebben lehetett változás mostanában a Raspianban ?
(Lehet amúgy a Buster-el jött be valami, mert azt még keveset raktam, csak egy PI4-esre, de ott nem ellenőriztem hogy mit csinál.)
De gyakorlatban tesztelni most már majd csak holnap tudom. -
atesss
addikt
válasz
BalanceR
#38257
üzenetére
Ez a Neo Case elég jó konstrukciónak néz ki.
Pont gondolkoztam rajta, hogy a PI4-et hogyan lehetne lehűteni úgy hogy minden port rendesen használható lehessen rajta.
A kis bordák sajnos nem elegek már a Pi4-hez (még nyitott házzal sem, főleg nem zárttal).
A ventilátorok általában a GPIO-ról mennek, amibe nekem meg az esetek felében be van dugva egy szalagkábel. Oké, a szalagkábel másik végéről (ahova úgyis egy minden pin-t próba/proto -nyákra kivezető T-Cobblert szoktam tenni) vissza lehetne vezetni az 5V-ot, de az körülményesebb. Ha már fixálva lett egy eszköz, akkor lehet, de amíg hordozom is addig különösen problémás.Az Armor Case meg igazából nem normál Case, nem védi teljesen az egész PI-t (nyák széle, USB-k, RJ45).
A Neo Case viszont használható teljes Case-ként is (beépített hűtőbordával), és használható panel+hűtőborda funkcióban is.
Felpattintott fedlappal is elég jó vajon a hűtése ?
Lehet olyan kiegészítő, ami nem fér el fölötte ?
Pl. a POE-HAT ? Vagy más HAT-ek ?[ Szerkesztve ]
-
atesss
addikt
válasz
azbest
#38141
üzenetére
Végül az eszközcsere lett, lementem csütörtökön, és beraktam egy régebben vett, de gyakorlatilag nem használt 3B+-t, friss Raspbiannal és friss lejátszó SW-el (pipresents).
Sikerült megoldani hogy a PC SW a cserélt PI-t is tudja vezérelni SSH-n keresztül. Egyrészt sejtettem is már addigra hogy mit kéne csinálnom, másrészt meg mint kiderült lehetett a SW-t terminálban is indítani, és így ki is írta hogy pontosan mit csinál. A trükk abban, volt, hogy a PC SW a root user-el futott, tehát ezeket az SSH-s parancsokat is annak a usernek kellett kiadni (ez egy régebbi Debian)sudo sussh-keygen -f "/root/.ssh/known_hosts" -R IPssh-copy-id pi@IP
Raspbian-on amúgy a pi user pontosan milyen jogosultsági szinten fut ?
Amivel baromi sok időm elment lent, az a teljes image-ek mentése.
Egyrészt a 38232-ben írtak miatt[link]
Másrészt pedig még amikor ment is az SD maximumával, az is nagyon lassú volt. Csak tudnám hogy miben "Extreme" ez a Sandisk SDHC kártya, mert hogy nem a sebességben az biztos...
A hibás 3B-t meg elhoztam. Majd letesztelem, hogy pontosan melyik PIN-ek hibásak. Lehet mindegyik, de még akkor is lennének olyan feladatok, amire lehetne használni, GPIO nélkül.
GPIO tesztelésre tudtok valami könnyebben kezelhető kész GUI-s toolt ? (azaz nem ilyen wiringpi vagy hasonló...) -
atesss
addikt
válasz
azbest
#38273
üzenetére
Ez Debian volt, és abból is egy most már legalább 4+ éves. Lehet talán a párhuzamos port (PCI-os kártya, 2db teljes értékű) kezelése miatt lett a root userrel futtatva.
pi@BMediaPlayer:~ $ groupspi adm dialout cdrom sudo audio video plugdev games users input netdev gpio i2c spi
Igen, tényleg itt vannak a hardvereszközöknek is a csoportok.
Itt a sudo jelenti a "sudo-er"-t amit írtál ?
Az SD kártyát az olvasó biztosan nem limitálta, egy USB3.0-s Kingston MobileLite G4 [link]
V30-as kártyákkal tényleg elég komoly sebességgel működik is. -
atesss
addikt
válasz
BalanceR
#38424
üzenetére
Áh, köszi az infókat.
Én még azóta nem rendeltem, kivártam, meg igazából egyáltalán nem sürgős.
Ez a 12-15 fok mínusz mit jelent akkor a gyakorlatban ?
Maximálisan leterhelve, lakás hőmérséklettel (kb. max. 25 fok, nem az óriás kánikula) fel tud annyira melegedni, hogy már elkezdjen throttlingolni ?
Ha leveszed a fedlapot, kb. mennyire csökken a hőmérséklet ?
Tényleg minden csatlakozó maximálisan hozzáférhető ?
HAT-ek (pl, POE-HAT) is teljesen elférnének ?
Az alján van valamilyen rögzítési lyuk, amivel (természetesen ehhez már a PI-t kiszedve) felületre felcsavarozható lehet ?
Ha nincs rajta a fedő, egy 3-as PI-vel akkor sem lenne kompatibilis semennyire ?
AliExpress Standard Shipping-el szállították ?
Ezt most posta hozta ki, futárszolgálat, vagy csomagpontra ment ?
(Az Aliexpress topicban többen azt írták hogy mostanában ez már csomagpontos lett.) -
atesss
addikt
Raspberry Pi 1 Model B+ v1.2 ugye elbírná azt, hogy 1db vagy esetleg 2db, belső LAN-on elérhető max. 1Mpixel RTSP kamera stream-et rögzítek vele, egy külső USB-s 2,5" HDD-re ?
Annak az USB portja elbírhat egy régebbi fajta 2,5" HDD-t ? Vagy egy Y-kábel mindenképp kellene ? -
atesss
addikt
válasz
atesss
#38472
üzenetére
No közben gondolkodva a dolgon, lehet hogy - első körben legalábbis - egy 3B+, vagy akár a 4-es Pi-m lenne berakva. Legalábbis amíg a tesztelés-hibajavítás fázisában van a projekt.
Egy "8D" mozi rendszerben egyfajta kicsi vezérlőnek/automatizálónak használnám.
És jó lenne az - amúgy is meglévő - kamerák képén akkor már egyben követni, hogy amikor működésbe lépett ez a "hibajavító vezérlő", előtte/utána mi történt fizikailag.
Milyen CCTV-rendszereket ismertek Raspberry-re ?
Valami olyan megoldás kellene, ami tud külső "érzékelőt" is kezelni (ez jelen esetben fizikailag egy GPIO pin lenne). És az igazi az lenne, ha lenne idővonal nézet, ahol a külső érzékelő állapotát is látnám a kameraképek(egy, vagy több egyszerre) mellett. -
atesss
addikt
válasz
ReFleXx
#38479
üzenetére
Itt olvastam a topicban, hogy sokan a qbitorrentet ajánlják, mert akár többszöröse a sebessége, mint a transmission.
Rémlik hogy többen is panaszkodtak a transmisson-re, ugyanúgy ahogy te. Váltottak, utána meg összehasonlították a sebességeket, és nagyon komoly volt az ugrás. Olvass vissza. -
atesss
addikt
Üdv !
Adott egy 3B+, gyári táppal, amivel egy vezérlési projektet csinálok éppen, link másik topicból: [link] illetve [link]
Végül egy külső, I2C-s AD konvertert kellett rákötnöm, konkrétan egy ilyen [link] PCF8591 alapú modult. Az AD modul tápja is ugyanúgy a GPIO-ról megy, az 5V-os körön van.
CH0 és CH1 csatornára kötöm a fototranzisztorokat, folyamatosan mérem az értékeket (alapvetően amilyen gyorsan csak tudja a Pi), és 1s-ra átlagolom. 1s-onként írom ki a konzolra is az eredményeket. Sikerült is belőnöm egy érték-küszöböt, ami alatt egyértelműen normál állapot van, és fölötte pedig egyértelműen hiba állapot. Relémodult [link] is rákötöttem, kapcsol is ahogy kell.
Szóval a lényeg működne is tesztként összedugva.
De, ha a relével többször kapcsolok egymás után (ami nagyon azért nem gyors, ugye a max. kapcsolási sebesség 1s), akkor a következő hibával száll el a program:bus.write_byte(address,A0)OSError: [Errno 121] Remote I/O error
Vagyis szinte biztos vagyok benne, hogy az I2C eszköz ekkor éppen nem elérhető, és ez a hiba oka.
Én arra kezdek gyanakodni, hogy az 5V-os tápra kerül valami zavar, a relével közös táp miatt.
Szerintetek mekkora az esély, hogy tényleg ez a gond, és ha igen, esetleg hogyan lehetne segíteni rajta (ha nem akarnék külön tápot, és optocsatolózást) ?
Grátisz, hogy egyelőre úgy tűnik ki csak akkor jön elő a hiba, ha a relé kapcsain ténylegesen rajta van a terhelés is (24V DC, ami a másik topicban már linkelt Motion Controllert táplálja). Ha csak kapcsolgatom a relét magában, akkor meg nincs hiba... -
atesss
addikt
Azóta egyelőre nem foglalkoztam ezzel a konkrét indítási problémával.
Most viszont egy projektben előjött egy hibajelenség (egy I2C-s ADC modulról egy relé kapcsolgatása közben néha nem tudtam olvasni, és ilyenkor hibával kilépett az egyébként folyamatosan futó Python script), és erre megoldásokat keresve rátaláltam a Supervisor-ra [link] és [link] .
Ez vajon megoldhatná egyben ezt a korábbi, autostart-os problémámat is ?
Mert ha igen, akkor ebbe ásnám bele magamat, ugyanis a supervisor funkció is egy elég hasznos dolog, most pl. ez a hardverhibás eset is megmutatta.
(Ok, persze a programkódba is bele lehet rakni még komolyabb hibakezelést, de nem biztos hogy ez minden eshetőségre eszembe jut. És bizonyos - tényleg ritka - hibákat meg teszteléssel nem is könnyű előhozni.) -
atesss
addikt
Üdv !
Hogyan lehet módosítani a Raspbian-nak (vagyis pontosabban most már Rasberry Pi OS-nek) a hálózati idő szinkronizációs beállításait ?
Még jobb lenne, ha valamilyen formában tudnék róla, hogyha módosítás történt a rendszeridőn.
Olyan python programkódot írtam, ami jó pár dolgot a rendszeridőt felhasználva csinál (lekérdezem a time.time()-al, és úgy mérem hogy épp mennyi idő telt el).
És ha futás közben megváltozik a rendszeridő, az adott esetben okozhat kavarodást a működésében.
De teljesen letiltani se akarnám, mert az nem lenne rossz ha induláskor egyszer lekérdezné (ha tudja), ha ez viszonylag gyorsan lefut. -
atesss
addikt
válasz
cog777
#38935
üzenetére
Igen, van olyan része is a kódnak, aminél a pontos idő a fontos.
Jól mondtad, ez a log, a releváns része így néz ki most a programomnak:import timefrom time import localtime, strftime...# MAIN függvényTimeStamp_Failure_Left = strftime("%Y-%m-%d %A %H:%M:%S", localtime())print("A hiba ideje: ", TimeStamp_Failure_Left)with open(LOG_PATH, "a") as logfile:logfile.write(TimeStamp_Failure_Left)logfile.write(' - Hiba az A motornal (LEFT) \n')Hát annyi, hogy viszont egyelőre - Pi elindulásakor - a rendszeridő beállításához szükség van a netes szinkronizációra. (Van ugyan RTC modulom, de nem nagyon akarnám használni, csak ha nagyon muszály.)
De később meg ha már fut a Pi, felesleges.
Bár ok, elvileg ekkor nem is kellene már ugrálnia.[ Szerkesztve ]
-
atesss
addikt
Ezt akkor valahogy így kellene a Python scriptembe írnom ?
os.system("sudo timedatectl set-ntp false")
Ha kilépek a python scriptből (pl most még a tesztelésnél, Ctrl+C-vel), akkor ez hogyan áll vissza ?
Ha valami ilyesmi van a main ciklusban ?except KeyboardInterrupt:GPIO.cleanup()os.system("sudo timedatectl set-ntp true") -
atesss
addikt
válasz
cog777
#38935
üzenetére
Ja és igen, most én is ezt az Epoch-os megoldást használom - a log kivételével mindenhol.
Pl. a legegyszerűbb ezek közül egy a kód működését/futását jelző ledet villogtató függvényem. Bár ugye ez pont nem annyira kritikus dolog, de most önálló példaként ezt tudtam egyszerűen leírni.SLOW_CYCLE_TIME = 1slow_time_previous = 0def run_flasher():global run_led_stateGPIO.output(RUN_LED, run_led_state)run_led_state = not run_led_state...# MAIN függvényslow_time_elapsed = time.time() - slow_time_previousif slow_time_elapsed > SLOW_CYCLE_TIME:slow_time_previous = time.time()run_flasher()[ Szerkesztve ]
-
atesss
addikt
válasz
cog777
#38940
üzenetére
Igen, ez jogos.
De a #38936-ben írt kódomban [link] azstrftime("%Y-%m-%d %A %H:%M:%S", localtime())
nem az Epoch-ot használja alapként ?
Azzal a különbséggel, hogy az oprendszer localisation -jét is beleszámolja, azaz - ha be van állítva a Magyarország - akkor mindig a megfelelő időzónában van, és állítja az időszámítást is. Így mindig a pontos helyi időt kapom.
"nagyobb idotavlatbol viszonylag pontos osszehasonlitasokat vegezzunk."
Nekem első körben arra kellhet a log, hogy tudjam mikor történt a hiba, össze tudjam hasonlítani a kamerák képével (ezt másodperc pontosan), tudjak beszélni az épp akkor dolgozó kollégával, stb. És ugye ő is a saját óráján ezt az időt "használja".
Második körben meg statisztikára (milyen gyakran fordult elő hiba összesen, pl. egy hónap alatt, illetve volt-e olyan hogy egy óra alatt nagyon sokszor).Az időszámítás miatti ugrálás viszont bizonyos esetekben tényleg gond lehetne...
Viszont az átállás ideje, az éjjel 3 óra az én esetemben abszolút üzemidőn kívül van, úgyhogy ez nem lesz gond most nekem.
Mondjuk máshol a LOG-ba lehet be kéne írni azt is, hogy egy óra-átállítás történt.time.monotonic() → floattime.monotonic_ns() → int
A felsőt én az eddigi time.time()-omhoz hasonlóan tudnám használni ?
Annyi, hogy jóval kisebb értékekről van szó. De a rendszerindítás után egy 15-20 sec úgyis biztosan el fog telni, mire elindul a python scriptem.
Mondjuk ezt akkor át kell gondolnom, mert asszem van ahol úgy adtam meg egy kezdeti értéknek (a program-induláskor) a time.time() visszatérési értékét, hogy az "Úgyis jó nagy lesz", és így - amíg nincs külön esemény, ami módosítaná ezt a változót - addig a "Jó nagy" miatt biztosan nem lesz igaz az egyik if szerkezetem.[ Szerkesztve ]
-
atesss
addikt
válasz
azbest
#38943
üzenetére
"hogy kikapcsoláskor elmenti az utolsó ismert időt és újraindításkor alapból azzal indul a rendszer elvileg"
Az én gyakorlati tapasztalataim alapján így működik a Raspberry.
"Másrészt óraátállítások is vannak és ha jól csináltad, akkot utc idővel dolgozol, nem pedig helyi idővel, ami évente kétszer urál és egyszer még visszafelé is megy."
Igen, ez tényleg okozhat bizonyos esetekben problémát. Sőt, igazából a programozási esetek döntő többségében tényleg jobb az UTC, ez jogos.
De most nálam, ha gyakorlatban a #38941-ben írt felhasználása van a log-nak, akkor én úgy érzem hogy pont hogy jobb ha nem UTC időt használom. És így rögtön a szemem előtt az az időpont szerepel, amivel a többi dolgot össze tudom hasonlítani.Vagy - ha valamiért lényeges a helyi idő is - ti hogyan szoktátok azt fejben tartani ? Vagy egyszerűen kiszámolni ?
Mentsem le a fő logban mindkét időt ?
Vagy egy ilyen esetben ez hogyan lenne célszerű ?"A másik lehetőség, hogy szimplán veszel valami filléres hardver órát és bekötöd a pi-re egy gombelem társaságában."
Hát, igazából van is. Konkrétan több darab ilyenem van: [link]
Sőt, - ehhez a projekthez - a nyákon meg is van már neki a hely, és a modulon át is forrasztottam a tüskéket derékszögűre, így be is dugható.
De ez most igazából egy teszt lenne, hogy mennyire kell a HW-es RTC. A későbbiekben lesz remélhetőleg több olyan projektem is, ahol nem lesz nyák az RPI-hez, így a HW-es óra körülményesebb és drágább. Nem lenne a GPIO-ra csatlakozó nyák, meg még egy - amúgy jó drága - HAT RTC modul se nagyon férhet el egy standard RPI házban, stb.
És most jelen esetben elég megbízható netkapcsolata lesz az eszköznek. Nem is egy otthoni/kisvállalati, hanem egy bérelt vonali kapcsolatról kapja az RPI a netet, fixen kábelen.
MOD:
"A lényeg, hogy sosem jár visszafelé az óra, mindig csak előre halad így."
Igen, ezt én is így sejtettem.
De ez is okozhat problémát.
Pl. van egy folyamatom, aminek megadok egy kívánt időtartamot. Legyen ez mondjuk 4 perc (240 sec). Ha a folyamat indítása előtt nem sokkal történt pl. egy rövid áramszünet (esetleg véletlen áram-lekapcsolás, stb.), akkor lehet hogy a rendszeridő már a folyamat futása közben frissül (növekszik). Így a végén a 240 sec-ből lesz aztán valami sokkal kevesebb.[ Szerkesztve ]
-
atesss
addikt
válasz
azbest
#38945
üzenetére
"A megjelenítés vagy kiírás pedig, ha oda helyi idő kell, akkor arra szokott lenni függvény, ami kiadja magából olyan, emberi fogyasztásra alkalmas formában."
Akkor ezzel a függvénnyel az alapból UTC-ben kiolvasott TimeStamp-ot alakítsam át ?
Most a konkrét esetben amúgy nem végeznék semmilyen műveletet vele, csak kiírnám a log-ba a már részletezett célokra.
De amúgy arra jó lehet az UTC használata, hogy akkor ezt a megoldást szokom meg már most. És így írom meg a kezelő-függvényeimet, amit akkor később - amikor már tényleg kell is az UTC - egyszerűbben újra tudok hasznosítani/ ismét fel tudok használni."Szóval nem azt mondod, hogy végeten ciklusban nézegeted az órát, hanem megmondod neki, hogy 1 másodpercenként történjen a végrehajtás és adott függvény végezze akkor el. "
Igen, ez teljesen jogos.
Annó Atmega-n használtam Timer Interruptokat. És nem a - HW-es működést elég komolyan elfedő - mostanában nagyon népszerű Arduino alatt, hanem a gyári IDE-vel (akkoriban még AVR Studio-nak hívták), közvetlen a regiszterek bitjeit címezve. Sőt, asszem még AVR-assembly alatt is használtam timereket.
Viszont mivel úgy tudom hogy a Raspberry Pi ilyen szempontból elég gyenge ehhez képest, így első körben nem erőltettem a Timer Interruptot.
(Lehet kivétel ha valami RealTime OS-t rakok fel rá, de ahogy sejtem az RTC hiánya miatt még az alatt sem lesz teljes értékű.)
De persze nem lenne rossz, csak kérdés mennyire bonyolult használni. Illetve ezekre a feladatokra még oké lesz, ledet villogtatni, meg ADC-t átlagolni.
De kicsit valamiért úgy érzem, hogy - bizonyos szempontból - hiába tanulnám meg. Mivel amit te írtál, hogy:
", de komolyabb feladatokra túl kell lépni ezeken."
Az a sejtésem, hogy bizonyos komolyabb feladatokra, ahol pontosabb időzítés kell, oda meg mégsem lesz elég ez sem."Az áramszünetre: az már egy teljesen más probléma és gondolom most sem tudod lekezelni. Oda már valami nyilvántartás kell (adatbázis), hogy mi történt meg és ha késik, akkor megtörténjen -e és ha igen, akkor mikor."
Jó igen, ha olyan a feladat, hogy ez fontos, akkor ilyen eseteket tényleg csak így lehetne profin. De most erről azért nincs szó.
Itt nem arról van szó, hogy az áramszünet befolyásolt-e valamit. Hanem szimplán csak arról, hogy az áramszünet okán a Raspberry órája kicsit elállítódott. És ha pont akkor áll vissza a pontos idő, amikor a scipten belül fut valamilyen, a rendszeridőt kalkulációnak használó függvény, akkor ezt a függvényt az óra-átállítás "eltérítheti"."Egyébként újraindulásnál érdemes azt is megnézned, hogy mikor történik az óra netes szinkronizációja. Hogy előtte elindul-e a szolgáltatásod."
Igen, már a téma-indító hsz-emben is feltettem ezt a kérdést. Hogy hogyan lenne arról információm, hogy egy netes idő-szinkronizáció történt.
cigam ötlete közvetlenül ezt nem oldja meg, mert azzal csak letiltani tudnám meg engedélyezni a funkciót. De arról nem lenne információm, hogy egy rendszerindulás után megtörtént-e a "kezdeti" szinkronizáció."Egyébként systemd óta úgy emlékszem külön érdemes megadni a raspbianon, hogy várja meg a szolgáltatások indításával a netkapcsolatot."
Egyrészt: az internet-csatlakozás, és a hálózati idő-szinkronizáció megtörténte nem feltétlenül esik egybe.
Másrészt: azért ha esetleg nincsen net, attól még nem lenne rossz ha elindulna a scriptem.
Vagyis akkor be kéne rakni ide egy plusz timeout-ot is, hogy ha nincs netkapcsolat x idő után sem, akkor viszont indítsa el a scriptet, ne várjon a végtelenségig.[ Szerkesztve ]
-
atesss
addikt
válasz
t72killer
#38947
üzenetére
Akkor viszont ha az 5V-os oldalon akarsz kapcsolni, akkor itt a feszültségesés miatt valami normálisabb kapcsoló kell. Abba a kínai kapcsolós kábelbe minden bizonnyal az elérhető leggagyibb kapcsolót rakták bele...
Nekem is volt ilyesmi kábeles kapcsolóm. Egyik fele 5,5/2,1-es DC aljzat másik fele dugó, közte a kapcsolóval. Használhatatlan volt, már 12V-on is olyan feszültségesést produkált némelyik infrás analóg CCTV kamerával, hogy szakadozott a képe.
A 3m-es kábelnél már tényleg nagyon nem mindegy milyen minőségű. Mennyire vastag benne a réz.
Én mértem be annó microUSB kábeleket. Direkt pont Raspberry-vel való használatra. Volt egy olyan - minőségi, márkás, nagyobb magyar informatikai boltból beszerzett - 3m-es kábelem, amin a hosszához képest abszolút nem volt nagy a feszültségesés. Jobb volt mint némelyik ránézésre is gagyi 50-70cm-es... -
atesss
addikt
válasz
azbest
#38945
üzenetére
Közben rájöttem hogy az én függvényem ezt az időkonvertálást már nagyjából így is csinálja.
# Time in RFC 2822 Internet email standard: strftime("%a, %d %b %Y %H:%M:%S +0000", gmtime())# Magyar formátum szerinti: strftime("%Y-%m-%d %A %H:%M:%S", localtime())
Vagyis akkor jól gondolom hogy az alsó sor függvénye is az UTC időt számolja alapból, csak a végén csinál egy formázást, és a localtime-os formátumban írja ki (időzóna, időszámítás-t beleszámolja) ? -
atesss
addikt
válasz
t72killer
#38952
üzenetére
Sajnos az a helyzet, hogy - pár speciális kivételével - szerintem nem nagyon lesz még 0.5mm2 érkeresztmetszet sem még a jobb microUSB/USB Type-C kábelekben sem.
Ha csak a tápot vivő kábelről van szó (tehát az adat-erek nincsenek is benne), akkor is egy 2x0.5mm2-es, dupla szigetelésű kábelről lenne szó. Villamossági célra ebből a lapos keresztmetszetű a 2x0,5 MTL [link]
Ok, ennél valamivel vékonyabbra is megoldható a szigetelés (főleg hogy nem kell tudnia 230V-ot szigetelnie). De a végülis egy ilyen USB kábelnek a külső átmérője közel ekkora kellene hogy legyen.
Ha meg vannak benne adat-erek is, akkor még vastagabb lesz. Lehet esetleg az adat-ereket vékonyabbra hagyni. Bár nem sok olyan kábelt láttam ahol egy külső köpenyen belül eltérő belső átmérőjű erek voltak (gondolom azt körülményesebb lenne gyártani).És némelyik kábel nem is biztos hogy réz. Ez még növeli a feszültségesést.
Akár csak hajlékonyság és tartósság okán, pl. olyasmi szálanként "szigetelt" mint a fülhallgatók kábele.
Vagy egyszerűen azért, mert a réz drágább lenne."A kapcsolós, jellemzően 1m-es kábeleket viszont tömegével árulják a kínaiak Alin és nem sok negatív feedbacket látni. OK, az is igaz, hogy nagyon kevesen terhelik 5W/1A felett a Pi-ket"
Egyáltalán honnan gondolod, hogy ezeket Pi-hez használják ?
Szerintem a döntő többség telefonhoz használja, az pedig a Pi-hez képest sokkal-sokkal jobban bírja a feszültségesést.
Lehet aztán van aki telefonnal használja főleg, de azért egy Pi-vel is kipróbálja. Konstatálja hogy ez erre nem jó, de ha nem direkt Pi-hez vette, akkor nem nagyon fog adni negatív értékelést.
Sőt, az is lehet hogy amikor nem megy egy 4-es Pi-vel, eszébe jut hogy "jah, olvastam valamit annó hogy a 4-es Pi-nek valamit elrontottak a Type-C táp-kezelésével". És ennyiben is hagyja a problémát, pedig simán lehet hogy ennek igazából köze sincs hozzá (vagy már amúgy is egy később vett, javított táp-áramkörös Pi4-e van).[ Szerkesztve ]
-
atesss
addikt
válasz
cog777
#38951
üzenetére
Igen, részben tanulási célzattal is csinálom.
Persze úgy, hogy ezzel most azért alapvetően olyanokat akarok megtanulni, aminek a nem túl távoli jövőben hasznát is veszem. Pont ezért ilyen RTOS kategóriájú kérdésekkel nem nagyon van értelme foglalkoznom most (azon felül hogy esetleg érdekességként, röviden elolvasom)."En tovabbra is a monotonic orat hasznalnam kalkulaciora, pont erre van."
Igen, ezt írtad is, csak még nem néztem utána, illetve nem alakítottam át a teljes kódomat erre.
Addig a rendszeridő-alapú műveletekről való gondolatot vittük tovább. De ha jól megy a monotonic, akkor amúgy tényleg felesleges lenne a rendszeridő-alapúval ennyit foglalkozni."Viszont ha nem akarod, akkor irj egy szolgaltatast ami var addig amig nincs internet, majd kenyszeritsd ki az idoszinkronizaciot."
Na ez így már egy egész részletes leírás, ez alapján már akár ezt is meg tudom csinálni, köszi. Egyelőre csak a fájlon keresztüli menne. Vagy esetleg egy shell sciptbe lehetne az egészet beírni. És a feltételek végén (benne egy timeout-al, hogyha nem tudta x idő alatt szinkronizálni, akkor is továbbmenjen) meg ott van a python scriptem indítása.
Akár lehetne egy indítási paramétere (parancssori paraméternek hívják ezt?) a python scriptemnek, hogy sikerült-e az időszinkronizáció.
De később akarok majd MQTT-vel is foglalkozni (sőt, konkrétan elég komolyan számítok az MQTT-re, minél előbb).
A megfelelően működő, használandó ntp szolgáltatást meg majd max. kikísérletezem."Alternativakent, RTC-t kell hasznalni ha a logokban fontos a mp pontossagu ido."
Ahogy írtam, lesz olyan kiépítés, ahol lesz RTC, mert a perifériák miatt úgyis meglévő nyákra elfér, és nem egy nagy tétel árban sem.
De van ahol meg nem lesz, mert nem is lesz nyák a Pi-hez.
Ezért nem árt foglalkoznom az RTC nélküli megoldással, kitalálni/megtanulni egy jól használható megoldást arra is."Ha surun, akkor komoly megoldas kell. Ha par evente 1x akkor felesleges tul sok energiat belelolni hacsak tanulni nem szeretnel..."
Igen, ez is jogos.
Hát - most így a tanulás okán - ahogy írtam, az a fő kérdés, hogy milyen gyakran várható majd olyan feladat számomra, ahol egyáltalán használnom kellene.
Viszont ha már idő-alap: kisebb szervo és léptetőmotor vezérlés viszont abszolút előfordulhat. De az az érzésem, hogy ha ilyeneket akarok használni, akkor még ha nem is akarok nagyon pontos lenni, akkor is egy plusz, ezt kezelő HW lenne a jó megoldás (leginkább egy külön, kisebb AVR) a Raspberry mellé bekötve.[ Szerkesztve ]
-
atesss
addikt
válasz
t72killer
#38956
üzenetére
Én összeraktam kb. egy éve egy terhelő-tesztelő áramkört magamnak erre a célra.
Egy nagy próbanyák, rajta egy mini-nyákos microUSB aljzat [link] , és asszem 4 vagy 6db nagy teljesítményű ellenállás. Úgy hogy párosával tudom őket variálni (épp be legyen-e kötve a teszthez vagy sem), bontható sorkapcsokkal a nyákon belül. Meg mérési pontok feszültségnek, áramnak.
Asszem direkt úgy számoltam ki, hogy egy pár ellenállás 500mA-t terhel.
Simán kiegészíthetem még egy Type-C aljzattal is, ha találok valami hasonlóan könnyen beforrasztható kivitelt. Mondjuk Ali-ról biztos lenne, de Mo.-n még nem láttam.
Teszteltem vele annó vagy 10-15 kábelt is, meg még USB hosszabbítót is, a töltőfejeket is variáltam, néztem RPi gyári tápot is, stb. Ezért írtam ám ilyen magabiztosan a tapasztaltaimat.
Majd ha lesz rá időm, lehet csinálok egy tesztet Logoutra, tanulságos lenne.
Ha van közérthető dokumentáció róla, és nem nagyon bonyolult, akkor akár a "kommunikálós" alapú táp-igény kiszolgálós Type-C-t is tesztelhetem. (Bár nekem ilyen tápegységem egyelőre nem sok van.)
Hogyan működik ez, egyszerűen ilyen ellenállás-lépcső alapon (mint asszem a kisebb teljesítményű POE szabványok is) ?
Új hozzászólás Aktív témák
- RTX 2080TI ROG STRIX GAMER PC+ 144hz monitor hdr 10 27 col 1ms
- ASUS ROG STRIX Z370-H GAMING + Intel Core i5-8600K + SK Hynix 16GB DDR4 2666MHz - Számla + Garancia
- Eladó a felső polcról származó konfigom garanciával: 5800X/32GB DDR4/RTX 4070/250GB SSD/2TB HDD/850W
- i7-es PC, i7-4790 CPU, 16 GB DDR3 RAM, 1030 2 GB VGA, 240 GB SSD
- ICERIVER KAS KS5L - 12TH - 3400W
- Lenovo Thinkcentre M720Q Tiny minipc Win10 Pro 22 Hó Garancia
- Lenovo ThinkCentre M710q Intel Core i5-7500T(4mag,4szál)Wifi,Bluetooth
- Eladó újszerű Gamer Config I5 9600K, 32GB RAM, ASUS ROG RTX 2060 SUPER, Samsung ívelt 27 monitor
- Eladó több darab HP 400 G4 I3 7. gen számítógép Windows11, 250 gb SSD, 8gb ddr4 ram 6 hó gari!
- Eladó gyönyörű HPE ProLiant MicroServer Gen10, 1 év garancia, 0%-os számla