1 byte -> 2 km

 ( csearo | 2019. szeptember 4., szerda - 15:13 )

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

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

subs.
____________________
echo crash > /dev/kmem

subs.

sub

"é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).

Szerintem ide nem feltétlen kell ACK, feltéve, hogy elég sokáig ad az adó fél.

LoRa?

sub

Ez tök jó! Én mégis inkább P2P oldanám meg, annál is inkább, mert a térképen lefedetlennek jelölt területen is kéne.

:wq

LoRA mehet
- eszköz - eszköz (kis távolságon)
- eszköz - saját gw ...
- eszköz - gw szolgáltatás (pl. AH gw) ...

Tehát nem muszáj AH-ra felcsatlakozni.

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.

Na, közben megpróbáltam újra, és ma reggelre megérkezett a visszaigazolás, be is tudtam már lépni.

Rendszerhasználati díjakat nem találok sehol...

https://www.youtube.com/watch?v=9qcghiz246E

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

Köszi! Ez a videó alig hagyott megválaszolatlan kérdést, és ez alapján nekem eddig egyértelműen az RFM69HW + 8-ad hullámhosszos antenna a nyerő.

:wq

https://www.aliexpress.com/wholesale?catId=400103&initiative_id=AS_20190904063814&SearchText=rf+transmitter&switch_new_app=y

most igy fejbol nem tudom hogy melyik (433 vagy a 915) a "szabad". (egyik jo nalunk is, mert a epitett dron telemetry azt hasznalja)

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Az a baj ezekkel, hogy nincs bennuk modem igy _mindent_ neked kell leprogramozni, ami csak elso hallasra tunik jo mokanak. A feljebb linkelt modult csak fel kell konfiguralni, aztan mar mehet is a cucc a bufferbe. Az, hogy at is erjen a masik oldalra az adat mar a modul dolga.

Ha jól sejtem, ennek az RFM95-nek jobb lenne a hatótávja, mint az RFM69-nek.

:wq

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.

Van rfm69 868MHz-en is. Bár az én céljaimnak valószínűleg elég lenne a 433 MHZ is.

:wq

A LoRaWan pont erre van kitalálva: https://lora-alliance.org/about-lorawan

Ilyesmi hardware kell hozzá: https://www.ebay.com/itm/123740330808

--
https://iotguru.live

A LoRaWAN gateway-es arhitektúrára volt kitalálva, nem?

Igen, ez valóban ígéretes lenne, de lásd:
https://hup.hu/node/165645#comment-2383702

:wq

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

Aha. Szóval akkor az én esetemben pl. a 'gateway' lenne a 'vevő', és nem lenne semmiféle backhaul semmiféle felhő felé?

:wq

nem, megy az p2p is lora esetében.
A főbb kérdés az, hogy milyen időközönként szeretnéd ezt az adatot átküldeni, mert lorawan esetében megkötés van a frekvencia használatra időben


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

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

:wq

Ha jol ertem, ez alapjan inkabb 10 masodpercenkent fogsz tudni kuldeni max egyszer: Duty Cycle


Sic Transit Gloria Mundi

akkor a lora kiesett


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

Ha tudja egy csomagban küldeni és ritkábban, akkor még beleférhet. Túl is lehet lépni, ha amúgy alig használják, csak nem szabad... :)

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

Hogyne, de használhatsz kettő-három modult is. Amíg komolyan nem teszel valakinek keresztbe a szabad sávban, addig nem fognak kijönni mérni...

--
https://iotguru.live

Igen igen.

A mérőkocsival arra próbáltam utalni, hogy pl nagy erejű és állandó 433 -as modulokkal jó esély van rá hogy bele lehet futni velük az utcán utánad kutakodva ;)


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

OK, hát akkor ki.

:wq

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

ez pl pont nem jó mert ez 433 -as band, lora esetében a 868 van engedélyezve


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

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

Kar, hogy illegalis. 2.4GHz-en max 10mW-tal lehet adni EUs szabalyozas szerint. A 20dBm az 100mW.

Lehet, hogy én emlékszek rosszul, de a 2.4 Ghz-es wifi eszközök 100mW-on adhatnak maximum.

Igen, de ez nem WiFi.
nRF24L01 GFSK-t használ, channel spacing 1 MHz-es és ETSI-nél 10 mW/MHz, ha jól tudom a határ GFSK-nál.

ez igy van, raadaskent wifi-nel ERP a 100mW hatar, nem az adora vonatkozik


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

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:32013D0752&from=EN
30. oldal teteje

"megbízható legyen az átvitel"

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

hit

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

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.

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

Ne tegyünk úgy, mintha nem lenne broadcast adás a világon...

--
https://iotguru.live

Ne tegyünk úgy, hogy azt megbízhatónak nevezzük.

Eléggé megbízható, ezért rettentő sok helyen használják, ahol teljesen felesleges a kétirányú kommunikáció.

--
https://iotguru.live

Pont azért mert nem kell megbízhatónak lennie pl video stream .

Emlékeim szerint ez a különbség a tcp és az udp között. Emiatt gyorsabb is.

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

Elsőre a naiv megközelítés részemről az lenne, hogy minden adatot n-szer átküldök, majd az adásidőnél többnek kell lennie a szünetnek. Ezzel a "módszerrel" csökkenteném le a hibákat.
Amúgy az őskorban biztos volt ere jobb megoldás is. Úgy kb 50++ éve.

> 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

- duplán küldeni. ha egyezik, akkor OK. ha nem, meginn duplán... mindaddig, amíg nem egyezik
- minél kisebb baud, annál stabilabb

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

És azt honnan tudod meg, hogy megint küldeni kell, mert nem egyezik?

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

"'A' egy másik, vissza irányú kommunikációs csatornán "rálát" 'V'-re"
És máris kétirányú a kommunikáció. Az, hogy ez két simplex csatorna, vagy egy (half-) duplex, az teljesen mindegy.

Pontosan.

:wq

Akkor mi a kérdés?

Zahyt kérdezd, mert részemről semmi.

:wq

Hát ha kétirányú a kommunikáció, akkor nekem sincs kérdésem, de nekem úgy tűnt, hogy egyirányúról szólt ez az ág.

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

A kérdező egyirányú kommunikációt említett. Mivel nincs visszaküldés a fogadott jelről az adó felé, így hibaellenőrzésre nincs más mód, csak a redundancia.

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

De akkor első hozzászólásom második fele még mindig áll: 5 adatból egy elveszik, 2 egyformá n sérül, akkor mi van? Értem én, hogy ennek csekély a valószínűsége, de ekkor hogy döntesz?

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

Vevőoldalon bevetjük a mindenható Kálmán filtert.

: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 5-ből csak 2 egyforma, akkor ott már akkora a bibi, hogy eszembe sem jutna, hogy az jó. de pl. hogy 5-ből 4 sérül egyformán, arra meg kicsi az esély

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

Nyilván nem úgy simán küldesz adatot át az éteren. Szóval 1. kell hibajavító kódolás, 2. kell checksum. Mindenképpen többszintű hibajavítás kell, de simán elképzelhető, hogy le lehet csökkenteni annyira a hibaarányt, hogy ne kelljen ACK.

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.

[Feliratkozás]

[sarcasm]IP over Avian Carriers?[/sarcasm]

latency problemas :D

:wq

Meg a packet loss :-D

Életemben először és utoljára akkor röhögtem halott állat képén, amikor a cikkben megláttam az "An example of packet loss" részt. Mondjuk hozzá teszem, muszáj volt hozzá a kontextus.

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.

Ez legális?

:wq

szurke.... elvileg nem pakolhatsz ra kulso antennat, gyakorlatilag csak akkor kurnak meg erte ha gebaszt csinalsz

Akkor viszont nagyon megkúrnak. 5Ghz-n simán bezavarhatod a meteorológiai radarokat.

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

Rákérdezek. Te OGN vevőállomást üzemeltetsz? :)
Akkor az szuper hír, hogy az adók komolyabb antenna híján is látják egymást 10-30 km-ről!

:wq

Talált, de nem egyet, hanem 25-öt :)

Wow! Azt lehet tudni, hogy az őcsényivel mi történt? Régen mintha lett volna ott is, az ogn.hu/map-on most is fönt van, de már jó ideje nem látom a live térképen.

:wq

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.

ha van ralatas, akkor lezer...