Próbálkoztam egy olyannal is, hogy egy 20cm körüli vezetékdarabbal összekötöm az adó és vevő lábakat (meg persze a földet), de úgy sem ment át értelmes adat.
Maga a modul pedig jónak tűnik, csak ez jelre nem alacsonyról magasra vált, hanem magasról alacsonyra, és nem tudtam mit kezdeni a dolgokkal...
Szerintem tehát a programmal van valami gond (más picek, más órajel, csillagok hibás állása...). A PIC programozás topicban kérdezősködök a szoftveres oldalról. A manchester kódolás elvileg biztosítaná az adatvesztés javítgatását egy határig, de ha direkt vezetéken sem jut át, akkor mégis el van írva valami.

A manchester kódolás a javíthatóságot nem, csak az átvihetőséget biztosítja.
Szerintem dobj ide egy kapcsolási rajzot és egy forrást, mert így nem nagyon tudja senki kitalálni hogy mit varázsoltál el.
Ha minden áron dróttal akarod tesztelni, a modulokat vedd ki, és úgy drótozd össze a két PIC-et. Amíg az nem megy esélyed sincs a rádiós átvitelre.
Az hogy a kimenete invertált-e azt az adatlap biztosan taglalja.

Adó Vevő adatlapok, elég szűkszavúak...

Kapcsolásilag annyi, hogy a vevőn PIC16F877A (4Mhz)-n B3 lábon veszek, az adón egy PIC16F887 (20Mhz) D7 lábon adok. A vevőn az LCD működik, azzal nincs dolgunk.
Mikor dróttal próbáltam, természetesen kivettem a modulokat.
A betöltött programok:Adó, vevő, és az eredeti Topi-féle manchester kódoló rutin

Ja, és az adatlap 4800 baudot ajánl, de ha az eredeti 1200ról 4800ra állítom, akkor még dróton sem jut át a zavar...

Hoppá az első nagy bajom: a baud nem bit/s
Tehát ha az optimális adatátviteli sebességem 4800bps, akkor az 8 bites csomagokkal 4800/8=600 baud, nem?
Bár ettől még dróton át kellett volna jutnia a dolgoknak... Első körben a direkt kapcsolattal kéne mennie, aztán jöhet a zavarok szűrése, stb.

Az adatlapok valóban elég szűkszavúak, és nem is nagyon találtam mást, de....
A forrásaidon átszaladva, nincs jelölve a szoftveres és a hardveres RS232.

Ugyan ez megvan a vevő oldalon is.
A másik ami esetleg okozhat gondokat, az az hogy a vevőt nem kristályról hanem belső oszciról hajtod. Annak bizony lehet akkora a pontatlansága, hogy a soros átvitel már bizonytalan lehet. Tegyél rá egy kvarcot, nem olyan drága és egy hibalehetőséget kizártál.
Mint említettem ettől a rádiós átvitel még nem fog megjavúlni, de dróton már tesztelhető lesz (akkor nem kell az adó oldalon az invert, az a modulnak kell, mivel a soros kimenet alapban H-n van, és én ideiglenesen kikapcsolnám a manchester kódolást is, hogy az se zavarjon be).
Ha elindul érdemesebb lenne a rádiós részt tenni a hardveres soros portra, hogy megszakításból tudd kezelni.
Ami a baud/bps-t illeti a baudrate a hasznos átvitt bitek száma másodpercenként, a bps pedig az összes átvitt bit. Ennek régen a modemeknél volt jelentősége, jelen esetben a kettő ugyan az.

A vevőn is ott a 4Mhz kvarc. Vagy valami a konfigban nem jó?
Tudtommal kvarcról megy.
Egyébként az adó és vevő kód is a cikkben található példa minimálisan átalakítva: ennek a végén van az rf.c, lényegében az órajelet és a pic típust változattam meg.
Az invert dolgait nem értem. "Check that the INVERT option in the USE RS232 is right for your level converter. If the RCV pin is HIGH when no data is being sent, you should NOT use INVERT. If the pin is low when no data is being sent, you need to use INVERT." Ezt mondja a ccsc súgó. Nekem tehát nem kell az invert, mert rcv láb alapból magasan van. Az adó oldalon pedig szintén magasan kell tartani, és a lemenő élekre reagál.

Igen, a 4 MHz zavart meg, azt csak belső oszcival szoktam használni.

Ezt meg én nem értem.... semmi erre utaló dolgot nem láttam az adatlapon.
Azért annyit higgy el nekem, hogy egy multiméterrel nem mész messzire.

Hát tudom ez nem mérés, de a következőt csináltam:
vevő kimenetére egy led, adó bemenete ellenállással földön; gombbal adogatom rá az 5V-t.
A led alapból világít. Megnyomom a gombot -> világít tovább. Felengedem a gombot->elsötétül rövid időre, aztán világít tovább.
Mondjuk tényleg jó lenne, h a gyártó nyögne valamit az ilyesmiről, és nem otthon kéne megtippelni...

Elkeserítelek, nem baud, hanem bps, azaz b/s (bit per sec) A baud egy régi sebesség egység, még a morzés időkből, egyébként jelsebességet jelent. Hogy mi az a jel, hát lehet változó, mint a morse jelek, lehet 5, 6, 7, 8 bit stb.
Ma már nem is használják, az adatlapon is bps szerepel.
Amire Te gondolsz, az a bájt/s, azaz B/s, (kB/s)
Az RF sávszélesség erősen függ a jelsebességtől, ezért szerepel az adatlapon. Nem szerepelnek RF jellemzők, mert arra nincs igazán szükség, ha párban használod az adó és vevő modult.
whalaky: nem létezik szabad frekvencia, a 433 MHz ún ITO (ipari tudományos, orvosi) felhasználású frekvenciákon az ilyen SRD eszközöket megfelelő minősítés, gyártási, forgalmazási engedély alapján lehet használni, más hasonló SRD (kishatótávolságú) eszközökkel megosztva. Más frekvenciákon is lehet üzemeltetni SRD eszközöket megfelelő zavarvédettségű frekvencia felhasználás mellett, pl 868 MHz sávban (és més sok más helyen)

Van itt egy értelmezhető dolog is: Rákötöttem a pickit 2 UART tooljával a gépre az adó picet. Oda ugyanazt küldi, mint ami a vevő picre megérkezik vezetékes kapcsolat esetén. Ott persze semmi értelme, mert elvileg ugye kódolva van. Csak akkor a vevő nem dekódol?

Ascii: ??ZZZZeejjii??UUZZeeffeeVV??

HEX: A6 A6 5A 5A 5A 5A 65 65 6A 6A 69 69 AA AA 55 55 5A 5A 65 65 66 66 65 65 56 56 A9 A9
Gondolom ezzel nem vagyunk beljebb...

Ugyan írtam már hogy a drótos tesztelés idejére első körben vedd ki a kódolás-dekódolást, és ha anélkül már stabil csak akkor tedd bele. Ugyan nem tudnám már megmondani miért, de valamiért lecseréltem.
Ilyenkor jön a papír ceruza, amit kiküldesz szépen leírod binárisan, átalakítod manchester-el, és máris látod hogy minek kéne kimenni, és az jelenik-e meg. Ha nem, akkor is látszik hogy mi jött, a bitmintákból elég jól lehet következtetni a hiba okára.
Pucuka: Igen, tudom, de általában a nem engedély köteles frekvenciákat szabad frekvencia néven emlegetik. Igen, tudom hogy vannak elég kemény megkötések amit be kell tartani.

Na játszottam vele még egy kicsit; a kódolás nélkül dróton gond nélkül átviszi a szöveget, és ki is írja.
Tehát a manchester.c -vel van a baj.
Olvastam egy olyan trükköt, hogy nem szórakozunk manchesterrel, hanem minden karakter elé és mögé írunk egy 'U' betűt. Ez hexben 0xAA-ként van elküldve. A vevő oldalon meg egyszerűen megvizsgáljuk, hogy ha nem=u, akkor írjuk csak ki. Használni nem lehet még, de keb minden 10. alkalommal helyes az elküldött szöveg.

(A manchester.c elején a keyhit delay értéke nem tud bezavarni minket ha módosítottam az órajelet, és a baudot?)

Igen.... emlékeztem rá hogy valamiért lecseréltem a manchester kódolást, de nem mertem volna biztosra állítani hogy Topi kódja hibás lenne.
Nézz körül a ccsinfo-n, azt hiszem ott találtam sok ígéretes megoldást. A manchester nélkül nem fog menni....

Maga a kódolás (man_encode, man_decode) az megtalálható a neten, azt lehet szidni bátran
Az m_send és az m_get meg nem tiszta nekem. Mondjuk nem úgy néz ki mint ami működni szeretne...

Játszik az, csak bugos.
kikommenteztem neked, hátha így érthetőbb

Erre változtattam:


Így kiír dolgokat, tehát nem érez hibát, de csak random karakterek. Vezetékkel összekötve ugyanez.

Beküldtem gépre, hogy mit ad ki kódolt adat gyanánt:
(excelben váltottam át a hexet, a 7jegyűek nyilván 0val kezdődtek és az nem írta ki nekem)

1010101 10100101 1011001 1010101 1100110 1010101 1101010 1011001 1101001 10101010 1101001 1011001 1101001 1010110 1011001 1010101 1101010 1100110 1101010 10011001 1101001 1100110 1101001 10101001 1101001 1100110 1101010 1100101 1011001 1010110 1011001 1010110

Úgy látom teljesül az 10 01 váltakozása. Nem a getchar van rosszul időzítve?

Túl nagy csodát nem tettél vele. Szerintem így kéne mennie

mint az előző hsz-ben írtam fel van cserélve a két byte

Azt fel is cseréltem. csak én nem a getc és timed getc-nél írtam át, hanem az utánuk következőkben cseréltem fel őket.
A fenti bitekkel tudunk valami kezdeni?

Attól függ mi ez. Kötésminta? Mit küldtél ki?
Próbáld meg papír ceruza módszerrel dekódolni, és kiderül(het) hogy hol csúszik szét.

Na, életre kelt. Vezetékes kapcsolaton átjön a jel, dekódol, mindent megcsinál. A szoftver végre jó. (nem az eddig taglalt, hanem a manchester kódolás topicban lévő)
Viszont rádiós kapcsolaton kb minden 50. alkalommal ér át a szöveg.
Ezt a baud-bps dolgot nem értem egészen. 4800baudnál nem jött át a vezetéken, csak zavar. 1200on hirtelen tökéletes lett. Rádión 600 bauddal sem.
Wikipedia szerint a baud az elküldött csomag/mp. Itt ha egy csomag 8bit, akkor a gyárilag ajánlott 4800bps-re 4800/8=600 baud kéne? (azzal sem megy...) Tudtommal a bluetooth és a wifi a GHz nagyságrendű frekvenciájával nemigen zavahatja be, nem?

A baud a legrövidebb elemi idejű jel ( szimbólum ) idejének reciproka. Távíróban ez a "ti" vagy a betűköz idejének reciproka, RS232-nél egy bité.
Ha kétállapotú átvitel van, akkor a bit/sec ennél csak kisebb lehet, például a startbit, paritásbit, stopbit miatt, vagy ha eleve több állapotot használ egy bit átviteléhez.
Ugyanakkor ha az elemi idő alatt a jel, szimbólum pl. 4 állapotból vehet fel értéket ( pl. 0, 90, 180, 270 fok ), akkor a bit/sec több is lehet, mint a baud.
baud
Elvben a zsebtelefon, infravörös távirányító sem zavarhatja a középhullámú zsebtelefont, de mégis megteszi.
Kitekintésként: rádióamatőr csomagrádió protokoll.

Nem kellene foglalkoznod ezzel a baudos dologgal.
Az adatlapon is bps azaz bitpersecundum van, ez pedig elég egyértelmű. (szó sincs sehol baudról)
A zavarással pedig az a helyzet, hogy a WIFI és a bluetooth nem, de a számítógép, és a monitor, bármilyen hihetetlen is, de zavarhat. Más ebben a sávban működő hasonló berendezés (modul) nem okozhat zavart legalábbis addíg amíg az adó és vevő modul egymás közelében van. Az sem jó, ha túl közel vannak egymáshoz, legalább egy méter távolságra legyenek egymástól.
A hibakareséshez legalább is egy szkóp kellene, az adóra rákapcsolod a továbbítandó jelsorozatot, és a vevő kimenetén látni kellene a vett jel formáját.amit a PIC feldolgoz.

Kicsit pontosítva annyit kell vele foglakloznod, hogy mivel egy byte adat két byte-on kerül átvitelre, ha az első beérkezett byte után beállított átvitel mellett egy byte átviteléhez szükséges idő másfél-kétszeresén belül nem esik be a második byte is, akkor ott adatvesztés van, amit le kell kezelned de itt még nem tart a projected.
Itt jön képbe a timed_getc.
Sajnos már nekem sincs szkópom (agyament módon kölcsönadtam és privatizálták), de egy-egy RS232 kimenettel és egy jó terminál programmal el tudtam vele boldogulni.

Én a programmozási részéhez nem értek (sajnos), a rádiós átvitelnél nincs jelentősége, ha folyamatos impulzusokat kell átvinni, akkor már csak az impulzus sebesség számít, és ezt hogyan dolgozod fel, az más tészta.
Egy egyszerű szkópot tudsz csinálni a hangkártyával, a célnak tökéletesen megfelel, ilyeneket találsz akár a HE topikjaiban is, mármint ha nem akarsz fel - lefutási időket mérni. A jel meglétének indikálására jó.
Érdmes átnézned a többi rádiós átvitellel foglalkozó topikot is, azokban olvastam olyan tapasztalatokat, mintha AGC szerűen működne, az első néhány bit vétele után adna ki a vevő értékelhető adatot. Nem biztos, hogy a tied csinálja, de érdemes erre is gondolni. Ha viszonylag ritkán, rövid adatokat (bitcsomagokat) akarsz átvinni, ez gond lehet.például
például például
nem nekem van a projektem, hanem szkrep kollégának, én csak próbálok segíteni a rádiós rész élesztésénél. Az információ előállításához, meg a feldolgozásához nem negyon értek, legalábbis a programmozási részéhez, ahhoz nem is ütöm bele az orromat

Találtam egy ilyet.. Nekem tehát a delay 1000000 [us] /1200 [bps]/10= maximum 83us? Gondolom minél kisebb, annál jobb. A timeout ugye az, hogy mennyi ideig várjon a következő beérkező adatra. Ehhez a 300ms rengeteg sok, ha kb 833us-enként küldök adatot (1s=1 000 000us => 1000000/1200=833,3us). Lehet hogy egy elveszett csomag ellenére tovább várakozik, és simán valami zavart hozzászámol? Ha nem sugárzok semmit, akkor is dől befelé az adat.
Elvileg ugye az kéne nekem, hogy az első fogadott byte után kb 1 bit átviteli idejéig várjam a következő bejövő bájtot, ami ha nem jött meg, tudom hogy hiba van. Max 2ms elég lenne erre, nem?

Kösz, de már beinvesztáltam egy PICKIT2-be, és nem bántam meg. Van triggerelhető 3 csatornás "szkópja" és soros analizátora is, az ilyen egyszerűbb funkciókhoz megfelel.
Mindemellett tervezem hogy veszek egy rendes szkópot is, csak még nem találtam meg az ár/érték/lehetőség/igény paramétereknek megfelelőt. Ami megfelelne azt nem tudom megfizetni, amit most hirtelen meg tudnék fizetni azt nem veszem meg, inkább kicsit még zsíroskenyerezek, nem akarom csak azért hogy legyen. Továbbra is kitartok amellett hogy a műszereklbe igenis be kell invesztálni, a hangkártyából barkácsolt szóp szerű képződmények igen visszafogott tudással bírnak.

Nem. A kbhit akkor lesz true, ha egy BYTE már a pufferben van, azaz minimum annyit kell várnod, amíg egy byte biztosan átmegy - eze picivel több mint az átviteli idő.
Ha 2-3-5 byte-nyi időt adsz timeoutnak az nem baj, ha beesik a várt byte nem fog tovább várakozni, ha pedig szemét jön be azt a CRC dolga kiszürni.

Így van. Ha visszaolvasol ezt taglaltam. Protokoll, CRC stb.

Most azzal próbálkozom, hogy elküldök mindent 5-ször, a vevőn pedig a kapott 5 érték közül kiválasztom az első 2 utamba kerülő egyformát, és azt veszem jónak. Tudom, ez még elég primitív, és 100 évig tart a művelet, de én ennyit tudok így hirtelen összehozni, de ezt is úgy, hogy nem az történik amit én megálmodtam.
Az adó annyit ad manchester kódolva, hogy "11111 22222 33333 stbstb".
A vevő ezt meg is kapja és dekódolja, de nem találja a 2 egyformát. A program lefut; raktam bele minden folyamat végére egy ledvillantást, vagy putc(akármi, csak lássam, hogy odajutott).
Csatolom a vevő kódot; gondolom fogadáskor összekuszálok valamit....

Nagyon nem vagyok meglepve hogy nem működik.
Megtennéd hogy kikommentezed hogy mit is akartál elérni vele? (mondjuk soronként)

Gondolg végig! Mi van ha az 5-ös for ciklusodban csak egyszer nincs semmi a rádió pufferben (a kbhit(radio) == false)?
Szerinted mi garantálja azt hogy minden ciklusban be fog esni egy egy byte?
Aztán azt sem látom hogy ha éppen jön is valami, az bemegy az i változóba, azzal mit teszel? Nem látom hogy bármit is kezdenél vele....
Szerintem gondold újra a dolgot!
Az optimális megoldás az interruptos lenne, de nem lehetetlen anélkül is megoldani, csak nagyon végig kell gondolni a dolgot.

A terv az volt, hogy a megkapott, kikódolt byteot elteszem i1, i2, i3, i4, i5 változókba a value(int n)-el. Annak függvényében, hogy n éppen hol áll (hanyadik), eldöntöm, hogy mi legyen a neve. Ha bejött mind az 5, a check() megnézi őket, és keresi a 2 egyformát. Aztán kiírom mit talált.
Alapvetően azzal van a bajom, hogy hogy jegyzem meg a legutóbbi 5 bejött byteot. Próbáltam eepromba írni, oda be is írta, de nem dobott ki semmi értelmeset az sem.
Annyit kéne módosítanom, hogy ne az lcd-re tegye ki, hanem az 5 változó egyikébe. Ha el tudtam rakni, onnantól vizsgálhatom ahogy akarom...