At work, we just got a large number exotic cellular devices that need to be programmed. To do this, you plug in a standard home telephone and dial a series of numbers, with pauses between them.
To me, this is a task that begs to be automated, and we've got one Linux desktop (a test Asterisk machine) with a modem on it.
So, how can I automate this task?
Simply send the necessary AT commands to your modem via the modem's corresponding /dev device, e.g. ATDT 12,456567,21
I think you should be able to open the modem device (often sym-linked from /dev/modem), and enter modem codes to reset the modem (atz, perhaps), then the codes to dial (atd), then the number, with "," for pause.
You can automate this in probably almost any language that allows you to write to the device file.
Take a look at the reference here:
http://www.zoltrix.com/support_html/modem/USEMODEM.HTM
My typical dial out string (all directed at the modem device):
ATZ (Dear modem, forget everything you knew)
ATS11=33 (I liked dialing fast)
ATF0 (Auto negotiate link speed)
ATL3 (I like it loud)
ATM3 (I only like hearing the handshake loudly)
AT&G(x) (In case you have a US modem and need to use it in the rest of the world (guard tone))
AT&K3 (hw flow control, if not available use software via AT&K4)
AT&R1 (CTS (clear to send) is always on. Wrapping RJ-11 connections in static free softener sheets helps this.
Finally, and most importantly:
ATDT (number) (Dial a number using DTMF) Depending on the age, your modem may support ATDP (pulse dialing).
Just keep in mind, +++ is an escape sequence, returning you to the modem console :) Have fun. +++ ATH0 and you hung up. ATH1 takes it off hook and does little else. ATA answers an incoming data call. Comma, , is a pause.
Yeah, others linked to the Hayes AT command set, I actually used it for years as a SysOp of a BBS :)
Finally, screw Kermit, use Zmodem.
Links: Synchronet, WWiV, the rest are an exercise for the reader, though I humbly suggest searching for Renegade, Telegard, TaG and others.
Oh dear, I'm off on a tangent.
If you need to pause and respond to replies back from the device - this is exactly what expect was invented for
Use the Hayes command set:
The following commands are understood by virtually all modems supporting an AT command set, whether old or new.
D Dial
Dial the following number and then handshake
P - Pulse Dial
T - Touch Tone Dial
W - Wait for the second dial tone
R - Reverse to answer-mode after dialing
# - Wait for up to 30 seconds for one or more ringbacks
, - Pause for the time specified in register S8 (usually 2 seconds)
; - Remain in command mode after dialing.
! - Flash switch-hook (Hang up for a half second, as in transferring a call.)
L - Dial last number
See Linux Modem-HOWTO for details.
Related
I want to implement a P2P protocol in C for personal education purposes.
What would be the protocol with the shortest specification that is still used today?
I have already implemented a web and IRC client and server.
I agree with Mark, that point to point over a serial link would be a good exercise.
In particular, I would recommend the following programme of stuff...
Implement basic transmission over a "Serial Port" (using RS-232 if you have some Arduinos/embedded processors lying around, or using a null modem emulator if you don't (see com0com on Windows, or this on linux/mac).
I.e. send lower case letters from A->B, and echo them back as upper case from B->A
Implement SLIP as a way to reliably frame messages
i.e. you can send any string (e.g. "hello") and it is returned in upper case with "WORLD" appended ("HELLOWORLD").
Implement the "Read Multiple Holding Registers" and "Write Multiple Holding Registers" part of the Modbus protocol, using SLIP to frame the messages.
I.e. you have one follower (slave) device, and one leader (master) device. The follower has 10 bytes of memory that are exposed over modbus with the initial value "helloworld".
Just hard-code the follower / leader device Ids for now.
The leader reads the value, and then sets it to be "worldhello".
At the end of this you would start to have an understanding of the roles of network layers, ie:
The physical layer - Serial/RS-232
A "link layer" of sorts - SLIP
An "application" layer - Modbus
Serial. The answer is serial. You're not going to get any leaner than simple RX/TX communication but you'll lack a lot of convenience methods. If you want to explore more than simple bidirectional comms, I2C or modbus open up a lot of options.
I have a bluetooth keyboard that I use on a regular basis. It has a Logitech logo, but is manufactured by ZAGG and has model number Y-R0023.
I have paired the keyboard with my Ubuntu desktop and it works great.
Upon powering up my computer and keyboard, I can sometimes reconnect without having to pair again, but other times I have to remove the existing pairing and reconnect before Ubuntu can receive keystrokes.
Extra information: Ubuntu displays a bluetooth symbol as a status when it connects (regardless if it is able to receive keystrokes or not). This symbol will appear and disappear roughly every 10 seconds until the two devices are able to successfully negotiate a valid connection.
I notice that I have best success when I press 'delete-delete-enter-enter' after powering the ZAGG keyboard up. (Sometimes, just repeatedly pressing a key every second or so seems to work too.)
I am wondering if the "delete-delete-enter" keystroke combination (or some other that I haven't discovered) is recognized by the Logitech BIOS as a special sequence to help retry a paired re-connection. I'd be interested in finding out if this trick works for devices other than those made by ZAGG. Otherwise, it would help just to know if there is a reliable script I can run that calls bluetoothctl to help improve the re-connection. (I want to avoid having to enter a pairing code on subsequent connections).
ZAGG sites and Logitech ones don't say anything about this key combination. So I don't think it's recognized as a special sequence, only advice they give is to re-pair the device when it's not working.
In summary I'm sure they would include this troubleshooting option in manual and/or troubleshooting guide if it was present.
Using BlueZ, which
is the official Linux Bluetooth stack
I'd like to know which of the below two methods are better suited for detecting a device's presence in the nearby.
To be more exact, I want to periodically scan for a Bluetooth device (not BLE => no advertisement packets are sent).
I found two ways of detecting it:
1.) Using l2ping
# l2ping BTMAC
2.) Using hcitool
# hcitool name BTMAC
Both approaches working.
I'd like to know, which approach would drain more battery of the scanned device?
Looking at solution #1 (l2ping's source):
It uses a standard socket connect call to connect to the remote device, then uses the send command to send data to it:
send(sk, send_buf, L2CAP_CMD_HDR_SIZE + size, 0)
Now, L2CAP_CMD_HDR_SIZE is 4, and default size is 44, so altogether 48 bytes are sent, and received back with L2CAP_ECHO_REQ.
For hcitool I just have found the entrypoint:
int hci_read_remote_name(int dd, const bdaddr_t *bdaddr, int len, char *name, int to);
My questions:
which of these approaches are better (less power-consuming) for the remote device? If there is any difference at all.
shall I reduce the l2ping's size? What shall be the minimum?
is my assumption correct that hci_read_remote_name also connects to the remote device and sends some kind of request to it for getting back its name?
To answer your questions:-
which of these approaches are better (less power-consuming) for the remote device? If there is any difference at all.
l2ping BTMAC is the more suitable command purely because this is what it is meant to do. While "hcitool name BTMAC" is used to get the remote device's name, "l2ping" is used to detect its presence which is what you want to achieve. The difference in power consumption is really minimal, but if there is any then l2ping should be less power consuming.
shall I reduce the l2ping's size? What shall be the minimum?
If changing the l2ping size requires modifying the source code then I recommend leaving it the same. By leaving it the same you are using the same command that has been used countless times and the same command that was used to qualify the BlueZ stack. This way there's less chance for error and any change would not result in noticeable performance or power improvements.
is my assumption correct that hci_read_remote_name also connects to the remote device and sends some kind of request to it for getting back its name?
Yes your assumption is correct. According the Bluetooth Specification v5.2, Vol 4, Part E, Section 7.1.19 Remote Name Request Command:
If no connection exists between the local device and the device
corresponding to the BD_ADDR, a temporary Link Layer connection will
be established to obtain the LMP features and name of the remote
device.
I hope this helps.
Does anyone know of a good way to get a bi-directional dump of MIDI SysEx data on Linux? (between a Yamaha PSR-E413 MIDI keyboard and a copy of the Yamaha MusicSoft Downloader running in Wine)
I'd like to reverse-engineer the protocol used to copy MIDI files to and from my keyboard's internal memory and, to do that, I need to do some recording of valid exchanges between the two.
The utility does work in Wine (with a little nudging) but I don't want to have to rely on a cheap, un-scriptable app in Wine when I could be using a FUSE filesystem.
Here's the current state of things:
My keyboard connects to my PC via a built-in USB-MIDI bridge. USB dumpers/snoopers are a possibility, but I'd prefer to avoid them if possible. I don't want to have to decode yet another layer of protocol encoding before I even get started.
I run only Linux. However, if there really is no other option than a Windows-based dumper/snooper, I can try getting the USB 1.1 pass-through working on my WinXP VirtualBox VM.
I run bare ALSA for my audio system with dmix for waveform audio mixing.
If a sound server is necessary, I'm willing to experiment with JACK.
No PulseAudio please. It took long enough to excise it from my system.
If the process involves ALSA MIDI routing:
a virtual pass-through device I can select from inside the Downloader is preferred because it often only appears in an ALSA patch bay GUI like patchage an instant before it starts communicating with the keyboard.
Neither KMIDIMon nor GMIDIMonitor support snooping bi-directionally as far as I can tell.
virmidi isn't relevant and I haven't managed to get snd-seq-dummy working.
I I suppose I could patch ALSA to get dumps if I really must, but it's really an option of last resort.
The vast majority of my programming experience is in Python, PHP, Javascript, and shell script.
I have almost no experience programming in C.
I've never even seen a glimpse of kernel-mode code.
I'd prefer to keep my system stable and my uptime high.
This question has been unanswered for some time and while I do not have an exact answer to your problem I maybe have something that can push you in the right direction (or maybe others with similar problems).
I had a similar albeit less complex problem when I wanted to sniff the data used to set and read presets on an Akai LPK25 MIDI keyboard. Similar to your setup the software to setup the keyboard can run in Wine but I also had no luck in finding a sniffer setup for Linux.
For the lack of an existing solution I rolled my own using ALSA MIDI routing over virmidi ports. I understand why you see them as useless because without additional software they cannot help at sniffing MIDI traffic.
My solution was programming a MIDI relay/bridge in Java where I read input from a virmidi port, display the data and send it further to the keyboard. The answer from the keyboard (if any) is also read, displayed and finally transmitted back to the virmidi port. The application in Wine can be setup to use the virmidi port for communication and in theory this process is completely transparent (except for potential latency issues). The application is written in a generic way and not hardcoded to my problem.
I was only dealing with SysEx messages of about 20 bytes length so I am not sure how well the software works for sniffing the transfer of large amounts of data. But maybe you can modify it / write your own program following the example.
Sources available here: https://github.com/hiben/MIDISpy
(Java 1.6, ant build file included, source is under BSD license)
I like using aseqdump for that.
http://www.linuxcommand.org/man_pages/aseqdump1.html
You could use virtual midi devices for this purpose. So you have to load snd_seq_dummy so that it creates at least two ports:
$ sudo modprobe -r snd_seq_dummy
$ sudo modprobe snd_seq_dummy ports=1 duplex=1
Then you should have a device named Midi through:
$ aconnect -i -o -l
client 0: 'System' [type=kernel]
0 'Timer '
1 'Announce '
client 14: 'Midi Through' [type=kernel]
0 'Midi Through Port-0:A'
1 'Midi Through Port-0:B'
client 131: 'VMPK Input' [type=user,pid=50369]
0 'in '
client 132: 'VMPK Output' [type=user,pid=50369]
0 'out '
I will take the port and device numbers form this example. You have to inspect them yourself according to your setup.
Now you plug your favourate MIDI Device to the Midi Through ports:
$ aconnect 132:0 14:0
$ aconnect 14:0 131:0
At this time you have a connection where you can spy on both devices at the same time. You could use aseqdump to spy the MIDI conversation. There are different possibilities. I suggest to spy the connection between the loopback devices and the real device. This allows you for rawmidi connections to the loopback devices.
$ aseqdump -p 14:0,132:0 | tee dump.log
Now everything is set up for use. You just have to be careful about port names in your MIDI application. It should read MIDI data from Midi Through Port-0:B and write data to Midi Through Port-0:B.
Some additional hint: You could use the graphical frontend patchage for connecting and inspecting the MIDI connections via drag and drop. If you do this you will see that every Midi Through port occurs twice once as input and once as output. Both have to be connected in order to make this setup work.
If you want to use GMidiMonitor or some other application you spy on both streams intermixed (without showing the direction) using aconnect suppose 129:0 is the Midi Monitor port :
$ aconnect 14:0 129:0
$ aconnect 132:0 129:0
If you want to have exact direction information you could add another GMidiMonitor instance that you connect only to one of the ports. The missing messages come from the other port.
What about using gmidimonitor? See http://home.gna.org/gmidimonitor/
I use a Linksys PAP2 for my fax line and I can toggle modem mode by dialing *99 before the number, however I do not want to have to dial it every time to send a fax. Is there any way to incorporate the modem toggle into the dial plan ? I have googled and haven't found anything, I'm afraid the answer may be no, but I wanted to give this a try.
I know faxing over IP is not reliable, yet, I would still like to entertain it. Are there are other analog adapters that are more suitable?
suppose its the same number you want to use for sending the fax, lets assume its "16131234567" just add the following rule in your dial plan. (|<16131234567:*9916131234567>|)
when you will dial the fax number ATA will automatically add *99 before it.
My pap has the *99 modem code too. I researched this some time ago. *99 does the following: Force dtmf inband, echo cancel off, echo supress off, silence supress off, force g.711/ulaw, and call waiting off. In respect to modems and fax, due to the half duplex nature of fax, there may be a benefit of using echo cancellation. Most any normal dial up is where it's best disable of the echo canceller, not fax. However, some may be using "echo suppress", and/or silence suppression, both of which hurt fax greatly.
In terms of making fax reliable over Voip, the number one best thing you can do is complain, complain, and complain to your ISP and get them to reduce the packet jitter on your line! There is T.38 to experiment with which was designed to work with jittery lines, but not all ata's and providers support it. However, there is no real "better" ata then another ata for fax and modems. Voip uses primarily g.711/ulaw codec, which is what the PSTN uses. It's mainly the high packet jitter on many residential lines that make fax not work. The local nodes can be oversold, but they generally want to deliver high speed (quantity), not low jitter (quality).
Oh! the one biggest myth going around is to disable ECM mode. DON'T! Ecm mode was invented just for improving success rates over noisy and unreliable phone lines. In fact, ECM helps greatly with Voip. Turning off ECM is "I don't care if my faxes are unreadable" mode, going back to the early 80's with fax machines were thermal roll. Turning off ECM will increase the apparent "success" to you because there will be fewer errors given to you by your machine in front of you. However, pages may be missing or cut in the middle, unreadable, etc. but your machine will indicate a "success". I’ve heard from too many people that leaned the hard way when it occurred to them because people were telling them that pages were missing, etc.
One last thing I want to touch on is baud rate, generally many machines have two modes: no ecm 9600, and ECM 14400, and if you have it, super g3 33600. Of course, SG3 is going to give the most problems. Generally reducing the baud rate below 14400 isn’t necessary, since it's not a big jump, and 14400 is more tolerant to noise anyhow. Don’t switch to 9600 if it means disabling ECM mode.