"Piotr C." <k...@g...com> writes:

> 2. Modem US Robotics zewnętrzny 33k6 nie działa - łączy się (tylko na
> wymuszonym 300bps, na 1200 nie chce gadać lub rzadko) natomiast nawet
> podając dobry pin, brak jest odpowiedzi urządzenia - taki sam efekt
> jak podanie błędnego PINu. Być może są duże przekłamania i automat
> odczytuje błędny pin, a może nie słyszy niczego.

Rozumiem że nie ma możliwości "podsłuchania" po drugiej stronie?
Korzystne może być przejrzenie instrukcji od USRa i pokombinowanie.
Np. ustawienia handshakingu.
Co dokładnie jest po "naszej" stronie? Pecet z Windows?
Czy modem po drugiej stronie jest na pewno dobrze skonfigurowany?

> Czyli jako tako działa tylko badziewny winmodem na USB, który dostałem
> przez pomyłkę sprzedającego. Natomiast przy dłuższej transmisji
> (wysłanie taryf i konfiguracji) występuje zawsze błąd.

Handshaking?
Najlepiej wyłączyć XON/XOFF ("software handshaking" - w modemie i na
pececie).
Modem może mieć kilka profili (at&f0, at&f1, czy jakoś tak, to już dawno
było), które od razu ustawiają cały komplet parametrów. Ale to trzeba
sprawdzić w dokumentacji.

Najlepiej używać sprzętowego handshakingu (RTS/CTS), modem na pewno to
umie (po włączeniu), ale czy w tym programie da się tego użyć, to nie
wiem.
W ogóle bez handshakingu modemy będą gubić większe porcje danych - jeśli
tylko soft po obu stronach takich używa (bez potwierdzeń w trakcie).

> Nie wiem, może
> uwalona płyta główna, bo też wywala błąd na rządanie zapisania RAMu do
> EPROMu?

Płyta główna (raczej jedyna) modemu?
Raczej do EEPROMu, ew. do flasha (flash ((E)EP)ROMu).

> Drugi US Robotics, typowy z rynku USA, nie współpracuje w ogóle i
> bardzo dziwna sprawa - zainstalowałem sniffer szeregowy. Program na
> początek wysyła do modemu "+++" i "ATZ" (reset) i modem nie odpowiada.
> Natomiast z tej samej maszyny wirtualnej, jeśli wpiszę ATZ w hyperterm
> - ładnie odpowiada "OK" i generalnie działa idealnie.

Może to być ustawienie handshakingu - modem ma wyłączony CRTSCTS
(a dokładnie nie wystawia CTS), pecet bez tego nie chce wysyłać. Można
włączyć hw handshaking w modemie.

Alternatywnie może modem nie wystawia DSR, wtedy pecet może uważać, że
w ogóle żadnego modemu nie ma -> trzeba włączyć wysyłanie DSR w modemie.

Albo inne podobne kombinacje w rodzaju ustawienia CTS i DSR na stałe.

Aaa, i jeszcze może to być brak przerwy pomiędzy "+++" i ATZ - nie wiem
jaki program miałby tak robić, ale efekt mógłby być podobny. Po "+++"
musi być chwila przerwy, chyba był na to S-rejestr. Możliwe, że
producent winmodemu nie zapłacił za licencję Hayesowi czy coś tam,
i działa bez przerwy, ale nie powinno (modem nie może szukać poleceń
w treściach tylko przesyłanych przez niego).

Można też wrócić do ustawień fabrycznych (i zapisać je) itp. Możliwe że
to at&f1 oraz at&w?

Nie wiem jaki to dokładnie USR, ale generalnie one nie sprawiały
problemów, oczywiście jeśli były dobrze skonfigurowane. Oprócz jakichś
tam USR Winmodemów, które nie miały DSP, i robiły wszystko procesorem
peceta (przypuszczalnie). A może miały DSP, tylko nie miały interfejsu
Hayesa?
--
Krzysztof Hałasa

do góry

"Piotr C." <k...@g...com> writes:

> Mam jeszcze inny pomysł, do daleszego przemyślenia. Bramka działa z
> kodekiem G711 i generalnie jakość jest naprawde dobra na ucho.

A, to ładnie.

> Natomiast pomysł jest taki - spieprzyć ustawienia tak, by nie było w
> ogóle słyszalności. Następnie sprzęgnąć obie linie przy pomocy
> kondensatorów 1uF - w ten sposób powstanie centralka "analogowa" -
> użyjemy tylko źródeł prądowych z bramki i prądu dzwonienia.

W ogóle nie myślałbym o takich rzeczach. To powinno działać normalnie.
I podejrzewam, że powinno - trzeba tylko odpowiednio ustawić.
--
Krzysztof Hałasa

do góry

On Thu, 11 Aug 2022 08:54:57 -0700 (PDT), Piotr C. wrote:
> Drugi US Robotics, typowy z rynku USA, nie współpracuje w ogóle i
> bardzo dziwna sprawa - zainstalowałem sniffer szeregowy. Program na
> początek wysyła do modemu "+++" i "ATZ" (reset) i modem nie
> odpowiada. Natomiast z tej samej maszyny wirtualnej, jeśli wpiszę
> ATZ w hyperterm - ładnie odpowiada "OK" i generalnie działa
> idealnie.

Byc moze modem jest skonfigurowany jakos na stałe na inna predkosc.
Był tam jakis "full reset".

Druga sprawa - po tych +++ powinna byc sekunda przerwy.
I przed chyba tez.

Jesli program tego nie robi, to modem powinien +++ zignorowac.

Kolejna sprawa - ilosc bitow, parzystosc na porcie.
Automat moze sie czegos kontretnego domagac.

J.

do góry

On Wed, 10 Aug 2022 19:42:28 +0200, Krzysztof Halasa wrote:
> "J.F" <j...@p...onet.pl> writes:
>> Aaa - moze tez tak byc, ze automat wymaga konkretnej predkosci na tym
>> modemie, i na innej nie odpowie, nawet jak sie modemy połączą.
>
> Możliwe, ale mało prawdopodobne.
> Generalnie było tak, że albo modem robił buforowanie, i wtedy port był
> ustawiony "szybko" (9600 bps dla modemów 2400 bps, 19200 dla 9600, 38400
> i szybciej dla 14400+), albo buforowania nie robił, i wtedy port musiał
> być ustawiony zgodnie z szybkością transmisji między modemami.
> Smart modemy miały typowo opcję przestawiania szybkości portu po
> komunikacie "CONNECT xxx".

Jakbys mial porzadny modem i zainicjowany od strony portu RS232.

W "automacie" moze byc cos kompletnie nieuniwesalnego, i w dodatku
na konkretną predkosc.

J.

do góry

On Thu, 11 Aug 2022 17:41:22 +0200, Krzysztof Halasa wrote:
> "J.F" <j...@p...onet.pl> writes:
>> Na VoIP testowałes, czy przez satelite?
> Domyślam się, że to było przez satelitę, bo jeszcze wtedy VoIPów nie
> było, a opóźnienie z czegoś musiało wynikać.
>
>> Są tam dwa slabe punkty:
>> a) protokół nawiazania połączenia - są tam czasy po ktorych druga
>> strona ma zareagowac i cos zmienic
>
> Tak, ale to są dłuższe czasy. Nie jakoś dużo dłuższe, ale wystarczająco.

W ms liczone, o ile pamietam.
Satelita w 4 strony bedzie mial blisko pol sekundy.

> W przypadku tamtych transmisji, bo z VoIPem byłby większy margines.
> No i 300 bps jest ostatnie i trwa do "odłożenia słuchawki", więc tu
> w ogóle nie powinno być problemu - kwestia jedynie zgodności ustawionego
> standardu (Bell vs. ITU-T).
>
>> b) kompensacja parametrow łącza - w tym echa. I takie 20ms moze
>> rozwalic system :-)
>
> A gdzie tam jest coś takiego? @ 300 bps? :-)

W 300 nie ma, w wysokich jest.
A kolega nie podal predkosci.

> Modem 300 bps składa się w wersji minimalnej z przestrajanego
> genereratora (jeden, może dwa tranzystory sterowane bezpośrednio z linii
> TxD) oraz z detektora FSK (filtr dolno lub górno-przepustowy + "dioda"
> i tranzystor). Takiego nigdy nie widziałem, ale taki na 4 opampach
> (z dwoma filtrami pasmowymi) - owszem.

Od Atari?
Prawdziwe modemy jakos inaczej robione, choc w dawnych latach moze i
tak :-)

> Natomiast oczywiście szybsze modemy także działały na połączeniach m-n,
> w tym takich np. z USA itp. Nie pamiętam niestety kiedy to przestało iść
> przez satelitę - ale na pewno cały czas są to opóźnienia znacznie
> większe niż 20 ms.

Ale byly tez kable.

>> Ale tu nie o modem chodzi. Połaczenie sie koledze nawiązuje, czyli
>> negocjacja modemow przechodzi ... chyba.
>
> W wersji minimum @ 300 bps "negocjacja" sprowadza się do odbierania
> sygnałów "answer tone" oraz zmodulowanych mark/space, coś w stylu:
>
> A: ATDTxxxxx
> B: RING, ATA, answer tone
> A: (answer tone) -> CONNECT, space/mark z TxD do modulatora FSK.
> B: wykryty FSK -> CONNECT, wyłączenie answer tone, space/mark po
> demodulacji na linię RxD.

Tym niemniej ten answer tone musi byc, wiec modemy sie jakos łączą.

>> Tylko w automacie pewnie jakis procesor jest i łącznosc obsluguje.
>> I co ma wysłac? "Login:" ?
>
> Coś pewnie musi wysłać, albo może na coś czekać, ale to nie zależy od
> VoIPa lub jego braku.

No wlasnie o to chodzi - nic nie wysyla, czeka na tajny kod ...

>> W dodatku port moze miec ustawiony na konkretną predkosc,
>> a sam modem moze byc zubozony i predkosci nie konwertuje w locie.
>
> Nie musi. Wciąż brak zależności od VoIPa.

Ale to nie jest tak, ze przez VoIP nie dziala.

Kolega ma tylko VoIP, nie dziala, i nie wiadomo dlaczego :-)

J.

do góry

"J.F" <j...@p...onet.pl> writes:

> Jakbys mial porzadny modem i zainicjowany od strony portu RS232.
>
> W "automacie" moze byc cos kompletnie nieuniwesalnego, i w dodatku
> na konkretną predkosc.

No ale praktycznie wszystkie USRy, poza być może winmodemami (ale chyba
nie o taki chodzi), były porządnymi?

Natomiast mam wrażenie (być może mylne), że (w odróżnieniu od typowych
Rockwelli) at&f oznaczało tam xon/xoff, i dopiero at&f1 było "normalne".
Ale to było dawno, to tylko wrażenie.
--
Krzysztof Hałasa

do góry

"J.F" <j...@p...onet.pl> writes:

> W ms liczone, o ile pamietam.
> Satelita w 4 strony bedzie mial blisko pol sekundy.

Answer tone to są ms, owszem. Np. setki ms.
Praktyka: działało.
Teoria: być może opóźnienia nie miały znaczenie - w końcu answer tone
dochodził do "dzwoniącego" modemu, co z tego, że po jakimś czasie? Modem
go w końcu wykrywał i po problemie.

Dodam, że przy tego typu opóźnieniach działały także takie rzeczy jak
MNP2-5, V.42 i V.42bis.

Może po prostu ktoś to prawidłowo zaprojektował? :-)

>> W przypadku tamtych transmisji, bo z VoIPem byłby większy margines.

> W 300 nie ma, w wysokich jest.
> A kolega nie podal predkosci.

Coś tam podał chyba, 300 i 1200 bps?

>> Modem 300 bps składa się w wersji minimalnej z przestrajanego
>> genereratora (jeden, może dwa tranzystory sterowane bezpośrednio z linii
>> TxD) oraz z detektora FSK (filtr dolno lub górno-przepustowy + "dioda"
>> i tranzystor). Takiego nigdy nie widziałem, ale taki na 4 opampach
>> (z dwoma filtrami pasmowymi) - owszem.
>
> Od Atari?

Nie, raczej taki niezależny od komputera, z V.24 itd.

>> Natomiast oczywiście szybsze modemy także działały na połączeniach m-n,
>> w tym takich np. z USA itp. Nie pamiętam niestety kiedy to przestało iść
>> przez satelitę - ale na pewno cały czas są to opóźnienia znacznie
>> większe niż 20 ms.
>
> Ale byly tez kable.

Wciąż znacznie więcej niż 20 ms.
--
Krzysztof Hałasa

do góry

Dnia Fri, 12 Aug 2022 22:55:41 +0200, Krzysztof Halasa napisał(a):
> "J.F" <j...@p...onet.pl> writes:
>> Jakbys mial porzadny modem i zainicjowany od strony portu RS232.
>>
>> W "automacie" moze byc cos kompletnie nieuniwesalnego, i w dodatku
>> na konkretną predkosc.
>
> No ale praktycznie wszystkie USRy, poza być może winmodemami (ale chyba
> nie o taki chodzi), były porządnymi?

Kolega ma porzadny modem, ale co tam jest "w automacie" to nie wiemy.
Ja bym tam nie wsadzal "porzadnego", bo nie ma po co ..

> Natomiast mam wrażenie (być może mylne), że (w odróżnieniu od typowych
> Rockwelli) at&f oznaczało tam xon/xoff, i dopiero at&f1 było "normalne".
> Ale to było dawno, to tylko wrażenie.

Moze w AT&T xon/xoff jest "normalny" :-)

Bo IMO - sam RS-232 nie ma nic do sterowania przeplywem.
Tzn nic przewidzianego.

J.

do góry

On Fri, 12 Aug 2022 23:11:58 +0200, Krzysztof Halasa wrote:
> "J.F" <j...@p...onet.pl> writes:
>> W ms liczone, o ile pamietam.
>> Satelita w 4 strony bedzie mial blisko pol sekundy.
>
> Answer tone to są ms, owszem. Np. setki ms.
> Praktyka: działało.
> Teoria: być może opóźnienia nie miały znaczenie - w końcu answer tone
> dochodził do "dzwoniącego" modemu, co z tego, że po jakimś czasie? Modem
> go w końcu wykrywał i po problemie.
>
> Dodam, że przy tego typu opóźnieniach działały także takie rzeczy jak
> MNP2-5, V.42 i V.42bis.
>
> Może po prostu ktoś to prawidłowo zaprojektował? :-)

ale np V.22 protocol
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&sour
ce=web&cd=&cad=rja&uact=8&ved=2ahUKEwi2lIn8rMv5AhVHl
osKHQQ3CmsQFnoECAcQAQ&url=https%3A%2F%2Fwww.itu.int%
2Frec%2Fdologin_pub.asp%3Flang%3De%26id%3DT-REC-V.22
-198811-I!!PDF-E%26type%3Ditems&usg=AOvVaw1ZrcTf2jqZ
J1Df4_yPGdvZ

i tam na rysunkach widze czasy np 270+/-40 ms.
One akurat chyba bez znacznenia, bo to do sygnalizacji, ale sa tez
inne.

V.42 pewnie jeszcze bardziej skomplikowany, i jakies timeouty ma.

>>> W przypadku tamtych transmisji, bo z VoIPem byłby większy margines.
>
>> W 300 nie ma, w wysokich jest.
>> A kolega nie podal predkosci.
>
> Coś tam podał chyba, 300 i 1200 bps?

Na poczatku nie.

>>> Modem 300 bps składa się w wersji minimalnej z przestrajanego
>>> genereratora (jeden, może dwa tranzystory sterowane bezpośrednio z linii
>>> TxD) oraz z detektora FSK (filtr dolno lub górno-przepustowy + "dioda"
>>> i tranzystor). Takiego nigdy nie widziałem, ale taki na 4 opampach
>>> (z dwoma filtrami pasmowymi) - owszem.
>>
>> Od Atari?
>
> Nie, raczej taki niezależny od komputera, z V.24 itd.

Atari w magnetofonie uzywalo FSK, i taki detektor mialo.

>>> Natomiast oczywiście szybsze modemy także działały na połączeniach m-n,
>>> w tym takich np. z USA itp. Nie pamiętam niestety kiedy to przestało iść
>>> przez satelitę - ale na pewno cały czas są to opóźnienia znacznie
>>> większe niż 20 ms.
>>
>> Ale byly tez kable.
>
> Wciąż znacznie więcej niż 20 ms.

Kabel chyba mniej.

A gdzies tam jeszcze w wyzszych predkosciach wchodzilo kasowanie echa-
i watpie aby modem mial bufor na pol sekundy :-)

J.

do góry

"J.F." <j...@p...onet.pl> writes:

>> Natomiast mam wrażenie (być może mylne), że (w odróżnieniu od typowych
>> Rockwelli) at&f oznaczało tam xon/xoff, i dopiero at&f1 było "normalne".
>> Ale to było dawno, to tylko wrażenie.
>
> Moze w AT&T xon/xoff jest "normalny" :-)

No wiesz, pierwsze modemy nie robiły żadnego buforowania, ale xon/xoff
(^Q/^S i/lub scroll lock) służyły tam do wznowienia i zatrzymania
przewijania ekranu - a wcześniej drukowania. Więc to _był_ normalny
mechanizm. BTW ten mechanizm cały czas jest obecny np. w xtermie.

> Bo IMO - sam RS-232 nie ma nic do sterowania przeplywem.
> Tzn nic przewidzianego.

Oczywiście że RS-232 ma przewidziane "coś" do sterowania przepływem.
Nawet wersja z 1960 roku (2.1.6 Clear-to-Send Circuit).
Inną sprawą jest to, że wtedy to było używane z łączami half-duplex.
--
Krzysztof Hałasa

do góry