Miniszámítógépek, SBC-k

WebRTC server Raspberryn?

Hello, ha van valakinek otlete, hogy helyi (Raspberryn levo) video file-t hogyan lehet WebRTC streamnek kiadni (pl, Janus, stb.) , az jo lenne. Azaz a Raspi legyen a streamer szerver.

Itt nem a Raspi kamerajat akarom streamelni, amire rengeteg leiras van, hanem egy fullHD-s (vagy kisebb) mp4 file-t.

Ha van otlet, koszonettel veszem....konkret megoldas erdekel, nem teoriak.

(ha sima Ubuntu-s -azaz nem Raspis  leiras van, azt is koszonettel veszem...)

RPi + VMware

Érdekel mindenkinek az ezen irányú tapasztalata. Pl. 4 GB-os verzióval 3-4-5-8 VM-et tudtam, amik ezt-azt vagy amazt csináltak, és azt érzékeltem, hogy. Viszont a 8 GB-ossal ellenben, míg a 2 GB-ossal ezzel szemben.

A többi értelemszerűen offtopic. (ne Pi, hanem; ne VMware hanem; ne virtulizáció, hanem; ne SBC, hanem)

A miért-re a válasz egyértelmű: mert megtehetem.

z80 assemblert keresek linuxra

Parancssoros z80 assembler cross-compiler-t keresek. Jó lenne valami high-assembler szintű de legalábbis jó makrókezeléssel, hibareportolással. Az pedig hab lenne a tortán, ha képes lenne több parancsot is értelmezni egy sorban.

Amiket eddig próbáltam:

z80asm: hibás kódot is lefordít hibaüzenet nélkül, makrókezelése kezdetleges, akár fordítási időbe is belefagy, ha nem tetszik neki. Hibákat néha arra a fájlra jelzi, amiben van, néha arra a fájlra, amelyik include-dal használja, emiatt elég nehézkes.

crasm: nem tud bináris include-ot (legalábbis én nem találtam)

pasmo: a konstan kifejezéskiértékelése nem tud zárójelezni (a z80asm ebben elég jó), a lokális címkéket csak blokkon belül képes értelmezni, fájlon belül nem. (Ráadásul nem a . karaktert kezeli lokálisnak, mint más fordítók.)

zasm: bináris inlcude-ot ebben sem találtam. A többi tulajdonságában emiatt még nem mélyedtem el.

Eddig a pasmo a leginkább használható, de a lokális címkézése nehézkes. A perl féle objektumkezelés fájl szintű lokális címkézéssel kényelmesebb lenne. A konstans kifejezések külön nevesítése is felesleges körökre kényszerít.

Ha van ötletek, tapasztalatotok, szívesen olvasnám.

GPU terhelés mérése RPi4-en

Tud-e bárki valami hasonló toolt, mint

  • radeontop - nyilván AMD GPU-kra
  • intel-gpu-top - nyilván Intelre
  • gpustat, nvtop, nvidia-smi - Nvidia cuccokra

de működik a Raspberry pi4-ben levő Videocore VI GPU-ra és meg tudja mondani, hogy mennyi a GPU kihasználtsága?

OS: Raspberry pi OS 64 bit, Debian bullseye release (gyakorlatilag a latest ami most elérhető)

Háttér: Chromium-ból kísérletezek youtube és hasonló video streamelő oldalakról lejátszani. h264ify extension fenn van, a debug nézet ellenőrizve, hogy a video codec tényleg h.264. Lejátszás közben a

vcgencmd measure_clock h264

mutatja az órajelet, leállított lejátszásnál 0-t mutat. Ez alapján szerintem eléggé jól bizonyított, hogy hardveres h.264 lejátszás működik. VLC-vel a letöltött video lejátszása teljesen folytonos teljes képernyőn 1080p 60fps-sel is. Böngészőből viszont használhatatlanul akad. Full screenben kicsit jobb a helyzet.

Azt vettem észre, hogy a lejátszás közben a CPU igazából nincs teljesen kihasználva, a 4 magból mindre jut terhelés, de egyik sincs kimaxolva. A CPU húzva van 2GHz-re, semmit nem segített rajta. A Pi egyébként egy Flirc házban lakik, ami teljes egészében hűtőborda, remekül teszi a dolgát, minden maxra terhelve se megy 61C fölé - vagyis nem throttling a probléma. 

Megpróbáltam még a böngészős "UFO" tesztoldalon video nélkül megnézni, hogy mégis milyen sebességgel tud képet frissíteni, ez a szövegscrollozós teszt tűnt a leghasznosabbnak: https://www.testufo.com/framerates-text
Az eredmény, hogy a böngésző maximize-olt ablakban nem képes még szöveget sem 60fps-sel újrarajzolni, kb fél képernyőre kell az ablakot összehúzni, hogy a 60fps stabilan menjen. A CPU eközben nincs kimaxolva.

Az utolsó kisérlet volt a GPU overclock-olása. És valóban, ettől határozottan javul a helyzet. A doksi szerint a default 500 MHz-ről egészen 750 MHz-ig mehet. Mint kiderült ez nem hard limit, nekem egészen 830 MHz-ig sikerült húznom, mielőtt instabillá vált volna. Ennyi kellett is, hogy a szöveges scrollozása akadásmentesen vigye a 60 fps-t. Alapértelmezetten a

gpu_freq=830

paraméter mindent is 830MHz-re húz, ami nem ARM mag. Mint kiderült a h.264 engine ezt nem bírja, a video helyett csak memóriaszemetet látni.

h264_freq=750

sor hozzáadásával ezt vissza lehet venni 750MHz-re, de igazából bőven maradhatna 500 MHz-en is.

A videolejátszás böngészőben most ott tart, hogy 720p60 fullscreenben már egész folyamatosan megy, 1080p30 is, de 1080p60 továbbra is túl sok neki. Szerintem eléggé igazolt, hogy itt csakis a GPU lehet szűk keresztmetszet, viszont érdekes lenne tudni, hogy mit csinál a Chromium és valójában mekkora terhelést produkál a GPU-n. 

Mini PC w/ 2x 2.5" SATA

Sziasztok!

Tud valaki ajanlani egy olyan kis mini PC-t amibe 2x 2.5" SATA (vagy opcionalisan 2x M.2 NVME) diszket bele tudnek tenni? Olyasmire gondolnek mint a D@ll OptiPlex 7070 Micro vagy HP ED 800 G1 USDT, de nem 1x NVME + 1x SATA hanem "2x valami" kombinacioban. Ezen felul meg nem baj ha van rajta gigabites ethernet, de az gondolom mar alap :) 

Koszi, A.

ZX spectrum melegedésre betöltődés problémája

Van egy ZX Spectrum 48K számítógépem, amire a programokat nem magnóról, hanem laptopról tölteném be. A laptop teljes hangerőre van állítva, de így is 5 perc kell, mire a gép annyira bemelegszik, hogy sikerül betölteni a programokat.

Vagyis hidegen, bekapcsolás után a LOAD parancs nem tudja betölteni a programokat. A Spectrum a képernyő keretét villogtatja a talált bitek függvényében, így látszik is, hogy amíg be nem melegszik a gép, a keret nem csíkozódik. Aztán idővel egyre több csík jelenik meg, később már a program fejlécét is be tudja olvasni, de töltési hibával leáll. Kb. 5 perc elteltével pedig már stabilan be tudja tölteni a programokat.

A beszerezhető információk alapján ez egy issue 3-as gép, de az alaplap elrendezése mégis inkább az issue 2 elrendezésre hasonlít. A lényeg, hogy a 7805-ös hűtőbordája a gép hátuljánál halad végig, ahogy ez az issue 3 alaplap fotó mutatja.

A célom az lenne, hogy a normális működés megtartása mellett elérjem, hogy bekapcsoláskor is rögtön be tudjak tölteni a laptopról. Ehhez meg kellene találnom, hogy melyik alkatrész lehet az, aminek így változik az értéke, és azt egy másikra kicserélni.

A kapcsolási rajz alapján én a R36, R37 vagy D13-ra tippelnék. Ezek ott vannak az EAR csatlakozó és a hűtőborda végének a közelében. A hűtőbordához legközelebb a C28 kondenzátor van - ez az issue 3 elrendezésben nincs ott, de nálam ott van -, tehát ez érezheti meg legelőször a melegedést. De - az én elég hiányos ismereteim alapján - nem szólhat bele ennyire a betöltési szintbe.

Ha valakinek van kedve, és kicsit jobban ért hozzá, szívesen venném az ötleteket, hogy melyik alkatrész okozhatja ezt a jelenséget, miért, és milyenre lenne érdemes cserélni. (Remélem, hogy ez egy ellenállás lesz, aminek hőre csökken az értéke, így egy picit kisebbre cserélve hidegen is be tudna tölteni.)

ESP - Resol VBUS kommunikacio - segitsegkeres.

Kedves mindenki...

Nem tudom, jo helyre irom-e, ESP projekt - elektronikai komponens, forraszta stb ugyeben keresnek segitseget.
 

Van nekem egy RESOL VBUS napkollektor kontrollerem, ami nagyon jol teszi a dolgat, melegiti puffer tartalyt, csak sajnos en nem tudom integralni a Home Assistant-ba. Ennek akadalya, hogy teljesen ketbalkezes vagyok elektronikai aramkorok eloallitasabn, remeg a kezem, nem tudok forrasztani - es bar egy DHT11 et, PIR-t meg csak-csak osszedrotozok egy ESP-vel, de az alabbi cimen nehany ellenallast, IC-t is be kellene epiteni az aramkorbe.

Az ESPHome tamogatja a RESOL VBus-t es igazabol en keresnek valakit aki tudna nekem segiteni megepiteni a cimen szereplo aramkort hogy hozza tudjam kotni vegre a RESOL VBus-t a futes vezerlo ESP-mhez.

https://esphome.io/components/vbus.html

Ha nem jo helyre irok - elore is elnezest kerek, es kerem tegyetek a megfelelo helyre...

Elore is koszonom

RPi Korábbi LibreElec multiboot PINN (NOOBS) mellett

A NOOBS utód PINN is friss listát ajánl telepítésre a felkínált rendszerekből. Rasbian, azaz RaspberryOS-ből lehet választani előző kiadást, de LibreElecből nem. Ebből pedig mindenképp a korábbi KODI18-ra épülő kellene, mert az új LibreElecben hibás a hdmi-cec. Ez nyilvánvalóan nem a Kodi19 hibája, inkább az alatta levő Linux jeosban rontottak el valamit. Nem akarom megjavítani és bőven elég a KODI18, mert úgysem tudná kihasználni a Raspberry Pi a KODI19 újdonságait. 

Hogyan lehet korábbi LibreElec imaget letölteni PINN-hez? Illetve egy kisebb SD kártyán van egy korábbi LibreElec rendszerem. Az is megoldás ha ezt át lehet másolni az új nagyobb SD kártyára, csak nem árt ha be is bootolja a PINN. 

Más OS mint a RaspberryPiOS

Van bármilyen előnye, más operációs rendszert választani Raspberry Pi-re általános célokra, mint Raspberry Pi OS, régi nevén Raspbian? 

Ubuntu, Manjaro, Apertis a választék Linuxokból, illetve RiscOS. Természetesen ennél szélesebb a kínálat, Raspberry Pi imager ezeket tudja automatikus letöltéssel, kényelmi okokból elég ez a választék. 

Arduino analóg gombok

A kérdés inkább elektronikai/fizikai jellegű mint programozás.

Arduino nano-ból csinálok "okosotthon" vezérlést (egyelőre: világítás kapcsolás illetve hőmérséklet mérés a helyiségekbe, ami alapján kapcsolja majd a fűtés köröket egy másik arduino).

A probléma, hogy a digitális lábakból nincsen sok, és bizony van ahol pl. 8 kapcsoló van... Nem akarok 8 digitális lábat ellőni csak erre, hogy maradjon még jövőbeni fejleszéseknek. Itt van egy példa arra, hogy hogyan lehet 1 analóg lábra több gombot tenni:https://www.instructables.com/How-to-Multiple-Buttons-on-1-Analog-Pin-A…

Ez tök jó... Csak én azt találtam ki, hogy jó lenne, ha lennének kombók, azaz pl. más történik, ha 2 vagy 3 kapcsolót egyszerre nyomsz meg (Pl. két adott kapcsoló lenyomása egyszerre a helyiség összes világítását lekapcsolja. Vagy a főbejárat melletti kapcsolósornál 3 kapcsoló egyszerre lenyomása a ház összes felkapcsolva maradt villanyát lekapcsolja, és hasonlók). Szóval az ellenállások értékeit úgy kellene megválasztani (mondjuk menjünk el 8 db kapcsolóig, amiből egyszerre maximum tetszőleges 3-at le lehet nyomni), hogy egyértelműen meghatározható legyen, hogy melyik 1, 2 vagy 3 kapcsoló van lenyomva.