Matekozd ki! 2 méteren egy közel 1 méter átmérőjű kör átlagát nézi. Attól függően, hogy hogyan van telepítve, ennek a körnek csak pár százalékát, de maximum egy harmadát adja ki egy emberi test. Az arc még kisebbet. Hacsak nem nagyon hideg környezet van, nem fog érzékelni. Ha meg ugye hideg a környezet, akkor az ember is fel van öltözve, vagyis a hőnyoma is kisebb/gyengébb. Nem is ajánlja a gyártó erre a célra.
Ha valahogy az SD kártyára ki tudod írni az RTC-ből származó valós időt, akkor valaminek mennie kellene.
Az Arduino IDE-ben elérhető könyvtárak nekem sok éve problémamentesen működtek, úgyhogy lehet, hogy halott az RTC, de az is lehet, hogy kábelezési/bekötési probléma van.
Ezeket első körben egy i2c scannerrel teszteld (soros monitoron kiírja a használt címeket). A címek (vigyázz, kettő van, az egyik az eepromé, a másik az rtc-é) alapján módosítani kell a kódot.
Utána jön a setup, az idő beállítása (soros monitoron), utána mehet a kiolvasás. Csak arra kell figyelni, hogy (viszonylag) jó elem legyen benne.
Ne olvashatóra konvertált valós időben gondolkodj, hanem ha egyszer beállítottad az RTC-t valós időre (kiolvasva a valós időt mutassa), akkor utána a forrás időformátumot kell csak figyelned megfelelő algoritmussal. Úgy 5-6 éve csináltam ilyet egyszer és gond nélkül ment.
DS3231 RTC-t használok egy loggerben SD kártyára írásra.
A teremtőnek nem sikerül valós időponthoz kötnöm a rögzítés időpontját.
Most (millis) alapon rögzít 5percenként, de pl óra 0, 05,10, 15 stb -kor szeretném.
A valós időt nem tudom behívni a programba, példaprogramok sem mennek. Azt viszont tudja hogy az éppen aktuális időt és a hozzá tartozó adatokat rögzíti...
Mindenképp kell hozzá egy külső programozó, ez lehet akár egy másik Arduino is, de az IDE-ben is számos megoldás adott. Amíg ez nincs, nem fog menni, USB-n, direktbe nem lehet.
Elvileg nincs kizárva, gyakorlatilag egy újabb telefon BT szabványa több gerenrációval frissebb, mint a HC-05-é. iOS-szel, vagyis bármilyen almás telefonnal már eleve ki is van zárva a dolog.
Műszaki oldalról is lehet gond, pl. az Arduino 5 V-os TTL jelszintet használ, a HC-05 kiépítéstől függően lehet, hogy 5 V-os tápfesz mellett is 3,3 V-os jelszintet kér a soros vonali adásra-vételre, vagyis jelszint-illesztésre lesz (lehet) szükség.
Plusz. Szoftver oldalon a teljes távirányításhoz szükséges kódrendszernek készen kell lennie, tehát az Arduinonak képesnek kell lennie kiküldenie azt a telefon felé, hogy "hello, én egy zenei irányító eszköz vagyok, ilyen és ilyen protokoll menténk fogom megmondani, hogy mit csinálj". Tekintve, hogy kínában ilyet valószínűleg már csináltak pár ezer forintos áron. Itt van egy 13000 forintért például: https://www.amazon.com/TUNAI-Button-Media-Remote-Control/dp/B07JQ8Q6X6
"Egyébként úgy 25 éve talán a BME-n egy projekt keretében kísérleteztek azzal, hogy nagyon precíz mágneses iránymérőkkel irányítsanak robotokat"
Kihelyezett mágnesekkel vagy a föld mágnesem mezöjével?
Volt olyan ötletem, de nem sikerült megvalósítanom. Kicsi neodym mágneseket akartam tenni az akadályokhoz és a fordulási pontokhoz, akár több 100 darabot, mindenfele a kertben. Érzékenységen bukott el a dolog, ha jól emlékszem kb csak 5cm volt a max érzékelési távolságom. Ha van olyan chip vagy hall érzékelő ami "messziről" is érzékelné a kis neodym mágneseket, akkor lehet tavaszra megcsinálnám vele a teljes robotizálást. Illetve gyanítom a benzines fűnyírómotor mágneses gyújtása is bekavarna.
Nagyon meg akartam csinálni a full automata fűnyírást úgyhogy van még rp-lidarom is. Működik is szépen arduino alatt. Beltérben. Viszont kültérben sem a napsütés, sem pedig fűnyíró álltal felkavart por, fű stb. , nem a barátja.
Sok zsákutcán túlvagyok már. Vizuális feldolgozás lenne a tuti megoldás de ahhoz meg én vagyok kevés. Pedig egy okostelefonnal biztosan meg lehetne oldani.
Még csak belepillantottam a dokumentumba, de meglepődve olvasom hogy a kitöltési tényező és a sávszélesség is számít, ez kimaradt eddig az életemből. Rendben, kapisgálom, beállításaimon múlik hogy legális vagy sem. Köszönöm a tájékoztatót.
Az stm32-t lehet félreérthetően fogalmaztam. Szóval. Vettem a jófogáson még évekkel ezelőtt, vadonatúj de hibás hoverboardokat, akkumulátor nélkül adták nagyon olcsón. Ilyen vezélőpanel van(volt) bennük, motoronként 1-1db master/slave kapcsolatban:
Az eredeti gyári chipet programoztam át, ami pont megegyezik az arduino Blue Pill boardokéval STM32F103C8T6.
Ezzel az ST-link V2 programozóval mentek át az adatok:
3-4éve volt, valami STM32Cube-hez hasonló (már nem találom) segédprogram kellett a lezárt chip resethez, meg a feltöltéshez. Később már közvetlen az ardinoIDE-ből is tudtam rátölteni a programot ugyanezzel a képen levő ST-link V2 programozóval.
Hosszú kihagyás után mostanában kezdtem újra aliexpress-es bluepill-t programozgatni. Sehogy nem megy a kommunikáció csakis ezzel a képen szereplő programozóval, pedig van 4félém. Se usb se uart, csak st-link és csak ezzel. Azt olvastam a hamis chipek miatt. Viszont ezzel közvetlenül az arduino IDE-ből is megy.
Alapvetően azok a frekvenciák, amelyeket lehet (és kell) ilyen célra használni, nagyon határozottan kötöttek. A 10 mW ERP is borzasztó kevés, az 1 mW pedig gyakorlatilag légyfing. Az aktív Wifi routerek régióban engedélyezett maximális effektív kisugárzott teljesítménye 100 mW (2,5 GHz-es sáv), és irányított antenna nélkül azért már eléggé gáz, hogy a háztól 15-20 méterre már nincs értelmes Wifi vétel (ennek mondjuk a telefonokba épített antenna is az oka).
Olyan, hogy "környéke" és olyan, hogy 10-20 dB-ig, nem létezik. Adekvát értékek vannak konkrét frekvenciákkal és konkrét kisugárzott teljesítményekkel (amelyből következik a dB[m], de nem egyértelműen). A 20 dBm és a 10 dBm között tízszeres teljesítménykülönbség van, 10 dBm kb. 10 mW, 20 dBm kb. 100 mW leadott teljesítményt jelent. Ebből a 10 dBm lehet akár még legális is, a 20 dBm abszolút nem az, és hobbialkalmazásoknál nem is lesz. A dolgot még árnyalja, hogy a mérési sajátosságok miatt egy szűk iránykarakterisztikájú antennára jóval kisebb kimenő teljesítmény ereszthető rá, mint egy optimális körsugárzóra (ezért jobb a vevő oldalra irányított antennát tenni).
> Amúgy kifejezetten szeretnék egy domborzatkövető frekvenciát, de úgy tudom az legálisan nem megoldható. kb 20méter völgy-domb-völgy szintkülönbség és 2,5km távolság lenne a feladat, átjátszó és torony nélkül ha lehetséges.
Ez csak átjátszóval vagy cellával oldható meg. Ezzel egyébként a 27 megás rádióirányító sávban elvileg lehetne próbálkozni (konkrétan ki kell menni és meg kell mérni a legrosszabb helyeken a jelszinteket), de erre sincs garancia. Az összes többi (magasabb frekvencia) erre alkalmatlan, mindegyikhez jó rálátás kell.
Egyébként úgy 25 éve talán a BME-n egy projekt keretében kísérleteztek azzal, hogy nagyon precíz mágneses iránymérőkkel irányítsanak robotokat. Ha nem is tökéletes megoldás, de ezzel is el lehetne indulni, ha fix az a terep, ahol a fűnyírónak dolgoznia kell. Aztán jönnek az extra cuccok, a lidar vagy uram bocsá a vizuális feldolgozás, de ez már nem feltétlenül Arduino-szint (bár Arduino alapon csináltak térhálógeneráló LIDAR-t, ami meglepően precízen működött ahhoz képest, hogy milyen műszaki tartalommal bírt).
> Aliexpress-ről tucatnyi mindenféle olcsó rádiómodulokat rendeltem, próbálok egy következőt, cc1101-et. (nem csak a fűnyíró miatt)
Megnéztem az adatlapját. Nincs érdemi eltérés a 24L01-hez képest. Ugyanazok a frekvenciák, ugyanazok az átviteli módok.
Amatőr körökben megy az oltás folyamatosan, hogy "melyik a jobb rádió". Bár lehet mérni, és a mérések eredményeként lehet egy objektív listát felállítani, a gyakorlat ugyanakkor az, hogy számottevően nagyobb jelentősége van a földrajzi helyzetnek (völgy vagy domb), az antennának (dipól vagy valami jó beam), a környezeti zajnak (szomszéd karácsonyi led világítása), ad abszurdum, az operátor fülének, mint annak, hogy a listán épp a 21. vagy az 57. helyezett rádióval forgalmaz valaki. Már csak a poén kedvéért is megnéztem, a 21. az Icom IC-7610, az 57. pedig a Yaesu FT-950... :-D Szóval, itt próbálkozhatsz n+1 lehetséges megoldással, ha a frekvencia és az átvitel minden fontos paramétere azonos, akkor az eredmény is nagyjából azonos lesz. A rádiós átviteltechnika sajnos ilyen, a fizikát nagyon nehéz megerőszakolni.
Melyik STM vezérlőt használod a BLDC meghajtó motorokhoz? Proto kivitel vagy egyedi nyák vagy a kettő között valami modul kínából?
"nem vagy tisztában a hatályos szabályozással (ITU, frekvenciagazdálkodási jogszabályok)"
Ez most elbizonytalanított, úgy tudom (azaz gondolom) hogy 10-20dB-ig 2,4Ghz és 433Mhz környéke is teljesen szabadon használható.
Amúgy kifejezetten szeretnék egy domborzatkövető frekvenciát, de úgy tudom az legálisan nem megoldható. kb 20méter völgy-domb-völgy szintkülönbség és 2,5km távolság lenne a feladat, átjátszó és torony nélkül ha lehetséges.
A 24L01-re jópár féle antennát próbáltam, volt hogy a bokortól letört antenna működött a legjobban. Áthelyezve is volt már többször. Tudom rossz helyen van a videón, bokrok alatt, ágak alatt nyírás miatt van fizikailag védett helyen.
Úgy néz ki, LoRa az asztalomnál távolabbra nem fog jutni. Ez a LoRa.setSyncWord nálam úgy működik, ha átírom egyformára, minden rendben. Ha direkt eltér a két rádiómban a szinkronszó, akkor is kb. minden 3. 5. 10. csomag véletlenszerűen átjön. Néha sérülve, sokszor sértetlenük, de rendszeresen átjönnek az adatok. Kipróbáltam vagy 30 szinkronszó variációt. Ha egyformák mindig minden rendben. Ha direkt eltér, akkor véletlenszerűen jönnek át csomagok. Másik gond hogy nem csak a saját adásaim jönnek, van hogy párpercenként, van hogy csak félóránként, de jönnek idegen adatok is. Például minden egész órakor, szinte mindig. (lehet a malackák :) )
Aliexpress-ről tucatnyi mindenféle olcsó rádiómodulokat rendeltem, próbálok egy következőt, cc1101-et. (nem csak a fűnyíró miatt)
Még 3éve próbálkoztam Arducopter szettel is, (de akkor nem a rádió miatt), most is itt van a fiokomban. A robotizált fűnyírást próbáltam megoldani vele, GPS alapon, de a pontatlansága miatt esélytelen volt. Házilagos RTK-szerű GPS-t is próbáltam, saját bázispontokkal, de az olcsó kínai GPS így is pontatlan volt az akadályokkal teli kerthez. Időnként fejlesztgetem a fűnyírót. Van egy kezdetleges lánctalpas kivitele is. Arra jutottam hogy terepen a robotizáláshoz elengedhetetlen a lánctalp. Jelenleg 1 töltéssel, kb 1000m2-t lehet lenyírni. Generátoros, korlátlan üzemidejű verzión is dolgozom. Ezek a hoverboard kerekek szuperek, a hoverboard gyári STM32 vezérlőjét használom, arduino alatt írtam rá, részben összeollózott, új programot. Aszfalton 40Km/h fele van a fűnyíró végsebessége, persze olyankor életveszélyes. Nem látszik rajta, de 1ember nem nagyon tudja felemelni, olyan nehéz. Aszfalton is lehet vele rallizni csak akkor a gumik percek alatt elfogynak.
Talán mindenki okulására egy kis műszaki gyorstalpaló, de tényleg csak a felszínt nagyon-nagyon kapargatva.
A rádiós adatátvitel (az átvitel jellegétől függetlenül) Marconi óta létezik. Itt a kvázi fizikai réteg az éter, vagyis az az ismert tulajdonságú elektromágneses sugárzás (hullám), amely a rádióadó rezgőköréről leszakad és elindul a fény sebességével (elvben) minden irányba. Magának az átviteli módnak (modulációnak) rengeteg fajtája van a "van jel/nincs jel" megoldáson (CW, continuous wave, közismert, bár szakmailag hibás nevén a "morze", hivatalosan A1A) az FM (frekvenciamodulált) műsorszóró átvitelen át a pl. az NRF24L01 által is használt GFSK modulációig (bár ez utóbbi ismét csak nem teljesen szabatos szakmailag). Ez gyakorlatilag azt determinálja, hogy a rádióhullám mely tulajdonságában vagy tulajdonságaiban és milyen szisztéma mentén van elhelyezve a továbbítandó adat. Ez önmagában még mindig nem jelenti azt, hogy ha halljuk (vagy valamilyen eszközzel hallgatjuk), akkor abból kiderül, hogy mi is a továbbított adat. Távíró üzemnél pl. elég egyszerű, ha van pitty, akkor van jel, ha nincs pitty, akkor nincs jel: ha ismered a morze ábécét, akkor a jelek és nem jelek üteméből vissza tudod olvasni (vagy a skimmer vissza tudja neked fejteni) magát az elsődleges adatot. Ez a folyamat egyébként az ún. demoduláció (az ellentettje meg a moduláció).
És még ez sem biztos, hogy érthető lesz, kell ugyanis egy egységesített protokoll, amely azt határozza meg, hogy az adat maga milyen "nyelven" (vagyis milyen szintaxissal, milyen kódolással, stb. stb.) került küldésre és hogyan kell visszafejteni ahhoz, hogy megkapjuk azt az információt, amire szükségünk van. No, ez pl. a morze ábécé. A kódolása meg lásd pl. Enigma. Hallod, vissza tudod fejteni, de még úgy sem tudod, hogy mi a frászkarikát jelent, hogy egyébként tudsz németül. (Versus az amerikaiak "enigmája".)
Ebből az egész folyamatból te a programírás során csak annyit látsz, hogy mi az adat, amit el kell küldened, és ha ezt az adatot megkapod, akkor azt a rovered hogyan dolgozza fel. Minden mást elkészítettek már, ezek a könyvtárak, amiket használsz.
A fentiek közül minden résznek (rétegnek), illetve ezek tulajdonságainak van ráhatása arra, hogy a rendszer mennyire megbízható, mennyire biztonságos, és milyen peremfeltételek mellett képes az elvártak szerint működni. Vannak p2p, közvetett, és cellás megoldások (te a fűnyíróhoz az elsőt használod, a T meg az utolsóval demózta az 5G-t, amikor elkezdték pár éve). A céljaidra megfelelő technológiából viszont nincs túl sok.
Hatótávot alapvetően a frekvencia csökkentésével, a kisugárzott energia növelésével (pontosabban a vevőbe érkező jel/zaj viszony javításával), a zavar csökkentésével, a sebesség csökkentésével, és bizonyos esetekben a rálátás tisztázásával (plusz a visszaverődések csökkentésével) lehet nyerni. Bár ez sem feltétlen igaz, mert pl. 80 méteres hullámhosszon pont a visszaverődéssel lehet játszani. Messze a legfontosabb ezek közül a vevőoldali jel/zaj viszony. Ez csak részben függ az adóoldali kisugárzott teljesítménytől (a közhiedelemmel ellentétben), sokkal fontosabb, hogy a vevő oldalán (és környékén) mi a helyzet. A kulcsszavaknak nem meglepő módon semmi köze a programozáshoz. Ezek: antenna, antennanyereség, vevő szelektivitás, vevő érzékenység, antennaillesztés, antenna sugárzási karakterisztika. Nyilván ez az adó oldalán is számít.
Én két dologgal kezdenék (minden mást félretéve): egyrészt távolabbra (kb. egy méterre) vinném az antennát a motortól, mégpedig felfelé (nagyon jó minőségű kábellel), másrészt kipróbálnék a vevő (és esetleg az adó) oldalán nagyobb nyereségű antennákat. A vevő oldali 'jobb' antennával óvatosan kell bánni, mert a vevőbe jutó jelet ugyan erősíti, de minden jelet (a zavart is), így a jel/zaj viszony nem fog javulni, ez viszont fontos lenne. Ha ezek nem jönnek be, akkor lehetne tesztelni valamennyire irányított antennákkal. Ennek egyik előnye, hogy azonos adóteljesítmény szűkebb tartományba sugározva magasabb jelszintet ad, másrészt csökkenti a nem kívánt (háttér) környezei terhelést is [nem purcannak ki a malackák]. Ezt műszakilag valamivel nehezebb megvalósítani. Végül ugyanez esetleg a vevő oldalán is, de ott a forgatást valahogy meg kell oldani és az nem annyira magától értetődő, szóval ezt az utolsó utáni esetnek hagynám. Errel az NRF24L01 IC-re épülő arduinos projekttel csináltak 30 km-es átvitelt. [A BME-n egyébként rendszeres feladat, hogy a Schönzerz tetejéről ki tud a legmesszebbre és milyen messzire wifi jelet eljuttatni.]
A film kafa, mivel hülyéskedésnek írtad, így csak az a rész, ami a szabályozás-vezérlésre vonatkozik lett 'figyelembe véve'. Impresszív, tényleg.
Nézzük mélységében. A gyári megoldások között van több is, amelyik "nyitott" olyan lehetőségekre, amelyekre te is áhítozol. Open Source modellirányító rendszer mindenféle platformra van a legkülönfélébb adatátviteli megoldásokkal. A gyári itt azt jelenti, hogy annyira van kész, hogy ne neked kelljen szívnod azzal, hogy a legkritikusabb részt (az adatátvitelt) megcsináld. 5-6 évvel ezelőtt egy projekthez kerestem ilyeneket és bőven találtam megoldást. És mivel írod, hogy arduinoban csak nagyon kezdőként ügyködsz, így nyilván nem biztos, hogy értelmes idő- és energiabefektetés valamit nulláról megcsinálni.
Az, hogy nem gondolod, hogy nagy zavart keltenél az eszközeiddel csak egy feltételezés a részedről. Ha nem tudod, hogy pontosan hol, milyen teljesítménnyel, milyen leadott teljesítménnyel, és mit adsz, akkor alapos okkal feltételezheted, hogy zavarsz valakit. Pláne, ha nem figyeled az adott frekvenciát és egyébként nem vagy tisztában a hatályos szabályozással (ITU, frekvenciagazdálkodási jogszabályok). Ez addig nem (nag) baj, ameddig nagyon lokálisan csinálod, pl. az NRF24L01-gyel. De a Lora már más liga, onnan ki tud jönni annyi kraft, ami lefektethet egy kevéssé jól implementált ipari rendszert. Te meg az újságban csak azt olvasod, hogy a 10 km-re lévő sertéstelepen elpusztult az összes sertés, mert az IoT alapú fűtésrendszer valamiért meghülyült. [A példa teoretikus, de a nullánál nagyobb esélye van.] Írod, hogy egyébként nem nyugtázol. Akkor a bldc nyomatékot hol látod? Mert ha a kontroller kijelzőjén, akkor bizony van nyugta. Sőt. Én a helyedben továbbra sem zárnám ki az analóg rendszereket, bár az tény, hogy számottevően nagyobb feladat rá megírni és megtervezni mindent. Ha ezt nem akarod, akkor el kell kezdeni nulláról gondolkodni és felírni, hogy pontosan mi a cél (a biztos), és milyen mozgástérrel mehet a dolog. Négyzethálós füzet, ceruza, radír, aztán lehet írni. Példa: legyen a vezérlőtől a lehetséges hatótáv 1500 méter, függetlenül a vizuális láthatóságtól (vagyis ha az eszköz és az irányító között mondjuk van egy ház vagy egy domb, akkor is működjön). Aztán az átadandó adatok mennyisége és minősége tételesen felsorolva, ide-oda). Ezekből, ha tényleg minden megvan, ki fog jönni egy paraméter-csomag, amelyből viszonylag rövid iterációval kiderül, hogy milyen hardveres és szoftveres műszaki megoldással lehet életet lehelni bele. Aztán meg kell nézni, hogy van-e ilyen készen vagy félkészen valahol. Mondk egy példát erre is: az 5G-t konkrétan erre találták ki. Kurva drága és jelentős benne a függés, de működik.
A SyncWord, amit találtál kb. a handshake. Igen, bizonyos megközelítésben ezt keresed, mert ez párosítja az "adót" és a "vevőt" (valójában két adóvevőd van -- minimum). De egyáltalán nem biztos, hogy erre van szükséged. Anélkül, hogy a dokumentációt elolvastam volna, ez nagy valószínűséggel azt jelenti, hogy a két oldalon lévő eszközök (szerver / kliens legyen mondjuk) közül a szerver tudja, hogy kihez szól, a kliens pedig tudja, hogy mikor szólnak hozzá. Viszont. Az, hogy azonos nyelven (pl. ASCII), azonos módon (FM), azonos helyen (frekvencia) próbálnak kiabálni egymáshoz a szerver és a kliens, még egyáltalán nem biztos, hogy hallani fogják egymást. Kis túlzással ez egyfajta bábel tornya, de hogy az előbbi sertéstelepes analógiát átfordítsam, hiába állsz te és a haverod 3 méterre egymástól egy K&D koncerten és próbáljátok egymást a nevén szólítani, pokolira nem fogjátok egymást hallani, mert a környezeti zaj (ami egyébként szintén kommunikáció, bár itt inkább csak közlés) rohadtul elnyomja. A "nem zavarok másokat" az ilyen körben úgy kezdődik, hogy az egyik szobában a szerver, a másik szobában a kliens, és a lehető legkisebb teljesítménnyel és a leglassabb tempóban próbálnak egymáshoz suttogni. Mert ami 5 méterre nem hallatszik a legkisebb teljesítménnyel, az a legnagyobbal sem fog. Csak utóbbival esélyes, hogy kinyírod a malackákat. Írok még.
Esetemben gyári megoldás szóba sem jöhet, ahogy az analóg rendszer sem. Egyedi funkciók sorozatát használom az irányításon kívül pld.: a bldc agymotorok nyomatéka, tól-ig sebességtartomány, passzív fék, aktív fék, fékezés ereje, domboldalon-lejtőn poziciótartás, giroszkopos iránytartás, félautomata fűnyírás....mind mind a ps2 távirányítóról szabályozható egy oled kijelzővel megtámogatva. Csak nagyon amatőr szinten és csak arduinoval programozok de a gyári megoldások lehetőségeit már messze túlléptem. Nem gondolom hogy nagy zavart keltenék az eszközeimmel. Másodpercenként csak 10szer, rövid kb 10byte adatot küldök át egyszerre. Nincs folyamatos kapcsolat. Még a nyugtázást sem használom hogy ne legyen miatta + késés, mindig az aktuális joystick adatokkal működjön. Ha kimarad a jel 2szer, akkor lefékez és megáll. Lehet hogy a LoRa túlzás ide, de van más projektem is ahova meg szükséges. Nem célom mások zavarása, és lehetőleg az én eszközömet se zavarja más, pont azért jöttem ide hogy a szelektáláshoz segítséget kérjek.
Akkor itt most álljunk meg egy pillanatra! Bármilyen ilyen eszköz távirányításához rohadtul más technológia kell, ami egyrészt nem annyira DIY/házibarkács kategória (mondjuk meg lehet csinálni), másrészt jellegéből fakadóan nem épp olcsó. A Lora a legkevésbé erre való. Vannak pompás kész szettek hozzá nem is borzalmasan drágán (nyilván kínából), amelyek működnek. Két-három szervó, egy generál távirányító, egy generál vevő (e kettő nyilván párban), pár akku, és onnantól csak a meghajtást kell a fűnyírón megoldani.
Az 1100 méter abszolút ideális körülmények között, mindenféle zavartól mentesen (ha benzinmotoros a fűnyíró, ott olyan brutális lokális rádiózaj van, hogy az is csoda, ha 50 méteren még működött). Az NRF24L01 és folyamodványai az "alsó" normál WiFi frekvencián működnek, nagyjából hasonló átviteli paraméterekkel (moduláció, hibajavítás, stb., csak valamivel lassabban). Ahhoz, hogy ez a rendszer elhasaljon, elég a környéken egy erőszakosabb WiFi.
A csatorna és a cím közül a csatorna konkrét frekvencia, a cím pedig már a szoftveres (adat) réteg egy paramétere, amit a vevő figyel. Lora-n is megvalósítható, csak ugye meg kell írni. Illetve LoraWAN-nál nem, de ott részben még nagyobb a látencia, részben még kevésbé erre való.
Én azt tanácsolnám, illetve tisztelettel kérem, hogy az éter ilyen mértékű szakszerűtlen használatát lehetőleg hagyd abba, mert lehet, hogy neked nem megy, de ami miatt neked nem megy, amiatt mondjuk hardveresen gyengébben támogatott kutatási projektek eredményei fognak sérülni, mert 30 km-es körzetben mindent kinyírsz a távirányítós fűnyíród tesztelésével.
A Lora elsődlegtes céjla a viszonylag nagy hatótávolságú (sok kilométeres), nagyon kis sávszélességű (vagyis rendkívül lassú) adatátvitel megvalósítása. Például az, hogy egy napelempark negyed óránként elciripelje, hogy éppen mennyit termelt, kinyitották-e a kaput, volt-e riasztás valamelyik inverteren, és van-e a felügyeleti akkuban elég szufla. Én két felé mennék. Az elsőt megírtam fent, modern (digitális) rádióirányító szetteket kell keresni (ha a Futaba-tól elindulsz, akkor kb. az epicentrumból indulsz, de milliárdnyi találat lesz elvileg). A másik a még hőskorból származó analóg jelátvitelt használó (modell) irányító rendszerek, nekem most a 27 MHz ugrik be [ellenőriztem, 27, 35 és 40 MHz és környéke]. Ezek atombiztosak, gyakorlatilag már csak elvétve használják őket, hatótávjuk megfelelő körülmények között akár több száz méter és lényegében nincs látenciájuk. Cserébe gyakorlatilag semmi nincs hozzájuk Arduino környezetre (annál szebb feladat megírni). Üdv!
Eddig NRF24L01+ -t használtam pld. fűnyíró távirányításához ps2 gamepadba építve. De kevés a hatótáv, van néha hogy már 50méternél megszakad a jel, elméletben 1100méter lenne. Van némi balesetveszély is ezért jó lenne a stabil megbízható kapcsolat. Gondoltam kipróbálom a LoRa 433Mhz-et.
A 24L01-nél tudtam tetszőleges címet adni és kb 100 csatornából választani:
const byte address[6] = "00076"; // Address
radio.setChannel(99); // csatorna 2400-2525 mhz 0-125
Egy ilyen szintű párosítás szelektálás nekem már megfelelő.
LoRa-nál viszont nem találokoztam ilyen lehetőségekkel.
Közben keresgélek keresgélek, de csak ilyet találtam:
LoRa.setTxPower(20); //20 max power LoRa.setSpreadingFactor(12); //12 for max range LoRa.setSignalBandwidth(62.5E3); //Supported values are 7.8E3, 10.4E3, 15.6E3, 20.8E3, 31.25E3, 41.7E3, 62.5E3, 125E3=default, and 250E3.
A rövid válasz az, hogy sehonnan. A picit bővebb az, hogy a LoRa csak a hardveres leíró réteget definiálja. Ez magyarra fordítva annyit tesz, hogy a LoRa megadja a frekvenciát (pontosabban több frekvenciát) és az átivteli módot (mondjuk modulációt). Minden más, vagyis a szoftveres réteg (protokoll) már ezen felül van. Technikailag (a szabvány adta műszaki kereteken belül) te magad határozhatod meg az egyes adatcsomagok tartalmát, kódolását, a handshake protokollját, stb. stb. stb. Ez a valószínűleg végtelenül leegyszerűsített implementáció amatőr felhasználásra "mindenki mindent hall" elv mentén valósult meg. Ahhoz, hogy ennél komolyabb lehetőségeid legyenek, választanod kell egyet az elérhető többféle már létező megoldás közül és/vagy fejlesztened kell egyet magadnak. Ezek között vannak ipari felhasználásra szánt, meglehetősen drága megoldások is.
Szóval alapvetően azt kell eldönteni, hogy mit akarsz csinálni. Ha point-to-point összeköttetést, akkor csinálni kell valami handshake-et az adó és a vevő (valójában a két adóvevő) között, hogy tudják, melyik kicsoda, milyen adatot vár, stb. Ha ez megvan, akkor küldheted az adatot. Nyilván ezt mindenki más is látja majd, aki azon a frekvencián vesz, de ez a rádió feltalálása óta így van.
while (!Serial); Serial.println("LoRa Sender"); if (!LoRa.begin(433E6)) { // or 915E6, the MHz speed of yout module Serial.println("Starting LoRa failed!"); while (1); } }
void loop() { int val = map(analogRead(pot),0,1024,0,255); LoRa.beginPacket(); LoRa.print(val); LoRa.endPacket(); delay(50);
}
#include <SPI.h> #include <LoRa.h> int LED = 3; String inString = ""; // string to hold input int val = 0;
