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

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

No to co? Pokaż coś, co miałoby uniemożliwić pracę w takich warunkach.

No i to działało - używałem w pewnym momencie V.22 na takich łączach.

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

Tym niemniej to działało.

>> Wciąż znacznie więcej niż 20 ms.
>
> Kabel chyba mniej.

Jakim cudem?
Odpal sobie choćby google maps. Warszawa - Boston to ponad 6500 km.
Razy 2 (round trip time) = 13000 km. Nawet z prędkością światła w próżni
to zajmie ponad 40 ms. A realnie, prędkość światła w światłowodzie,
kabel raczej nie leży na kole wielkim itd. Pomnóż przez 2 albo 3.

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

Swobodnie mógł mieć. Dlaczego nie? Najmniejsza (realistycznie) pamięć
w tamtych czasach to było 6116, 2 KB RAM. W czasach Rockwelli V.32b
pewnie znacznie więcej.
Tak czy owak, działało - to chyba dowodzi, że mogło?
Obawiam się, że V.32bis też działało na połączeniach satelitarnych,
przypuszczalnie V.34 także (to już dość dawno temu było).
--
Krzysztof Hałasa

do góry

W dniu 16.08.2022 o 00:39, J.F. pisze:

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

RTS/CTS to właśnie do sterowania przepływem.

do góry

On Tue, 16 Aug 2022 17:46:59 +0200, Krzysztof Halasa wrote:
> "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.

No wlasnie ... wiec powinien byc przeniesiony do nowoczesnych modemow?

>> 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.

No wlasnie - do half duplexu. Modem ma powiadomic kiedy jest gotow
do nadawania ... i jakos nie napisali, ze moze przerwac swoją
gotowosc.

Choc juz w wersji 1988
https://www.itu.int/rec/T-REC-V.24/en

pojawil sie flow control przy pomocy tej linii.

Wczesniejsze wersje to chyba w bibliotece, ale
-stary modem w zasadzie nie ma po co przerywac transmisji,
dopiero przy kompresji sie pojawila potrzeba,

-w starych protokolach łacznosci modem-modem druga strona nie miala
jak zasygnalizowac niegotowosci. Nie bylo przewidziane.
Dopiero chyba gdzies przy korekcji błędow mogło sie cos pojawic.

-ale jak mialby drugi DTE powiadomic, ze chce przerwy?
sygnal DTR do czego innego sluzy.

J.

do góry

W dniu 10.08.2022 o 22:42, Adam pisze:

>
> Bamki VoIP miewały ustawianie kodeka.
> OIDP do głosu (czyli telefonu) to najczęściej się wybierało właśnie G711a,
> natomiast do faksu G723.
>

Do faksów/modemow są dwa i tylko dwa kodeki: G.711 czyli std strumień
PCM 8bit, żaden bit nie wypada, zero kompresji, ale kosztem pasma, 64kbit/s
Jest też drugi, dedykowany kodek do faksu, T.38
Bramki voip można skonfigurować z opcją Pass-Through. Czyli w defaulcie
idzie jakimś kodekiem z kompresją (żeby oszczędzić pasmo), a jak bramka
wykryje piski faxu, to robi renegocjację (re-INVITE) połaczenia z T.38 w
sekcji SDP. Można tez ustawić żeby w przypadku wykrycia transmisji robić
re-INVITE ze zmianą kodeka do G.711.

Każdy inny kodek jest dedykowany do głosu, bo robi kompresję stratną,
czasem jest silece supression (jak cisza, to nie idzie żaden pakiet
RTP). Faxy i modemy na takich kodekach nie przejdą.

> Swego czasu bawiłem się w wysyłanie danych faksem. Program na komputerze
> kodował coś, drukowało się to na papierze A4 (jedna kartka lub więcej) -
> przypominało to QRCode całostronicowe. Wysyłało się faksem, a później
> skanowało, aby zdekodować pierwotne dane.
> Nawet nie wiem, czemu służyły takie kołomyje.
>
> W każdym razie mam na bramce faksowej ustawienie G723 (Cisco SPA 2102) a na
> drugim porcie dla telefonu G711a.
>
A bramka Cisco miała Pass-Through i robiła re-INVITE na G.711 albo T.38.
Innej opcji nie ma.



> Może, jeśli u Piotrka da się wymusić jakiś faksowy kodek, to i modemy się
> prawidłowo spikną?
>
> j.w.

--
viktorius

do góry

On Thursday, August 18, 2022 at 6:26:06 AM UTC-7, viktorius wrote:
> Do faksów/modemow są dwa i tylko dwa kodeki: G.711 czyli std strumień
> PCM 8bit, żaden bit nie wypada, zero kompresji, ale kosztem pasma, 64kbit/s
> Jest też drugi, dedykowany kodek do faksu, T.38

Próbowałem z T38 i nic.
Chip modemu w urządzeniu to 73K212AL
(https://datasheetspdf.com/pdf-file/1196373/TDK/73K2
12AL/1). To jest modem Bell 212A / 103 (czyli 1200 DPSK / 300 FSK). Ma duplex i inne
bajery. Stąd dziwie się, czemu takie robi problemy ze zgraniem się np. z US Robotics.
Swoją drogą, na V21/V22 (czyli wersje CCITT tych prędkości) też się zdzwania, ale (1)
pewności na 100% nie mam co faktycznie się dzieje i (2) - V21 działa jakby gorzej.

No nic, będe próbował jeszcze. Możliwości są 3, na logikę: uszkodzenie w urządzeniu,
zły modem, zły kanał komunikacyjny.
1. Mam drugi taki automat, ale żeby się połączyć, trzeba zresetować ustawienia (w tym
hasło). Nie chcę tego robić, bo jako tako działa, a jak zresetuję - będzie
bezużyteczne do czasu zaprogramowania. Dane trzymane są w pamięci EEPROM
przylutowanej do płytki. W pierwszym urządzeniu pamięć wyciąłem, zczytałem i
wlutowałem nową przez podstawkę - być może doszło do jakiegoś uszkodzenia, mistrzem
lutownicy nie jestem, aczkolwiek przedzwoniłem wszystkie linie adresowe i danych do
CPU (Zilog Z180).
2. Tutaj już tracę nadzieje, próbowałem różnych ustawień flow control, prędkości
samego łącza. Jedyna nadzieja jeszcze w uruchomieniu "prawdziwego" PC 486 z win95,
tam też mam kolejny USR - wewnętrzny. Ale chwilowo czeka na zasilacz, a nie wiem co
jeszcze będzie uszkodzone.
3. Para modemów fizycznych łączy się na 9600 i działa ładnie, jak wspomniałem, więc
raczej nie podejrzewam. Aczkolwiek w akcie desperacji mogę wyknuć coś analogowego dla
pewności.

pozdrawiam

do góry

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

> No wlasnie - do half duplexu. Modem ma powiadomic kiedy jest gotow
> do nadawania ... i jakos nie napisali, ze moze przerwac swoją
> gotowosc.

Bo nie było takiego scenariusza. DTE transmitował tak długo, jak chciał.
Zresztą dokładnie tak się tego używa z typowymi liniami RS-485
(np. z konwerterami RS-232 <> RS-485 i/lub ze specjalnymi kartami,
typowo ze scalakami Oxforda, które robią HD sprzętowo).

> -w starych protokolach łacznosci modem-modem druga strona nie miala
> jak zasygnalizowac niegotowosci. Nie bylo przewidziane.

Nie było przydatne. Dlaczego terminal miałby nie być gotowy? Albo
komputer? Terminale potrafiły wyświetlać z pełną szybkością 9600 bps,
komputery tym bardziej, miały długie bufory itd.
Oczywiście gotowość w sensie "bycia włączonym" itp. sygnalizował DTR
(nie było go w oryginalnym RS-232, chociaż był DSR - aka "interlock").

> -ale jak mialby drugi DTE powiadomic, ze chce przerwy?
> sygnal DTR do czego innego sluzy.

Gdy tego typu zagadnienia stały się realnymi, wprowadzono handshaking
RTS/CTS. Aczkolwiek DTE zwykle są w stanie odbierać dane zawsze - modemy
mogą potrzebować przerywać transmisję. W gruncie rzeczy wystarcza do
tego CTS.
--
Krzysztof Hałasa

do góry

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

> Próbowałem z T38 i nic.
> Chip modemu w urządzeniu to 73K212AL
> (https://datasheetspdf.com/pdf-file/1196373/TDK/73K2
12AL/1). To jest
> modem Bell 212A / 103 (czyli 1200 DPSK / 300 FSK). Ma duplex i inne
> bajery. Stąd dziwie się, czemu takie robi problemy ze zgraniem się np.
> z US Robotics.

Jeden z modemów (lub oba) może mieć zablokowane niektóre wersje,
np. Bella albo ITU-T. To było dość typowe. Można oczywiście odblokować -
szczegóły powinny być w instrukcji obsługi.

> No nic, będe próbował jeszcze. Możliwości są 3, na logikę: uszkodzenie
> w urządzeniu, zły modem, zły kanał komunikacyjny.

Można ew. popatrzeć oscyloskopem na fizycznych liniach.
Albo użyć adaptera RS-232 - USB, najlepiej chyba ze scalakiem FTDI
(niepodrobionym), i "podsłuchać" co i kiedy jest tam przesyłane.
--
Krzysztof Hałasa

do góry

On Thu, 18 Aug 2022 23:08:47 +0200, Krzysztof Halasa wrote:
> "J.F" <j...@p...onet.pl> writes:
>> No wlasnie - do half duplexu. Modem ma powiadomic kiedy jest gotow
>> do nadawania ... i jakos nie napisali, ze moze przerwac swoją
>> gotowosc.
>
> Bo nie było takiego scenariusza. DTE transmitował tak długo, jak chciał.
> Zresztą dokładnie tak się tego używa z typowymi liniami RS-485
> (np. z konwerterami RS-232 <> RS-485 i/lub ze specjalnymi kartami,
> typowo ze scalakami Oxforda, które robią HD sprzętowo).
>
>> -w starych protokolach łacznosci modem-modem druga strona nie miala
>> jak zasygnalizowac niegotowosci. Nie bylo przewidziane.
>
> Nie było przydatne. Dlaczego terminal miałby nie być gotowy? Albo
> komputer? Terminale potrafiły wyświetlać z pełną szybkością 9600 bps,
> komputery tym bardziej, miały długie bufory itd.

A jak drukarka?

> Oczywiście gotowość w sensie "bycia włączonym" itp. sygnalizował DTR
> (nie było go w oryginalnym RS-232, chociaż był DSR - aka "interlock").
>
>> -ale jak mialby drugi DTE powiadomic, ze chce przerwy?
>> sygnal DTR do czego innego sluzy.
>
> Gdy tego typu zagadnienia stały się realnymi, wprowadzono handshaking
> RTS/CTS. Aczkolwiek DTE zwykle są w stanie odbierać dane zawsze - modemy
> mogą potrzebować przerywać transmisję. W gruncie rzeczy wystarcza do
> tego CTS.

ale ja o czym innym. mamy łąńcuch
DTE1 - DCE1 - DCE2 - DTE2

DTE1 wysyla dane, DTE2 odbiera. DTE2 ma danych za duzo i chce
zatrzymac naplyw ... i jak ma to zrobic, skoro ma dwie linie sterujace
wyjsciowe, DTR i RTS.
Ktorej użyc ?



J.

do góry

On Thu, 18 Aug 2022 08:23:07 -0700 (PDT), Piotr C. wrote:
> On Thursday, August 18, 2022 at 6:26:06 AM UTC-7, viktorius wrote:
>> Do faksów/modemow są dwa i tylko dwa kodeki: G.711 czyli std strumień
>> PCM 8bit, żaden bit nie wypada, zero kompresji, ale kosztem pasma, 64kbit/s
>> Jest też drugi, dedykowany kodek do faksu, T.38
>
> Próbowałem z T38 i nic.
> Chip modemu w urządzeniu to 73K212AL
> (https://datasheetspdf.com/pdf-file/1196373/TDK/73K2
12AL/1). To
> jest modem Bell 212A / 103 (czyli 1200 DPSK / 300 FSK). Ma duplex i
> inne bajery. Stąd dziwie się, czemu takie robi problemy ze zgraniem
> się np. z US Robotics. Swoją drogą, na V21/V22 (czyli wersje CCITT
> tych prędkości) też się zdzwania, ale (1) pewności na 100% nie mam
> co faktycznie się dzieje i (2) - V21 działa jakby gorzej.

modemy V. i Bell sa nieco rozne. Jedno z drugim nie zadziala,
ale prawdziwy modem, w szczegolnosci USR, powinien miec oba.
I podejrzewam, ze dzialaja, skoro dostajesz komunikat Connect.

> No nic, będe próbował jeszcze. Możliwości są 3, na logikę:
> uszkodzenie w urządzeniu, zły modem, zły kanał komunikacyjny.
> 1. Mam drugi taki automat, ale żeby się połączyć, trzeba zresetować
> ustawienia (w tym hasło). Nie chcę tego robić, bo jako tako działa,
> a jak zresetuję - będzie bezużyteczne do czasu zaprogramowania.
> Dane trzymane są w pamięci EEPROM przylutowanej do płytki. W
> pierwszym urządzeniu pamięć wyciąłem, zczytałem i wlutowałem nową
> przez podstawkę - być może doszło do jakiegoś uszkodzenia, mistrzem
> lutownicy nie jestem, aczkolwiek przedzwoniłem wszystkie linie
> adresowe i danych do CPU (Zilog Z180).

> 2. Tutaj już tracę nadzieje,
> próbowałem różnych ustawień flow control, prędkości samego łącza.
> Jedyna nadzieja jeszcze w uruchomieniu "prawdziwego" PC 486 z
> win95, tam też mam kolejny USR - wewnętrzny. Ale chwilowo czeka na
> zasilacz, a nie wiem co jeszcze będzie uszkodzone.
> 3. Para modemów
> fizycznych łączy się na 9600 i działa ładnie,

Przez VoIP ?

> jak wspomniałem, więc
> raczej nie podejrzewam. Aczkolwiek w akcie desperacji mogę wyknuć
> coś analogowego dla pewności.

Jesli ma te kosc co piszesz, to raczej 1200 lub 300 ..

J.



>
> pozdrawiam

do góry

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

>> Nie było przydatne. Dlaczego terminal miałby nie być gotowy? Albo
>> komputer? Terminale potrafiły wyświetlać z pełną szybkością 9600 bps,
>> komputery tym bardziej, miały długie bufory itd.
>
> A jak drukarka?

To naciskasz ^P co stronę :-)
Aczkolwiek rzeczywiście drukarka mogłaby robić XON/XOFF (zamiast
RTS/CTS). Taka np. D-100 (model z RS-232), nie pamiętam jak to było.

> ale ja o czym innym. mamy łąńcuch
> DTE1 - DCE1 - DCE2 - DTE2
>
> DTE1 wysyla dane, DTE2 odbiera. DTE2 ma danych za duzo i chce
> zatrzymac naplyw ... i jak ma to zrobic, skoro ma dwie linie sterujace
> wyjsciowe, DTR i RTS.
> Ktorej użyc ?

Zwyczajnie. DTE2 zdejmuje RTS, DCE2 przestaje wysyłać, zapełnia mu się
bufor, V.42(bis) -> DCE1 nie wysyła, zdejmuje CTS, DTE1 przestaje
wysyłać. To tak działa od ponad 30 lat. Oczywiście były drobne problemy,
np. układy 8250/8251/16450/wczesne 16550 nie potrafiły odpowiednio
wcześnie zdjąć RTS, albo wysyłały znak dwukrotnie, ale generalnie nie ma
z tym problemu.

No i realistycznie, każdy DTE ma bufory wystarczająco długie, by się w
praktyce nie kończyły.
--
Krzysztof Hałasa

do góry