-
Fototrend
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
-
válasz
vadkörte
#48844
üzenetére
Az LLM-ekkel kapcsolatban az az általános tévhit, hogy egyfajta "intelligens keresők", azaz az intrnetről nézik ki a választ. Ez azonban nem így van, mert igen veszélyes lenne az internet teljes tartalmával tanítani egyrészt, másrészt maga a tanítási folyamat is igen hosszadalmas tud lenni. Az LLM a saját betanításakori információkat "ismeri", ami nem feltétlenül naprakész. Ezért naprakész információkat számonkérni tőlük nem jó elképzelés.
Amikor ragaszkodik egy információhoz, az nem hallucináció, hanem az esetleges rossz vagy elavult információkkal való betanításáé, és a "ragaszkodik a hallucinációjához" nem is értelmezhető - legalábbis a hallucináció fogalmának LLM-kontextusban való értelmezése alapján.
De én a téves elvárásokat nem nevezném user error-nak, hiszen a hype akkora körülöttük, hogy az olyan jogosnak vélt hallgatólagos elvárásokat generál, amiket az LLM ma (még) nem tud teljesíteni. Az, hogy mindenre (is), bármilyen rosszul feltett kérdés legyen, azonnal vágja a helyes választ, mára már a Kano-modell szerinti "dissastisfier" kategóriájú követelménnyé vált, és mivel nem teljesítik az LLM-ek, ezért jól láthatóak már mindenfelé a lelkesedés korszakát követő alapos kiábrándultság jelei (amikor olyanokat mondanak egy LLM-ről, hogy "buta mint a föld, állandóan hallucinál, és ragaszkodik a hallucinációjához", mert egy-egy XY által ismert információt nem helyesen közli, akkor XY elfelejti, hogy mindezek mellett az LLM tudásbázisa egy-egy emberének, így XY tudásának is többezerszerese; azt pedig a legtöbben (még) nem is tudják, hogy eme óriási tudásbázis kiaknázására ill. a válaszok tényszerűségének (factuality) növelésére és a hallucinációk számának csökkentésére külön tudományág van kialakulóban, az ún. "prompt engineering", ami komoly kutatásokon alapul, és amiben nap mint nap újabb és újabb tudományos publikációk születnek.
Én örülök ennek a kiábrándultságnak, mert kijózanítja az elvárásokat, és segít megtalálni az LLM-ekben azt az elképesztően hasznos eszközt, ami. De egy bonyolult eszköz, és mint minden bonyolult eszközt (pl. egy repülőgépet) ezt sem lehet felkészültség nélkül használni, bármennyire is próbálják elhitetni velünk.
Egy új kor hajnalán vagyunk, amiben ha úgy tetszik, a prompt engineering a programozás új paradigmája.
-
#48835
Aszpirin
támogató
///Krisz\\\
#48833
válasz
///Krisz\\\
#48833
üzenetére
-
Köszi, ez hasznos
Amúgy mit reklamáljak? Hogy érted, hogy miért nem vár az eszköz az internetre?
Az egyik egy Volvo V60 autó, a másik egy Viessmann Vitodens 100W kazán.
A Volvónak és a Viessmann-nak is saját IoT megoldásuk van, és a lokális API-t nem adják ki (a Volvo esetében főleg security, a Viessmann esetében főleg safety okokból teljesen érthető, hogy a lokális API-ra csatlakozást saját kézben tartják, nem adják ki 3rd partynak).
Az Edge nélküli IoT megoldásoknál (mindekttő tipikusan ilyen) a szenzoradatok "betáplálása" és azok kliens általi lekérése külön folyamaton megy, elkülönített interfészeken ("Southbound" ill. "Northbound", ha foglalkoztál már IoT-val), aszinkron módon. Ha lekérsz egy szenzoradatot, jobb esetben megkapod annak timestampjét is, ami azt mutatja, hogy az adat nagyon friss. Rosszabb esetben (ha leszakadt a kütyü /autó, kazán/ az internetről/, akkor régebbi adatot kapsz.
Mindkét gyártó publikálja a Northbound API-ját, és elérhetővé teszi az autentikált userek számára, hogy kliens applikációjuk számára (jelen esetben a HA) authentication key-t generáljanak, aminek használatával egyszrei user-autentikáció után az applikáció hozzáfér a user kütyüje szenzoradataihoz illetve eseményeket is tud kiváltani /pl triggerelni tudja az autó indítását, szellőztetés indítását, ilyenek/).
Alighanem ezeket tudtad, szóval bocs, hogy leírtam, inkább a többieknek, akik esetleg nem láttak még IoT architektúrákat.
Szóval az interneten a két gyártó Northbound interfésze ott van, ők nem "szakadnak le", és a HA-nak ezekre van szüksége. Az auto mint "eszköz" egyébként a saját SIM-kártyáján keresztül "lóg" az interneten, ő ée sem szakad. A kazán igen, de mint láttuk,, nem közvetlenül tőle lesz lekérdezve az adat.
A probléma inkább azzal van, hogy a HA-na zok az integrációk, amelyek internetet igényelnek, nem várják meg az indulással az internet meglétét, és belehalnak abba, hogy nem tudnak be-autentikálni a gyártói IoT-interfészekre.
A többi már ebből következik.
Fura, mert pl. a Homey-nál nincs ilyen probléma. Erre maga a HA is vigyázhatna egy (re)boot utáni integráció-indításokkor, mert az, hogy egy integráció igényel internetet, egyértelműen ott van a manifestben (az integráció IoI-class-a "cloud_polling"):{
"domain": "vicare",
"name": "Viessmann ViCare",
"codeowners": ["@CFenner"],
"config_flow": true,
"dhcp": [
{
"macaddress": "B87424*"
}
],
"documentation": "https://www.home-assistant.io/integrations/vicare",
"integration_type": "hub",
"iot_class": "cloud_polling",
"loggers": ["PyViCare"],
"requirements": ["PyViCare==2.55.0"],
"version": "1.0.99"
}
(mellesleg van okosotthon-topik, ahol intenzíven foglalkoznak a HA-val (főleg azzal), és nem is ide szántam a kérdést, csak véletlenül pakoltam ide be. A sors fintora, hogy Te adtál a legprofibb választ rá, szóval a HA-szakértőknél jobb vagy
(Amúgy meg nem használok docker-compose-t és ha a HA-t dockerbe rakod fel, ő sem pakol fel compose file-t /bár ebben nem vagyok biztos!/. Portainer-t használok, ahol egy Stack lényegében ugyanazt jelenti, mint egy docker-compose file, de még nem készítettem el neki. Ideje már...)
-
Az a gond, hogy ha nem jön meg az internet, nem indul el.
Olyan volt már nálam is, hogy visszajött az áram, és volt WLAN meg Ethernet LAN is, de az internetre várnolm kellett másnapig, amíg megoldották nekem távolról a telekomos műszakiak...
Ha leblokkolom a HAOS vagy docker esetében akár a host OS bootolását az internet hiányában, akkor egy halom automatizálást blokkolok, miközben a túlnyomó többségük nem igényel internetet. -
Köszi a Tippet.
Az oprendszert azt biztos nem blokkoltatnám internet hiányában, szerintem az nem annyira jó ötlet.
Viszont a HA docker konténerben van, annak jó lenne csak akkor indulnia, ha van internet, ha nincs, várjon. Függetlenül attól, miért és hogyan lett leállítva és újraindítva. -
Sziasztok!
Van egy általános jellegű problémám, talán Ti is találkoztatok már vele.
A probléma két olyan HA-integrációval van, amelyek internetet igényelnek a működéshez (nekem csak ez a kettő ilyen van, de lehet, hogy mindegyik internetes autentikációt igénylő integrációra kiterjed a probléma). A gond, hogy ha áramszünet van, a HA gyorsabban feláll, mint az internet kapcsolat, elindulnak az integrációk, autentikálni akarnak a felhőikkel az API-kulcsot és a korábbi autentikációs tokennel, de mivel nincs internet, ez nem megy, és itt behal az integráció. A két eset nálam: Viessmann és Volvo. A viessmann egy sima Reconfigure-val ment, a Volvo viszont sehogy sem akart autentikálni, újra kellett generálnom az API kulcsot a Volvo felületén, újra kellett indítanom a HA-t, majd a Volvo integráción Reconfigure, újraautentikálás, új API key megadása, és innentől újra fut.
Ez a Viessmann esetében csak vgvagy 3 klikk, de a Volvo esetében is pár kliekkel beoldható, nem ez a fő probléma. Hanem hogy Elhalnak az automatizációik, és lehet, hogy észre sem veszem, mindez egy esetleges áramszünet miatt, ami akár pillanatnyi is lehet, nálunk sajnos ez eléggé gyakori. Márpedig az egész főleg az automatizációk miatt van... (Nálam Homey Pró-n futnak az automatizációk, a HA "csak" az integrációk miatt van speciális esetekre (jelenleg három Device-ot veszek át a Homey-ba a HA-ból: az Ecowitt WS90 időjárás-állomást, a Viesmann Vitodenss '00W kazánt, és a Volvo autómat. Mindegyiknek meg van az alapos oka, hogy miért nem a natív Homey-integrációt használom).
Szóval, Ti talékoztatok-e ezzel a problémával és ha igen, miként oldottázok meg, vagy miként oldanátok meg? Tul. képpen csak annyi kellene, hogy a Viessmann és Volvo integrációk késleltetve induljanak el egy HA-újrindítás esetén, én már belőném, hogy kb mennyi idő múlva van már internet. Nem sok ez az idő, de tuti nincs még, amikor elindulnak.
Köszi szépen a segítséget (és vegyétek figyelembe, hogy HA-ban viszonylag kezdő vagyok, szóval elnézést előre is, ha túl banális a kérdés).
-
válasz
#62436096
#48784
üzenetére
Igen, jól érted, bár a helyzet egy picit összetettebb lehet, mint itt sokan gondolnák.
A transzkódolást kép esetén erőltetetten ki lehet kapcsolni, itt csak az kell, hogy a kliens le tudja játszani. Hang esetén más ea helyzet, ott ha a kliens nem azt "mondja" a szervernek, hogy elboldogjl vele, akkor a szerver transzkódolni fogja a hangot. Tehát pl. egy Dolby Atmos-ból csinál AAC 2.0-t (Ezt csak egy példa), és ezzel küldi a képet a kliensnek.
Áltslában igaz, hogy ha ismered a klienseket, és tudod, hoygy mit képesek lejátszani, akkor tutod, hogy milyen kép/hangformátummal NE tölts le filmet, és mindenki heppi
-
válasz
#62436096
#48777
üzenetére
Nálam egy RPi CM5-ös konfigon (8GB RAM, 64GB eMMC a rendszernek és 1TB NVMe SSD a torrentezéshez) fut a PLEX, Directstream-mel és Directplay-jel viszi rendesen a képet, 4K kép-transzkódolás viszont megfekszi a gyomrát, hang-trasnzkódolás egy kliensnek nem probléma 4K direct streammel. Kép trnaszkódolás 1 kliensnek FHD-ben még elmegy.
TLDR: lakáson belüli használatra torrent szerverrel együtt is, jó kliensekkel, kikapcsolt kép-transzkódolással teljesen okés. Én elégedett vagyok vele. Ha ismeretlenek a kliensek, vagy korlátozott a sávszélesség, akkor nem javaslom az RPi-t. -
válasz
lkristóf
#48775
üzenetére
Igen, a bemásolt képernyőkép 6. sorában látható I/O error alapján eléggé egyértelmű, hogy a microSD kártya (/dev/mmcblk0) - amiről az oprendszert próbálná betölteni - meghibásodott.
Az eredeti kérdésre: van hivatalos RPi microSD kártya előtelepített PiOS-szel, szerintem azt lenne érdemes használni: [link] -
Nem tudok jobb szakmai érvet, mint hogy GitHub Copilotot használok már majdnem egy éve, napi szinten, a pénzkereső munkámhoz (Informatikus vagyok, a senior fullstack fajta, egy nagy /értsd: kb 2ezer fős) szoftverfejlesztő cégnél, ipari területetn, leginkább prototipizálással foglalkozom). Kb augusztus óta nem találkoztam hallucinációval. Amiben született ezalatt "kód": C#, Python, Terraform, _gitlab_ci.yml, dockerfile, docker-compose, bash scriptek és MATLAB.
A hobbi dolgokhoz (kb mindenhez, nem csak IT témákban) pedig előfizetéses ChatGPT-t. Jelenleg 5.2-nél tart.
Ha nem tudsz rájönni, hogy mire jó, akkor tényleg nem neked való, de akkor készülj fel rá, hogy NAGYON rövid időn belül nagy bajban leszel, és ezt érdemes nagyon komolyan venni.
Ugyanis tetszik vagy nem tetszik, a prgramozásra ill. IT-s fejlesztésekre kiélezett LLM-ek (ld. GitHub Copilot) teljesen újradefiniálják a szfrverfejlesztési paradigmát, értelmét vesztik a "Java-programozó", "C++-programozó", stb. kategóriák, és előtérbe kerül a prompt engineering. Komolyabb jhelkyeken már a promptok kerülnek a version management rendszerekbe, egyelőre a kód mellé, de hamarosan a kód helyett...
Nekem egyébként hányingerem van az AI-hype-tól, mert nem, az LLM nem intelligencia, csak a jó öreg machine learningre épített nagyon fejlett algoritmus(halmaz), de a hasznosságát és a hatékonyságát nehéz lesz megkerülni a szakmában. Nagyon nehéz lesz. Vagy felülsz a hullámra, vagy elmerülsz. És ez MOST tényleg nem vicc. -
Végülis igazad van, magamnak okoztam a szopást
, de hát az LXDE olyan fapados, 20 évvel ezelőtti feelinget ad, míg a GNOME egy modern, eredeti UI-koncepciójú felület, ami RPi-n is teljesen rendben fut...Az X úgy fut, hpgy az Xrdp egy Xorg-ot RDP-re, majd ezen az XRDP start scriptje (/etc/xrdp/startwm.sh) pedig ebben indítja el a gnome-session-t. Így persze nem az RPi-re esetleg csatolt képernyőn látható kép lesz duplikálva, de egy remote grafikus kliensem lesz, és ez nekem pont tökéletes!
(ehhez persze a megfelelő konfiguráció kell, de ezzel nem untatnám a nagyérdeműt, akit érdekel írja meg privátban)
Íme, az RPi session Gmome-mal egy macOS-ablakban:
Ami az MI-t illeti, amiot írtál az egy "divatos" érv ellenük, de: már leírtam egy Mac-es topikban: csak óvatosan a kijelentésekkel, a félévvel ezelőtti tapasztalat garantáltan nem releváns már. Az AI chatbot-ok és IT-s copilotok programozás- és általában IT-"tudása" félelmetes tempóban fejlődik. Az elmúlt évben rengeteget dolgoztam ilyen. copilotokat hasznélva, ami még május-júniusban széthallucinálta az agyam, az augusztustól NAPI hasznéálatban máig egyetlen egyet sem hallucinélt már. FÉLEMLETESEN jó. Itt az idő ezt a hallucinálásra hivatkozást félretenni, és ez nem vicc, járj magad is utána...
Nálunk már kvázi-kötelező az AI, mindenesetre már mérik, hogy ki mennyit használja a Github-Copilot-ot. Ésn a csapból is az folyik, hogy használd. Nem véletlen, iszonyatosan fel lehet gyorsítani vele a fejlesztést, főleg a prototipizálási fázisban. -
Na, Éjjel 2 óra van, és VÉGRE a probléma megoldva.
Nem is akarom elmondani, mi mindennt csináltam végig, iszonyat frusztráló volt, nem ment.
A tanulságok, hátha valakinek segítenek, direkt beírva a kulcsszavakat, amivel esetleg elő lehet keresni ezt a bejegyzést:
1. Jump Desktop sz RPi-vel NEM KOMPATIBILIS, RPi-re nem fogsz tudni vele RDP-zni. Az ajánlott RDP kliens Mac esetében a Microsoft Windows App nevű progi (App Store-ban fellelhető, ingyenes), Windows esetében a beépített Remote Desktop.
2. a GNOME saját hnome_remot_desktop service-e egyszerűen NEM MŰKÖDIK Raspberry Pi CM5-ön.
3. A megoldás: XRDP-t kell telepíteni és használni. Mivel az XRDP Wayland-en nem működik, úgy kell konfigurálni, hogy saját magának egy Xorg-ot indítson a távoli elérés részére
4. az RPi-n / GNOME-on javasolt beállítani az auto logint valamint a képernyő lockot.
5. a haverom, ChatGPT 5.2, további hasznos magyarázatokat és tanácsokat is adott, lásd:
Ez a történet sikerrel zárult, távoli képernyőn GNOME felületet kapok az RPi-hez, de ismét megerősítette a Linux elleni antipátiámat: egy olyan oprendszerrel, amivel folyamatosan éjszakába nyúló sessionöket kell eltölteni, hogy a máshol teljesen simán és 2-3 perc alatt beállíthatóan működő dolgok menjenek, csak igazi geek-eknek van keresnivalójuk, akik szórakozásból órákon át püfölik a billentyűket a Linux által mindegyre előállított feladványok megoldása érdeképben. Akiknek a géphasználat nem eszköz, hanem maga a cél.
Persze ha az embernek már RPi-je van (főleg CM4/5), akor eléggé geek-nek számít hogy ilyen apróságokon, hogy éjszakázások, ne rinyáljon -
-
Elérem az RPi-t a 3389-es porton a kliens gépről (M2Pro Macbook Pro), nem ezzel van a gond, hanem ezzel ni:
Vagyis az RDP service halott az RPi-n. Na jó, akkor indítsuk újra:
Én ezt nem értem. Milyen credential-ok hiányoznak? Mi az a GKeyFile?
Van ötleted, hogy mit kezdhetek ezzel? -
Visszaállítottam az imént Wayland-re (raspi-config-gal), reboot... és megáll az ész... most nincs a Settings / Sharing alatt Remote desktop... WTF???
(imádom bmeg a linuxot.... mindennel napokat kell szopni, ami más rendszereken kb azonnal megy).
De egyébként volt már waylandon, próbáltam, nem ment. csak most a javaslatodra a tűzfalat csekkolnám... mert azzal lehet gond...Szerk.: megvan, a Settings / System alatt van a Remote Desktop.... bocs, valszeg korábban is onnan lőttem be...
Mindjárt nézem, mi történik.
Szerk2. Van egy olyan fül is itt , hogy Remote Login. Ha azt bekapcsolom, átrakja a Remote Sharing-et 3390-re egy üzenettel, a Remote Login pedig elfoglalja a 3389-et...
Egyelőre így lesz, aztán meglátjuk... -
X11. Az xrdp nem megy Wayland-on, ezért váltottam vissza X11-re. De Wayland-on sem ment a gnome-remote-desktop (ami az általad említett beépített RDP-megoldás, vagyis természetesen próbáltam)
Hogy érted, hogy melyik disztró? A Trixie-re épülő legújabb 64 bites PiOS, hadd ne mondjak most verziószámot, a legújabb Így értetted? -
Sziasztok! Van valaki, akinél működik RPi-n GNOME-mal a RDP vagy VNC alapú remote dektop?
Amióta GNOME-ra váltottam, már mindent kipróbáltam, de még a RPi ID alapú felhős távoli elérés is megszűnt létezni.
xrdp-t egyszer működésre bírtam, nem Gnome jött be vele, de legalább grafikus felület... és még ezt a félsikert sem sikerült soha többé megismételni.Jump Desktop-ot (fizetős többprotokollos remote desktop kliens) használnék kliensnek Mac-en, Windowsra, másik Mac-re megy vele gond nélkül a bejelentkezés
-
Igen. Legalább 4GB RAM legyen és legalább 32GB microSD, utóbbi legyen jófjta, ne a legolcsóbb izé.
Nálam RPi 5-ön fut a HA, a 64 bites PiOS-en, dockerben, de persze felrakhatod direktben a HAOS-t is RPi Imager 2.0.0-val (az OS választásánál "Another specific OS" - "Home automation" - "Home Assistant"), ha csak arra akarod használni, úgy jobb is. -
#48703
Aszpirin
támogató
wassermann
#48702
válasz
wassermann
#48702
üzenetére
Köszi, igen, elég sokat keresgéltem a problémával kapsolatban, a probléma ismert, és eléggé öszetett. Az okozza, hogy a BT-perifériák, ha nincsenek használatban, egy idő után "elalszanak" az akkumulátoridő növelése érdekében. A BT-kommunikáció sajátosságai miatt itt megszakad a kapcsolat, és a felébredéskor szükség lenne agy reconnectre, de ezt a periféria nem tudja kezdeményezni, az RPi pedig nem észleli a "felébredést". Patthelyzet. A megoldások között a legtöbbeknbél egy cron-nal időzített script fut, amelyik folyamatosan polloz, és vagy nem engedi elaludni a perifériát (ez nem jó az ajkkumulátorának), vagy ha a trusted perifériát disconnect állapotban találja, akkor megpróbál reconnectelni, és ezt folyamatosan mondjuk félpercenként ismételgeti. Azt hiszem nem kell magyaráznom, miért nem ideális megoldás ez, de egyelőre jobbat nem találtam. Ezt fogom én is csinálni, de csak a billentyűzettel, mert ha a billentyűzet automatikusan konnektál, annak segítségével már tudok terminált indítani és egyetlen paranccsal újraindítom a BT-alrendszert, amiután konnektelni fog az egér is.
-
Az új problémák...
Probléma 1. Bluetooth billentyűzetet és bluetooth egeret használok ( [kép] ), de ha huzamosabb ideig (mondjuke egy éjsztakéra) úgy hagyom, és lelockol a monitor, akkor mindekttő valahogy "leszkad", és nem akar újracsatlakozni. Ilyenkor be kell SSH-znom az RPi-re egy másik gépról és újraindítanom a bluetooth alrendszert (
systemctl restart bluetooth), és akkor minden jó lesz megint. De ez macera... Egyelőre fingom sincs, mitől vabn ez... ötlet esetleg? Találkoztatok már hasonló jelenséggel?Probléma 2. A felületet átváltottam GNOME-ra, mert 8GB memóriával már nem szükséges ez a minimalista KDE alapú RPi-felület... Na de ezzel sajnos megszűnt a Raspberry Pi Connect-en való screen sharing. Ellenőriztem a Connect-et az RPi-n, és semmi de semmi hibát nem mutat.
-
#48695
Aszpirin
támogató
wassermann
#48690
válasz
wassermann
#48690
üzenetére
Szerintem kell neki. Akkor nem kellene, ha nem lenne dobozban.
A hűtőborda ugye azért kell, hogy a CM5-ös chipjei könnyebben leadják a hőt. Ha ezt egy nyílt térben végzik, akkor az felforrósítja a levegőt a bordák között , ami egyszerűen felszáll, a helyébe alulról hideg lép (konvekciós hatás)
A dobozban viszont nagyon szűk a tér, nem tud elszállni a felmelegedett levegő, és a bordák nem érik a doboz tetejét, nem tudják közvetlenül átadni a hőt annak, így a doboz beldeje befülled, és egyre rosszabb a hőleadása a bordának. A kis ventiáálor abban segít, hogy beszívja a hideg levegőt, így nyomás keletkezik azon az oldalon (a ventillátor nem a bordák fölött, hanem azotkól balra van, és a dobozon lévő ventilátor-lyukakon szív), ami "kifújja" a forró levegőt a doboz jobboldali nyílásain.
A ventillátor alapesetben nem dolgozik, és elég "fösvény", viszonylag későn indul be... de ha a procit meghajtom, bizony a CM5-ös rendesen bemelegszik, a ventillátor beindul, egyre gyorsabban, és fújja ki a kézzel is érezhetően meleg/forró levegőt a jobb szélen.
A gond annyi, hogy maximális fordulatszámon nagyon hangos ez a piciny ventillátor... ezért első reakcióm az volt nekem is, hogy menjen csak ventillátor nélkül...
Mondom a borda elég, ha nyitva van a doboz. De a bezárt dobozhhoz kell a v ventillátor, sajnos. A CM5-ös rendesen tud már melegedni. -
Megvan!!!!!!
(kirpóbáltam másik antennával, azzal sem ment. De megvan a megoldás!!!! - és mint szinte mindig a legnagyobb szívásoknál, ez is egy végtelenül banális dolog...).A külső antenna csatlakozó csak a CM4 és CM5 sajátja, és alapból nincs bekapcsolva. Van egy alaplapi antennája, azt használja. És a megoldás, hogy a /boot/firmware/config.txt végéhez hozzá kel adni ezt a sort:
dtparam=ant2
majd újraindítani a Pi-t és MEGY!!!! felufrott a WiFi-sebesség, a háznak abban a szegletében, ahol van a Pi (távol a routertől) ez már teljesen jó és használható WiFi sebesség:
Hát ez színtiszta sz.pás volt. De hátha okul valaki még belőle, aki CM4-et vagy CM5-öt használ (a normál RPi 4B vagy RPi 5 nem érintett ebben, nem lévén külső antenna-csatlakozója.... (esetleg az összefoglalót érdemes lenne kiegészíteni ezzel az infóval? Ebbe a problémaába TITU hogy belefut, aki CM4-et vagy CM5-öt akar fémdobozban használni.... -
válasz
Aszpirin
#48684
üzenetére
Naszóval, levettem a CM5-öt is az I/O boardról, hűtőbordástól, de sajnos a kis csatlakozó felületszerelt, és a thátoldalon nincs olyan forrpont, ami jól láthatóan a csatlakozó forró pontját jelentené, ezért felülről kell találni ilyent. Ideteszem a képet. A két nagyobbik (alsó-felső) forrpont az árnyékolásra megy, a képen baloldalinak konkrétan sem az árnyékolással, sem a forróponttal nincs kapcsolata (modjuk ez fura), valószínűleg a képen legkisebbnek látszó, jobboldali lesz a forróponté, de ahhoz meg a műszerem legvékonyabb tűjével sem tudok hozzáférni, olyan apró (amúgy az egész csatlakozó átmérőben kb másfél milliméter vagy kevesebb, eszméletlen pici, olyan vele szarakodni, mint kesztyűs kézzel bolhát fogni....
PS. Közben hozzáfértem a felső képen a CM5 csatlakozó egységének jobboldali forrpontjához, na az a forrópont, szóval sikerült bemérnem a visszarakott csatlakozóval is, onnan egészen a dobozból kimenő csatlakozó forró pontjáig rendben van a vezetés. És nincs zárlat. Már csak azt kellene kitalálnom, hogyan mérjem meg, gogy az antenna, amikor betekerem a dobozból kijövő csatlakozóba, kontaktot képez. -
Köszi! Levettem a miniatűr csatlakozót amit olyan nehezen csatlakoztattam a CM5-ön lévő anyához (apához? fene tudja ezeknél melyik melyik...). Méricskéltem.
A kábelvégi miniatűr csatlakozó forró pontja és a házból kivezető csatlakozó forró pontja között gyakorlatilag nincs ellenállás, ugyanez van az árnyékoláó részek között. Az árnyékolás és a forró pont között nincs kapsolat. A kábel tehát nem szakadt, a rajta lévő cstalkozók pedig nem zárlatosak. A CM5-ön lévő csatlkozó sem zárlatos.
Azt viszont fogalmam sincs, hogyan mérjem ki, hogy amikor rátekerem az antennát, ott rendes kapcsolat van. Mindenesetre befújtam kontattisztítóval. Egyelőre keresem azt a pontot is, amin tudom ellenőrizni, hogy a CM5-re csatlakoztatott miniatűr csatlakozó nak jó kontaktot alkot a forróponton a CM5-ön lévő forró ponttal... Egyelőre befújom ezt is kontakttisztítóval.... Ami eddig biztos: zárlat egyik csatlakozóban sincs, és kábelszakadás sincs. Ami nem biztos: hogy a csatlakozók biztos kapcsolatot létesítenek. -
#48682
Aszpirin
támogató
wassermann
#48664
válasz
wassermann
#48664
üzenetére
Ha több lap meg volt nyitva akadoztak, fagytak. Nem tudom, hogy az Raspberry Pi 5-ös jobb-e ebből a szempontból
Határozottan jobb. Most is Rpi.ről írok, jelenleg ezzel együtt 8 oldal van megnyitva a Chromium-ban, köztük Facebook és Youtube is. Minden akadozásmentesen megy, teljesen használható (bár nem erre szántam, de kipróbáltam, és most nem tudok szabadulni tőle, hogy ez az apró kütyün milyen flottul lehet pl. böngészni
) -
Kedves topiktársak! Új vagyok ebben a topikban, ezért elnézést kérek, hogy nem olvastam végig az összes hozzászólást, és olyasmit kérdezek, amiről esetleg esett itt már szó.
Elsősorban otthoni PLEX-szerver céljából raktam össze egy RPi CM5 alapú kis kütyüt, az alábbiakból (mind "hivatalos" alkatrész)
- Raspberry Pi Compute Module 5 8GB RAM 64 GB eMMC
- Raspberry Pi Compute Module 5 Passive Cooler
- Raspberry Pi Compute Module 5 I/O board
- Raspberry Pi Compute Module 5 I/O Board Case
- Raspberry Pi NVMe SSD 1 TB
- Raspberry Pi Compute Module 4/5 Antenna KitAz eMMC-re telepítettem a PiOS-t, PLEX szervert, QBitTorrent-et, és egyéb apróságot (de szándékomban áll még Docker alatt egy Home Assistant telepítése is, ez még nincs kész)
Az NVMe SSD-t pedig permanens módon mountoltam az /mnt/ssd mountpoint alá, szintén extfs4-tre formáztam, és itt van a PLEX médiakönyvtára (egyben a QBittorrent célkönyvtára )A művelet eddig totál siker.... lenne, ha a WiFi és a BlueTooth rendesen működne. Az hagyján, hogy az antennacsatlakozóval kb fél órát kínlódtam, amig sikerült rányomnom az apát a CM5-ösön lévő anyára (közben bőszen anyázva azt, az aki ezt az elcseszett kontrukciót kitalálta...), de az antenna maga olyan gyenge, hogy ha rendeltetésszerűen becsukom a csupa fém készülékdobozt, akkor a WiFi-vétel 1 MBps alá csökken, és a bluetooth is annyira akadozik, hogy pl. egy BT-hangszórón élvezhetetlen egy Youtube-videó hangja is, folyton akadozik. Ha leveszem az RPi doboz tetejét, akkor megszűnnek a problémák, tehát egyértelműen az antenna a bűnös. A WiFi helyett így fix ethernet-csatlakozást használok, de a BT problémája akkor is ott van.
Kérdésem esetleg azok felé, akik esetleg használtak már hivatalos CM4/CM5 antennát: ez tényleg ilyen gyenge, vagy én fogtam ki egy vacak példányt, esetleg mégsem sikerült a csatlakoztatás tökéletesen? (utóbbit nem tudom elképzelni, hogyan lehetne jobban....)
)
Új hozzászólás Aktív témák
- Asztali PC , i7 9700 , RX 6600 , 16GB DDR4 , 512GB m.2 , 500GB HDD
- Gamer PC
- MSI MAG B650 TOMAHAWK WIFI + AMD Ryzen 9 7950X3D
- BESZÁMÍTÁS! Asus PRIME H510M i5 11400 16GB DDR4 512GB SSD RX 6600 8GB Rampage SHIVA Adata 600W
- BESZÁMÍTÁS! ASRock A520M R5 5500 8GB DDR4 250GB SSD GTX 1050 Ti 4GB Sharkoon RGB Slider 400W
- ÚJ AKKU! Ár/ÉRTÉK BAJNOK! Dell Latitude 5330 i3-1215U 6mag! 16GB 512GB 13.3" FHD 1 év gar
- HIBÁTLAN iPhone 15 Plus 128GB Blue-1 ÉV GARANCIA - Kártyafüggetlen, MS4531,90% Akksi
- Beszámítás! Apple iPad 9 (2021) Wifi 64GB tablet garanciával hibátlan működéssel
- MacBook Air M1 13" 16GB RAM 256GB SSD 27% áfás számla 0347AB
- 14" Dell Latitude laptopok: 5400, 5480, 5490, 7480, E6410, E6440, E5450 / SZÁMLA + GARANCIA
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest