Como controlar programaticamente um modem?

Uma ferramenta que pode ajudar com o seu problema é o AT Command Tester Desktop App , um produto comercial ($ 9,95) com teste gratuito de 7 dias.

Este produto pode executar um script de comandos AT em sua guia "Modo Script", onde pode salvar e carregar o script do computador local.

Ele também possui um modo de linha de comando onde pode ser chamado por:

atc –port portname –script filename

A ferramenta também pode coletar e salvar logs de modem. Não tentei, pois não tenho um modem ou não conheço nenhum número para ligar, mas se os logs forem salvos como arquivos de texto, deve ser uma questão simples escrever um pequeno script de pesquisa de texto para erros/sucesso.

Se você preferir escrever o seu próprio, um script simples do PowerShell pode fazê-lo, usando a classe System.IO.Ports.SerialPort .

Aqui está um exemplo (não testado e muito teórico):

# Create your instance of the SerialPort Class
$serialPort = new-Object System.IO.Ports.SerialPort
# Set various COM-port settings
$serialPort.PortName = "COM1"
$serialPort.BaudRate = 19200
$serialPort.WriteTimeout = 500
$serialPort.ReadTimeout = 3000
$serialPort.DtrEnable = "true"
# or in one command
# $serialPort= new-Object System.IO.Ports.SerialPort COM#,Baudrate,None,8,one
# Open the connection
$serialPort.Open()
# write to it
$serialPort.WriteLine( "at+csq" + "`r" )
# wait
start-sleep -m 50
# read line
$line = $serialPort.ReadLine()
Write-Host $line
# write to it
$serialPort.Close()

Observe que o caractere de fim de linha usado pelo modem precisa de atenção.

Aqui está minha sessão em uma VM XP onde instalei o .Net Framework 2.0 e o KB968930 . Quase funcionou, exceto que não há nada conectado ao COM1, então ele travou na chamada ReadLine () até terminar por um tempo limite.

Observe que houve um erro de copiar e colar no meu script, agora corrigido. A linha que não funcionou foi:

$line = $port.ReadLine()

Deve ter sido:

$line = $serialPort.ReadLine()

O método mais básico de controlar um modem é enviar comandos através de uma porta serial. Quase todos os modems dial-up suportam comandos Hayes AT , como ATDou ATH(geralmente em hardware para modems seriais, às vezes emulados pelo driver para modems USB/PCI).

Exemplos:

• Linux/OpenBSD/FreeBSD: Todos os programas e bibliotecas eventualmente usam os /dev/ttyS*arquivos especiais para acessar as portas seriais. (Observação: no Linux, os adaptadores seriais USB são denominados ttyUSB ou ttyACM.)
  Na maioria dos casos, seu programa pode apenas abrir o caminho como se fosse um arquivo normal, depois escrever/liberar um comando e ler a resposta.

• Windows: Todos os programas eventualmente usam os \\.\COM1:arquivos especiais para acessar as portas seriais. Os quatro primeiros podem ser abertos simplesmente como COM1:(o atalho é uma relíquia do MS-DOS).

• PowerShell: Existe um DevBlog sobre este tópico.

• Python: use pySerial .

O outro método, no Windows, pode ser usar a Telephony API . No entanto, não consigo descobrir se ele suporta chamadas de dados (terminal) ou apenas chamadas de voz.

Como observação: aqui estão apenas dois utilitários que uso para controlar meus modems. Envio e recebo muitos SMS, as ferramentas são feitas para isso. Eles suportam vários modems e os comandos AT são usados ​​para inicializar os modems. Considerando que todas as funções são de alguma forma definidas para funcionar com o SMS, ele pode ser altamente personalizado com scripts de inicialização e muito mais. Não testei um ciclo completo como discar em outro modem e receber dados de alguma forma, mas talvez valha a pena dar uma olhada neles:

http://smstools3.kekekasvi.com/index.php https://wammu.eu/smsd/

AutoHotkey.com pode ser útil.

Acredito que um truque importante para fazê-lo funcionar de maneira confiável será usar a abordagem correta. Simplesmente despejar as teclas digitadas no Microsoft Windows para que o Windows as forneça ao aplicativo em primeiro plano não será o método mais estável. Aqui está um pouco de código que usei para interagir com o PuTTY. Funcionou bem o suficiente para que eu pudesse iniciar o script, que iniciaria o PuTTY e, ainda assim, o programa poderia interagir com a instância correta do PuTTY, mesmo que o PuTTY estivesse em segundo plano.

(Você provavelmente desejará adaptar significativamente este código de exemplo.)

sPuTTYloc:="C:\Users\\me\PuTTY\PuTTY.exe"
sSiteName:="NameOfSite"
Run, "%sPuTTYloc%" -load "%sSiteName%",,UseErrorLevel,sPuTTYPID

    if %sPuTTYPID%
    {
        WinWait, ahk_pid %sPuTTYPID%
        sleep ,5000
        IfWinExist,ahk_pid %sPuTTYPID%
        {
            ControlSend,,{Enter},ahk_pid %sPuTTYPID%
; other stuff
        else
        {
MsgBox "PuTTY Window closed, spot #1"
            return ; Apparently the PuTTY window closed
        }
        Sleep 1500
        IfWinExist,ahk_pid %sPuTTYPID%
        {
            ; do other stuff
        }
        else
        {
MsgBox "PuTTY Window closed, spot #2"
            return ; Apparently the PuTTY window closed
        }
        Sleep 1500
        return
    }
return

Não há necessariamente uma razão convincente pela qual eu ainda tenho coisas quebradas em pedaços, chamando "IfWinExist" várias vezes. Quando eu estava criando e inicialmente depurando o script, achei útil para depurar (ou pelo menos sentir que tinha uma ideia melhor do que estava acontecendo) se a extremidade remota encerrasse a conexão (o que faria com que minha janela do PuTTY fechasse) .

O principal é que ao usar o ControlSend para dar as teclas digitadas para o programa usando o PID que foi criado pelo meu comando Run, se algo ruim acontecesse, o script não continuava tentando enviar as teclas digitadas para o Windows e acabava tendo as teclas digitadas entre no programa errado.