 | Strona: 1 / 1 strony: [1] |
Nadawanie CW z "czkawką" pod Win10 |  |
| | | | SP9GFY | 30.01.2024 23:03:53 | Grupa: Użytkownik
Posty: 6 #8149449
Od: 2012-9-22
| Witam serdecznie Kolegów
i proszę o podpowiedź, pomoc w rozwiązaniu mojego problemu.
Nadawanie na CW niezależnie czy spod Loggera czy też N1MM nie działa prawidłowo.
Co kilka sekund coś (chyba zajmuje port) i w zależności co jest aktualnie nadawane albo wydłuża kreskę albo wydłuża przerwę między znakami. Niezależnie które są to przerwy.Jak trafi.
W teście trwającym minutę, to coś występuje 6 razy.
Niezależnie od szybkości nadawania to coś trwa mniej więcej sekundę.
W październiku ubiegłego roku coś stało się z systemem (Win10) w skutek moich zabaw z Avast Driver Updater.
Zakupiłem nowy dysk, pozostałe powypinałem i postawiłem system od nowa. Od nowa, aby było na czysto" w pełnych wersjach zainstalowałem Logger32 v.4 , WSJT-x, N1MM+. Sądziłem, że coś sie pomieszało w systemie.
No i tak chyba będzie, że jest to któryś z nowych driverów lub innych aktualizacji.
Tylko jak to Koledzy znaleźć i zabić? To jest właśnie moja prośba do Was.
Konfiguracja sprzętowa nie zmieniła się. PC z Win10 + K3 + TI-3000.
Szybkości transmisji czy bity stopu, bity danych, parzystość to wszystko posprawdzałem. Zawsze było tak jak jest teraz.
Pozdrawiam,
Heniek SP9GFY
73's
| | | | | Electra | 27.04.2024 12:11:24 | 
 |
| | | | | sp5it | 30.01.2024 23:07:19 | 
Grupa: Użytkownik
QTH: KO02OI
Posty: 7263 #8149450
Od: 2009-12-28
Ilość edycji wpisu: 3 | Takie objawy są gdy jakiś program w tle obciąża system. rts/dtr używane do kluczowania CW mają timing sterowany przez windowsa i stąd te chece.
Monitor zasobów i może znajdziesz który to.
Michał
_________________
***** ***
You can't have too many antennas...
 | | | | | SP9GFY | 30.01.2024 23:54:43 | Grupa: Użytkownik
Posty: 6 #8149460
Od: 2012-9-22
| sp5it pisze:
Takie objawy są gdy jakiś program w tle obciąża system. rts/dtr używane do kluczowania CW mają timing sterowany przez windowsa i stąd te chece.
Monitor zasobów i może znajdziesz który to.
Michał
Witam Michał i dziękuję za podowiedź.
Obserwuję ten monitor ale na razie niczego nie znalazłem.
Już wcześniej co mogłem to powywalałem i nic sie nie zmieniało.
Będę szukał dalej.
Dziękuję Ci serdecznie.
Heniek
| | | | | SN9MT | 31.01.2024 06:23:56 | 
Grupa: Użytkownik
Posty: 57 #8149490
Od: 2019-4-12
| Windows działa w multitaskingu i takie objawy prawdopodobnie występowały zawsze od kiedy pojawiły się pierwsze wersje tego, jak to niektórzy piszą "systemu". Dlatego zaczęto wymyślać i produkować różne keyery zewnętrzne. Wtedy program wysyła ciąg znaków do keyera a dopiero to sprytne urządzonko kluczuje radio. Jak widać na Twoim przypadku przez długi czas może być dobrze aż nagle któregoś dnia po jakiejś aktualizacji - zonk. Po prostu z Win nie znasz dnia ani godziny.
Pozdrawiam Mirek SN9MT | | | | | djbpm | 31.01.2024 08:58:45 | 
Grupa: Użytkownik
Posty: 367 #8149548
Od: 2018-8-31
| Dawno temu rozwiązywałem podobny problem, tylko przy przetwarzaniu dźwięku na żywo. Użyłem do tego aplikacji LatencyMon. Udało mi się zidentyfikować sterownik, który powodował przycinanie. Szczegółów już nie pamiętam, ale może znajdziesz jakieś poradniki do tego programu i może coś się uda nim znaleźć. | | | | | SP9GFY | 31.01.2024 10:40:32 | Grupa: Użytkownik
Posty: 6 #8149578
Od: 2012-9-22
| SN9MT pisze:
Windows działa w multitaskingu i takie objawy prawdopodobnie występowały zawsze od kiedy pojawiły się pierwsze wersje tego, jak to niektórzy piszą "systemu". Dlatego zaczęto wymyślać i produkować różne keyery zewnętrzne. Wtedy program wysyła ciąg znaków do keyera a dopiero to sprytne urządzonko kluczuje radio. Jak widać na Twoim przypadku przez długi czas może być dobrze aż nagle któregoś dnia po jakiejś aktualizacji - zonk. Po prostu z Win nie znasz dnia ani godziny.
Pozdrawiam Mirek SN9MT
Tak Mirku. Masz rację. Microsoft dba o to abyśmy nie popadli w rutynę i abyśmy zawsze musieli zajmować sie jego produktem.
Szkoda, że tego czasu nie możemy poświęcić na to, czym chcemy się zajmować.
| | | | | SP9GFY | 31.01.2024 10:42:54 | Grupa: Użytkownik
Posty: 6 #8149580
Od: 2012-9-22
| djbpm pisze:
Dawno temu rozwiązywałem podobny problem, tylko przy przetwarzaniu dźwięku na żywo. Użyłem do tego aplikacji LatencyMon. Udało mi się zidentyfikować sterownik, który powodował przycinanie. Szczegółów już nie pamiętam, ale może znajdziesz jakieś poradniki do tego programu i może coś się uda nim znaleźć.
Dziękuję serdecznie za podpowiedź.
Program ściągnąłem, zainstalowałem i testuję. Na razie bez pozytywnych efektów.
Pozdrawiam,
Heniek
| | | | | SP9GFY | 31.01.2024 11:46:51 | Grupa: Użytkownik
Posty: 6 #8149616
Od: 2012-9-22
| Wydaje mi się, że przynajmniej na tą chwilę mam problem rozwiązany i spokojnie mogę pość pod prysznic i ogolić się.... hi
TI-3000 "tworzy" miedzy innymi port do obsługi CW i PTT.
W zaawansowanych ustawieniach tego portu wyłączyłem "Selective Suspend". Idle Timeout był ustawiony właśnie na te 10s
czyli okres występowania problemu.
Jeden temat wydaje się być załatwiony. Pozostałych 100 czeka na swoja kolej.... hi
Dziękuje Koledzy. Pomogły obserwacje zarówno monitora zasobów jak również programu LatencyMon.
Pozdrawiam Was wszystkich bardzo serdecznie i życzę wielu sukcesów i zadowolenia z nich.
73's, Heniek
| | | | | janeksp6 | 08.03.2024 13:42:45 |
Grupa: Użytkownik
QTH: W-ch JO80dt
Posty: 295 #8161324
Od: 2018-11-7
Ilość edycji wpisu: 1 | SP9GFY pisze:
Witam serdecznie Kolegów
i proszę o podpowiedź, pomoc w rozwiązaniu mojego problemu.
Nadawanie na CW niezależnie czy spod Loggera czy też N1MM nie działa prawidłowo.
Co kilka sekund coś (chyba zajmuje port) i w zależności co jest aktualnie nadawane albo wydłuża kreskę albo wydłuża przerwę między znakami. Niezależnie które są to przerwy.Jak trafi.
W teście trwającym minutę, to coś występuje 6 razy.
Niezależnie od szybkości nadawania to coś trwa mniej więcej sekundę.
W październiku ubiegłego roku coś stało się z systemem (Win10) w skutek moich zabaw z Avast Driver Updater.
Zakupiłem nowy dysk, pozostałe powypinałem i postawiłem system od nowa. Od nowa, aby było na czysto" w pełnych wersjach zainstalowałem Logger32 v.4 , WSJT-x, N1MM+. Sądziłem, że coś sie pomieszało w systemie.
No i tak chyba będzie, że jest to któryś z nowych driverów lub innych aktualizacji.
Tylko jak to Koledzy znaleźć i zabić? To jest właśnie moja prośba do Was.
Konfiguracja sprzętowa nie zmieniła się. PC z Win10 + K3 + TI-3000.
Szybkości transmisji czy bity stopu, bity danych, parzystość to wszystko posprawdzałem. Zawsze było tak jak jest teraz.
Pozdrawiam,
Heniek SP9GFY
73's
@ SP9GFY
Otwórz Panel sterowania i Opcje zasilania ( zas.baterią, zas.sieciowe ustaw na nigdy
| | | | | SP9IT | 09.03.2024 09:41:02 |
Grupa: Użytkownik
QTH: KN09IO
Posty: 520 #8161440
Od: 2016-4-7
Ilość edycji wpisu: 4 | SN9MT pisze:
Windows działa w multitaskingu i takie objawy prawdopodobnie występowały zawsze od kiedy pojawiły się pierwsze wersje tego, jak to niektórzy piszą "systemu". Dlatego zaczęto wymyślać i produkować różne keyery zewnętrzne.
Windows od Win NT jest systemem bez cudzysłowu, i z tym nie ma dyskusji. Można dyskutować, że do Win98 był opcjonalną nakładka.
Diagnozę problemu przedstawiasz źle. Rdzeń problemu jest inny.
Microsoft Windows NIE JEST systemem czasu rzeczywistego, zresztą tak samo jak św. system od Linusa, Kleta, Klemensa choćby natchnieni apostołowie tak przedstawiali różnice (krawaciarze z jabłuszkiem też)
Pojawienie się sytuacji braku natychmiastowej odpowiedzi np na klucz telegraficzny, ale dowolny czynnik który by należało szybko obsłużyć, nie jest kwestią "czy" ale liczbową.
Wbrew temu co piszesz, to dlatego zaczęto wymyślać keyery, i inne sprzętowe bufory, które dają szybki odzew. To nie zemsta nad Windowsem, ale nad wszystkimi systemami konsumenckimi, one takie są (i jest to uzasadnione)
Nie tylko w krótkofalarstwie.
Nawet usługi dźwiękowe/YT itd choć mają najwyższy priorytet, też miewają czkawkę, jak coś intensywnego sie w komputerze dzieje.
W ostatnim czasie z kumplem analizujemy webowe CW serwisy, one również nie są w stanie wytrzymać timingu klucza (w optymistycznych warunkach trzymają się w ryzach)
BTW amerykańskie wirtualne kluby CW wykluczają sztorce i bugi, dozwolone tylko double paddle i (single) sidesweepery. Do przemyślenia dlaczego.
ps. definicja https://pl.wikipedia.org/wiki/System_operacyjny_czasu_rzeczywistego
Aha, warto dodać, że i ten SYSTEM (coś, co integruje wiele konkurujących procesów / działań), też nie gwarantuje "natychmiast" a tylko "w zdefniowanym czasie", i nie bedzie bardziej reaktywny od bare metal (znów: z wykluczeniem programowania arduino na delayach - mówię o bare matal na przerwaniach)
_________________
Jacek SP9IT | | | | | Piotrek76 | 09.03.2024 20:43:58 |
Grupa: Użytkownik
Posty: 60 #8161573
Od: 2021-1-22
Ilość edycji wpisu: 1 | SP9IT pisze: SN9MT pisze:
Windows działa w multitaskingu i takie objawy prawdopodobnie występowały zawsze od kiedy pojawiły się pierwsze wersje tego, jak to niektórzy piszą "systemu". Dlatego zaczęto wymyślać i produkować różne keyery zewnętrzne.
Windows od Win NT jest systemem bez cudzysłowu, i z tym nie ma dyskusji. Można dyskutować, że do Win98 był opcjonalną nakładka.
Diagnozę problemu przedstawiasz źle. Rdzeń problemu jest inny.
Microsoft Windows NIE JEST systemem czasu rzeczywistego, zresztą tak samo jak św. system od Linusa, Kleta, Klemensa choćby natchnieni apostołowie tak przedstawiali różnice (krawaciarze z jabłuszkiem też)
Pojawienie się sytuacji braku natychmiastowej odpowiedzi np na klucz telegraficzny, ale dowolny czynnik który by należało szybko obsłużyć, nie jest kwestią "czy" ale liczbową.
Wbrew temu co piszesz, to dlatego zaczęto wymyślać keyery, i inne sprzętowe bufory, które dają szybki odzew. To nie zemsta nad Windowsem, ale nad wszystkimi systemami konsumenckimi, one takie są (i jest to uzasadnione)
Nie tylko w krótkofalarstwie.
Nawet usługi dźwiękowe/YT itd choć mają najwyższy priorytet, też miewają czkawkę, jak coś intensywnego sie w komputerze dzieje.
W ostatnim czasie z kumplem analizujemy webowe CW serwisy, one również nie są w stanie wytrzymać timingu klucza (w optymistycznych warunkach trzymają się w ryzach)
BTW amerykańskie wirtualne kluby CW wykluczają sztorce i bugi, dozwolone tylko double paddle i (single) sidesweepery. Do przemyślenia dlaczego.
ps. definicja https://pl.wikipedia.org/wiki/System_operacyjny_czasu_rzeczywistego
Aha, warto dodać, że i ten SYSTEM (coś, co integruje wiele konkurujących procesów / działań), też nie gwarantuje "natychmiast" a tylko "w zdefniowanym czasie", i nie bedzie bardziej reaktywny od bare metal (znów: z wykluczeniem programowania arduino na delayach - mówię o bare matal na przerwaniach)
Do tego dochodzi sama natura portów COM - to nie są gniazda z pinami GPIO tylko interfejs do komunikacji szeregowej. Port COM nigdy nie był przeznaczony do takich rzeczy jak ręczne sterowanie poszczególnymi pinami, ale w czasach gdy sprzętowo na płycie siedział scalak UART 8250 wymagający "ręcznej" obsługi transmisji, to się dało trickowo wykorzystywać RTS i DTR (czyli linie sprzętowo sterujące komunikacją i informujące drugą stronę czy ma nadawać, czy nie) - to działało, bo ten scalak miał jednobajtowy bufor (a potem w UART 16550 doszły dwa bufory maksymalnie 16-bajtowe, ale można było tego scalaka przerzucić w tryb kompatybilności z 8250 i bufor jednobajtowy). Obecnie porty COM działają inaczej (nie ma bezpośredniego ręcznego sterowania pinami przez program z userspace, drivery buforują dane i jeśli program wyśle "wstrzymaj przyjmowanie danych" to niekoniecznie oznacza natychmiastowe wstrzymanie komunikacji przez odpowiednie piny RTS/DTR, bo scalak ma swój własny bufor i driver też).
To trochę jak z piórem świetlnym w komputerach - wykorzystywało zjawisko, że stare monitory wyświetlały obraz punkt o punkcie i natychmiast po odebraniu tego sygnału z komputera (sygnał z komputera był bezpośrednio wykorzystywany do sterowania wiązką z katody w kineskopie), ale współczesne monitory komputerowe już tak nie działają, nawet analogowy sygnał jest buforowany i nie ma już zapalania punktów na ekranie pixel po pixelu (i stan piksela na ekranie nie zmienia się natychmiast po tym jak komputer wyśle jego dane). Pióro świetlne przestało działać, bo bazowało na specyficznej konstrukcji hardware dawnych monitorów i korzystało z efektów ubocznych nie objętych specyfikacją.
Stare rozwiązywania keyerów CW wykorzystywały fakt, że scalaki w komputerze miały bardzo mały bufor (a więc częste generowanie przerwania i zmiana stanu RTS/DTR sterującego przepływem odbywała się natychmiast - to był efekt uboczny a nie "dobroć" układu czy systemu operacyjnego). Współczesne implementacje portów COM nie mają problemu małych buforów i konieczności ręcznego sterowania transmisją, więc nie można obecnie bazować na efektach ubocznych tych zjawisk (które tak naprawdę były wadami tych portów). Tu nawet system czasu rzeczywistego by nie pomógł, zmieniła się konstrukcja i zasada działania portów COM (choć specyfikacja się nie zmieniła, to zmieniła się implementacja). | | | | | Electra | 27.04.2024 12:11:24 |
|
| | | | | SP9IT | 10.03.2024 12:25:58 |
Grupa: Użytkownik
QTH: KN09IO
Posty: 520 #8161614
Od: 2016-4-7
Ilość edycji wpisu: 1 | Piotrek76 pisze:
Do tego dochodzi sama natura portów COM ... Port COM nigdy nie był przeznaczony do takich rzeczy jak ręczne sterowanie poszczególnymi pinami ...
Tu nawet system czasu rzeczywistego by nie pomógł, zmieniła się konstrukcja i zasada działania portów COM...
Dzięki za te wyjaśnienia / przypomnienia.
Kupę ważnych myśli podałeś
_________________
Jacek SP9IT |
 | Strona: 1 / 1 strony: [1] |
| << Pierwsza | < Poprzednia | Następna > | Ostatnia >> |
| Aby pisac na forum musisz sie zalogować !!! |
|
FILMY VIDEO