1 byte -> 2 km

Elektronika, Elektromos eszközök

Szeretnék átküldeni kb. 4-8 bitnyi információt nagyságrendileg 1-2 km távolságra, valamilyen rádiófrekvenciás átvitellel. A két pont között nincs tereptárgy, közvetlen rálátás van, földfelszínen. A bitek forrása és vevője egyaránt 1-1 stm32 mikrokontroller lenne, és csak egy irányban kell küldeni a biteket, szinte bármilyen lassan, akár csak 1200 baud-dal. Emberélet/dolog nincs veszélyben, de fontos szempont, hogy megbízható legyen az átvitel.

Milyen RF megoldást javasoltok erre?(Én addig jutottam, hogy az ISM 868MHz sávban lehetne ilyen kapcsolatot csinálni, talán RFM69 adóvevőkkel, de nem tudom, hogy ez valóban működhet-e ekkora hatótávval, ill. milyen antennák kellenének.)

( chx | 2019. 09. 04., sze – 15:19 )

subs.
____________________
echo crash > /dev/kmem

( answ | 2019. 09. 04., sze – 15:46 )

"és csak egy irányban kell küldeni a biteket"
...
"fontos szempont, hogy megbízható legyen az átvitel."

Ebből kétirányú kommunikáció lesz az ACK miatt.

És igen LoRa átviszi, de még egy nRF24L01 is külső antennával (van rálátás).

Pont pár napja próbáltam regisztrálni, de nem érkezett sem automatikus, sem human által írt jóváhagyás, vagy elutasítás azóta. Valakinek sikerült már? Mi a menete, próbáljam újra? A lap alján van telefonszám is, azt próbáltam hívni (igaz, csak egyszer), de nem vették fel.

Az RFM69-bol ha jol latom csak 433MHz-es meg 915MHz-es van es nincs benne LoRa modem.
915 itthon nem hasznalhato, a 433 viszont jol terjed csak lassu es mivel nincs benne modem nehezkesebb a kezelese.

RFM95 megy 868MHz-en is ami itthon szabad (de a felhasznalas modja szabalyozva van) es van benne modem ami egy csomo terhet levesz a valladrol.

Nem értem az összefüggést, nem kell szolgáltató általi lefedettség a LoRaWan-hoz, tehát attól még magad is építhetsz LoRaWan hálózatot, hogy az Antenna Hungária is szolgáltat, pont ez a jó benne. Sőt, építhetsz szigetüzemben is magadnak LoRaWan hálózatot, nem kötelező regisztrálni a TTN-be.

--
https://iotguru.live

bizonyos modulokban (kb majdnem mindben) a limit beépített és egy "no free channel" üzenettel elhajt a picsába ;)
Persze kivétel mindig van és ha nagyon pofátlan módon tolod, meglátogatnak a mérőkocsival (ismerek rá példát). Mérőkocsiba egyébként bármelyik szabad sávon bele lehet futni ha az emberrel elszalad a ló

// Happy debugging, suckers
#define true (rand() > 10)

> Kb. másodpercenként max. 10x.

Az maris 10byte/sec!

Pontosan 10szeresere ugrott a kovetelmeny....

Mostantol legalabb 10x tervezd tul a hardvert, hogy tobb meglepetes ne erjen.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( Nyosigomboc v | 2019. 09. 04., sze – 21:43 )

Anno ezt neztem ki magamnak hasonlo celra, de nem probaltam meg ki: https://www.aliexpress.com/item/32783191387.html

Elonye, hogy a sima filleres NRF24L01-essel kompatibilis, tulajdonkeppen az van benne, csak erositett a jel. Ja, es leteznek hozza Arduinos library-k, amivel peer-to-peer szeruen egymasnak lehet tovabbadni az adatot, attol fuggoen, hogy epp melyik masik modult tudja venni. Szoval ha van ket "telephelyed", akkor a long range valtozatok kornyeket tele lehet rakni ilyenekkel.

--
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

Az elozo valaszom elnagyolt volt.
100mW-tal lehet sugarozni, ha frekvencia ugrasos vagy szort spektrumu protokolt hasznalsz plusz egyeb technikakat, amikkel megprobalod elkerulni hogy mas eszkozoket zavarj. (pl listen before talk https://people.kth.se/~sungkw/files/song_sung_han_comml_2015.pdf ) A wifi szabvanyokra ez mind jellemzo de a feljebb linkelt modul semmi ilyesmit nem tud.

https://eur-lex.europa.eu/legal-content/HU/TXT/PDF/?uri=CELEX:32013D075…
30. oldal teteje

( Oregon | 2019. 09. 05., cs – 07:27 )

"megbízható legyen az átvitel"

Két irány (RX/TX) nélkül ezt, hogyan? (Tényleg nem tudom, nem kötekedés.)

Ezen már más is fönnakadt, szóval a félreértést tisztázandó: nem szükséges, hogy az adó számára bizonyított legyen a csomag garantált megérkezte a vevőhöz, tehát kb. mint az UDP esetében. Emiatt nem kell a visszafelé irány. A 'megbízhatóság' pedig simán értelmezhető szimplex kapcsolaton is, packet loss rate vagy valami hasonló metrikával. Tehát 'reliable messaging'-ileg nem elvárt a megbízható üzenetküldés, csak annyi az elvárás, hogy a kiküldött byte-ok előre definiáltan kevés hányada vesszen el.

:wq

"kiküldött byte-ok előre definiáltan kevés hányada vesszen el"

És ezt mégis hogyan garantálod egyirányú kommunikációval? :)

Mérések nélkül fogalmad sincs az állandóan változó rádiós közegről. Ezt nem lehet számítani, hogy milyen FEC-et alkalmaz vagy/és mennyivel adj többször.

Itt ACK kell és annak hiányában újraadás. Ráadásul valamilyen random tag is kell bele nehogy szinkronba kerülj valami más adóval. Még CSMA-t sem alkalmazhatsz, mert nem ismered fel az ütközést.

Persze ha a rádiós közegnek meghatározol egy általad felállított követelményrendszert illetve ha elég a vevő oldalon jelezni a hibát, akkor már más a helyzet.

Például ha lenne egy öntözőrendszerem, aminek van egy RTC-je, amit naponta legalább 1x szinkronizálni szeretném NTP-hez, akkor az adón egy órát felosztanák 12 nem egyenlő részre, aminek a seedjét termikus zajból generálnám és akkor adnék. Így napi 24*12 adás (tehát átlag 5 perc) közül 1 nagy valószínűséggel eljutna a vevőhöz. De ha nem jutna el akkor sem lenne nagy baj, mert mondjuk a vevő jelezné 1 hét után, hogy nem kapott jelet és így nagyobb lehet az óra pontatlansága.

Köszi, igen, valahogy így értettem, csak rosszul fogalmaztam.
Elég a vevő oldalon jelezni a hibát, és failsafe lesz a design. Nincs nagy gond, ha kiesés van, csak olyankor egy másik csatornán keresztül kell kapcsolatba lépni, ami 2-4 km sétálást jelent. :)
"Üzem" előtt lehetne végezni egy próbát, a rádiós közeget pedig az üzem idejére változatlannak feltételezni. Ha nem változatlan -> séta.

:wq

> kb. mint az UDP esetében. Emiatt nem kell a visszafelé irány.

Az udp nem azt jelenti, hohy egyiranyu a kommunikacio.

Mindket fel adhat udp csomagot es maris ketiranyu a kommunikacio.

Az egyiranyu kommunikacioval olyan fontos dolgokat vesztel el, ami a hibakeresest nagyban megkonnyiti.

Pl. mit csinaljon az ado, ha a kozpont nem veszi az adast?
Valtson at backup kommunikaciora?
(pl. ket fuggetlen radio)

Inditsa magat ujra?
Te mit tennel amikor probalnad elharitani a hibat? Egy csomot programozottan meg tudna tenni.

Vagy a legegyszerubb esetben pl. elmenti a gyujtott adatot helyileg, mivel a kozpont nem vette az adast.
Vagy a mintavetelezest 10edjere csokkenti, mivel a sajat tarhelye veges.

Rengeteg dologtol elesel, azzal hogy csak beszelsz a nagyvilagba es nem gyozodsz meg hogy a masik fel fogta.

Kb. mint a forumozas. Az is altalaban ack nelkuli...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"Az udp nem azt jelenti, hohy egyiranyu a kommunikacio."
Ez igaz, én sem állítottam az ellenkezőjét.

"Az egyiranyu kommunikacioval olyan fontos dolgokat vesztel el, ami a hibakeresest nagyban megkonnyiti."
Tkp. egy másik kommunikációs csatornán keresztül fog menni a visszacsatolás, így végül is meg lesz az adónál az az információ, hogy vette-e az adást a vevő. Itt most tényleg csak az 'odairány' RF-es része érdekel.

:wq

nahh... itt jól félregondoltam... :D

elküldeni 5x... és amelyikből a legtöbb van, az a jó érték. Ha meg hibás, akkor vagy elbaszódott a cucc, vagy zavart a sáv... tehát: olyankor vagy más freki, vagy más cucc.
Ha sokszor rossz az adat, úgysem lehet sokmindent kezdeni vele, az már nem megbízható frekvencia.
Hacsak az adó egységben van még egy vevő is, ami az adás frekvenciáján vesz, és adni csak akkor ad, ha a sáv üres. Ez sem 100%-os, mert a vétel helyén lehet így is zavart a sáv.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Én mág mindig nem látom ebből a levezetésből, hogy ha csak egyirányú a kommunikáció, akkor honnan a bánatból tudja az A (adó), hogy a V (vevő) szerint szar van a palacsintában.

De ezen kívül ilyen trivialitásokat sem látok, hogy a "protokoll" szerint A elküldi az 1 adatát 5x, amiből 1 adat elveszik (vagy éppen másként sérül, mint többi), a maradék 4 2/2 arányban tartalmaz I-t vagy J-t. Most akkor melyik a helyes adat, amit V-nek használnia kell?

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Lásd https://hup.hu/node/165645#comment-2383894: 'A' egy másik, vissza irányú kommunikációs csatornán "rálát" 'V'-re, tehát 'A' nyugodtan küldheti ész (és ACK) nélkül a csomagjait, mert minden résztvevő számára egyértelmű lesz, ha valami nem OK. Kb. úgy képzeld el, mintha a távirányító megnyomására nem nyílna ki a garázskapu. Naívan úgy gondolom, hogy egy ilyen rendszerben sincs feltétlenül visszafelé ACK RF-en. Lehetne persze, és talán van is ilyen megvalósítás, én nem tudom. Ez esetben pl. újraküldhetné 'A' az adatot automatikusan.

:wq

Erre van egy vicc is:
Az őrmester kérdezi az újoncot:
- Mit csinál, ha eltávozásról jövet lekési a vonatot?
- Felívom az ügyeletes tisztet, vagy ...
- Rossz válasz! Nyugodtan leül, és megvárja a következő vonatot.
- ???
- A jó katona mindig az előző vonathoz megy ki!

Tehát egy űrrakétánál biztosan szükséges a kétirányú kommunikáció, kettős handshaking, ecc, crc, checksum, meg amit még ki tudsz találni. De nem is biztos, mert a biztonságot más módszerekkel is lehet garantálni.
Lehet, hogy itt nem egy űrrakétáról van szó.
Az általad feltett kérdésre az első válasz:
Ha ilyen előfordulhat, akkor rossz az adatok védelme. És ezt meg kell oldani, ha szükséges.
Mi az, hogy egyformán sérül? 8 bites processzoron, assemblerben van olyan kódom, ami ezt, meg még sokmindent kizár. Nem én találtam fel. Úgy hívják aes256...

Ha pl. egy hőmérő adatgyűjtéséről lenne szó, akkor legfeljebb kimarad egy-egy mérési ciklus. Az meg teljesen elfogadható, mert a hőmérséklet elég lassan változik. Azaz a ciklusidőt a változásnál gyorsabbra kell állítani, és akkor meg kit érdekel?

Nyilvánvalóan, ha általában csak néha jön adat, akkor máshol kell keresni a hibát.

Szerintem a Kossuth Rádió atomcsapás című közleményére is ki kellene dolgozni egy algoritmust! Nem elég, hogy egyirányú, de úgy is csak egyszer adják le. XD

Ha zavart szenved az adás, tökmindegy, hogy redundancia, checksum, vagy hibajavító, úgy is csak azt lehet megállapítani, hogy hibásan jött az adat. (sérülhet a checksum meg a hibajavító is)
Az ACK sem 100%, mert ha zavart a sáv, az ACK kérés is hibásan menne vissza.
Ha meg csak a vevő közeli helyen van valami zavar, akkor megérkezik az ACK a másik oldalra, de ismét hibás fogadás lenne. Mindez addig ismétlődne, míg meg nem szűnik a zavar.
Na jó, ez már szélsőségesen szerencsétlen eset...

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

( sigellef | 2019. 09. 05., cs – 23:13 )

Gondolom, elvárás, hogy a cucc fogyasztása kicsi legyen, tehát először is kell 2 darab nagy nyereségű antenna. Egyet a cuccnak, egyet meg amivel veszed a jelet.
Ha nagy frekvencián (200+ MHz)csinálod, kell hogy legyen optikai rálátás, ha kisebb frekin, akkor elég, ha nincs betonfal a 2 pont között.
... én építenék egy oszcillátort, amit a soros port kimenete kapcsolgat, utána egy hangolt erősítőfokozat, a végére meg 15-20mW-os erősítőt. Vevőnek meg minimum 2 hangoltkörös egyenesvevőt, csinálnék, demodulátor-dióda helyett meg gretz hidat, és amit ott kapok, azzal meg egy kapcsolóüzemű fokozatot vezérelnék, aminek a kimenete mehetne a soros bemenetre.
Antennának meg biquad, nálam wifi-routereknél bevált. 500m-re még simán kommunikált a wifi-routeremmel a mobiltelefon. Ha az adó is, vevő is ilyen antennával dolgozna, 100mW-tal simán meglenne az 5km is.
Gyártottam egy kalkulátort is, ha más frekin használod, kiszámolhatod a méreteit:
http://fellegis.hu/elektro/antenna/biquad.html

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

( VincentV | 2019. 09. 05., cs – 23:36 )

A 868-as RFM69 bőven jó erre, én 30-120km közötti tartományban veszek mozgó stm32+rfm69 -ekből érkező adatokat, ráadásul ennél jóval nagyobb csomagokat (20 byte, 5 másodpercenként küldve). Adó oldalon még csak nem is 868-ra hangolt antenna van, hanem aliexpressen beszerzett sma csatis GSM botantennák. A vevő oldal komolyabb (méretesebb collinear antenna + SDR). Az a "cheat" persze itt is megvan, hogy szinte mindig van közvetlen rálátás, de az nálad is adott.

Szóval röviden: igen, az RFM69 a barátod, szerintem kár LoRa-val vagy egyébbel bonyolítani/drágítani, 2km-re közvetlen rálátással kb. egy darab lambda 1/4-es drót elég lesz mindkét RFM-be 25mW-on. Ezzel véletlenül konkrét tapasztalatom is van, mert a fent említett eszközök relayeznek is, és simán megesik, hogy 10-30km távolságban levő társuk jelét veszik (a közvetlen rálátás itt is adott mindig), és volt idő amikor csak egy darab dróttal tesztelgettem őket antenna gyanánt :)

Az egy speciális eset, helyi erő üzemelteti, tudtommal nem nagyon van rá ideje. Utolsó infóm róla, hogy frissíteni kellene rajta az ogn klienst, és az OS-t is. Terítéken van egy ideje, hogy átvegyem, de az illetékes őcsényi ismerősnek kellene leszerveznie, ő meg egyelőre nem lépett. Az ogn.hu -ra meg csak felrakni szoktam a vevőket, leszedni nem (ebben nincs ott semmi automatizmus, simán hardcode-olva vannak egy js-be :) ). Mondjuk megszűnni még egyik se szűnt meg, max átmenetileg nem megy.