Stránka 3 z 4

Re: Stehujici se digi a podobne anomalie

Napsal: sob 11. zář 2010 23:09:23
od OK1LOL
OK1MJO píše: Po dobu co budu v nemocnic
Drzim palce at to dobre dopadne!

Re: Stehujici se digi a podobne anomalie

Napsal: ned 12. zář 2010 19:56:22
od ok2slc
OK1MJO píše:Problematika je v 90% v CRC kvuli emulaci UARTu 16c550A v cipsetu WRAPu/Alixe/RB atd. , ktery by mohl vyresit soft pro APRS v Linuxu.
Standardni stolni PC P4 nema problem. Schvalne prepnete TNC do hosta W8DED a nastavte WRAP Linux pro praci v hostu misto kissu a uvidite....pojede to bez problemu, bez zmrsenych hlavicek AX25 paketu.
Po dobu co budu v nemocnic nekdo kdyztak vyzkousejte Esc prikaz @K + ESC Z 0 (http://www.ok0bez.com/files/aprs/TNC2-G ... ametry.txt).

http://www.pcengines.ch/schema/alix2d.pdf
Pokud by to tedy bylo tak jak pises a skutecne to bylo hw WRAPu, tak by me prece nemohl APRX na WRAP2.C chodit s TNC2 bez problemu, ne ? Nemuze to byt nahodou tim, že se do seriovyho portu "vykecava" terminal, ktery se v BIOSu zapomnel vypnout ?

Re: Stehujici se digi a podobne anomalie

Napsal: ned 12. zář 2010 20:30:52
od ok1mgj
Nemuze, konzole pri startu do modemu sice nasype nejaky kraviny, ale chybu nezpusobi.
Na WRAPu co byl na KSO jsem se ani neobtezoval konzoli v biosu vypnout a jelo to jako novy (s TNC2 multi) => nemelo cenu ji vypinat.

Jeste k DCD

Napsal: pon 13. zář 2010 0:21:29
od OK1MJO
To DCD o kterem taky je rec, je tez velice dulezite.
Dalsi info mimo toho co mam na strankach muzete najit zde:
http://www.dk7in.de/TinyTrak_e.html#cd

Obrázek


Pokud potrebujete NF generator pro odladeni, tak si ho stahnete ode me:
http://www.ok1mjo.com/all/ostatni/prsoft/NF_generator/
Ja jsem pouzil hned ten prvni ( http://www.ok1mjo.com/all/ostatni/prsof ... nerator_1/ ).
Pripadne Vam pomuze jeste tohle:
http://www.ok1mjo.com/all/ostatni/prsof ... _zvukovky/

Pokud udelate spravne DCD a obvody vymenite za CMOS (CPU s 8MHz....na Dyleni je tusim TTL verze 6MHz Z80), tak z HW hlediska je GC12AX v poradku.
Zkratka se nesmi prehrivat a DCD musi najet do 1ms (do doby W u TX delay).

Zbytek problemu jsou 70% radic COMu u "WRAPu" (vecer mi volal Ludek, ze nelze napajet Baycoma ze seriovky WRAPu a tak musi udelat zdroj s 7805 napajeny z 13.8Vdc spolecneho napajeni....je to jasny, kdyz ARM nebo GEODA cipset musi sw emulovat UART, kterej tam schazi...proto stolni PC P4 tyto problemy NEMA, GC12AX mi tu bezel nonstop tyden s UI-View32 na stole do externi anteny, az prijedu z nemocnice, tak odladim ini "davku" a bude to dobry, kazdopadne onen problem je sw problem...samozrejme, kdyz mate spatny DCD a topeni-IC, tak to taky blbne) a 30% nekompatibility GES KISSu vuci TNC2 KISSu v CRC.

73! Martin

PS: Pokud mate Icoma IC-F1010 na kopci jako ja, tak se sikne toto: viewtopic.php?p=4302#p4302 .

Dopis od Karla OK2SCS z Brna

Napsal: pon 13. zář 2010 2:55:21
od OK1MJO
Karel nam ve vcerejsim mailu naznacil problem, dovolim si obsah zverejnit vzhledem k zavaznosti veci.
---------------------------------------------------------------

Myslím si, že jsme to asi společnejma silama trefili. Ten soft prostě nepočítá
CRC v AX.25 packetu, neb počítá s tím, že z TNC vadnej packet nedojde. Zbývá
teda zjistit, KDE se to mrší + napsat nějakýho démona, kterej to CRC bude
počítat. Zažil jsem KISS firmware, kterej posílal po seriový lajně i vadný
packety, prostě se s tím nesral, z posledního FLAGu v řadě udělal FEND, nasral
hlavičku od KISSu a sral data co přijal, pochopitelně FEND v datech překládal na
FESC TFEND a FEST na FESC TFESC a jinak to prostě sral zrovna ven. Jak došel
FLAG vysral FEND a fertig. Doporučuju si přečíst specifikaci KISSu, kam se na to
chodí ale už nevím, též to bylo na nějakým CD, já si to pamatuju jen rámcově.
Vím, že po FEND musí přijít další FEND, nebo dva bajty, jeden je adresa portu,
ten druhej tuším příkaz/data, ale už si to pramálo pamatuju. Je to už holt
dlouho co jsem se v tom hrabal. Prostě to TNC sralo ven i blbě přijatý packety a
já měl furt v logu z jádra malformed packet a honil jsem to mezi seriovým
řadičem v TNC a PC, pak jsem hledal chybu už i v RAMce, ale všechno marný.
Nakonec jsem na to došel, nainstaloval jinej firmware a byl pokoj, ale trvalo mi
tejden než jsem na to došel. Takže možný to rozhodně je, navíc všechny softy, co
umí KISS, kontrolujou CRC v AX.25 packetu a když to nesedí tak to zahodí, jádro
z Linuxu teda o tom vybleje hlášku, ale to je světlá vyjímka. To je mimo jiný
důvod, proč KISS nemá CRC, že. CRC má už AX.25 packet, takže proč to srát ještě
do KISSu? Totiž, ať to vezmete z který chcete strany. Spojenej packet se dá
udělat buď tak, že vypadne kus přenosu na AX.25, nebo vypadne kus přenosu na
KISSu, ale je nad slunce jasný, že se v tom softu následně nekontroluje CRC
přijatýho AX.25 packetu, ač se kontrolovat má. Pochopitelně že s TNC, který
posílá jen packety, co jsou OK, se tenhle průser prakticky neprojeví, chybovost
na sériáku je minimální, zvláště pak při nízkejch rychlostech.

Taky by mohl být průser v tom softu, ale to se mi nezdá. Ať už se prostě ty
packety srazí do sebe jakkoliv, tak přece nemůže sedět CRC, ne? A nebo jsem
vedle? Podle mýho nejsem.

Ty data se pochopitelně můžou zmršit kdekoliv, tj. na vysílací straně, při
přenosu po rádiu, někde v modemu, v TNC, při přenosu do PC, to je jasný, jenomže
je taky jasný, že TOHLE v závěru nesmí projít přes kontrolu CRC a ten packet je
prostě tímhle ztracenej a ne aby prodifundoval kdoví kam. Že se tam něco mrví je
jasný, ale ten průšvih vypadá, že bude na dvou místech a musí být na _obou_
místech, aby se projevil, tj. TNC který posílá i vadný packety + soft, kterej
nekontroluje CRC v AX.25 packetech. V jinejch případech se tohle podle mýho stát
nemůže.

OK2SCS
-------------------------------------------------

73! Martin OK1MJO

Re: Stehujici se digi a podobne anomalie

Napsal: pon 13. zář 2010 9:50:15
od ok2slc
Pokud by slo jen o zabezpeceni KISS frame o CRC, tak je tu SMACK, viz. http://www.symek.com/g/smack.html, ale to myslim problem neresi. Jinak jsem si vsiml, ze i OK2ILA-1 (doufam, ze jsem ho vytipoval dobre) "pridava" na konec paketu nejaky bordel.

Re: Stehujici se digi a podobne anomalie

Napsal: pon 13. zář 2010 10:02:28
od ok2ila
ok2slc píše: Jinak jsem si vsiml, ze i OK2ILA-1 (doufam, ze jsem ho vytipoval dobre) "pridava" na konec paketu nejaky bordel.
Dela to teprve od vcerejska, kdy jsem s necim experimentoval. Pocitam, ze restart to vyresi... T.c. nemam k nemu pristup. Takze se stehovanim digin to (snad) nema nic spolecneho.

Re: Stehujici se digi a podobne anomalie

Napsal: úte 09. lis 2010 8:11:59
od OK1MJO
Odpoved ohledne toho CRC jsem popsal zde:
viewtopic.php?p=4489#p4489

Re: Stehujici se digi a podobne anomalie

Napsal: stř 01. pro 2010 12:04:05
od OK1MJO
Jeste dalsi info (viewtopic.php?p=4555#p4555) k tematu.
Utvrzuje me v moznem reseni i to, ze problemy nejsou jen v konkretnim TNC2 GC12AX, ale i v jinejch klonech TNC2.
Pokud reseni bude fungovat, tak se o nem rozepisi.

Re: Stehujici se digi a podobne anomalie

Napsal: čtv 02. pro 2010 16:26:27
od ok1mgj
Hojda, jenom dalsi postrehy:

na OpenWRT a APRX (ktere evidentne kontroluje packety) vadny packet neprojde (tedy ten obsahujici nesmyslne znaky, proste naboreny).
Ovsem projde packet, ktery je v poradku, ale vzniknul sloucenim dvou ruznych packetu zrovna tak "sikovne" ze vznikly ramec je "v poradku". Takze i pod APRX s GES TNC vznika problem se stehovanim digi.