I remember years ago my friend and i were playing command and conquer red alert and there was a mode were we put the others phone number and the game would dial up and connect. What was this called? and where can i find resource to program for this?
Dial-up Networking perhaps. You will have to learn how to control the modem. I remember there were some commands that looked like this: ATH0++ which was how you could make the modem do different things. Perhaps that will give you something to search for.
This resource looks kind of helpful: http://www.activexperts.com/activcomport/tutorials/modem/
One issue you might find is that there are two types of modems generally. One is an actual modem which is connected to your serial port. The other is what is typically known as a "winmodem" which is usually in a PCI slot and didn't have all of the functionality on the hardware but instead used the hardware drivers which typically only worked in Windows. MODEM stands for "MOdulator DEModulator" which means it just converts a digital signal to analog and vice versa.
In essence, it seems that if you can figure out how to program to the serial/com ports on your computer, you should be able to access the modem.
Another interesting link: http://en.wikibooks.org/wiki/Serial_Programming:Modems_and_AT_Commands
Have a look at TAPI (Telephony API). In Windows world there is a set of APIs in the OS for this (http://msdn.microsoft.com/en-us/library/ms737219(VS.85).aspx). The AT command set (Hayes commands) can also be used without TAPI in Windows if you treat your Modem as a COM port and send AT commands to that COM port (that's what actually TAPI does) but it isolates you from their different variants and also running initialization and other commands in a particular order.
Related
I am involved in a project where we have some kind of IoT device. An nxp processor with an LTE modem on a PCB. The software running on it connects to the modem over a single uart interface. It will initialize the modem through AT commands, and finally made a data call to the provider (PPP).
Then, it uses lwIP (light weight IP) to open some mqtt subscriptions, and allow user code to make http get/post requests to our servers.
Every 15 minutes we want to retrieve signal strength from the modem and report this back to the server. What I do now, is put the modem back in command mode, retrieve the signal strength info, go back to data mode, and resume normal operation.
The round trip from data mode, to commando mode, and back to data mode takes several seconds (4-5 ish). This is annoying, because during that time we are not receptive for commands.
I've read about gsm mux 07.10. By following some defined protocol it allows to create virtual serial ports, over one physical uart. That sounds nice, although I realize this will go at the cost of performance (bytes will be added to each frame we send to either command mode / data mode).
The gsm mux 07.10 spec dates from 1999. I am far from an expert in mobile solutions. I was wondering: is muxing still the way to go? How does a typical smart phone deals with this for example? Do they include modems with more than one uart to have parallel access to AT commands and a live internet connection? Or do they in fact still rely on gsm mux?
If somebody would be so kind to give some insights. Also on potential C libraries that are available that implement gsm mux 07.10? It seems that TinyGSM implements it (although I can't seem to find where), and I also can find the linux kernel driver that implements gsm mux 07.10. But that driver is written on top the tty interfaces in linux, so that would mean I would have to reverse engineer the kernel driver and strip out the tty stuff and replace it with my own uart implementation.
First of all, the spec numbering is the old GSM specification numbering, so those old specs will never be updated, the new specifications with new numbering scheme will. I do not remember when the switch was made, but I do remember someone at work giving a presentation on 07.10 probably around 1998/1999, so probably a few years after that or around that time (and definitely before 2009).
The newer spec numbering scheme uses three digits for the first part.
So for instance the old AT command spec 07.07 is now 27.007, and the current 07.10 multiplex specification is 27.010.
The following is what I remember of 07.10.
The motivations for developing 07.10 was to exactly support the kind of scenario that you describe. Remember back in the mid 90's, if mobile phones had a serial interface then that was RS-232 though each manufacturer's proprietary connector at the bottom of the phone. One single serial interface.
However, in order to use 07.10 mux in serial communication you needed to install some specific serial drivers in Windows with support for 07.10 (and I think maybe there was some reliability issue with them?), and for that reason 07.10 never took of and became anything more than an rarely used solution.
Also by the end of the 90's additional serial interfaces like Bluetooth and IrDA became available on many phones, and later USB as well, which both added additional physical interfaces as well as natively multiplexing within each protocol.
So the need for multiplexing over physical RS-232 became less of an issue, and whatever little popularity 07.10 ever had dwindled down to virtual nothing.
Fast forward a couple of decades and suddenly someone asks about it on stackoverflow. Good on you :) As far as I can tell I cannot see any fundamental problems with using it for the purpose you present.
Modern smart phones that support AT commands will most likely have a code base for the AT command parsing with roots in the 90's, which most likely include the AT+CMUX command. Of course manufacturers today have zero explicit wish for supporting it, but when it is already present it will just come along with the collection of all other legacy AT commands that they support.
So if the modem supports AT+CMUX you should be good to go. I have no experience or recommendation with regards to client protocol libraries.
My work involves interacting with legacy hardware that uses serial ports. I often have to monitor more than one serial line, and for the purpose I have a couple of the common USB serial adaptors. When I connect both of them to the same (Windows 10) machine, irregularities show up. Both ports show up in device manager, but only the first one that I plug in to the USB connector works. The other one indicates port not open when I try to send data via RealTerm.
I have also seen the situation where when I plug the second adaptor in, its port comes up, but the one for the other adaptor disappears. Does anyone know a way that two devices can happily coexist on the one machine? Thanks in advance.
Just ion case this helps anyone in the future......
The problem seems to be caused by the fact that one of the adaptors was coming in via a (powered) USB hub. When I liberated another native port on the machine so I could host both serial adaptors directly, everything worked fine.
Not worth hunting the cause down, a solution is at hand.
I have the following: STM32F407G-DISC1. My goal is to communicate (sending strings back and forth) between my pc and the mcu over serial and I currently am able to do so using the micro-usb (otg) port, while powering separately using the mini-usb st-link port (so using two cables).
Is it possible to use the mini-usb port for serial communications? (eliminating one of the cables)
I have read the user manual and my interpretation is that this is not possible without physical modifications. But I am a beginner and would like to verify I am correct in this interpretation. I have researched thoroughly however most sources seem to not refer to this specific board and it is my understanding with the newer version of st-link it uses this should be achievable.
It is possible - just send the messages via the USART2
You need to solder those two wires as they screw up the design.
There's a old piece of software we run in our company that manages RFID cards tapping in/out to open doors.
We want to create an app who identifies who just touched in on a specific place (we have the id for that) and grab their 1st name, to say "Hi [NAME]" on a screen.
As I mentioned, the software is quite old and there are no APIs. It communicates with the RFID hardware via a serial port (COM1).
I was wondering if the best way to get the data I need is to somehow intercept the COM1 traffic and extract/look for the data I want.
Does this sound like the best way to go about it? Would it work, or would it be impossible to get names and numbers from the data being transferred?
Cheers,
Andre
Can you configure the software to use a port other than COM1, or configure the hardware so it's physical serial port is assigned to a different COM port?
If so, take a look at com0com. It's a Windows driver that creates two COM ports on your PC with a virtual NULL modem between them. Data going in on one side comes out on the other.
Here's how you'll set things up:
RFID Reader connected to physical COM port (COMx)
your program bridging COMx to COMy and sniffing the traffic
com0com linking COMy (for your program) to virtual COM1 (for the legacy software)
legacy software
You'll need to write a program to pass data between COMx and COMy while monitoring it for the information you're looking for. Make it simple yet robust, since if it goes down you're reader will stop working.
A Simpler Solution
If you only need to monitor one side of the communications, create a cable that connects the GND and RX pin of COM1 to another COM port. Now your program can monitor that side of the conversation, without interfering with the legacy software.
Well, generally, you can look at RS232 signals, if that's the way you want to do it. It's tricky because you need to "sniff" the signals, which means buying or making a rig that allows the original signals to go through, and then gives you a way to attach to them as well. And, you need to send the transmit and the receive signals to TWO serial ports (on the RX lines). Then you'll probably want to get some "sniffing" software that allows you to look at what you're getting in time sequence (ideally, with time-stamps). Some cutesy protocols also will use modem lines, so you may need to monitor those as well.
Or, try searching for "free serial port monitor" or "serial sniffer".
Good luck!
I have an Arduino-based device which connects through USB.
I'd like to detect it from my Qt 4 application, using QExtSerialPort (or whatever necessary), when it's plugged in.
If this weren't possible, I thought I could somehow get a list of the system's port names and just try all of them in search for my Arduino (where I'd implement some kind of handshaking procedure for it to detect it correctly). My concern in this approach is that I'm not sure if a device (for example, printer) would get damaged if I send some kind of handshaking ack at a different baud rate.
So, I don't really know where to start for any of them. Which would be the best approach? How would I implement it?
I believe you can find list of serial ports on Windows by looking into
HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM
registry key
Each serial port on a UNIX system has one or more device files (files in the /dev directory) associated with it:
System Port 1 Port 2
IRIX® /dev/ttyf1 /dev/ttyf2
HP-UX /dev/tty1p0 /dev/tty2p0
Solaris®/SunOS® /dev/ttya /dev/ttyb
Linux® /dev/ttyS0 /dev/ttyS1
Digital UNIX® /dev/tty01 /dev/tty02
more details on serial programing on POSIX systems here
Since your device is USB, your UART port will be emulated by some kind of conversor in his hardware. So first you must understand what driver is being used on your system.
The most common SERIAL->USB conversor uses PL2303/PL2301 chip, so it would create a path on /dev, if its the first device, it will appear as "/dev/ttyUSB0", but you may also see the list reading the proc path (like "cat /proc/bus/usb/devices").
Under Windows it usually creates a virtual "COM", just go to device manager and check the port.
When you are sure about how the HW talks to your system, you may use QExtSerialPort for wrapping the system API and talk to the device.
Way too hard and too platform specific, using weird Windows Registry keys or rely on hard wired device nodes on Linux.
You are on the right way. Get QextSerialPort or QSerialDevice (which I preffer in my projects, because it got integrated in Qt5), have a look at the examples and simply use it. In both libraries you get some kind of port enumerator class which returns you a list of all configures serial ports. Only platform/device specific settings you will have to do manually (like getting RS485 in half-duplex mode on my current embedded project), but "standard" problems are perfectly encapsulated in a QIODevice implementation.
You can use both QextSerialPort and QSerialDevice like a file. Open it (instead of a filename you specify the device name ie. "COM1" on Windows or "/dev/tty0" on Linux, depending on your configuration) and then read or write like you are doing it with an ordinary QFile, QBuffer, Qwhatever-inherits-from-QIODevice.
If you have any problems opening the port and communicating, don't hesitate to ask! :)