Ahoj, takze jsem vcera vecer zprovoznil minihotspot od Freda PA4YBR. Bylo to temer bez problemu, jen bylo potreba udelat reverze u TX. Vse ostatnu probihalo temer bez problemu. Vyzkousel take nase CML modemy a funguji. Potrebuji malinko hybnout s urovni vstupniho signalu, ale vzhledem ke kontrolkam RSSI to neni zadny problem. Dale jsem take provadel upload FW v processoru a jelikoz jsem mel k dispozici pouze starsi verzi byl jsem prekvapen velkym rozdilem ve funkcnosti. Starsi FW nepodporuje RSSI a pracuje nejak podivne. Proto doporucuji pouzivat tu nejnovejsi 🙂
Nevite nahodou nekdo o plosnaku ktery by slouzil jako redukce SOIC 24 pin na DIL?
neco jako http://cz.farnell.com/aries/24-350000-11-rc/adaptor-soic-to-dil-24way/dp/1136596 ale za podstatne priznivejsi cenu 🙂
Nevite nahodou nekdo o plosnaku ktery by slouzil jako redukce SOIC 24 pin na DIL?
neco jako http://cz.farnell.com/aries/24-350000-11-rc/adaptor-soic-to-dil-24way/dp/1136596 ale za podstatne priznivejsi cenu 🙂
On je s tímto adapérem trochu problém. Nohy SOIC 24 jsou totiž stejně vzdálené jako u DIL t.z.n nejde udělat adaptér jednoduše tak, ze se plivne doprostřed a přivede se k nožičkám místo DIL. V podstatě je několik řešení jak by to šlo udělat. To co nabízí Farnel je jedno z nich, problém je s tím, že nohy DIL jsou tam na kant (nemůžou být zkrz) a asi to není výrobně jednoduché. Nevím kolik je okolo tohoto pouzdra místa ale teoreticky by přicházely do úvahy dvě řešení.
1. koupit např. toto: http://microcontrollershop.com/product_info.php?products_id=3541 a pomocí dvou vinglových lišt provést na jedné straně zúžení na DIL rozměr. Je nutné aby bylo místo vedle DIL pouzdra a celé to vyjde vyšší.Toto je takové cikánské řešení, žádná krása, ale mohlo by to fungovat dobře.
2. Udělat tišťák, který bude delší než DIL pouzdro a SOIC bude předsazen před DIL nohy. V tomto případě je zase nutné mít aspoň 2-3cm prostoru v podélném směru DIL pouzdra. Tady je nevýhoda, že bude stát nějakou kačku příprava. Cena by pak byla zajímavá kdyby se udělal počet tak který by zaplnil alespoň A4 formát (20ks?)
Nic jiného mne v tuto chvíli nenapadá.
M.
Dale jsem take provadel upload FW v processoru a jelikoz jsem mel k dispozici pouze starsi verzi byl jsem prekvapen velkym rozdilem ve funkcnosti. Starsi FW nepodporuje RSSI a pracuje nejak podivne. Proto doporucuji pouzivat tu nejnovejsi 🙂
Kterou verzi FW máš na mysli ? Pokud si dobře vzpomínám, tak i první dostupná verze od Freda normálně podporovala RSSI a SW squelch.
Mimochodem, ON8JL na svých stránkách nabízí taky nějaký FW pro GMSK adaptér, nezkoušel ho už někdo ?
Jirka / Brno
Dale jsem take provadel upload FW v processoru a jelikoz jsem mel k dispozici pouze starsi verzi byl jsem prekvapen velkym rozdilem ve funkcnosti. Starsi FW nepodporuje RSSI a pracuje nejak podivne. Proto doporucuji pouzivat tu nejnovejsi 🙂
Kterou verzi FW máš na mysli ? Pokud si dobře vzpomínám, tak i první dostupná verze od Freda normálně podporovala RSSI a SW squelch.
Mimochodem, ON8JL na svých stránkách nabízí taky nějaký FW pro GMSK adaptér, nezkoušel ho už někdo ?
myslim verzi 0.1.30-07 ono to nemusi byt nutne tim FW, muze to byt i trochu jinym CML ktery jsem v hotspotu pouzil.
Nevim o tom ze by v Cechach nekdo zkousel ON8JL firmware. Nicmene mam to v merku a casem se do toho pustim.
Reaguji na dnešní debatu, že si nemáme nechávat informace pro sebe ... a zasílám printscreeny u mě aktuálně funkčního konfigu hotspotu s Kenwoodem TM-G707...
73! Tom
Tak jsem si hral s linkovanim a vytuhlo to temer okamzite. Po pripojeni na vnc jsem zjistil ze je na vine zasekle klicovani, ale pouze v sw. Hotspot nevysilal. Slo to opravit pouze restartem na nic jineho to nereagovalo.
Ptal jsem se ohledně tuhnutí Brianea GW6WTK (tvůrce kompilace obsahu SD karty pro RPI) a dopověděl mi, že zatím nikdo takovýto problém nehlásil a jemu že to jede 24/7 bez problémů. Psal mi, že by bylo dobré zjistit, co to napíše do logu, když se to kousne. Už od Soboty se to pokouším nachytat na švestkách a zatím se mi to nepodařilo. Pokaždé když už jsem myslel že je to hryzlý, tak to bylo něčím jiným, swině klouzavá... Když jsem procházel starší logy, tak tam anomálie vidět byly (poslalo to Err a pak už byl na USB modem nedostupný) ale nevím jak se to chovalo prakticky, jestli to zamrzlo úplně, nebo se to pak rozběhlo samo...
Jestli to někdo dokáže vyprovokovat pošlete mi prosím část logu (alespoň tak půl minuty před až po zakousnutí s popisem jak se to prakticky chovalo. Zkusím to nějak skolektovat a poslat Braenovi jestli ho něco nenapadane.
Vycházím-li ze premisy:
- Na Widlích se toto neděje (nezeměňovat s problémem standardní podzimu - padání Woken je vlastnost, nikoli chyba)
- Jestli si nevymýšlí, tak jsme jediní kde se to projevuje (ani strýc google mi nenašel, že by se s tím někdo potýkal)
mi vychází dvě možnosti:
a) máme něco jinak v konfiguraci a tím jak tichou poštou nastavujeme modem a GMSKRepeater jsme si to uvedli všichni do stejného stavu
b) problém s HW RPI (či použitá nevhodná (pomalá) SD karta) - tedy Brien psal cosi o SD kartě ale moc jsem to nepochopil - jestli někdo zná tento dialekt prosím přeložte (zejména druhou část souvětí).
"Have you got logging turned-on and are you using suitable a SD card,
perhaps logging to a flaky SD card is stalling things."
Tak-že mám v plánu, jakmile se povede mít jednoznačný zázanam logu s popisem co se prakticky stalo, pošlu mu to a poprosím ho, aby mi poslal screenshoty konfigurace modemu.
Logy se ukládají do /var/log a tam jsou tam s názem GMSKRepeater-datum.log. Stáhnout se dají jednoduše pomocí WinSCP.
Milan
M: 2013-02-23 22:16:23: Transmitting to - My: OK1POR B/ Your: OK1LOL Rpt1: OK1POR G Rpt2: OK1POR B Flags: 01 00 00
M: 2013-02-23 22:17:16: Header decoded - My: OK1LOL / Your: CQCQCQ Rpt1: OK1POR B Rpt2: OK1POR G Flags: 40 00 00
M: 2013-02-23 22:17:18: AMBE for OK1LOL Frames: 1.8s, Silence: 0.0%, BER: 0.0%
M: 2013-02-23 22:17:18: Slow data set to "Not linked "
M: 2013-02-23 22:17:18: Transmitting to - My: OK1POR B/ Your: OK1LOL Rpt1: OK1POR G Rpt2: OK1POR B Flags: 01 00 00
M: 2013-02-23 22:17:20: Network header received - My: OK1POR /INFO Your: CQCQCQ Rpt1: OK1POR G Rpt2: OK1POR B Flags: 00 00 00
M: 2013-02-23 22:17:20: Transmitting to - My: OK1POR /INFO Your: CQCQCQ Rpt1: OK1POR G Rpt2: OK1POR B Flags: 00 00 00
M: 2013-02-23 22:17:22: Stats for OK1POR Frames: 2.5s, Loss: 0.0%, Packets: 0/123
I: 2013-02-23 22:19:57: Frame logging set to 1, in /root
M: 2013-02-23 22:27:22: Transmitting to - My: OK1POR B/RPTR Your: CQCQCQ Rpt1: OK1POR G Rpt2: OK1POR B Flags: 00 00 00
I: 2013-02-23 22:30:36: Starting GMSK Repeater - 20130219
I: 2013-02-23 22:30:43: $Revision: 304 $ on $Date: 2013-02-18 21:46:47 +0000 (Mon, 18 Feb 2013) $
I: 2013-02-23 22:30:43: Using wxWidgets 2.8.12 on Linux 3.2.27+ armv6l
I: 2013-02-23 22:30:46: Callsign set to "OK1POR B", gateway set to "OK1POR G", mode: 1, ack: 1, restriction: 0, RPT1 validation: 0
I: 2013-02-23 22:30:46: Gateway set to 127.0.0.1:20010, local set to 127.0.0.1:20011
I: 2013-02-23 22:30:46: Timeout set to 180 secs, ack time set to 150 ms
I: 2013-02-23 22:30:46: Beacon set to 10 mins, text set to "GMSK Repeater", voice set to 0, language set to 0
I: 2013-02-23 22:30:46: GMSK modem: type: LibUsb, address: 0x0300
cervene jsem vyznacil neco co mi prijde podivne a odhadem to odpovida chvili kdy se mi to hrazlo
Tak to se chová jinak než u mne. Jediný motiv který jsem ve starších logách našel s různými variacemi (řaděk kde je err=-4 se liší, bylo tam třeba "GET_PTT, err=-4" ) vypadá asi takto:
M: 2013-02-16 15:37:47: Network header received - My: OK0OMX /INFO Your: CQCQCQ Rpt1: OK0OMX G Rpt2: OK0OMX B Flags: 00 00 00
M: 2013-02-16 15:37:47: Transmitting to - My: OK0OMX /INFO Your: CQCQCQ Rpt1: OK0OMX G Rpt2: OK0OMX B Flags: 00 00 00
M: 2013-02-16 15:37:53: Network watchdog has expired
M: 2013-02-16 15:37:56: Stats for OK0OMX Frames: 4.3s, Loss: 7.9%, Packets: 17/216
M: 2013-02-16 15:38:22: GET_REMAINSPACE, err=-4
E: 2013-02-16 15:38:22: Cannot find the GMSK Modem with address: 0x0300
E: 2013-02-16 15:38:23: Cannot find the GMSK Modem with address: 0x0300
E: 2013-02-16 15:38:24: Cannot find the GMSK Modem with address: 0x0300
E: 2013-02-16 15:38:25: Cannot find the GMSK Modem with address: 0x0300
E: 2013-02-16 15:38:26: Cannot find the GMSK Modem with address: 0x0300
E: 2013-02-16 15:38:27: Cannot find the GMSK Modem with address: 0x0300
E: 2013-02-16 15:38:28: Cannot find the GMSK Modem with address: 0x0300
....
Ale nejsem si jist a nejsem schopen dát dohromady s jistotou jak se to navenek chovalo, tak že stále čekám... jakmile to padne, tak chci mít 100% jistotu, že bude popis situace a log odpovídat.
Nicméně linkování, odlikovávání, CCS, mi nikdy záhryz nezpůsobily. Vždycky když mi to chcíplo, pod rukama, tak to utlo veprostřed něčí relaci a ještě s takovým lupnutím. (jen se stanici bych si toho asi nevšiml, ale díky tomu že mi tu potichu hraje UP4DAR, tak stanice (tudíž i hotspot) zdechla ale on hrál dál.
Aktuálně došlo k vytuhnutí hotspotu. V logu nic, přes VNC to ukázalo TX ON. Raspberry jsem nerebootnul pouze jsem nejdřív restartoval gmskrepeater což nevedlo
k zmátoření hotspotu, musel jsem ještě restartovat ircddbgateway. Takže asi začnem měnit podložky pod matičkama.
Metodou pokus omyl zatím několik zjištění:
- Podle různých indícií to vypadá, že RPI chvilkama krátkodobě nestíhá obsluhovat USB. Někdy to nechá v logu záznam někdy ne. Proto jsem se vydal touto cestou a snažil jsem se mu co nejvíce ulevit, což se zdá bylo ku prospěchu - včera jsem to umělým zatěžováním dokázal umrvit i 3x za 5 min.
a) ač je to pro mne nepochopitelné, vypnutím zaškrtávátka GUI update v položce VIEW na GMSKrepeateru a na IRCDDBGateway kleslo vytížení skoro na polovinu a to i při shozeném VNC (přistupoval jsem tam přes SSH) - pozor, při rebootu se defaultně myslím sami zaškrtnou, je nutné je přes GUI vypnout a VNC zavřít
b) další nárazový požadavek výkonu přicházel z IRCDDB - proztím jsem ho vypnul - (byl jsem připojen na ostrém serveru a balíky dat chodí sice občas, ale je jich hodně, je možné že když se sešla relace, kdy to příjmalo a zároveň to muselo odbavovat tento traffic, tak chudák zblbne)
c) do logu se píše každé uprdnutí a zápis na flashku není nic rychlého a nevylučuji, že by to také mohlo krátkodobě způsobit nějakou kolizi, chtělo by to zkusit (i z důvodu zvětšení životnosti flashky) to vypnout, ale bohužel s mými znalostmi linuxu jsem na to krátký.
Nechám to v tomto stavu a uvidíme, zatím to vypadá nadějně.