I want to know about GSM modems. I need low level info.
Can the modem get me Layer 3 Messages, Rx and Tx level, Rx Qual., C/I, BCCH, BISC, ARFCN and ...
Edit
Note: I'm not asking about embedded modems only, I'm asking on both embedded and external modems.
Thanks and Best Regards
Your best bet for low level information is AT commands. See the answer to this SO question for specific commands for the information that you want.
Although it's about Android, you can assess AT commands on any operating system, as long as the modem device exposes a modem port (It may sound obvious that any modem would expose a modem port, but this is not the case. Some modems appear in Windows as network adapters, for example).
But note that Layer 3 messages aren't available over the AT interface. You would need a diagnostic tool from the chipset manufacturer to read the air interface messages. These are not usually available unless you're a partner company or customer of the manufacturer.
Edit:
Embedded and external modems are treated the same. The best interface to use depends on the driver. AT commands work with the vast majority of modems. Read the AT command manual for information that you can get via AT commands.
Try to get hold of a manual of manufacturer specific commands that are particular to your chosen modem.
Use AT+CLAC to get all the supported AT commands of your particular modem.
L3 messages arrive via the air interface. As I said before, the chipset manufacturers have their own interfaces to access this information, but these are not public.
Related
I'm doing a security analysis project on an IoT device that uses an unencrypted BLE connection (with ATT protocol) and I want to spoof an individual BLE packet with the source address of an already connected device. Is there some tool or API that would allow me to do this easily? I've already tried gatttool and spooftooph but they seem to be connection based and don't allow you to send out single packets with modified fields (as far as I could tell).
You will need some hardware where you can access the radio peripheral directly. What you basically need to do is to find or write a ble sniffer firmware, with the modification that it at a given moment sends a packet on the connection it is currently listening to. But note that the signal strength must be stronger than the original device's signal so it doesn't interfere.
The only open source project I'm aware of is Ubertooth. You will also be able to do this with an nRF52 but then you need to write your own sniffer firmware since Nordic Semiconductor's is closed source.
I can't comment on Emils reply yet, < 50 rep:
Nordic Semis nRF Sniffer v2 needs only the nRF52DK and wireshark to work as a general BLE sniffer. At 40$ it's not that expensive. I know for a fact they will release a new dongle soon that will sell for ~10-15 bucks if you can wait a a month or two.
I am trying to use GPRS functionality of the GSM/GPRS modem for sending data to the remote server but i am unable to do so.I had posted a question on Arduino Forum but didn't get any reply.Here is the link for the question.
Well my Main concern is i) I am using a GPRS/GSM Modem and i am not sure about the Power requirements of the Modem.At present i am using a 9V and 1 amp supply but the network LED on the modem is dignifying that Modem is not getting the network. So can this be because of the insufficient supply to the modem?
I very much doubt it's a power thing. Although I have limited experience with Arduino boards.
You can verify that the general GSM stuff is working by executing AT+CREG commands to check if it is connected to the mobile operator.
If you need more detailed help then I think it makes sense for you to post what AT commands are being sent to the modem. And what the modem on the firmware/software side is saying.
Below some information about dealing with GPRS and AT Commands (aka GSM stuff).
With GSM modems there are commonly three ways of getting GPRS and executing AT commands (GSM) simultaneously.
1) Inline multiplexing
As far as I am aware you can switch contexts within the AT command console. This is a little challenging when it comes to writing code. I would advise against this.
2) Mulitplexing over a single serial interface
This is done via drivers that support the GSM 27.010 specification. Some manufacturers provide MUX drivers for this purpose.
The standard command is AT+CMUX. I strongly suggest taking a look at the modem reference manual to find out exactly how to execute this command. You can get a rather information also via AT commands. By executing AT+CMUX=? to see what parameters are expected.
Effectively then you would have two serial connections open to the same serial port. One for GPRS and one for AT Commands.
Negative impact is that the performance (speed of command execution) is significantly reduced depending on how the hardware copes with it.
3) Multiplexing over multiple serial interfaces
The GSM modems that I know of provide multiple serial interfaces (UART). Therefore one can be used for executing standard AT commands. And another can be used for GPRS communications.
I'm not entirely sure if this is possible with the SIM900A. There you would have to look at the hardware information.
I have a GSM ModeM connected to a serial port, and I use it so send SMS upon certain events.
Since it is not Plug-and-Play, I am confused as to how I'll detect its connection status. Win APIs like GetCommState will obviously not work.
I could periodically send packets of data and check whether the data is being consumed or not, but I'm wary about the risks of polling over performance and clogging up the buffers which might be in use.
So, is there any other method, or some interrupt based thing, which I could use to check whether is still connected, via a serial port, to my system?
I'd be grateful for any help on this.
Thanks.
From Windows 7 onwards, use Windows Mobile Broadband API to get information about a GSM modem.
Serial ports are very primitive communication devices, they date from the very early days of computing. It is what you plugged your ASR-33 teletype into to start banging in your Fortran program. The only reason they are still around is because they are simple, hardware vendors like them because they don't have to spend money developing and supporting a custom api to use their device.
Still, even back in the sixties did a computer have a need to find out if a teletype was attached. Which is done through the hardware handshake signals. The DSR signal, Data Set Ready, is turned on by the device when it is powered up. If you use the .NET SerialPort class then you can check that signal with the SerialPort.DsrHolding property. If you use the winapi then use GetCommModemStatus(), MS_DSR_ON flag.
That still only tells you that some device is attached. If you want to find out that it is the modem that you wrote your program for then you can interrogate it with AT commands, a protocol that's specific to modems. No vendor implements this exactly the same way but you can usually count on an identification from the modem with the ATI command. Check the programming manual for the modem for details.
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 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.