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.
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.
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.
Please pardon me if this question comes as a little too basic but I have tried searching almost everywhere but haven't found a clue.
I am using the esp8266 module and have uploaded the firmware in it. I have also set it as "Access point" so that other modules are able to connect with it. My problem is that I want to control it pro-grammatically through an 8051 micro-controller. I have searched online and there is a lot of documentation on how it program it through arduino, but that doesn't solve it for me. I want to use assembly language to build a serial protocol that communicates the data from 8051 to esp8266 and then to the connected modules (such as Android device).
My question really is, "would it be possible to just connect TX/RX of 8051 to RX/TX of esp8266 and write a code in assembly that transfers data as I desire to esp8266? Or, do I have to do something else?".
At the moment the only documented way for a host controller (the 8051 in your case) to talk to the ESP8266 is to use the serial port (there is a slave SPI port but the mechanism for driving it isn't known yet). So you will have to make up a little protocol to send and receive commands and data (assuming that the standard support for an enhanced AT command set isn't sufficient for you).
The baud rate can go a lot higher than the default 115200bps, if you need it to (although I'm not sure if the 8051 could keep up).
I am trying to connect ATmega128 uart to PC using USB-to-RS232 converter so that PC can receive and transmit data from microcontroller using hyper terminal. I set the correct stop bits and baud rate in hyper terminal. It doesn't seem to work.
Can any one tell me if this is possible by USB-to-RS232 converter and if not what other options are there for serial communication between PC and microcontroller ?
You should be able to do this without any issues. I'd suggest putting your USB-to-RS232 cable in loopback mode first (if possible) to ensure you can communicate, then connect it back up to your MCU.
If you aren't seeing what you expect the first thing to look at are the settings, specifically the baud rate. Since your USB-to-RS232 cable is from a third party vendor I'd assume that your settings on the host side are OK. So you should look in to your MCU code to ensure that all your clocks are running at the proper speed and you have indeed performed the correct calculations to achieve your desired baud rate. Debugging here to ensure you are transmitting data out of the device is important.
Additionally, there are tools that can help you debug. Portmon is a tool from Microsoft that lets you look at the serial data path on the host side. I'd also recommend a USB analyzer, such as an Ellisys, that will allow you to view data going across the line from your MCU to the host.
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.