Po dobu co budu v nemocnic
Drzim palce at to dobre dopadne!
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-GC12AX_GES/TNC-GC12AX_firmware/TNC2-GC12AX_popis_prikazy_parametry.txt ).
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 ?
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.
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
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/prsoft/NF_generator/NF_generator_1/ ).
Pripadne Vam pomuze jeste tohle:
http://www.ok1mjo.com/all/ostatni/prsoft/test_ze_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: http://www.hamradio.cz/forum/viewtopic.php?p=4302#p4302 .
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
