I2C busz-on nem látja egyik szenzort sem Raspberry Pi 3 model B plusszon

Elektronika, Elektromos eszközök

Sziasztok,

Adott egy
Raspberry Pi 3 model B+
Raspbian lite (stretch) default install image-ből, minden működik megfelelően, kivéve az I2C, de erről lentebb.

Adott egy BME680-as szenzor, ami I2C és SPI-t is támogat, 3,3V és 5V-ot, természetesen RPI-n 3,3V-ot adok neki.

Termék infó:
https://www.adafruit.com/product/3660

Leírás, bekötés, ez az érdekesebb:

https://learn.adafruit.com/adafruit-bme680-humidity-temperature-baromet…

GPIO-ra kötöm, a megfelelő helyre:

https://learn.sparkfun.com/tutorials/raspberry-gpio/gpio-pinout

Itt fent a RPI pin-ek.

A szenzoron:

Power Pins:
* Vin - this is the power pin. Since the sensor chip uses 3 VDC, we have included a voltage regulator on board that will take 3-5VDC and safely convert it down. To power the board, give it the same power as the logic level of your microcontroller - e.g. for a 5V micro like Arduino, use 5V

Ezt kötöm a GPIO PIN 01-re, ami 3,3V.

* GND - common ground for power and logic

Ezt kötöm a GPIO PIN 09-re, ami a föld.

I2C Logic pins: az I2C-s kommunkációhoz

* SCK - this is also the I2C clock pin, connect to your microcontrollers I2C clock line.

Ezt kötöttem az I2C SCL-hez, ami a GPIO PIN 05.

* SDI - this is also the I2C data pin, connect to your microcontrollers I2C data line.

Ezt kötöttem az I2C SDA-hoz, ami a GPIO PIN 03.

Ez így jó? Kell valami ellenállást rakni, ha csak 1 I2C eszközt rakok rá? Több szenzor esetén hogy kössem? (lásd lentebb I2C master/slave)

Bekapcsoltam az RPI-t, I2C busz engedélyezve az /boot/config.txt -ben, és az /etc/modules -ben is betöltődik az I2C buszhoz szükséges modul, az lsmod-nál látom, hogy megy.

Látszik az I2C busz a /dev/ -ben is, fel van rakva az i2c-tools is, le tudom kérdezni az adatbuszt, azonban ez a BME680-as szenzor alapból a 77-es ID-n működne, de átállítható a 76-os ID-re. Ezt azonban nem látom.

Egy másik szenzort, ami fény / LUX mérő szenzor, azt is hasonló módon bekötöttem, azt sem érzékeli az RPI az I2C buszon. (Csak nem rossz 2 új, bontatlan szenzor.)

Mi lehet az oka, hogy nem látom a szenzort az I2C buszon keresztül?

A másik LUX-os szenzornak van python driver-e, természetesen azt mondja, hogy nem látja a szenzort.

Merre induljak el, hogy megoldjam?

Ha már végre ez működne, onnan jönne a következő lépés, hogy az I2C-t buszba kössem, azaz a szenzorok egy adatbuszon legyenek. Ide milyen ellenállást javasoltok, és hogy kell-e?

Továbbá az I2C master/slave dolgot még nem teljesen értem, ennek az elolvasása / megértése folyamatban.

Köszönöm.

( martonmiklos v | 2019. 06. 13., cs – 16:18 )

A CSB lábat magasba kell húzni az I2C módhoz

Részlet az adatlapból (a CS láb induláskori állapota adja meg, hogy SPI vagy I2C módban legyen a szenzorod):

6.1 Interface selection
Interface selection is done automatically based on CSB (chip select) status. If CSB is connected to VDDIO, the I2C interface is
active. If CSB is pulled down, the SPI interface is activated. After CSB has been pulled down once (regardless of whether
any clock cycle occurred), the I2C interface is disabled until the next power-on-reset. This is done in order to avoid
inadvertently decoding SPI traffic to another slave as I2C data. Since the device startup is deferred until both VDD and VDDIO
are established, there is no risk of incorrect protocol detection because of the power-up sequence used. However, if I2C is to
be used and CSB is not directly connected to VDDIO but is instead connected to a programmable pin, it must be ensured that
this pin already outputs the V DDIO level during power-on-reset of the device. If this is not the case, the device will be locked
in SPI mode and not respond to I2C commands.

azonban már találkoztam a magasba vagy alacsonyra húzni a lábát kifejezéssel, de nem tudom, hogy itt ebben a szenzor esetében mit jelent. :-(

Magasra/ba húzni = logikai magas jelszinttel (kézenfekvően tápfesz) összeköztni, alacsonyra: logikai alacsony jelszinttel összekötni (GND-re)
Tehát kösd a 3.3V-ra (modulodon a VIN láb)

Ja igen ezt írni is akartam az elején: a szenzort ne kapcsolgatott GPIO-ról tápold meg hanem a VIN-t a 3.3VDC kimenetéhez kösd a PI-nek (17-es láb ha jót nézek: https://pi4j.com/1.2/images/j8header-3b-plus.png)

Kérdésedre válaszolva amíg be nem indul addig a CS-t kösd valamelyik magasba állított GPIO-ra.

Hú, itt most nem egyértelmű, ezért leírom újra, más szavakkal, ahogy értem.

Tehát alapból én a GPIO 17-es lábából adnám neki a VIN-re a 3,3VDC-t. Ez így jó? Ha lesz 3-4-5-6-10 hasonló szenzor, akkor is jó lesz így, hogy az összes erről az 1 lábról kapja? Vagy külső tápegységről 3VDC + földet kapjanak, és csak az I2C-hez szükséges 2 lábat (SCK + SDI ) kössem az RPI GPIO-ra?

Van különbség, ha a 17-es lábról kapják a 3,3VDC-t, vagy ha az 1. lábról?

Ha kb 30-60 szenzort akarok mérni (kezdésnek 15: 3 fajtából 5 helyen), akkor mennyire célszerű külön I2C portra rakni?

Ez a BME680 is alapból a 77-es ID-n fut, átrakhatóan a 76-ra, de máson nem tud futni. Tehát ha 5 darabot akarok használni, akkor meg kell oldani, hogy ne ütközzenek.

Amiket találtam:

"HOW TO CONNECT MULTIPLE I2C DEVICES WITH SAME ADDRESS TO A RASPBERRY PI AND ACCESS THEM ONE AT A TIME!"

http://www.gadgetexplained.com/2016/04/how-to-connect-multiple-i2c-devi…

és

I2C Multiplexer for the Raspberry Pi (RPI-I2C-HUB)

https://www.tindie.com/products/land_boards/i2c-multiplexer-for-the-ras…

Ezekkel akkor meg tudom oldani, hogy lehessen akár 10 is mondjuk a BME680-ból, ami alapból csak 2 ID-n tudna menni, jól értem?

Ilyenkor kell valami ellenállást rakni valahova, és ha igen, milyet, és mitől függ, hogy milyet?

Sakk-matt,
KaTT :)

Tehát alapból én a GPIO 17-es lábából adnám neki a VIN-re a 3,3VDC-t. Ez így jó? Ha lesz 3-4-5-6-10 hasonló szenzor, akkor is jó lesz így, hogy az összes erről az 1 lábról kapja? Vagy külső tápegységről 3VDC + földet kapjanak, és csak az I2C-hez szükséges 2 lábat (SCK + SDI ) kössem az RPI GPIO-ra?

Igen jó lesz. Az 1-es és 17-es láb ugyanazon funkciójú.

Van különbség, ha a 17-es lábról kapják a 3,3VDC-t, vagy ha az 1. lábról?

Nincs.

Jó lett, működik a szenzor, a VIN és CSB összekötése volt a hiányzó láncszem.

Mindjárt próbálom a másik 2 szenzort is egy I2C buszra rakni, ezek alapján, és jobban elolvasom a leírást. Köszönöm a segítséget, sokat léptem előre, hogy már 1 szenzor megy.

A Home Assistant egyből látja, bár aki a YAML mellett döntött, azt megkérdezném, hogy miért nem maradt az egyszerű INI formátum mellett vagy miért nem volt elég jó a JSON. Nem látom még, hogy miért jó, ha egy szóköz formázás nincs ott, vagy tab kerül a helyére, de szemmel nem látható, és nem jó miatta a konfiguráció, az miért jó.

Sakk-matt,
KaTT :)

( Nyosigomboc v | 2019. 06. 13., cs – 17:29 )

Az i2c egy busz, amit ugy talaltak ki, hogy hol a master, hol valamelyik slave le tudja huzni a 2 vezeteket a foldre. Felfele mindkettot felhuzoellenallas huzza, igy nem hal meg, ha ket eszkoz ellentetes iranyba szeretne huzni a buszt.

A felhuzoellenallas erteke mindenfeletol fugg (sebesseg, vonal kapacitasa), de ilyen tavolsagon nem kritikus az erteke. Ketto kell, egyik az SDA es 3.3, masik az SCL es 3.3 koze. De semmikepp ne helyettesitsd egy darab drottal, mert akkor nagy arammal probalna lehuzni ami kommunikalni akar, es az nem fog menni.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Láttam az I2C busz példa képeken ellenállásokat, konkrétan milyet rakjak, és hogy fogom látni, hogy nem jó oda az az ellenállás? Okozhatok ezzel valami kárt?

Tudna valaki konkrét terméket mondani, hogy mit vegyek az I2C? Ha jól láttam, száz darab is igen olcsó ezekből az ellenállásokból.

Tehát ha 2 szenzort akarok például az I2C buszra kötni, különböző ID-vel, akkor is már kell valami ellenállás vagy mást rá kötnöm a kábelelre?

Hogy RPI + hő szenzor + fény szenzor az I2C buszon, itt akkor mi lesz a master és slave? (érzem, hogy ez egy hülye kérdés)

Ha 20 méterre akarom kb húzni a szenzort, akkor jól sejtem, hogy kell ilyen fentebb linkelt I2C jelerősítő?

Sakk-matt,
KaTT :)

Az a master, aki start condition-t és az órajelet adja. (pi)

Az sda és scl jelekre 1-1 ellenállást kell kötni. Esetedben a 3,3V a másik végük.
Értéke:
- min. 1,1kOhm (3,3V/3mA)
- max. - az összes kapacitás függvénye (kimenetek + bemenetek + kábel)
Az utóbbi max 400pF lehet 100kHz névleges i2c órajel mellett. A kapacitás függvényében 1,2..10kOhm értéket kell használni. Itt az adótól távolabb, vagy a vezeték elején és végén (dupla értékű) kell elhelyezni az ellenállásokat.

Elméletileg az i2c busz maximális hossza 10cm nagyságrendjébe esik 100kHz-es órajelnél. Kisebb órajellel és kisebb kapacitással hosszabb busz is működik. Az i2c minimális órajele 0Hz, de ez azért nem jelent végtelen hosszú buszt!

Nagyobb távolságra differenciális meghajtást (DI2C) alkalmaznak, vagy - megfelelő áramkörrel szétválaszta az adást és vételt - pl. rs485 hardverre ültetik a jelet. "Erősítő" nincs, mert nincs mit erősíteni. ;)

"Az sda és scl jelekre 1-1 ellenállást kell kötni. "

Tehát akkor az I2C buszra jelenleg ellenállás nélkül csak 1 szenzort tudok rakni biztonságosan? Meg se próbáljak többet?

Ha van ilyenem: "Fully Assembled Kit – pHAT Stack"

https://shop.pimoroni.com/products/phat-stack

Akkor sem tudok ellenállás nélkül több szenzort beüzemelni biztonságosan?

Ilyen ellenállás akkor jó lesz, amit a kolléga itt linkelt:

2,2 K 1%
Fémréteg ellenállás 0,6W
Teljesítmény 0.6W
Ellenállás 2.2kΩ
Szerelés THT
Tolerancia ±1%

https://www.hestore.hu/prod_10020525.html

"Az i2c minimális órajele 0Hz, de ez azért nem jelent végtelen hosszú buszt!"

Az olvastam, hogy van akinek jobb, árnyékolt kábellel 20 méterig működik a szenzora, igaz, nem írták, hogy hány Hz-en. Hogy tudom mérni és kideríteni, hogy ha hosszabb kábelt használok, hány Hz-en megy az I2C busz?

"Erősítő" nincs, mert nincs mit erősíteni. ;)

Hát, én találtam, ami 50 méterig jó elvileg:

https://www.ebay.com/itm/I2C-IIC-Active-Long-Cable-Extender-P82B715-Mod…

https://shop.controleverything.com/products/long-distance-i2c-bus-exten…

Itt van leírva a működése jobban:

https://sandboxelectronics.com/?p=289

Tehát veszek 2 ilyet, rövid kábellel bekötöm az 1-1 ilyen modult, és a hosszú kábelt pedig az eszközökre, ha jól értem.
Van amibe tápot is lehet/kell dugni. Melyiket vennétek, ha több esetben 20-30 métert kell vezetni a kábelt I2C buszon?

A kábelek, amikkel tudok még gazdálkodni, és még nincsenek beépítve / felhasználva:
-6 eres riasztó kábel
- CAT6A beltéri
- CAT6A kültéri, 2 érpáronként árnyékolt
- CAT7A duplán árnyékolt (2 érpáronként + külső köpeny előtt is árnyékolás)

Gondolom minél inkább árnyékolt, annál erősebb lesz a jel és annál kevésbé romlik az I2C busz Hz értéke az azonos távolságon, de különböző kábeleken.

Egy ide kapcsolódó kérés:

1. ha 2 érpáronként van árnyékolás, és mondjuk 4 érre van szükségem a szenzorhoz, akkor úgy az észszerű, ha mondjuk a VCC (3,3V) és GND (föld) megy az egyik árnyékoláson belül, a másikban pedig az SCL/SDA? Vagy menjen mondjuk a VCC és SCL, majd a másik árnyákolásban GND és SDA?

2. Ha egy kábelben több szenzor adatait akarom vinni I2C-vel, akkor a VCC és GND-ből elég vinnem 1-1-et, vagy vigyek külön többet?

3. Továbbá ha van 8 erem a CAT7A S/FTP kábelben, akkor hogy a legjobb kihasználni az ereket? Csinálhatom-e azt, hogy csak 4 eret használok: VCC+GND és SCL+SDA, amiket jelerősítővel viszek tovább (már ha van rá szükség), és a kábel végén pedig a 3-4 szenzort, amire szükségem van, I2C buszon kötöm ott össze, tehát ezen a 4 éren fog működni az összes. Természetesen mind a 4-nek egyedi I2C ID-je lesz, és mivel a szenzoroknak ahogy nézem csak 1 egyedi, alternatív ID-t lehet beállítani, így egy I2C buszon akkor maximum 2x4 szenzort tudok rakni, ha 4 fajta szenzor lesz, mindegyik egyedi ID-vel, és mindegyik átállítható egy másik egyedi ID-re. A BME680 az alapból 77, de 76-ra is átállítható. Tehát így 1 I2C buszon 2 helyég összes szenzorát tudom átvinni, I2C multiplexer és egyéb nélkül. Itt mi a jobb: megoldani egy ilyen multiplexerrel, hogy az alap RPI I2C buszra kerüljön az összes, 30-40 szenzor, vagy pedig ami nekem jobbnak tűnik elméletben, hogy legyen több I2C buszom (I2C busz port), ahova akkor 2 helységenként fel tudom fűzni a szenzorokat.

Ha veszek ilyet:

https://www.tindie.com/products/land_boards/i2c-multiplexer-for-the-ras…

Akkor nem gond az ID ütközés sem, ha jól értem? Tehát 4 portos, akkor ha a fenti logika alapján egy I2C buszra 4+4 szenzort tudok rakni, akkor 4 portra 4*(4+4) = 32 szenzort tudok rakni, tehát ez elég is.

További I2C cucc:

https://shop.controleverything.com/products/i2c-extension-cable-joiner

Sakk-matt,
KaTT :)

Vedd figyelembe azt is, amit a gpio-ról írtak!
Ha már találkoztál Ohm apó törvényével, akkor nem bonyolult:
- Az BME 3mA terhelést visel el.
- A meghajtó trazisztort képzeld el egy kapcsolónak!
- A vezetékeknek stb. kapacitása van.
Ha nincs ellenállás, akkor ki fogja feltölteni a kapacitást? Ha nics ellenállás, akkor senki, így logikai 0 lesz a vonalakon.

A P82B715 jó választás. A specifikáció szerinti 400pF helyett 3000pF terhelést is elbír.
A kábel késleltetése 5-6ns/m + az össz kapacitás * ellenállás miatt fellépő időállandó. Az utóbbit legyőzi a meghajtó. Ehhez 400/3000 arányban csökkenteni kell az ellenállást a meghajtó után, hogy ugyanazt az időállandót érd el. No, meg 5..12V kell a hosszú kábel meghajtásához. (Vcc a CABLE oldalon)

Pl. 0m kábel esetén a maximális órajel negyed periódusán belül jók az időzítések. (Ezt most nem magyarázom. Ha tudsz már adatlapot is olvasni, akkor majd elhiszed. ;)) A 0 hosszhoz képest pl. 10m kábelen 2*6*20=240 ns többlet késleltetéssel kell számolni. (Az aljas villany késik odafelé is, de visszafelé is!) Ekkor érdemes a negyed periódus idejét minimum a többlet késleltetéssel megnövelni. Azaz csökkenteni a frekvenciát legalább 10%-kal, vagy jobban.
Folyamatában: master szól -> kábel késik -> slave észreveszi és "időben válaszol" -> kábel késik -> master észreveszi a választ.

Ugorjunk vissza két bekezdést! Az 5..12V feszültségű buszra nem fogsz rákötni 3,3V-os modulokat! Ha maradunk a 3,3V értéknél, akkor is minden slave hajtaná a 10-20m kábelt - amit nem tud.

Tehát minden szenzor (csoport-)hoz kell egy meghajtó. Ez elég drága.
Helyette jobb lenne egy i2c-rs485 átalakító. Ezzel már gondolkodni sem kellene, csak összekötni. Csillag kapcsolásba nem lehet kötni, viszont a két végén lezárt busz ideális.

A jelet csavart érpárakon kell továbbítani: sda+Vcc, scl+GND. Minél jobban árnyékolt, annál nagyobb lesz a kapacitás - így csökkenteni kell a frekvenciát. ;)

Az rs485 egyszerűbb, mert egy csavart érpár kell, a többin meg lehet a tápot vinni. Mindenesetre 10-20m távolságra szimmetrikus buszt használnék, és az i2c nem az.
(Ennyit a többi kérdésről.)
Egy i2c-rs485 illesztés kihozható 500Ft-ból...

Köszönöm a részletes válaszokat, sokat vittél előre, jó irányba. :)

"Helyette jobb lenne egy i2c-rs485 átalakító. Ezzel már gondolkodni sem kellene, csak összekötni. Csillag kapcsolásba nem lehet kötni, viszont a két végén lezárt busz ideális."

Hát legyen akkor ez! :) Hol tudok ilyet venni? Mondjuk 3 ilyen i2c-rs485 átalakítót hogy kell összekötni, mik szükségesek hozzá? A végén lezárást ellenállásokkal érted?

Itt is 2 átalakító kell majd 1 távoli szenzorhoz (vagy több szenzorhoz, ami azonos helyen van), vagy csak 1?

Ezek az I2C ID-ket nem változtatják, vagy minden ilyen átalakító külön I2C portnak számít, tehát elég, ha átalakítónként nincs I2C ID ütközés?

"A jelet csavart érpárakon kell továbbítani: sda+Vcc, scl+GND. Minél jobban árnyékolt, annál nagyobb lesz a kapacitás - így csökkenteni kell a frekvenciát. ;)"

Rendben.

"Mindenesetre 10-20m távolságra szimmetrikus buszt használnék, és az i2c nem az."
Tudnál erre példát? CAN buszra gondoltál?
Vagy mit tudnék Raspberry pi-vel használni?
Ha más adatbusz lesz, és a szenzorom I2C és SPI-t támogat, akkor azt nem fogom tudni használni, vagy valami átalakító kell?

Olyan megoldást keresek, hogy:
- raspberry pi-vel lehetőleg ki tudjam olvasni, legyen hozzá megoldás
- 10-30 méter távra tudjam vinni a szenzorokat, 8 helyre, helyenként 4 szenzort
- a raspberry pi-hez csillagpontosan kihúzott 6 eres riasztó, CAT6A, CAT7A S/FTP kábeleket felhasználva tudjam az adatokat átvinni.

Erre mit javasolsz? Nem gond, ha nem I2C / SPI alapú, mert a most megvett 1-1 szenzort akkor abban a helységben használom fel I2C buszon, ahol az RPI van, as távolabbiaknál meg mást. Ezért vettem most csak 1-1 darabot.

Itt találtam egy írást, ami hasznos lehet:

https://hackaday.com/2017/02/08/taking-the-leap-off-board-an-introducti…

Sakk-matt,
KaTT :)

Gratulálok! Elkezdtél olvasni. ;)
Ha jól megfigyeled, mindazt már leírtam, ami a link mögött rejtőzködik.

A raspberry pi lényegtelen!
Egy i2c-szerű protokollt kell elvinni messzire, ahol i2c-t beszélő, de gyenge meghajtóképességű eszközök válaszolgatnak.

Egyik lehetőség a busz meghajtóképességét fokozni ("erősíteni";)), a másik pedig a buszt más hardverre ültetni, amely nagyobb távolságot képes kisebb zavarérzékenységgel áthidalni. Az i2c azért problematikus, mert a megszokott két logikai szint helyett háromra van szükség, hogy a meghajtás irányát is meg lehessen határozni. Ehhez speciális áramkörökre kellenek.

Ami feltétlenül drága, az pl. a "P82B715 Module" az 5000Ft-os árával. Egy ilyet kis sorozatban legyártva, még az európai árakkal sem lesz feleannyi sem!
Pl.: P82B715 100Ft/db.

Az egyik megoldás: Minden szenzorhoz egy mcu és egy meghajtó. Az mcu lefordítja az i2c beszélgetést egy másik protokollra. Pl. i2c->rs485 (half duplex soros). Költsége 5-700Ft, de az mcu-t programozni kell. Ekkor akár több megegyező ID is lehet a buszon. Én így csinálnám.

A másik megoldás: az i2c-t bikább meghajtóval ellátni. Itt szóba jöhet pl. P82B96, PCA9600. Az adatlapokon megtalálod azt a számítást, amit korábban leírtam.
Mivel itt már irányonként szétválik az sda és scl, akár 4db rs485 vonalra is szét lehet dobni. (4 csavart érpár) Hasonló példa CAN meghajtókkal. Itt ugye a CAN az hardver és nem protokollt jelent!
Itt még egy leírás: AN10658.

Csillagkapcsolás esetén elegendő egy db i2c port és néhány gpio, ami az "arbitert" meghatjtja. ehhez elegendő irányonként 2db analóg kapcsoló.

Bar az ultimate megoldas valoban a differencialis busz, en a helyedben az egyszerutol haladnek a bonyolultig.

1. szint: a szenzorokat egy UTP kabellel siman rakotod a Pi I2C labaira + 3.3V + GND.

Ez hivatalosan csak 10-20 centimeterig OK, valojaban altalaban siman jo par meterig, bizonyos esetekben akar meg 30 meterig vagy tovabb is jo lehet. Erre a te esetedben is van ra esely, mert:
- a gaz szenzorod alacsonyabb tapfeszrol is megy, tehat nem baj, ha a 3v3 kicsit leesik a hosszu kabelen (mas szenzorokkal lehet ebbol gond)
- raktam mar Pi-re 30 meteres UTP-s I2C buszt, mukodott, bar vegul CAN busz fizikai retegbe csomagoltam az I2C-t, mert kellett a megbizhatosag, lasd. kovetkezo pont
- neked nem biztos, hogy kell a 100%-osan megbizhato kommunikacio. Talan nem baj, ha zavar miatt kimarad egy meres, siman csak nem foglalkozol vele. Vagy rogton ujra kerdezed a szenzort, addig, amig nem sikerul a kommunikacio.

Probald ki, lehet, hogy mukodik annyira, hogy nem kell tovabb bonyolitanod.

2. szint: I2C erosito IC-k. (Ezt a szintet lehet, hogy szkippelnem, penzben es bonyolultsagban is kb. ott van, ahol a kovetkezo.)

3. szint: zavarszures miatt az I2C-bol differencialis I2C-t csinalo IC-k. Ez parban kell, a hosszu kabel elejen a 2 erbol (SCL, SDA) 4-et (mas IC 8-at) csinal, a vegen meg egy ugyaolyan IC visszaalakitja

4. szint: ha elfogy a tap a hosszu kabelen kenytelen vagy a szenzor oldalarol is taplalni. Viszont ez esetben biztositani kell, hogy a ket taplalt oldal egymashoz kepest ellebeghessen. CAN busz fizikai reteg eseten 50 V kulonbseg belefer a ket oldal kozott, ez altalaban eleg egy epuleten belul. (Es a CAN differencialis, tehat az is adott.)

5. szint: ha szukseg van meg galvanikus levalasztasra is, akkor lehet optikailag levalasztani, vagy ethernetre ultetheted.

Nekem van 4. szintnek megfelelo kesz panelem, a kovetkezoket csinalja:

- I2C-t CAN busz fizikai retegre ulteti, 8P8C (alias RJ45) csatlakozora, UTP patch kabelhez
- I2C master oldal (pl. Raspberry) raadja a SDA, SCL jeleket, plusz GND es 3v3
- a raadott 3v3 tapfeszt opcionalisan atadja az UTP szabad erein a slave oldalnak
- vagy valaszthatoan nem a kapott 3v3-mat adja at, hanem kivulrol kapott 12 V-ot, amibol a tuloldalon csinal lokalis 3v3-mat (igy celszeru...)
- a tuloldali 3v3-mat galvanikusan levalasztottan csinalja, tehat a board akkor is hasznalhato, ha nincs a ket oldal egyezo foldpotencialon
- kapcsolhato lezaro ellenallasok (CAN busz ket vegere kell)
- ugyanolyan panel valo a master es a slave oldalra is, nem kell ket felet venni
- lehet daisy chain kotni oket, nem csak ket vegpont lehet. (De az a CAN buszos megkotes all, hogy a hosszu gerincrol csak rovid oldalagak allhatnak ki.)
- bizonyitott ipari kornyezetben, nem home-made, hanem rendes, gyarilag beultetett kartya

Viszont nem 500 forint, hanem kb. 5000.

Javaslom, hogy probald ki az elso szintet (hatha nem kell semmi), ha nem megy jol, akkor a 3. szintet, esetleg egybol a 4. szintet.

A Pi-ről van sok infó a neten, hogy mennyire romlik el, mit nem szeret és mivel lehet növelni az élettartamát, a szenzorból meg veszek majd +1 darabot, és meglátom. Azt tippelném, hogy a szenzor, ha nem kap túlfeszültséget és megfelelően van üzemeltetve, a javasolt hőfok tartományon belül, akkor sok évig menni fog.

Sakk-matt,
KaTT :)

Nem triviális kérdéseket teszel fel, hanem random kérdéseket.

próbálok olyat csinálni, amivel előtte nem foglalkoztam

Azért a csinálás előtt meg kéne ismerkedni az alkalmazott technika alapjaival.
Volt idő, amikor azért nem regisztráltam a HUP-ra, mert úgy tudtam, az egy teljesen szakmai portál.
Arra az időre szerintem már senki sem emlékszik, talán csak városi legenda volt.

Mivel most adott egy helyzet, hogy x határidőre el kell(ene) készülni ezzel, így hogy gyorsítsak a tempón, párhuzamosan képzem magam a hiányosságokkal és teszek fel kérdéseket. A kérdések válaszaival sokat tudok előre lépni a cél megvalósításában, közben pedig egyre inkább értem a megoldást, feladatot. A cél meghatározott, a kábelezés elő van készítve, a hardver eszközök egy része már rendelkezésre áll, már csak a megfelelő adatbusszal a megfelelő szenzorokat kell a hardverrel összekötni. Tudom, milliókért egy okos otthont építő cég, már kész modulokból ezt megoldaná. Azért nem ezt a könnyebbik utat választom, mert érteni akarom, hogy működnek ezek, a szoftveres oldalam erős, tehát ha a hardver kiépítés megfelelően elkészül, akkor végre magasabb szintű szoftveres megoldásokat tudok alkalmazni, amilyet megálmodtam magamnak, és nagy eséllyel mással azok a funkciók nem esnek egybe az ő álmukkal. Van aki a sportmérkőzéseket nézi sörözve, tudja fejből x csapat összes eredményét az utolsó y évben és megver valakit, aki az ellenfélnek drukkol. Én pedig olyan területeket tanulok meg a sport figyelése helyett (és aktív sportolás mellett), amelyek érdekelnek és amelyekkel érdekesebbé, kényelmesebbé, komfortosabbá tudom tenni a családom és saját életemet.

Gyermekkoromban a családi műhelyben saját forrasztópákám volt a gyakori használat miatt (és hogy ne az apuméval bohóckodjak), általában gyengeárammal, ceruza elemekkel, kapcsolókkal, motorokból építettem ezt-azt (eleinte szülői felügyelettel és segítséggel), aztán technics lego motorokkal, lámpákkal, majd jött a programozás, Windows, Linux. Be kell tömni a hiányosságaimat, mert sok a lyuk, viszont itt-ott van ilyen-olyan tapasztalat.

Igen, régen biztosan csak ellenőrzött diploma, ellenőrzött referenciák és több órás szakmai elbeszélgetés után fogadták el a regisztrációt. Ja, nem. :)

A most éppen legjobban pörgő "szakmai" témák:

"Szerepelt-e pr0n filmben a barátnőd?"
"Teljesen értelmetlen áruk fóruma"

Szakmámmal kapcsolatban pedig ha látok megoldandó kérdést, és tudom a választ, akkor segítek, hiszen nekem is jól esik, hogy ti is segítetek nekem. Én hiszek abban, ha adok, kapok, és akkor is adok, ha nem kapok, mert én helyesnek érzem, hogy adok.

Sakk-matt,
KaTT :)

Igen, én álmodni szoktam, és az álomból (célból, tervből, koncepcióból, ütemezésből, kalkulációkból, tervezésből, projekt menedzsmentből, dokumentálásból) lesz a megvalósulás.

Nyilván nem ilyen egyszerű, a hardver választás, majd kiépítés egy más terület, ahol sok kihívással találkoztam, pedig még csak most indultam igazán erre.

Biztosan el fogom készíteni ezt, hiszen ennél jóval nehezebb dolgok is sokkal reménytelenebb helyzetből is megvalósultak, maximum több szakembert / céget vonok be a megvalósításba, mint amivel terveztem.

Köszönöm a hozzászólásaidat, mert ezek is erősítenek, hogy minél jobban valósítsam ezt meg. Hiszen felhívod a figyelmemet a jogos hiányosságaimra, gyengeségeimre.

Sakk-matt,
KaTT :)

mi szükség van a kérdező kioktatására? ha csak olyan jönne ide, aki mindenről mindent tud, kimerülnének a fórumtémák egymás vállának veregetésében, nagy egyetértésben bólogatna mindenki. sok értelme lenne, tényleg.
szerintem sokan azért járnak ide, mert jó szakembernek tartják magukat egy szakterületen belül, és szívesen segítenek másoknak, akik még nem tartanak ott, de szeretnének.
sokan azért, mert bizonyos területeken jók, más területeken nem, és szívesen tágítják az ismereteiket, olvasgatva a témákat.
sokan azért, mert guglizás után is maradtak megválaszolatlan kérdéseik, esetleg nincs olyan szakmai nyelvtudásuk, hogy nem magyar oldalról pontos tudást szerezzenek.
olyanok is vannak, akik úgyérzik, összegyűjtötték az elméleti tudást innen-onnan, de szeretnék olyanok tanácsát is kikérni, akiknek konkrét gyakorlati tapasztalatuk, rutinjuk is van az adott témában.
és úgy látszik, vannak olyanok is, akik saját felsőbbrendűségük demonstrálásában, mások fikázásában, kioktatásában lelik örömüket / vezetik le személyes frusztrációiukat, azért járnak ide...

Azért, mert szükség van.
Ha meg a kérdező válaszát is elolvasod, akkor bizony abszolút szükség van.

Ha valaki hobbizik, akkor azt a végét is meg kellene ragadni, amikor képzi magát!
Aki meg a sakk(matt & katt)játszma első órája után érdeklődi meg, hogy hogyan kell lépni a lóval, annak meg beszólnak.

Munkát meg úgy elvállalni, hogy fingod sincs az alapokról, de olyannyira, hogy azt se tudod mit nem tudsz, az elég gáz.

szerintem semmi baj nincs azzal, ha valaki olyasmivel is szeretne foglalkozni, amihez még nem ért, és ehhez segítséget kér olyanoktól, akik már igen. sőt én tisztelem az elszántságát és lelkesedését. nem kötelező neki segíteni, aki irigy megosztani a keservesen megszerzett tudását, az ne ossza meg, sőt járjon akár ide nyugodtan röhögni, mennyit szop valaki azzal, amit ő már rég kitapasztalt, hogyan lehet jól megoldani, sőt veregesse közben a saját vállát, hogy ő mennyivel nagyobb király a kérdezőnél, és érezze magát bátran felsőbbrendűnek ettől.

de ez a lekezelő beszólogatás, nagyképű, minden hasznos infót nélkülöző kioktatás és leoltás kizárólag azt eredményezi, hogy elvegye a kérdező kedvét a témától, amit nem tudom mi más indokolhat, mint mezei gonoszság, szakmaféltés, túlnőtt ego, csupa olyasmi, ami nehezen értékelehető pozitívumként. őszintén érdekel, mi a cél? ha nem akarsz neki segíteni, minek szólsz hozzá?

Félre értitek! Munka = magamnak vállalt munka, azaz én magam vagyok saját magam megbízója. Én magamnak "rendeltem meg" ezt, és dolgozom rajta egyedül. Ez egy hobbi projekt, csak magamhoz képest próbálom a legjobban kivitelezni, mintha kész terméket vennék. Ezért is tök mindegy, hogy milyen adatbusz lesz, ha az a célnak jobb, nem ragaszkodom az I2C-hez, stb. Akkor úgy fogom összehozni.

Sakk-matt,
KaTT :)

A Pi-nek pontosan csak a specifikációja hiányzik. :-D
A "sok infó a neten" az pontosan lóf. az alkalmazhatóságára.

Ezzel szemben pl. egy szenzornak van adatlapja, amiben az "Absolute maximum ratings" és a "Standard operating conditions" alapján pontosan tervezhető az üzemeltetés.
Az amatőrök ilyet nem olvasnak, de nem is értenék. Ha tönkremegy egy alkatrész, akkor általában mérhető és az adatlapból kiolvasható az a jellemző, amit túllépve kifingott a szerkezet. ;)

Én próbálok minél többet olvasni és betartani a gyártói ajánlásokat, mert nem akarom magam szívatni.
Sok esetben tapasztaltam, ha úgy csinálom, ahogy a gyártó ajánlja, az úgy hosszú távon is jó, és kipróbáltam, hogy "nekem jobb ötletem van", majd tönkre ment az alkatrész... :)

Sakk-matt,
KaTT :)

A nap párharca:

@fityiszkukac: "Kell ellenállás. Bővebb információt is kapsz a busz működéséről.
Nekem volt olyan egységem ami nem volt hajlandó ellenállások nélkül működni. "

VS

@BandiG: "2) Jelen esetben nem kell felhuzo ellenallassal foglalkoznod, mert a RasPI minden GPIO laba beepitett felhuzoellenallast tartalmaz, ezek kulon-kulon ki-be kapcsolhatoak, _kiveve_ pont a 02 es 03 labon, azaz a RasPI SDA es SCL labain. Ezeken ugyanis fixen bekapcsoltak (asszem 1.8kohm), ami jo neked, nem tudod veletlenul sem elrontani a beallitast.
...
Fontos, hogy a beepitett felhuzoellenallasok es a 3.3 V-os I2C busz, 1-2 meteren, 1-2-3 eszkozzel fog stabilan mukodni."

Akkor most kell, nem kell, vagy nem gond, ha van ellenállás?

Most első körben 3 különböző szenzort szeretnék megbízhatóan az RPI közelében (hő + fény[lux] + RGB szín), rövid kábelen tesztelni. Aztán szeretném távolabb átkábelezni a szenzorokat, még több szenzorral kiegészítve ezt. Utána pedig 4 szenzor * 8 helyre átkábelezni, hosszú kábellel valahol.

Sakk-matt,
KaTT :)

> Akkor most kell, nem kell, vagy nem gond, ha van ellenállás?

Alapvetoen kell az I2C-hez, anelkul nem mukodik. Viszont a Raspberry-be meg be van epitve. Tehat az is igaz, hogy "kell", meg az is, hogy "a te esetedben nem kell".

Mivel az I2C egy lassu busz (legalabbis altalaban), viszonylag szeles tartomanyban lehet az ellenallas erteke es a rendszer kapacitasa is. Pl. ha a beepitett 1.8k melle parhuzamosan betennel meg egy 1.8k-st, akkor 900 ohm-ra esne a felhuzas ellenallasa. Ez azt jelentene, hogy ha a proci 0-ba hajtana a labat, akkor a tap felol egy 900 ohm-os ellenallason folyna be az aram a labba. Ez 3.7 mA, amit a lab biztonsagosan kepes "elnyelni" (lasd proci datasheet-je). Ha viszont sokkal kissebb ellenallast raksz be, akkor tul nagy lenne a megindulo aram, es megolned a proci labat.

A lenyeg, hogy par meteren par szenzorral a beepitett ellenallassal sem lesz gondod. De ugy latom ezt mar azota te is tapasztalod.

( BandiG v | 2019. 06. 13., cs – 21:53 )

Alapvetoen mindent jol csinalsz, ezeket latom meg:

1) Aktivald a szenzor I2C modjat ugy, hogy a szenzor paneljen huzd fel a CS labat Vin-re (osszekototted egy 3 centis drottal), lasd ennek a 35. oldalan a 6.1-es szakaszt:
https://cdn-shop.adafruit.com/product-files/3660/BME680.pdf

2) Jelen esetben nem kell felhuzo ellenallassal foglalkoznod, mert a RasPI minden GPIO laba beepitett felhuzoellenallast tartalmaz, ezek kulon-kulon ki-be kapcsolhatoak, _kiveve_ pont a 02 es 03 labon, azaz a RasPI SDA es SCL labain. Ezeken ugyanis fixen bekapcsoltak (asszem 1.8kohm), ami jo neked, nem tudod veletlenul sem elrontani a beallitast.

Fontos, hogy a beepitett felhuzoellenallasok es a 3.3 V-os I2C busz, 1-2 meteren, 1-2-3 eszkozzel fog stabilan mukodni, idaig juss el, utana a 20 meter 50 I2C slave egy masik tema lesz!

3) a RasPI eseten nem a 0., hanem az 1. I2C busz van kivezetve, ugyhogy igy nezd:

$ sudo i2cdetect -y 1

1. Köszönöm, kész, ez volt a megoldás.

2. Tehát több szenzort is rakhatok az SCL/SDA-ra, az RPI I2C buszára, ellenállás nélkül?

Hogy fogom látni, hogy nem stabil? Nem jön érték, nem lesz érzékelhető a szenzor? Rossz adatok?

3. Amikor még nem volt az 1. pont megcsinálva, bekapcsoltam mindenféle modulokat (/etc/modules) és I2C config.txt beállítást, és megjelent a nullás I2C busz is, azt nem tudom, hogy miért.

Fully Assembled Kit – pHAT Stack
https://shop.pimoroni.com/products/phat-stack

Nyerek valamit, ha a fenti pHAT-ot használom? Segít ez azon például, hogy a BME680 szenzor csak a 77 és 76-os ID-n tud működni az I2C buszon? Jól sejtem, hogy ennek a használatával a gyakorlatban van + 5 I2C portom / buszom (0-4 x 40 pin) ?

Vagy hogy több szenzort tudjak rárakni, hogy stabilabb legyen?

Sakk-matt,
KaTT :)

> 2. Tehát több szenzort is rakhatok az SCL/SDA-ra, az RPI I2C buszára, ellenállás nélkül?

Igen, nehany meterig es par szenzorig _valoszinuleg_ nem lesz gondod. Probald ki es kiderul.

> 3. [...] megjelent a nullás I2C busz is, azt nem tudom, hogy miért.

Az egy masik hardweres I2C busza a procinak, csak az nincs kivezetve a tuskesorra.

Az a pHAT Stack ha jol latom egy egyszeru parhuzamos kapcsolas, tehat nem kapsz tobb I2C buszt es nem segit azon, hogy csak ket fele ID-d van.

Erre a problemara ket megoldas van:

1.: tobb I2C busz. Bar a RPI 3 eseten egy hardweres I2C busz van kivezetve, barmely ket GPIO labbol tudsz I2C buszt csinalni, szoftveresen.

2.: I2C multiplexer IC, tobb fajta is van, pl. itt egy:
https://learn.adafruit.com/adafruit-tca9548a-1-to-8-i2c-multiplexer-bre…

3.: nyilvan epithetnel is ilyen kapcsolot csomo mindenbol, de minek bonyolitsuk.

Kipróbálom, a hőmérő, páratartalom szenzor nagyon komoly, 2 másodpercenként lekérdezve nagyon szépen reagál a változásokra.

2: Tehát a linkelt I2C multiplexerrel lesz 8 I2C buszom. Ez nagyon jó.
Azonban itt az a kérdés, hogy a 10-30 méterre lévő szenzorokat I2C buszon érdemes-e vezetni, vagy más buszon?
3 helység van 5-8 méteres távon belül, a többi 10-20, és van 2-3 ami inkább 20-30 méteres távolság, amiket mérni akarok, és ahova akarok 3-4 különböző szenzort vinni. Szerinted az I2C busz és a kábel extender hardver a megoldás erre, valamint akkor még ilyen I2C multiplexer, vagy más az előnyösebb?

Sakk-matt,
KaTT :)

( KaTT | 2019. 06. 17., h – 12:03 )

Helyzet: Az I2C busz működik, eredetileg is működött, azonban a szenzort nem jól kötöttem rá az I2C buszra, azért nem ment.

Hála a sok hasznos hozzászólásnak, már jobban látom az irányt, hogy mi a megoldás.

Főként bucko javaslatára elindultam a CAN busz irányába, azonban a jelenlegi I2C busz tapasztalatok is nagyon hasznosak voltak.
2 legközelebbi helyiség simán I2C busszal lesz megoldva, és a szenzoroknak is tudok így könnyen egyedi I2C ID-t állítani, mindenféle trükk nélkül. Azaz alapból BME680 esetén 77, és lehet még 76, ha a földet lekötöm a CS lábra.

Sakk-matt,
KaTT :)