Btw nekem egy 700 mA-es Samsung (SGS) tápról ment kb fél évet (míg el nem adtam). Csak billentyűzet+hálózat volt rajta.

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Nekem USB infra vevővel, USB pendrive-al és egérrel még az 500mA-es is meghajtotta, de 2A-st szoktam használni.

Nekem is addig, amig az SSD-t neha-neha el-eldobalta...aztan jott a 2,5A es most a 4 portos 2*2A + 2*3A USB tap (eloszto)

Én igaz csak xbmc-vel használom, nas-ról.

"We'll meet you where the lights are...."

A B+ kevesebbet fogyaszt, ellenben konfigurálható, hogy mennyire legyen terhelhető az usb portja. Ezt már írtam is neked korábban, csak lehet átsiklottál felette [link]

A 600mA az alapértelmezett korlát, ha nincsen bekapcsolva a nagy áramú mód. Bekapcsolva már 1200mA, csak bírja a táp is.

A B+ megfelelő beállítással és erős táppal egyedül is képes meghajtani egy mobilwinyót is a hírek szerint.

[ Szerkesztve ]

RPi-Monitor és DHT11 szenzor - lyukas rögzítés megoldva

A DHT11 szenzor ugye mint az köztudott, nem mindig ad vissza megfelelően adatot. Ettől a RPi-Monitor szép fésűs jelet rögzít a grafikonjaiban. Egy nagyon egyszerű, kézenfekvő megoldással átvertem. Nem is értem, miért nem tette meg eddig, vagy miért nem ezzel kezdtem.

A python script-et használom, azt írtam át egy kicsit. A RPi-Monitor nem közvetlenül a szenzort kéri le, hanem egy percenként CRON-nal frissített log fájlból olvas (azt is ugye 2x kérné le szerencsétlen a két adat miatt).

A script-ben a vége így módosult, azaz nem tesz semmit, ha nincsen érték, hagyja a logot érintetlenül, ha van érték, akkor pedig közvetlenül ír a logba, nem a print-et használja adat átadásra:

...
if humidity is not None and temperature is not None:

line= 'Temp = {0:0.0f} *C, Hum = {1:0.0f} %'.format(temperature, humidity)
print line
file = open("/var/log/dht11.log", "w")
file.write(line)
file.close()

else:
print 'Failed to get reading. Try again!'

Ezt percenként futtatja a CRON:

*/1 * * * * sudo /home/pi/Adafruit_Python_DHT/examples/./AdafruitDHT.py 11 4 >/dev/null 2>&1

Az RPi-Monitor pedig a log fájlt olvassa csak. Ennyi a temp.conf-om erre vonatkozó része:

dynamic.16.name=temp_in
dynamic.16.source=cat /var/log/dht11.log
dynamic.16.regexp=Temp = (\S+)
dynamic.16.postprocess=$1/1
dynamic.16.rrd=GAUGE

dynamic.17.name=humidity_in
dynamic.17.source=cat /var/log/dht11.log
dynamic.17.regexp=Hum = (\S+)
dynamic.17.postprocess=$1/1
dynamic.17.rrd=GAUGE
...

Persze, még majd cizellálom annyival az egészet, hogy ha a log öregebb, mint 5 perc, akkor törlésre kerül, így nem lesz a szenzor levételekor, vagy elromlásakor egy vízszintes hamis érték.

Itt az este már normális értékeket rögíztő grafikon, melynek első fele igen csak randa, de megérte este fent maradni a jobb feléért:

Google: Sancho blogja

Nem, sajnos, ennyire nem értek hozzá.

Ja, és a cat nem kell, anélkül is olvassa a logot.

Google: Sancho blogja

eloszor is meg kell keresned, hogy hol van az a konkret rrd file, amibe ezeket az ertekeket irja. ha mas nem, akkor az rpi-monitor kodjabol kell kinezni. Remelhetoleg minden szenzorhoz kulon file-t hasznal, es nem egy nagy file-t az osszes mert adathoz. Igy csak azt az rrd file-t kell lecserelni. Ezutan kiadsz egy rrdtool info filenev parancsot, es megnezed, hogy mi a file-definicio. Ezt kell atszerkesztened sajatra. Ha ez alapjan megvan, hogy hogy tarolta az rpi-monitor az adatokat, akkor mar csak el kell kesziteni az uj, neki megfelelo szerkezetu rrd-t, amiben viszont te beallitod a limiteket, ez az rrdtool-nal transzparens, vagyis barmilyen korlatot allitasz be, az rpi-monitor nem fog behalni.
Peldaul nalam a homersekleti, fordulatszam, feszultseg ertekek rogzitese is egy ilyen strukturaba tortenik:
rrdtool create filenev.rrd --step 1
DS:data:GAUGE:1000
RRA:AVERAGE:0.999:1:4000
RRA:AVERAGE:0.999:5:4000
RRA:AVERAGE:0.999:15:4000
RRA:AVERAGE:0.999:60:4000
RRA:AVERAGE:0.999:300:4000
RRA:AVERAGE:0.999:900:4000
RRA:AVERAGE:0.999:3600:4000
RRA:AVERAGE:0.999:10800:4000
RRA:AVERAGE:0.999:86400:4000
ez a fenti definicio 1 masodpercenkenti adatrogzitest jelent (--step 1) nagyjabol 15 perces (DS:data:GAUGE:1000:U) megengedett adatkesessel, 99.9%-os megengedett adathiannyal (RRA:AVERAGE:0.999:1:4000) (tehat ha ~15 perc idejen belul csak az ido 0.1%-ban van adat, akkor azt en mar elfogadom rogzitendo adatnak, homersekletnel ez megteheto, nem valtozik olyan hirtelen) ahol nincs elvart minimum es maximum ertek (DS:data:GAUGE:1000 , U=unlimited), hanem minden szam rogzitesre kerul (valojaban ez nem igaz, mert en a rogzites elott manualisan szurok. Ennek az oka az, hogy ha holnap rajovok, hogy meg szeretnem emelni a minimum/maximum erteket, ahhoz ujra kell definialni az adatbazist, ami az osszes adat elvesztesevel jar - alapbol. Ez az oka az 1 masodperces rogzitesnek is, ez valojaban nem tortenik meg, de az adatbazis fel van ra keszitve (es debugolaskor bizony hasznalom is, ha nem akarok perceket varni a debug-ertekekre.)). Az atlagolt ertekekbol minden felbontasra 4000 erteket orzok meg (RRA:AVERAGE:0.999:1:4000) , hogy a jovore gondolva egy 4K-s monitor felbontasahoz igazitva az abrazolaskor 1:1 legyen az adat-pixel felbontas. Az atlagolt ertekek emberi idonkent vannak tarolva: 1=1 masodperc, 5=5s, 15=15s, 60=1m, 300=5m, 900=15m, 3600=1h, 10800=3h, 86400=1d (RRA:AVERAGE:0.999:86400:4000) . Ez utobbi legnagyobb felbontasban 1 pixel 1 napot abrazol, ez 4000 rogzitett ertekkel mar 10 evet lefed. Az adatmezo neve (DS:data:GAUGE:1000) "data" (szinten az ujradefinialas-adatvesztes miatt), az adatrogzites modja GAUGE (DS:data:GAUGE:1000), vagyis mero (homero, voltmero).
Tehat neked a minimum-maximum ertekekhez (nalam U=unlimited), a bejovo adatok megengedett kesesehez (nalam 1000 =1000 masodperc) es a megengedett adathianyhoz (nalam 0.999=99.9%) kell hozzanyulni, az eredetihez kepest modositani.

szerk: az a baj, hogyha nem monospace, hanem programkod taget hasznalok, akkor az kiirtja a benne levo formazotageket is, magyarul nem tudnam kiszurkiteni a nem kiemelt reszeket.

[ Szerkesztve ]

KöszI!!!

Google: Sancho blogja

Sziasztok!

RFID-t szeretnék rendelni, viszont értelmes infót nem találok az 522-es típusról.
Tudtok segíteni abban, hogy miért kerül négyszer-ötször többe a PN532-es verzió?

[RC522]

PN532

Köszönöm!

mert a drágábbik az egy nfc cucc, ami többek között rfid-t is tud, az olcsóbbik meg egy rfid cucc, ami nem tud nfc-t.

az rfid valódi részhalmaza az nfc-nek.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Adott egy taviranyitoval kezelheto eszkoz. Kigondoltam, hogy jo lenne a taviranyitot a RPI-vel helyettesiteni, mert arrol mar eleg sokminden mast is vezerlek. Az megoldhato, hogy a vezerelni kivant eszkoz erzekeloje a RPI iranyaba nezzen. Tudtok olyan kutyut javasolni ami megfelelne erre a feladatra, hogy egy tetszoleges taviranyitot kivaltsak vele, ha az RPI-re kotom? Milyen szoftvert hasznaltok Ti ehhez?

akkountvadasz

nekem a médiacenteres verzióban vásárolt tv tuner kártyámhoz adtak olyan infra cuccot, amiben adó is volt.
lirc-cel működött.

más cuccok távirányításával baj lehet, ha a távirányító túl hosszú parancsokat küldözget az eszköznek, azt a lirc nem kezeli alapértelmezésben. egy klímával jártam rosszul, a távirányító gombnyomásra a teljes klímaprogramot átküldte és ettől a lirc fejreállt.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Köszönöm!

Jaja, megint.

Google: Sancho blogja

Hello

Eddig hibátlan RPi B + OE 4.1.6 a napokban az alábbiakat produkálja:
- néha elmegy a hang
- kicsit elcsúszik a kép
- hosszú időre elmegy a kép
- ezek keveréke

A tv hibátlan, mert a menüje nem zavarosodik. HDMI kábelt cseréltem.
OC van beállítva, bár nem túlzásba.
Mi lehet a baj?

Előre is köszönöm a segítséget!

a "beta" jelző nem véletlenül van ott a neve mellett, használj stabil kiadást (4.0.7), ha pedig azzal is csinálja akkor vedd le az oc-t

Megtörtént mindkettő, semmi változás. Este még kipróbálom, hogy egy másik kártyát teszek a Pi-be. Hátha.

Sziasztok!

Azt szeretném megkérdezni, hogy hogyan lehetséges az, hogy van egy fizikai usb -s webkamerám ami /dev/video0 ként van jelen. Ezt szeretném virtuálisan video1 ként is, hogy jöjjön létre ugyan az a kamera.
Más programban is szeretném használni, de csak egyszerre csak egy helyen lehetséges.
Találtam egy kis leírást ami elvileg 2 osztja. Leirás

Viszont ha a leírás alapján próbálom indítani ezt kapom eredményül. Nem találtam a gstreamfiltershere elemet.
pi@raspberrypi ~/Desktop $ gst-launch -v v4l2src ! gstreamfiltershere ! v4l2sink device=/dev/video1
FIGYELMEZTETÉS: hibás adatcsatorna: nincs „gstreamfiltershere” elem
pi@raspberrypi ~/Desktop $

Mit javasoltok?
Köszönöm szépen előre is segítséget!

Ha kizarolagosan fogja valami akkor sztem ez nem fog menni.

Mjpg streamer -l képeket készítek percenként.
FFmpeg programmal meg Ustream felé szeretném streamelni.

mjpgstream lefogja kizarolagosan, meg akkor is ha csak fotokat keszitesz. Ekkor nem fog hozzaferni semmi sem.

De miert kell ehhez ffmpeg?
Miert nem csinalod akkor ezt inkabb fswebcam-mel?

Mert nem hallottam róla és nem ismerem

Van valakinek felesleges Raspberry Pi Model B+ háza? Három hete rendeltem meg ebayről másodjára, de még mindig nem érkezett meg és már szívesen bedobozolnám.

Ennél profibb megoldás egy PC táp háza

HOgy ez nekem nem jutott eszembe!!!

Mekkora otlet!

Szazasaval varnak megsemmisitesre a tapok nalunk, selejt mind.

Ennél az akril ház jobban tetszik. Vargáné Tsa táp van itthon, de ahhoz, hogy normálisan nézzen ki ahhoz szintereznem is kéne.

Ja a tápról tudni kell ha elég nagy az usb vége akkor ki fog lógni és nem tudod rátenni a tetejét. Én vettem hozzá 90 fokra elfogratott mikor usb -t a tápnak és USB nek is. Mert nem fért bele normálisan
+ vettem hozzá chipset passzív bordákat, ráragasztottam hővetető öntapadós ragasztóval.
12cm -s ventit meg 5v -n tartva hajtóm.
Faraday kalitkaként meg megvédi a külső zavaroktól a panelt.

Fswebcam programmal lehet programot futtatni?
Ezért használom az Mjpg streamert, külső programot lehet indítani vele miután elkészítette a fotót.

fswebcam-20061210

- Added syslog support via log command.
- Added pidfile command for saving the process ID (PID) to file.
- The output command has been replaced by the log command.
- Added framedump command for dumping the raw captured data to file.
- Added exec command for running external programs after capture.

Forrás

ÚÚÚÚ, de jó. Erre szokás mondani, hogy Google a barátom!

A másik kérdésem ha ezzel készítek fényképeket akkor is le lesz foglalva a kamera? Vagy streamelni tudok mellette Ustream felé.
1600x1200 -s felbontású képeket készítek. Mivel a kamera fizikailag is tudja ezt. Logitech c905.
Ustream felé egy enyhébb méretű képeket szeretnék küldeni.

A harmadik kérdésem, hogy megvettem 2 kodeket a raspberrytől. 2e Ft ba került. Ezzel elérhető, hogy ha videóval dolgozok a málnán besegít a számolásban a GPU is?

1. Mondtam mar, amig keszul a foto addig lefogja, igen. Tehat nem fersz hozza.

2. Szerintem az csak dekodolni fog neked.

Köszönöm!

Egy kicsit kitérnék FFmpeg felé.
A másik kérdésem, amikor elindítom FFmpeg -t mondjuk egy 640x480 -s felbontásban teljes erővel kiakasztja a processzort. Ez a konvertálás miatt lenne?
A videó bemenet v4l2 kodeket használ, mást nem tudtam választani, kimenete flv. Ezt tudok Ustream felé küldeni.

Nyilvan nem eleg neki a kraft.

én egy 15x15-ös falba süllyeszthető kötődobozba tettem és úgy fel a falra (kicsit régi kép, már ki van tömve a doboz rendesen):

akkountvadasz

remelem, szigetelted.

Sziasztok!

Sikerült vagy mégsem felkonfigurálni egy Xbox 360-as távirányítót Xbian alatt a gipo porton.
Ha tápfeszültség alá helyezem a masinát az XBMC indulása után a távirányítónak csak egy-két gombja üzemel, ha újraindítom az XBMC szervizt SSH-n keresztül, akkor minden működik tökéletesen.
Szerintetek mi lehet a gond?

Köszönettel:
Cini

Azt mondja már meg nekem vki hogy a banana
valójában a raspberry utódja vagy csal kínai koppintása?
A két eszköz teljesen kompatibilis?

Megvehető a banán?

[ Szerkesztve ]

" I'm going to make him an offer he can't refuse."

Nem utódja. Ez egy másik gyártó (talán kínai) cucca, hasonló (egyező?) mérettel és gpio kiosztással.
Az egyikben Broadcom cpu van, a másikban egy Allwinner cpu. Más magszám, más architektúra.

Azt vágom h technikailag jobb a banán.
Minden elfut a banánon amin a raspberry n
tud vmi olyat a raspberry amit a banán nem?

[ Szerkesztve ]

" I'm going to make him an offer he can't refuse."

Tudtommal az Allwinner és a Broadcom cpu nem egy ARM generáció, így nem hiszem, hogy egy az egyben lenne átjárhatóság. Gondolom újra kell fordítani és egyéb finomhangolások, ergo az RPi leírások ott maximum iránymutatónak jók.

Az RPi mögött van egy óriási közösség, tele megoldással és leírással, míg sztem a banán mögött csak nagyon kicsi.

De menjünk a dolgok elébe. Mit szeretnél az RPi-vel csinálni?
Hátha van rá jobb megoldás, mint a banán, vagy lehet az RPi is elég.

Igazából otthoni használatra kéne.
Mediára esetleg egy riasztóra de mivel hosszú távra tervezek
ha már veszek akkor jót szeretnék ezert gondoltam a banánra
látván hogy erősebb a vas.

MOD A málnánál a sima és a + verzió között a mi a difi?

[ Szerkesztve ]

" I'm going to make him an offer he can't refuse."