Fórum témák

» Több friss téma
Fórum » Rádiós adó-vevő modulok
Lapozás: OK   43 / 52
(#) pucuka válasza Logeen hozzászólására (») Nov 19, 2016 /
 
A közösítéssel az a probléma, hogy az antennát egy időben csak az egyik modulra kötheted. Ha csak egyszerűen összekötöd, az illesztést tönkre teszed, ezzel működés képtelen is lesz a rendszered. Tehát vagy kapcsolgatod, vagy illesztő áramkört gyártasz.
3 db 50 ohmos eszközt hogy tudsz összekapcsolni, hogy minden irányból illesztve legyen?
Természetesen lehet, illesztő tápvonalakkal, amit méretezni, és méréssel ellenőrizni kell, és járulékos csillapítással is számolhatsz.
Lehet még kapcsoló diódákkal is, ezzel is illesztési problémák jelentkeznek, mivel a kapcsoló eszköz átviteli ellenállásai összemérhetők a hullámimpedanciával.
(#) Kovabe válasza Gj hozzászólására (») Nov 28, 2016 /
 
Szia
Milyen rádiós modult használsz?
Én a kínai 433-as egyszerű olcsót de nekem csak a zavar jön bármit is csinálok.
(#) bernula válasza Kovabe hozzászólására (») Nov 29, 2016 /
 
Szia!

Én meg tudtam hajtani őket, ad is az adó vesz is a vevő, de a hatótáv max 1 méternél nem több. Állítólag 20métertől 200méterig működik, tápfeszültség és antenna függvényében.
(#) Kovabe válasza bernula hozzászólására (») Nov 29, 2016 /
 
Köszi
Közben eljutottam addig hogy már 2400-as bauddal megy a kommunikáció de amikor nem adok akkor valami be zavar és nem tudom hogy mi.
(#) Bakman válasza Kovabe hozzászólására (») Nov 29, 2016 /
 
Ez ilyen, nem tudsz mit tenni, mint lecserélni az RF modult egy jobbra. Bővebben: Link 2:25-től érdekesebb a videó.
(#) pucuka válasza Kovabe hozzászólására (») Nov 29, 2016 /
 
Ha a vevő nem vesz semmit, nincs vivő, akkor a zajt veszi, és abból produkál kimeneti jelet.
Ezért kell az adatfolyam előtt egy inicializáló, és szinkronizáló jelet küldeni, hogy a vevő tudja valamiból, hogy az elkövetkező adatfolyam lesz érvényes. Addíg, és a kommunikációt lezáró jelsorozat után nem kell az adatokat figyelembe venni.
Ez, a kommunikációt bonyolító MCU -nak feladata. Ha drábább modulokat használsz,aminek van saját mikrovezérlője, annál nem kell ilyennel is foglalkoznod.
A hozzászólás módosítva: Nov 29, 2016
(#) Gj válasza Kovabe hozzászólására (») Nov 30, 2016 /
 
Hali!

Én TME-ről rendeltem, de az első típus nem működött megbízhatóan.
A másodikat szintén onnan, de ezekkel már nem volt ilyen gond.

Utóbbiak:
Bővebben: Link
Bővebben: Link
(#) Gj hozzászólása Dec 3, 2016 /
 
Üdv!
Valaki meg bírja találni ebben az adatlapban, hogy a LoRa mód bitsebességét hogyan lehet beállítani? (melyik regiszterrel)
(#) Kera_Will válasza Gj hozzászólására (») Dec 3, 2016 /
 
Talán azt kellenne eldönteni milyen módban és gyakorisággal, messziről szeretnél kommunikálni?
Azután kellenne a sebességet és a bitrátát ledönteni.
Távolság növekedésével csökken a bitráta, fix sebesség vagy változó sebességet kell beállítani?
(#) Gj válasza Kera_Will hozzászólására (») Dec 4, 2016 /
 
Még nincsenek nálam a modulok, ezért nem tudok konkrétumot mondani.
A gyakoriság nagyon változó abból adódóan, hogy néhánytíz db modul lenne, amik hol eseményt küldenek egy mesternek, hol a mester szólítja meg őket. Ha egyszerre küldenek eseményt, akkor meg elveszik egy halom adat mindkét fél részéről.

Szóval nem azt kérdeztem, hogy mekkora legyen, hanem, hogy hogyan állítom be ezt. Sima one-wire szerű moduloknál nyilván egyértelmű, hogy olyan gyors lesz, ahogy én kapcsolgatom az adatlábát, de itt SPI-n adom neki a küldendő adatot.

Vagy ha nem lehet ezt közvetlenül beállítani, akkor mi alapján dönti el a modul a bitrátát?
A hozzászólás módosítva: Dec 4, 2016
(#) pucuka válasza Gj hozzászólására (») Dec 4, 2016 /
 
Először is, ha hálózatot építesz, akkor nem a bitrátával kéne foglalkoznod. Egy hálózatban nem fordulhat elő, hogy egyszerre két adás történik. Ebből a szempontból már két adóvevő modulból álló kapcsolat is hálózat. Egy frekvencián csak szimplex kapcsolat lehet, egyszerre csak egy adó működhet. Ezt szigorúan biztosítani kell.
Egy ilyen hálózatban csak egy master lehet, aki körbe kérdezgeti időnként az állomásokat, és azok válaszolnak neki.
Ha alkalomszerűen, eseményfüggően indulnak a hálózatban az adók, óhatatlan, hogy össze ne akadjanak, aminek adatvesztés a vége. Ez még két adóvevő modul esetén is fennállhat.
Épp, hogy csak belenéztem az adatlapba, igen intelligens egy szerkezet, ennek megfelelően bonyolult is. A programozó ki- bemenetein a táblázatokban foglalt (nem is egy) értékekből kell a programozó stringet összeállítani megfelelő sorrendben. Ehhez azonban alaposan át kéne tanulmányozni azt a bőséges adatlapot, ami sajnos rád vár.
A hozzászólás módosítva: Dec 4, 2016
(#) Gj válasza pucuka hozzászólására (») Dec 4, 2016 /
 
"Programozó ki és bemenetei" alatt az SPI interface-t érted?

Programozó string? Ahogy én néztem, egyesével is lehet címezni a regisztereket. Amiből jó a default érték, azt minek írjam fölül?

És igen, megnéztem a táblázatokat. (bevallom, csak a "Register Table Summary"-t (6.1) és a "LoRa TM Mode Register Map"-et (6.4)) Csak nem látok bitsebességre vonatkozó regisztert.
Maga az RF új még nekem kicsit, ezért kérdeztem, amit kérdeztem. Még mindig nem tudom, hogy hogyan tudom ezt beállítani, de mindegy, ha kapásból ti sem látjátok, akkor végigolvasom mind a 132 oldalt.

Az RF sehogy sem lenne elég gyors ahhoz, hogy események helyett mindenkitől lekérdezzem az aktuális állapotot, mivel sok eszköz lenne, és lehet, hogy amikor az 1.-n történik valami, de a master pont a 2.-at szólítja meg. Ha végig kell mennie mind az x eszközön (20-50db kb.), mire elér az 1.-höz, nagy lesz a csúszás, és a többi eszközön feltehetőleg semmi nem történt. Az esemény mindenképp kell, fontos a gyors reagálás.
Persze, tudom, hogy ennél biztosabb módja nincs az adatvesztés és egyszerre beszélés előidézésének, de erre van a CRC, nyugtázás, random divergens időközönkénti újraküldés, stb... (Egyszer már ez ki is lett tárgyalva, talán pont ebben a topicban.)
A hozzászólás módosítva: Dec 4, 2016
(#) pucuka válasza Gj hozzászólására (») Dec 4, 2016 /
 
Vannak külön programozó ki bemenetek, ha jól láttam, és értelmezem. DIO0 -DIO5 -ig. Szerintem ott kell betolni a vezérlő adatokat. Elég sok táblázatot láttam, bevallom nem néztem végig mindet, de ha ezekkel szeretnél dolgozni, akkor kénytelen leszel megtanulni. Azért elsőre nem a szórt spektrumú dolgokkal kéne foglalkoznod, mert az még bonyolítja a programozást, bár a végeredmény kétségtelen jobb.
Rádiós összeköttetéseknél mindíg alkalmazni kell vonali kódolást, meg CRC -t, de ez nem az egymásra beszélés elleni védelem, hanem egyáltalán alap. Nem ártana átnézni a ZIGBEE technikát, az direkt nagyszámú állomás lekérdezési technikájára lett fejlesztve.
Fontos a gyors reagálás, de gyakorlatilag us nagyságrendű késleltetésről van szó, persze az elérhető adatsebesség, sávszélesség függvényében. Ha ez nagy probléma, akkor nem 433, vagy 868 MHz -es modulokat kellene választanod, a 2,4 MHz -es sávban jóval nagyobb a használható sávszélesség, ezzel együtt az adatsebesség is. Szórt spektrumú adásmóddal, MIMO technikával GB -os sebességek is elérhetők, persze ezek nem annyira egyszerű technikák.
(#) Gj válasza pucuka hozzászólására (») Dec 4, 2016 /
 
Nézd meg te is, de szerintem SPI-n konfigurálható. (Képen az első mondat.)

Igazából kb 10-15B adat menne egyszer-egyszer, és erre 6B nyugta (ebben bennevan 2B preamble, valamint a címzett és feladó ID-je is). Emiatt gondoltam, hogy feleslegesen alkalmaznék wifi sebességű kommunikációt. A baj az, hogy addig oké, amíg 10B-ról van szó, az már 1Kbit-tel is kevesebb, mint egy tizedmásodperc alatt átér, de ha ezt 50 eszköznél 50*10=500-ra emeljük, arra már kevés a LoRa.
Sajnos a távolság az elég nagy, házon belül falakon át kéne min 20m, és lehetőleg nyilván minél olcsóbban.

A teknikákat majd megnézem, amiket írtál. A 2.4MHz nem inkább 2.4GHz akart lenni, mint pl a régebbi szabványos Wi-Fi?
A hozzászólás módosítva: Dec 4, 2016
(#) Kera_Will válasza Gj hozzászólására (») Dec 4, 2016 /
 
Specifikáció szerint 1 LoRaWAN "GateWay Állomás" 5000 eszközt is kitud szolgálni mindenféle frekin és mindenféle sebeséggel.
A LoRa eszközök 3 féle főosztályba vannak sorolva.
Mielőtt bármibe is belekezdenél előszőr tanulmányozd a LoRa hálózatok felépítését , egyes elemeinek a működését, logikáját, hálózat szervezési logikáját.
Sokkal előbbre fogsz jutni ... és nem egyből a fizikai rétegbe bele csapni.
(#) pucuka válasza Gj hozzászólására (») Dec 4, 2016 /
 
Elnézést, valóba 2,4 GHz -ről van szó, 2,4 MHz -en még kisebb lenne a rendelkezésre álló sávszélesség, ha lenne is.
Szóval körül kell nézni, tanulni, számolni. Én csak osztom az észt, nem valószínű, hogy ezekre a dolgokra már szükségem lesz, akkor meg minek ássam túl mélyre magam. De azért nem árt tudni ezekről a dolgokról úgy általában, de használni már nemigen fogom. Meghagyom a fiataloknak.
(#) Kera_Will válasza Gj hozzászólására (») Dec 4, 2016 /
 
Akiktől érdemes kérdezni :

előadás
(#) Bell válasza Gj hozzászólására (») Dec 5, 2016 /
 
A NodeMCU-t nézted már?
Ahol a wfi használható, ott az is jól működik. Nincs bonyolult konfig, titkosított, helyi hálózaton, vagy akár távolról a neten is használható, ráadásul nem drága.
(#) Gj válasza Kera_Will hozzászólására (») Dec 5, 2016 /
 
Köszi szépen mindenkinek!
Most elkezdtem normálisan utánaolvasgatni több helyen, ill megnéztem az előadást.

Azt már látom, hogy nem úszom meg az oldalszámokat, úgyhogy csak azzal kapcsolatban tennék fel néhány kérdést, hogy mire számítsak a végén, mit tudnak ajánlani ezek a modulok (sajnos szűkös az idő és nem akarok vakvágányra menni):


-A küldendő adatot mennyire kell előkészíteni, mielőtt odaadom neki SPI-n? Kell-e rá preamble, vonali-kódolás, stb... vagy ezt a modul elvégzi az adatokon, amiket SPI-n küldök neki/kapok tőle?

-Ha jól értem, nekem csak a Spreading Factor értékét kell beállítanom, és ha be van kapcsolva az adaptív moduláció, akkor a modul maga keresi meg a legoptimálisabb bitrátát?

-Hogyan fogom tudni, ha új üzenet érkezett? Írták az adatlapon, hogy csak a Slave SPI van implementálva a modulon, szóval tuti nem fogok megszakítást kapni a modultól. Folyton kérdezgetnem kell SPI-n a modult, hogy van-e valami a bufferében?
A hozzászólás módosítva: Dec 5, 2016
(#) Kera_Will válasza Gj hozzászólására (») Dec 6, 2016 /
 
néhány hasznos olvasmány tapasztalatok :
aprs lora
http://www.chipcad.hu/letoltes/MMGPSMOTE.zip" target="_blank" rel="nofollow" >alkalmazas minta forraskoddal
lora-qso
HAM célra
Chipcad & LoRa
(#) pucuka válasza Gj hozzászólására (») Dec 6, 2016 /
 
Idézet:
„A küldendő adatot mennyire kell előkészíteni, mielőtt odaadom neki SPI-n? Kell-e rá preamble, vonali-kódolás, stb... vagy ezt a modul elvégzi az adatokon, amiket SPI-n küldök neki/kapok tőle?”

Nagyon, kell kell, stb. Preamble, cím, adat crc, mindez vonali (Manchester) kódolva mehet az SPI -re.
(#) Gj hozzászólása Dec 6, 2016 /
 
Még amíg emésztem a LoRa-t, feltennék még egy kérdést, biztonsági szempontból.

Ennek a LoRa modulokból felépített hálózatnak egyes elemei elvileg csak a hálózaton belüli üzenetek hatására végezhetnének bármilyen feladatot. Ennek a meghatározására van nyilván a hálózatnak ID-je, a címzettnek ID-je, és a feladónak ID-je.
Tehát aki ezek közül valamelyiket nem ismeri, az elvileg nem tud utasítást küldeni az egyes eszközöknek a hub nevében.
Viszont egy mezei LoRa modullal el tudja fogni a levegőben szálló üzeneteket a hub és az eszköz között.

AES:
Teszem azt, van egy A eszközöm, ami ki és be tud kapcsolni. A bekapcsoláshoz a hub mindig a 0x1234ABCD üzenetet küldi el. (ebben benne van a preamble, címzés, crc, minden) Ha ezt titkosítom AES-sel, akkor a titkosított üzenet is mindig ugyan úgy fog kinézni, lesz mondjuk 0x12345678. Ha valaki el fogja ezt a titkosított üzenetet, akkor nem szükséges tudnia az eredetit, hisz ha ezt a titkosítottat elküldi, úgy, ahogy van, akkor az eszköz ugyan azt fogja megkapni, mintha a hub küldte volna titkosítva az eredeti 0x1234ABCD üzenetet. (visszafejti, és megkapja belőle, hogy kapcsoljon be)
Tehát az AES-sel titkosított üzenetbe még valamit bele kell titkosítani, ami változik, és csak a hub és az eszköz által ismert.

RSA:
Van másik lehetőségként az RSA, amihez viszont egyeztetni kell a nyilvános kulcsokat, ami az RF miatt szintén preamble, címzett, feladó, crc... vagyis nagyon sok plusz kommunikáció, ami ezeken a sebességeken nem lenne túl jó. RSA nélkül elmegy az üzenet, hogy "kapcsolj be" és visszajön egy nyugta. RSA-val viszont elmegy egy megszólítás a hubtól az eszköznek, amiben kéri a public kulcsot, az eszköz ezt visszaküldi, ez után a hub ezzel a kulcscsal titkosítva elküldi az üzenetet, amire az eszköz nyugtát küld a hub-nak, hogy megkapta. Ez így kétszer annyi kommunikáció (mivel a hasznos adat se lenne sokkal hosszabb egy RSA kulcsnál).

AES időszink I.:
Emiatt inkább az AES-t választanám, de ahhoz kell valami közösen ismert dolog, amit csak a hub és az eszköz ismer. Ez lehetne mondjuk az idő. A hub egy general call-lal időnként az összes eszközzel szinkronizálná a közös időt (ami lehetne persze egy számláló is, nem csak az idő, a lényeg az, hogy mindig azonos legyen) és ezt a közös időt beletitkosítaná a bekapcsolást kiváltó üzenetbe, amit a vevő miután az AES kulccsal (ami nem változik, az IC felprogramozásakor bele lenne írva a kódba) visszafejt, csak akkor hajtana végre, ha a visszafejtés után kapott idő megegyezne a saját idejével.

AES időszink II.:
Ez utóbbinak a következő változata (hogy a general call-lal járó szinkronizálást, illetve azt kiküszöböljük, hogy egy eszköz úgy kapcsolódik be a hálózatba, hogy "lekéste" a legutolsó general call-os szinkronizálást, és így sosem egyezne meg a visszafejtett és a saját ideje, egészen a következő szinkronizálásig) azt csinálná, hogy fogná a küldendő adatot és az időt, titkosítaná AES-sel, ahogy az előző változat, majd ehhez a titkosított adatsor végéhez hozzácsapná az időt titkosítatlanul. Amikor az eszköz megkapja, összehasonlítja, hogy a végéhez rakott titkosítatlan idő megegyezik-e a visszafejtés után a titkosított részből kapott idővel. Ha igen, az feltételezi, hogy a feladó ismerte az AES kulcsot, vagyis a hálózat tagja.

Az RSA-s megoldás nyilván tuti, viszont kétszer annyi kommunikáció szükséges hozzá.
A két AES-es megoldásnál fontos, hogy az AES-kulcs ne szivároghasson ki se a hubból, se az eszközökből. Az AES kulcsot RF-en nem küldöm el, így a kiszivárgást úgy értem, hogy ha valaki fizikai hozzáférést nyer valamelyik végponthoz, és kiolvassa a programot az IC-ből.

És a kérdésem: Melyiket használnátok inkább a fenti három megoldás közül, és miért? Vagy inkább egy itt le nem írt megoldást ajánlanátok?

Tudom, jó hosszú lett, köszönöm, hogy elolvastad és segítesz!
A hozzászólás módosítva: Dec 6, 2016
(#) Gj válasza Gj hozzászólására (») Dec 6, 2016 /
 
módosítani akartam, de már késő volt

A program kiolvasása ellen lehet persze védekezni lock bitekkel.
Van olyan lehetőség, hogy csak a kiolvasást tiltom le, de a programozást nem? (egyszerűbb lenne a fejlesztés során)
(#) Kera_Will válasza Gj hozzászólására (») Dec 7, 2016 / 1
 
Előzőekben már mutattam egy 1 2 linket ... amin megtalálod azokat akiket keresned és kérdezned kellenne a témában . LoRaWANon 128 bites titkosítást alkalmaznak.
(#) Bell hozzászólása Dec 17, 2016 /
 
Sziasztok!
Van két ilyen RFM69CW-s modulom és szeretnék vele kísérletezni, PIC-el, vagy egyszerű Arduino-s kínai klónnal felprogramozni, működtetni.
Az RFM69 adatlapjáról nem derül ki számomra az, hogyan lehet programozni, használni.
A Github és hasonló oldalain található libary-k mezei Arduino paneleken nem futnak, csak MOTEINO-n.
Keresek egy egyszerű mintaprogramot, vagy bármilyen infót, ami segít elindulni az RFM69 használatában.
Köszönet!
(#) Bakman válasza Bell hozzászólására (») Dec 17, 2016 /
 
Itt egy kicsit bővebb adatlapot találsz.
(#) Bell válasza Bakman hozzászólására (») Dec 17, 2016 /
 
Köszönöm, ezt nézegetem már.
(#) phr3ak hozzászólása Jan 20, 2017 /
 
Sziasztok,

Melyik ask adómodult ajánlanátok aminek állítható a frekije?
(#) phr3ak hozzászólása Jan 21, 2017 /
 
433.92 ASK/OOK
(#) phr3ak hozzászólása Jan 23, 2017 /
 
CC1101-re és SI4432 -re épülő modulokat nézegettem, de nem találok magyar helyet ahonnan pár nap alatt tudnák szállítani.
Következő: »»   43 / 52
Bejelentkezés

Belépés

Hirdetés
Lapoda.hu     XDT.hu     HEStore.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem