- Elektromos rásegítésű kerékpárok
- Luck Dragon: Asszociációs játék. :)
- gban: Ingyen kellene, de tegnapra
- Azonos árketegóriájú (105-110.000 Ft-os) relatív olcsó telefonok kamerái
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Pajac: tpm.msc
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- Szevam: „Rendszerleállás” – egy AI képzeletbeli halál utáni élménye
- Parci: Milyen mosógépet vegyek?
- bambano: Bambanő háza tája
-
LOGOUT
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
-
azbest
félisten
válasz
azbest
#42724
üzenetére
Libreelec kapcsán siker: a stable ágról kellett szedni a boot tartalmát [link] onnan felmásolni az overlay mappát, dto fájlokat és bootcode.bin fixup.dat start.elf fájlokat a kártyára.
Így játsza a videót is és nem száll el a kodi. Látja, hogy 1GHz-es a proci. Az 512 ramos gépek szerinti 160MB ramot fogja gpunak. Ez így pont jó.Terhelgetve 76 fok környékére ment fel most stress-ng --cpu=4 paraméterezéssel terhelve 1GHz-en. Viszont 1.2GHzen elkressel induláskor mint állat
-
azbest
félisten
válasz
azbest
#42722
üzenetére
Közben néztem, hogy 32 biten valamiért mégis jól meg a tavaszi raspbberry os rendszer alapból, az tölti le az imager is.
A 64-esen ha hagyom, hogy ráfrissítésre a kézzel másolt 5.10.76-v8+ kernel helyére a legutolsó stabilat, akkor elmegy a kép mert úgy tűnik 5.10.63-v8 a legutolsó stabil és az se teljesen kompatibilis még.Áh megvan, hogyan lehet másik kernel ágra váltani, a brancnek meg lehet adni, stable a sima, next a tesztelős (ahogy látom a next a master branch tartalmát szedi, 5.10.76 os verziót)
sudo BRANCH=next rpi-updateHa van másik 64bites pi, akkor lehet azon elő lehet ezt frissíteni a kártyán zero2be helyezés előtt.
Az rpi3 hoz való libreelecet is megpróbáltam feléleszteni zero2 w-vel. Ott az overlay mappát, dto fájlokat és bootcode.bin fixup.dat start.elf fájlokat frissítettem kézzel a master branchről.
Így elindul, de videó indítása helyett elkressel, lehet mást is kéne piszkálni vagy muszáj újabb verziót kivárni. Az új fajta wifit, ahogy várható volt nem ismeri. Szóval usb-lan adapterrel próbáltam.#42723 Aryes
a cpu rész ugyanaz, de most a tetejére van integrálva a ram is. És kisebb a nyák ami szétvigye a meleget. Ja és jobban megnézve, fentebb rosszul írtam, nem a pi3A+ hanem a sima pi3A -val egyező a cpu rész, BCM2837A1 -nek írják. Az alapítványosok is úgy fogalmaztak, hogy az első pi3-mal egyező fajta. Az meg 1.2 GHz-en ment, a + -os változat (BCM2837B0) lett 1.4 GHz. A pi zerora is azt mondják, hogy 1.2 sima liba, bár hűtés nem árt. Feljebb már lutri.
Nem tudom, hogy miért a régebbi dizájnt használták, amikor van frissített változatuk is belőle."uses the same Broadcom BCM2710A1 SoC die as the launch version of Raspberry Pi 3," [link]
-
cigam
titán
válasz
azbest
#42089
üzenetére
A docker image készítőjén múlik, de az is csak 1 beállítása a konténerek. Magának a konténernek a konfigja (létrehozása) ugyanolyan macera. Jó, lehet azzal kezdeni, hogy a portainer-t telepíted, és a GUI-ból "hozzácsapod" a többit, de ott is nagyon oda kell figyelni mit miért pipálsz be/ki, vagy hogy a portokoat, IP címeket hova állítod.
Persze ha elég türelmes - és ügyes - vagy, akkor készíthetsz magadnak egy scriptet, ami felveszi az összes konténert olyan beállításokkal, ami neked tetszik, de ez sem kezdőknek való móka.
Plusz ugye ott vannak az én rossz tapasztalataim(Se elindítani, de törölni nem tudtam a dokker image-t), ami miatt nem szimpi. Persze ettől még másnak simán működhet hosszútávon.
-
Tyson5
tag
válasz
azbest
#42038
üzenetére
A pi 1.2A áramot tud leadni usb interfészen, de én a tápfeszt két részre "osztom". Közvetlenül megtáplálom a raspbit és közvetlenül megtáplálok egy aktív usb hub-ot, amit rádugok a raspbira. A hub-ba megy minden ssd, pendrive stb.. így elvileg megoldódott a tápfesz probléma. Multiméterrel amit mértem áramokat egyenlőre tetszik
de néhány nap, néhány hét üzem után tudok biztosat mondani -
golya87
őstag
válasz
azbest
#41999
üzenetére
Feltette automatikus először a frissítéskor az OSMC, gondoltam kipróbálom. Az oldalán azt írták, hogy csak be kell jelentkezni, nem kell API kulcs. A régihez van kulcsom, de így én már nem kísérletezek ezzel. Már most megy a Win32DiskImg, tükrözi a másik Pi rendszerét. Ilyenkor bánom, hogy még nem hoztam össze az nfs-ről futtatást.
Sajnos engem ez a bő egy éve tartó bénázás a négyessel, a Youtube kliens köhögése egyre inkább valami dobozos médiajátékos megoldás felé terel.
-
válasz
azbest
#41955
üzenetére
Köszi, de szerintem marad a void, ha már ennyit szenvedtem vele. Meg nem vagyok egy nagy debian fan, plusz a rolling release otthoni használatra szerintem jobb, mint az ezeréves csomagok.
Ennek a setupnak annyi hátránya van, hogy mindent kézzel kell felszenvedni rá. A Bluetooth is 2 óra volt kb, mire összejött.
-
-
válasz
azbest
#41943
üzenetére
Köszi a választ!
1. Egyrészt azért választottam a zerot, mert ilyenem még nem volt. És igen, kicsi a fogyasztása. Illetve ami érdekes benne, az az OTG támogatás. A mikrotik routeremen van egy USB 2.0 port, azt rákötöttem a Pi Zero belső micro USB portjára, majd módosítottam a kernel init konfigját, hogy induljon, mint RNDIS eszköz. Így a router USB-n felismeri és be tudtam emelni egyetlen micro USB kábel segítségevel a Pi-t a hálózatba, plusz tölt is ugyanazzal a kábellel. Így a ping is kevesebb, mint 1 ms a router és a Pi közt, szóval nincs vele gondom. Meg 8 euróért nem kapok sehol pi4-et.
Ami viszont meglepett, hogy elég nagy input lag volt SSH-n, miután felraktam a raspbiant, pedig szűz telepítésről volt szó. GUI sem fut, full headless az egész és a light verziót raktam fel. Szerencsére ez "magától" elmúlt valahogy.
2. A video kimenetet már ismerem a pi4/pi2-ről, de sajnos ez itt nem pálya, ahogy írtam is, teljesen headless a rendszer. Még átalakítóm sincsen displayhez, csak egy micro USB kábel, meg egy SD kártya. A syslog viszont jó tipp, köszönöm. Egyelőre minden rendben van szerinte!
3. Nem tudom eldönteni, hogy mi okozhatja, maga az egyetlen processzormag alig van állandóan kihasználva a htop szerint. És csak az apt futott meg a htop, semmi más a stock rendszer processzein kívül. De csináltam egy dd tesztet cache nélkül és valószínűleg tényleg I/O bottleneck lesz. Jó, ha 2 MB/s-t tud, ami elég karcsú.
4. Hatalmas ötlet felcsatolni a /var/log-ot tmpfs-nek. Én is ezt fogom csinálni szerintem.
Egyébként felraktam a pihole -> stubby -> quad9 (DNS over TLS) triót és elég siralmasan teljesít, egy nem gyorsítótárazott kérés feloldása van hogy 730 ms, de általában 1-2 sec között van.
Olvastam pár helyen, hogy ez többek közt a Raspberry Pi OS/raspbian optimalizálatlansága miatt is lehet, de nem hiszem. Mindenesetre most kipróbálok egy Alpinet, illetve lecserélem a stubbyt unboundra. Van esetleg valami más lightweight os, ami megy headless és mondjuk nem musl-t, hanem glibc-t használ? Meg mondjuk nem debian alapú, hanem valami rolling release. -
#41856
wassermann
Topikgazda
azbest
#41853
wassermann
Topikgazda
válasz
azbest
#41853
üzenetére
Tulajdonképpen most nekem is csak vésztartaléknak van a "Málnám" (RPi 3). Nagyjából csak videómagnóként használom: ritkán, ha van kódolatlan csatornán olyan film amit fel akarok venni vagy később visszanézni, bekapcsolom és beállítom a TV-Headend-et.
... kivárok a következő nagy hardveres ugrásig!
-
Keem1
veterán
válasz
azbest
#41826
üzenetére
#41824 kutga:
Így van, pontosan. A DP++ (DP alternate) átviszi a HDMI jelet is (a két jelet együtt, tehát nem kell konvertálni), így ha egy DP++ aljzatba (átalakítóval) egy HDMI kábelt dugsz, akkor működni fog (épp azért, mivel ott van a HDMI jel is).
De a HDMI nem tartalmaz DP jelet, azt egy aktív átalakítóval konvertálni kell.Elnézést, nem azbest számára akart válasz lenni, csak idézni akartam
-
#41384
MasterDeeJay
veterán
azbest
#41383
válasz
azbest
#41383
üzenetére
Szerencsére jól működik de nyilván alaposan letisztítottam. Meg vagyok vele elégedve. Xbiant raktam rá. Kellőképpen gyors. Hűtésnek egy kis öntapadós rambordát kapott mert nincs nagy feladata, sima fullhd filmeket kell játszania. Kézzel nézve rajta tudom tartani a kezem lejátszás alatt így részemről nem kap plusz hűtést.
-
-
-
zzkrisz1
újonc
válasz
azbest
#40294
üzenetére
Szia!
Elvileg megcsináltam:
pi@raspberrypi:~ $ sudo vcgencmd bootloader_config
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
TFTP_IP=
TFTP_PREFIX=0
BOOT_ORDER=0xf14
[none]
FREEZE_VERSION=0
pi@raspberrypi:~ $Árírtam a BOOT_ORDER=0xf41-ről BOOT_ORDER=0xf14 -re
4:USB 1:SD (Jobbról-bal fele olvasa)
Mégsem hajlandó USB-ről bootolni, csak ha kihúzom az SD-t.
Valakinek, van ötlete, hogy miért? -
azbest
félisten
válasz
azbest
#39612
üzenetére
de fura, az alapítványos videóban azt mondják, hogy csak a lite (emmc nélküli) boarddal lehet használni az sd kártya slotot. Bár valószínűleg azért, mert a másik sd csatornát a wifi/bt modul használhatja (az sdio-n csatoalkozik a többi pi-n is)
Amúgy, mivel ilyen kompakt és még betáp szempontból is csak egy 5v kell tán neki, simán tudnak majd akár tablet vagy kézi játékkonzol alapokat is csinálni vele (persze valami hűtéssel).
-
-
válasz
azbest
#39595
üzenetére
Nem általános kodit telepítettem, a hivatalos tárolóból tettem fel.
Nem a felület lassú, azzal nincs baj. Online addonokat használok, az internetes kommunikáció bűn lassú, amikor keresi a stream-eket, frissíti a trakt.tv alapján az adatokat stb. Próbáltam már friss libreelec-kel is, az is ilyen lassú volt, nem a telepítés a probléma.
A kodi a rendszerrel indul, ahogy kell.Megírja végre valaki, hogy tudok régi verziót telepíteni tárolóból??
-
TheTruth
tag
válasz
azbest
#39547
üzenetére
Bocs, nem reszleteztem tul. Szoval en mar rtorrentet hasznalok, nem a kliens a hibas (de igen, anno Transmissionnel sok jogosultsagi herce-hurcam volt). Amugy
Pi 4 Model B Rev 1.1-em van.Ez a szomoru valosag kozben, hogy "The EMMC2 bus can only directly address the first 1GB."
Szoval az van hogyha elinditom az rtorrentet es figyelem kozbe masik terminalba a free parancs kimenetet, ahogy lefogy 3GB szabadig a memoria, egyszeruen elkezdodik az OOM reaper es kiirtja a dolgokat.
(Ahogy a fenti linken par comment javasolja elorebb, kiprobaltam nem-e az USB-re iras a problema, de a sima dd paranccsal kitudok irni 6-8 gigat is minden problema nelkul, tehat nem az kezdi ki a rendszert)
Elegge idegesito, tekintve h ott van meg 3GB szabadon
-
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
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. -
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. -
-
V.Stryker
nagyúr
válasz
azbest
#38885
üzenetére
Köszönöm. Ez meg is oldotta.
Amúgy az aposztróf ott volt a leírásban is.
MÁS: - sd kártyáról használom a rendszert, de sok minden, pl böngészésnél a youtube eléggé lagol. Van valami mód esetleg valami gyorsítótár vagy valami létrehozására? ha jól rémlik itt még swap partíció sincs.
-
V.Stryker
nagyúr
válasz
azbest
#38869
üzenetére
Olvastam csak nem értem.
Most kiolvastam és BOOT_ORDER=0xf41 és az általad linkelt leírásban az van,hogy jobbról balra olvasva kell nézni, tehát az 1-es az sd kártya és a fenti cím szerint folyamatosan próbálja az sd kártyát, majd usb.
Na, most kicseréltem egy másik sd kártyára, amint szintén alap rendszer van. Ennél meg nem dobja fel.
Nem értem. A bootloadert az sd kártya tartalmazza? az nem valami alap chipbe van írva?
-
_q
addikt
válasz
azbest
#38823
üzenetére
Lehet igazad van. Legelőször én is a leírás alapján csináltam amit linkeltem, azóta már csak upgrade-et használok és pár napja így frissült az eeprom is, legalább is láttam hogy pörögtek a sorok ott volt az eeprom frissítés is, majd megnéztem és az addigi 6.15-ről 6.16 dátumra változott a bootloader dátum.
Igen grafiksu felületen van egy SD copy applikáció, viszont aki lite, desktop nélküli verziót használ nekik nem opció .
-
Keem1
veterán
válasz
azbest
#38432
üzenetére
A routeren mindennek tartós bérlete van (értsd: dinamikus IP, de MAC alapján mindig ugyanazt osztja ki mindennek), a tévétől kezdve az összes telefon, tablet, pc, pi-k (4 esetén wifi, lan), de hostnevet nem lehet.
A gépemben is beállítottam a hosts alatt a lan ip-t, de mégse történik semmi...
Most kikapcsoltam a wifit...ami azért nem jó ötlet, mert ha elmenne itthon a net, akkor van itthon egy mifi is egy digis kártyával, és minden itthoni eszközön be van állítva, bekapcsolom a mifit, és 1-2 percen belül minden ugyanúgy kap netet, mint azelőtt.
Most home office alatt nem egyszer előfordult, hogy a UPC kapitulált (ami azért azelőtt nem igazán volt jellemző). -
Keem1
veterán
válasz
azbest
#38385
üzenetére
UPC, de most a home office időszakban náluk is voltak/vannak anomáliák. Eddig abban a tudatban éltem, hogy a UPC hálózata a legstabilabb, állandóan 300 Mbit fölötti sebességet, 6-8 ms pinget mértem. De mióta haza kényszerültek az emberek, a törékeny egyensúly megborult. A céges VPN azonnal elkezdett szakadozni.
Pedig az tutira megfelelően van méretezve, mi, a kritikus rendszerekhez hozzáférni jogosult alkalmazottak mindig is VPN-en (+hardverkulcs) keresztül dolgoztunk, ez nem is az a VPN szerver, amit a home office-os mezei irodai dolgozók használnak.
Szóval itt is tuti a UPC lehetett a ludas.
-
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
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ó...) -
#38261
Marcsello31
őstag
azbest
#38256
Marcsello31
őstag
válasz
azbest
#38256
üzenetére
Aha, akkor még lehet várni kéne pár hónapot míg ez is kiforja magát? Bár nem értem, mert az elődjeiknek meg vannak a dolgai akkor ennek mért nem? Várok még lehet egy két hónapot, megnézem mi változik addig. Androidnak fullosnak kéne lennie pedig, rengeteg változat van pedig, HA meg procierőből dolgozik az megint nem jó, mert nem húzza sokáig. Persze hogy magas a hőfokja akkor. Akkor marad a passzív hűtőborda. Amúgy lehet rá már tenni win10 desktopot is. Csak nem tudom mi értelme (:.
-
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). -
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
#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 ?
-
Keem1
veterán
válasz
azbest
#37938
üzenetére
Vagy nem interaktív hanem a login paraméter kell neki talán
/bin/bash -l script....
Úgy felszedi a futtató user profil konfigját (ami alapból talán a root
már ha általános cron és nem crontab -bal futtatod egy user alól. Ha crontabbal futtatod, akkor az adott userként futna szerintem, amihez beállítottad.Nagyon köszönöm ezt a javaslatot, ez volt a megoldás
Simán mennek a backupok cronból! -
Keem1
veterán
válasz
azbest
#37938
üzenetére
Már nem tudom szerkeszteni az előzőt...
Szóval a -l switchet mögé biggyesztem, aztán jön a script útvonala, és úgy oly módon fut, mintha bejelentkezett root indította volna?
Kipróbálom... Köszönöm a tippet!Update: rendben, köszönöm, beírtam a cronba, mindkét eszköznél. Holnap megnézem, mi lett a nóta vége.
-
Keem1
veterán
válasz
azbest
#37936
üzenetére
Hexa editor szerint 4 GB-nyi nulla a fájl tartalma.
A cron bejegyzés után biggyesztettem egy logba átirányítást, éjjel lefut újra, és holnap megnézem a logot.
Senki nem próbálta még cronnal futtatni a scriptet? Most lefuttattam kézzel, tökéletes. 5 napnyi mentést tároltam, az éjjeliek mind hibásak.
Ja, és a Zero mentéseivel is teljesen ugyanez a helyzet.Hoppáá.. a Zeron volt log.
Nem mindenütt, de több esetben az rynceknél operation not permitted/supported (mindkettő előfordul) szerepel.
Pedig a cron ugyebár rootként fut, ez biztos is, hisz az említett log root:root tulajdonosú. -
zsolt_64
senior tag
válasz
azbest
#37931
üzenetére
Ha kijön rá, és minden hardver lehetőségét kiszasználja (hardware video acceleration ) akkor istenbiz veszek egyet....
egyébként egy nagyvállalati rendszerben ahol mindenkinek virtuális gépe van, és csak 2 monitort kell mehajtani + klavevegér a távoli asztalhoz ott nagyon jó lehet. Mivel hálózati boot is van ezért még sd kártya sem kell bele. Így lehet egyen munkaállomást csinálni... -
mgergo76
tag
válasz
azbest
#37142
üzenetére
Ok, így már tiszta a lábak bekötése.
(#37143) TA
Ha 3 panelból egy sem működik rendesen, akkor vagy a csatlakozók vannak rossz sorrendben rádugva a GPIO-ra, vagy a programban kell módosítani a lábkiosztások paramétereit.
Ha van multimétered, akkor érdemes megmérni az egyes kapcsokon a feszültség különbségeket. -
TA
friss újonc
válasz
azbest
#37139
üzenetére
Igen, azért vettem direkt ezt...
Kollegánál van egy másik ugyanilyen PI, ugyanezen relé modul 2 relés változata, és ugyanez a szitu vele, mind a pi, mind a relémodul oldalról...
Igen, a linken lévő az. Pontosan ez: http://www.malnasuli.hu/wp-content/uploads/2019/11/eight_relay_cont_pi.py -
válasz
azbest
#36682
üzenetére
Nekem van olyan powerbankom, amelyik éppen el tudná látni a Raspberry szünetmentes tápellátását, de mivel valóban nem erre van kitalálva, ez a használat elég gyorsan degradálná az akkut.
Ez viszont egy szerintem használható ötlet a BitekMindenholtól.
Megjegyezném egyébként, hogy ilyen célra tipikusan az ólomakku lenne az ideális.
MaCS
-
#36683
wassermann
Topikgazda
azbest
#36674
wassermann
Topikgazda
válasz
azbest
#36674
üzenetére
Az évek során, nem csak a hardver, hanem a szoftverek is sokat fejlődtek. Emlékszem az első Pi-m örökké bekapcsolva lógott a régi CRT-s TV-m mögött, mert úgy volt megbízható.
A mostani szegény PI-t meg simán leállítás nélkül áramtalanítjuk, ha lekapcsoljuk a TV elosztóját. Már több hónapja megy ez így és az OSMC is és a Raspbian is sértetlen (Noob-os dual boot)
-
PistiSan
addikt
válasz
azbest
#36670
üzenetére
Ahhoz még így is drága, hogy csak azért vegyek egyet, mert most olcsóbb ^^
5 hónapja van meg a PI4-em, azóta főleg NAS funkciókat lát el, meglepődve tapasztalom, hogy atom stabilan teszi a dolgát, a régi 1-es pi-vel még anno sok gondom volt, 1-2 havonta mindig meghalt az SD kártyán a rendszer, meg lehet nem olyan volt az usb hubom tápellátása sem ami tökéletes volt neki, használom még az 1-et is, csak más célra. A PI4-el összességében nagyon elégedett vagyok.
-
Keem1
veterán
válasz
azbest
#36614
üzenetére
Így van, két partíció van rajta, de a / (root) a túlnyomó része
Szerk: kezdem érteni, a dd block szinten másol, és nem veszi figyelembe a katalógusbejegyzéseket (a fizikai blokkokban ott vannak ugyebár a törölt adatok is, csak a katalógusbejegyzésből hiányoznak, így az OS és a többi szoftver azt a területet üresnek látja).
Így nézek ki jelenleg partícióügyileg:
Filesystem Size Used Avail Use% Mounted on
/dev/root 118G 17G 96G 15% /
devtmpfs 1.8G 0 1.8G 0% /dev
tmpfs 1.9G 4.0K 1.9G 1% /dev/shm
tmpfs 1.9G 20M 1.9G 1% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
/dev/sda1 853G 115G 738G 13% /media/ssd
/dev/mmcblk0p1 253M 53M 200M 21% /boot
tmpfs 386M 0 386M 0% /run/user/1000 -
golya87
őstag
válasz
azbest
#36390
üzenetére
Szerintem idénre max ráncfelvarrás várható, ha egyáltalán. A type-c csatival van gond, bár nem tudom pontosan (talán nem elég "okos") és a melegedés, ami miatt nem árthat egy újabb revízió.
De egy Pi Zero-nak 3b+ procival, esetleg egy 4-essel nagyon örülnék.
CM változat 4-es procival dúrván jó lenne klaszterezésre. -
válasz
azbest
#35519
üzenetére
SD-vel 0 az előny, csak az új fotógép XQD-t és CFExpress-t használ, pont ennek a backupolása lenne a lényeg nomád környezetben, ahova laptopot nem de egy jól összecsomagolt berryt el tudnék vinni.
Utánanéztem, igen, ez 1x 2.0-ás busz, totál 500MB/sec, azaz legideálisabb esetben ebből 250MB/sec lenne a másolás kariról SSD-re/egyéb gyors adathordozóra.
-
-
Dißnäëß
nagyúr
válasz
azbest
#35506
üzenetére
Igazából egy átlagos "jutyúber" gépre, Raspbiannal, valami szép desktoppal szvsz tökéletes lehet, csak amíg nincs VP9, és 360p-vel is nyög egy video, na meg a minősége, az úgy még nem az igazi így 2020 előtt kicsivel.
De jó hallani, hogy tudja ezt is elvileg. A szoftver majd kiforrja magát. Addig is ezt a mostanit összerakom faternak, nekem pedig lehet hoz még egy Pi4-et a Jézuska.
Megjött az új Armour házikó, kézlangyi sincs a kütyü, pedig megy már vagy fél órája, letéve a sarokba. Nagyon-nagyon ajánlott. (Mondanám, hogy melegen ajánlott, de ne szórakozzunk a meleggel ez esetben)
-
cigam
titán
válasz
azbest
#35506
üzenetére
Meg is lennék lepve ha pi4-en a h.264 vagy az mpeg2 akadozna
![;]](//cdn.rios.hu/dl/s/v1.gif)
Viszont a (jóval)régebbi darabok igényelhetik. Nem eset szó konkrét modellról, csak hogy "akadozik". Ha jól rémlik eddig mindenkinek megoldódott, vmilyen beállítással és vagy licence-el a videólejátszással összefüggő probléma. -
Dißnäëß
nagyúr
válasz
azbest
#35497
üzenetére
Így a partvonalról: pucéron, Volumio alatt (tehát kvázi-terheletlenül) 56 fok a proci, szabadon a levegőben lógva.
A gyári házában felfő a Pi és throttlingol, egy teszt alapján lőttem hozzá egy passzív Armor nevű "házat" ami hűtés is egyben, ezzel szép konzisztens 4 mag púpon terhelés esetén is a hőmérséklet és tartja a gyári max órajeleket.
No meg élettartamot növel (már akinek ez számít).
[link] A teszt.
Én egy 5V-ra lekötött 12V-os PC házventivel meglegyezem az Armour passzív hűtést és tökjó lesz mindenre.
-
sztanozs
veterán
válasz
azbest
#35486
üzenetére
Nem tudom tesztelve lett-e a 10bit RPi4-alatt, sajna nekem nincs csak egy kettesem, szóval sem cáfolni, sem megerősíteni nem tudom. Mivel egyébként dekódolási szempontból ugyanaz a 10 bit, mint a 8 (legalább is láthatóan csak a colorspace van elcseszve) hihetetlen, hogy még senki nem írt egy szoftver patch-et a korrigálásra... vagy ez ennél bonyolultabb?
, értem legalábbis nagyjából 
. A transzkódolás meglep, mint Pi feladat, komolyabb erőforrásigényt képzeltem mögé.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
.
Olvastam pár helyen, hogy ez többek közt a Raspberry Pi OS/raspbian optimalizálatlansága miatt is lehet, de nem hiszem. Mindenesetre most kipróbálok egy Alpinet, illetve lecserélem a stubbyt unboundra. Van esetleg valami más lightweight os, ami megy headless és mondjuk nem musl-t, hanem glibc-t használ? Meg mondjuk nem debian alapú, hanem valami rolling release.
Új hozzászólás Aktív témák
Hirdetés
wassermann- Huawei Mate 20 128GB, Kártyafüggetlen, 1 Év Garanciával
- Xiaomi Redmi Note 13 256GB Kártyafüggetlen 1Év Garanciával
- Bomba ár! Dell Latitude E5570 Touch - i5-6300U I 8GB I 256SSD I 15,6" FHD I HDMI I CAM I W10 I Gari
- AKCIÓ! AMD Ryzen 9 3900X 12 mag 24 szál processzor garanciával hibátlan működéssel
- LG 45GS95QE - 45" Ívelt OLED / 2K WQHD / 240Hz 0.03ms / NVIDIA G-Sync / FreeSync Premium / HDMI 2.1
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest