Nadawanie CW z "czkawką" pod Win10
    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).


  PRZEJDŹ NA FORUM