I am a mess! I have been messing around with the cellular module and cannot get it to work. I have been changing here and there in the driver, but nothing seems to help. The AT command docs are pretty messy and unclear as well.
Can anyone have a look at the output and give me a clue about the problem:
I’ve tinkered with the driver and simply doing some secondary activations after the driver does its thing. Still haven’t got it to get the static IP and allow TCP/IP connection.
Now I am really getting frustrated about this cellular module! I have NOT been able to even create a connection to anything yet.
I am thinking that the messages coming from the Sim900 chip is very limited and looking for hardcore debugging options… “ERROR” does not really help a lot
Furthermore it could be feasible to connect the module directly to a terminal application on my pc to have a “direct interaction” - is that possible…like the camera module?
Any advice on documentation, debugging tips, and debugging tools are VERY WELCOME!
any time you send serial text to control a device, you csn “emulate” that using a PC and a terminal program, yes.
My suggestion: step through each command and tell which one is failing. ERROR is about the best you’ll get, but at least you’ll know what line threw it and therefore what probable causes were
edit: I also alerted Byron to this thread (he isn’t on here much) so he might pop over and help share his thoughts.
Test the module with the default driver, debug mode on
Consider next steps
ERROR is a generic response indicating the command was not accepted, sorry if I’m repeating the obvious. There is also a special case, from the manual:
It’s unlikely you’re hitting this special case. Much more likely is that the module is busy, you didn’t give it at least 40 seconds to power up, or there is a problem with the SIM card (functionality not supported?)
Please also make sure you are using a recent version of the AT command manual (I’ve got 1.03 here) because some of the early ones had even less information.
Can you please post examples of how you are interacting with the driver? It’s very sensitive to order of operations and correct state interlocking. It’s worth having the TCP application note as well “SIM900_TCPIP_Application Note_V1.02.pdf”.
I’m not sure you should be calling CIPMODE before you have a GPRS connection, for example. CIPMODE=1 (transparent data) requires a couple of other setup steps.
Great, this sounds promising. I just had a look in to application note - wondering why this document has sneaked outside my attention - it should be possible to mingle something better out of the chip with this.
I will use the next week on trying out your ideas. And report back.
I know that my SIM card is not able to send SMS (not needed), but thinking how to have a status of possible functions supported by the SIM card (provider). Is it possible to have the chip tell me if IP-server is supported?
@ logictechs - Really good job! I owe you a few beers, I wish we could sit down and discuss how to proceed from here over a few pints!
Anyway, as I understand the application note, each connection to the server is allocated a number, and you get the “+RECEIVE,0,39<insert 39 bytes of data here>” for each transmission to the server. That’s the closest we get an event-trigger I think.
If you maintain the CellularRadioManager.cs and CellularRadio_42.cs, you should add the parsing of this string to the main thread and create corresponding event handlers for it.
There is still lots of coding to do.
Meantime I have realized that my SIM-card was not M2M enabled, and I am waiting for a new one to arrive.
I’m actually trying to rewrite the driver now from Seeed website so it configs for server correctly. This way, we can use the commands implemented already in it and not have to do it in our app code. Then I’ll tinker with adding a server receive data event.
About your sim…my sim is activated with MO(mobile originated) and MT(mobile terminated). That means it can make and send a call(connection) from non-mobile devices only. Your MM config would only allow connections from another mobile device. Keep that in mind when you’re trying to connect from a desktop/laptop computer. You’ll only be able to connect with another mobile device. Unless you have the other options I listed activated also.
Scratch rewriting the driver to setup the modem as server idea! Figured out a much easier solution. We need to wait for the modem to register to the network. I was using a timer but then I thought about the network registration change event. So I came up with this event handler to ensure it’s are always ready as a server:
void cellularRadio_NetworkRegistrationEvent(CellularRadio sender, CellularRadio.NetworkRegistrationState networkState)
{
Debug.Print("NETWORK EVENT " + networkState);
if (networkState == CellularRadio.NetworkRegistrationState.Registered)
{
cellularRadio.SendATCommand("AT+CIPMUX=1");
cellularRadio.AttachGPRS("your APN here", "", "");
cellularRadio.ConfigureTCPServer(your port number here);
cellularRadio.SendATCommand("AT+CSQ");
}
}
The CIPMUX=1 is the fix to allow the normal driver functions to work correctly for server setup. I wanted to see the signal strength so I added the +CSQ command also. Now to figure out receiving and working with data.
Can someone add a “AT+CMEE=2” somewhere early to the driver? This will tell the modem to send a proper error message instead of just “ERROR”. Well, it works for all my GSM modems…
In my next attack I will try some extended error reporting!
I have been thinking about the approach. I am not sure about the GHI plans for a cellular module, so we are left a little dangling in regards to modifying the driver and how to collaborate on it??
Note that the module supports 2 data modes, TRANSPARENT and AT. Transparent mode allows you to have freeform conversations with the server without the module getting in the way (it acts like a connected modem).
AT mode means you need to continue parsing AT responses and unsolicited response codes, which can make writing your higher-level application a little more difficult, as well as requiring more rework of the driver.
