Testing the dronecell or other GSM modem

In this page you will find information about testing and using the dronecell or another GSM modem with APM's new AP_Modem library

The current code is still in early development, is buggy and requires some experience to compile and deploy. But, it works and it allows telemetry to flow over TCP or UDP anywhere around the world, directly from your drone!

Requirements:

- APM1 or APM2 can be used. The code is different slightly, so test each separately

- A dronecell or any other AT-command compatible modem

- A data-plan SIM card

- (Optional) Dynamic DNS or fixed IP for convenience

Skills: You will need to be able to compile the ardupilot-mega code from source and install it on the hardware. 

1 Getting the hardware



If you do not have a dronecell, you can try buying one online from diydrones or another store. You might find it difficult to source one. 

Other than the dronecell, you could try another GSM module. The closest is the Arduino GSM shield sold on Amazon which includes a SIM900 GSM module, which is the same brand as the dronecell modem. 

The code should work for any GSM modem that supports AT commands. The only changes would be in the init_script. If you are brave, try another type of GSM/GPRS modem.

SIM Card: Need a compatible GSM network. I personally use the T-Mobile pre-paid SIM card with $2 per day cost (for any day it is tuned on) and up to 200MB of data. It cost me only $10 to buy, all cash, no contract, no names, no addresses ;-)

2. Getting the software [UPDATED x 2]

The software is available as a new branch of the code, based on ArduCopter2.6 and ArduPlane2.4. (ie, the current master branch).

Using GIT

If you are familiar with git, you can pull the modem_test branch from google and compile it, from here:

 http://code.google.com/r/andreas-apm2-wip/source/checkout

You will need to checkout the modem_test branch

git checkout modem_test

then compile and install

Download a pre-compiled HEX file to flash

ArduCopter 2.6

Downloading Manually  [ This approach is no longer practical ]

3. Preparing the hardware

The dronecell comes with a default speed of 38400. Other modems may be set to 9600, or any other speed. The APM1 telemetry port is at 57600. So the two must match. You have three options:

a) Change SERIAL3_BAUD to 38400  in ardupilot code. My libraries respect whatever you set and will work with it. Then the dronecell will work. But xbees won't. So you will have to swap the speed in the code back and forth between 38400 and 57600 to use other radios.


b) A better option is to set the dronecell to 57600 permanently. Connect to dronecell serial to a serial2USB (FTDI) cable a terminal (the one in Arduino IDE will do) and change it to 57600. If you don't have an FTDI cable, you can slave the modem to any Arduino board by connecting it to TX0 and RX0 and then running an empty script ("Basic" in ArduinoIDE). 

Commands are:

AT+IPR=57600

changes speed to 57600

AT&W

writes the change to memory permanently.

c) If option (b) is too complex, then you can also do the following... do (a) to have APM able to speak to the dronecell at 38400. Then change the init_script (in Cellular_Modem.cpp) and add the following in the fifth or sixth line (doesn't matter really exactly where, just after the initial 4 commands):

"AT+IPR=57600",

"AT&W",

That will have the APM tell the dronecell to switch baud rates. The rest of the script will fail (APM is still trying to talk 38400 at this point, but the dronecell is now listening at 57600). Change the SERIAL3_BAUD back to 57600, and now dronecell (and everything else) speak 57600. 


4) Configuring the Software


You will need to make changes to the settings to reflect your SIM card provider


Open AP_Modem.h and find these lines:


#define VAL_APN         "internet" // value for the APN
#define VAL_USER        "" // value for the user name
#define VAL_PW          ""      // value for the password


The settings above are the ones that worked for the T-mobile SIM card. Most SIM cards no longer use a "username" and "password" to log onto the data network, so those usually remain blank. The APN is carrier specific, though many use "internet" as the APN, so try that.

 

Once you've made the changes, compile and install the code.


5. Connecting the modem


You will need to connect the modem to the telemetry port. Look at the instructions for Xbee, and see where the telemetry port is on your board. If you already use Xbee, this is easy ;-)


Connect RX, TX and GND to the modem. I can't remember if it is TX->TX or TX->RX, but if the modem isn't responding, try switching around. Having an FTDI cable to troubleshoot or an extra Arduino will help a lot.


IMPORTANT - POWER CONSIDERATION:

A GSM modem will draw up to 2.0-2.5A in bursts when transmitting. You cannot power it from the APM. You probably cannot power it from an ESC BEC, though you could try. I power it from a 10A rated BEC (Castle BEC). You can also use a separate battery and BEC to power it. Whatever you do, you need to meet two requirements:


1) provide at least 2.5A clean power at 5V

2) power modem and APM from same power*


* They must share a GND for the TTL to work. If you have two power sources and share a GND, you may create a weird path through your board from one power source to the other. *ZAP*. Easier to run both off a sufficiently strong BEC or battery.

 

6. Set the parameters [NEW]

 

 

MDM_BLIND 1.000000 -- Set to 1, to dial blindly. Set to 0 to validate the modem response


MDM_DEBUG 0.000000 -- Set to 1 for debug messages on the console 


MDM_ENABLED 1.000000 - Enable


MDM_IP1 192.000000  - First byte of IP address
MDM_IP2 168.000000 - Second byte of IP address
MDM_IP3 0.000000
MDM_IP4 161.000000 - Fourth byte...


MDM_PORT 14550.000000  - Port number 


MDM_PROTO 0.000000 - Protocol - UDP=0, TCP=1


MDM_RATE 115.000000 - Serial speed - short form (1=1024,2,4,9,19,38,57,115=115200)


MDM_SERIAL 3.000000 - Serial port (0 is Serial/console, 3 is Serial3/telemetry)


MDM_STATE 0.000000 - Don't change, used to see what state we're in

7. Setup the GCS


The GCS will need to connect to the Internet with a public IP address and the ability to receive traffic on UDP/14550 (or if you changed that, whatever you set). The IP address must be fixed or have a dynamic DNS name, or you will have to set it in the code each time you re-connect. I use a dynamic DNS for convenience. For testing, a fixed IP will work fine. 

Make sure the port is open on any firewalls or gateways and the traffic can get through. 

With Mission Planner, you will set it to UDP and to listen on port 14550.

8. Start the APM

If you are connected on the USB, you will see the modem initialization in ridiculous line-by-line detail (if debug is on). It looks like this:


Init ArduCopter V2.6-modem

Free RAM: 4096
FW Ver: 118
----------------------------------------


load_all took 67us

--MODEM starting on Serial 3 @ 115200 baud
Press ENTER 3 times for CLI

GSTABILIZE> Mode STABILIZE
ublox update:35: gps read timeout 3662 0
OK

GPS
----------------------------------------
enabled

9. Success (??)

If all goes well, here's what should happen:

- Your APM starts up

- The APM sends the init script to the modem

- The modem establishes an Internet link and then start copying traffic (bridging) over UDP or TCP. 

- The APM sends Telemetry data, once it is done initializing. 

- The telemetry data flows through the modem, across the Internet and to the UDP port. This takes about 30sec to a minute to start arriving the first time. 

Wait for a bit for the flow to start, then start MP and tell it to listen on UDP 14550. If all goes well, it will say "Getting parameters" and then connect in the usual way.

You will notice about a 2 second "lag" between activity on the drone and activity on the GCS. You move the drone, the horizon moves on the GCS two seconds later. That is because of the latency introduced by the Internet routers. It can be optimized (and will), but will always be a bit lagged compared to line-of-sight speed-of-light radios. However, despite the latency, the system is not losing packets at 57600 and the flow is consistent and good. So except for joystick flying, you can do your mission planning, PID tuning and such easily over IP.

Comments, questions or support requests below. 

Comment

You need to be a member of Telemetry over cellular IP to add comments!

Comment by Veikko Vierola on August 5, 2012 at 9:20am

How can I use the FTDI cable for troubleshooting DroneCell connection? How could I check that the DroneCell is uploading correct MavLink data?

Comment by Veikko Vierola on July 29, 2012 at 1:59pm

It gives error when I'm trying to make tcp connection, it says that the DC doesn't allow to make the connection?

Comment by Veikko Vierola on July 25, 2012 at 2:57pm

Oh I see, thanks.


Developer
Comment by Andreas M. Antonopoulos on July 25, 2012 at 1:53pm

Veikko,

I believe you are referring to "escaping" a character. That tells the compiler: "Don't interpret the next character, it is meant to be the literal character". To do that, you prefix the " with a backslash in the string. So instead of " you write \"

In that command:

"AT+CLPORT=\"TCP\",14550",

 

 

Comment by Veikko Vierola on July 25, 2012 at 1:40pm

In the modem .cpp all the lines begin and end with "-symbol. How can I write a command to the modem that includes "-symbol? Compile/Verify gives error if there is "-symbols between "-symbols....

For example if I want to send this comman to modem:

I should write it like this to the .cpp:

"AT+CLPORT="TCP",14550",

but I think it doesn't work with Arduino IDE because of the "-symbols on the TCP-text....

Is there some way to tell to the Arduino IDE that these "-symbols on this line are not begin and end symbols, these are suppose to be sent to the modem?????

Comment by Veikko Vierola on July 25, 2012 at 12:01pm

Should I use this to conf the port of modem? AT+CLPORT?

Comment by Veikko Vierola on July 25, 2012 at 11:38am

I managed to make a connection to the internet with the modem, because it answered to m y PING from the computer. I'm able to get the modem IP, but how could I get the PORT info too to establish the TCP connection. the command AT+CIFSR\r gives only ip not PORT info at all???


Developer
Comment by Andreas M. Antonopoulos on July 24, 2012 at 3:04pm

Here's the relevant page from the manual. It has been a while, I haven't checked and don't remember what it does. It worked in testing for me. It might be wrong!

Comment by Veikko Vierola on July 24, 2012 at 2:32pm

@Andreas

What does this parameter do, is this always the same or is this country/contract provider dependable?

"~~AT+CMUX=0,0,4,127,10,3,30,10,2", // GPRS/IP params

Comment by Veikko Vierola on July 24, 2012 at 2:27pm

@Larsen

Your concept is nice and the 450Mhz is very good - 120km Offshore and all...

We have similar option here in Finland too...

But I think the DronCell and standard 3G-modem on laptop will be also good once I get those parameters configured right :) I think I'm pretty close now...


Developer
Comment by Andreas M. Antonopoulos on July 24, 2012 at 2:21pm

Tommy: That is excellent, but we have still not seen documentation that other users (less experienced users) can apply. 

We would very much like to see documentation on your solution!

Comment by Tommy Larsen on July 24, 2012 at 2:15pm

I really must say that my solution is very good! Short time to connect to my Quad, and stable at TCP. And it takes the load of the APM2 by connecting to the UART0/2 interface.


Developer
Comment by Andreas M. Antonopoulos on July 24, 2012 at 2:14pm

Veikko, not that big a difference in speed. 

The issue is that some of the commands actually *do* stuff which takes a lot of time. 

The first dozen or so commands are all about make the settings right. 

The CIPCFG, CMUX and CSTT command will actually log on to the GPRS network and authenticate to the APN. Those three commands (the last especially) take longer to execute. So while you send them just as fast as the previous commands, the modem does not respond immediately. It takes some time to actually set up the GPRS connection before responding with OK. That's why you need to delay the commands that follow so that it doesn't try to send. 

If you need, you can also increase the timeout. I believe it is a #define in the Modem.h

Comment by Tommy Larsen on July 24, 2012 at 2:13pm

I have mounted a ICE broadband (Norwegian site) router in my car. This is based on the old cell phone frequencies at 450Mhz. This router has WiFi so i can connect to this from my laptop even some meters outside my car.

Comment by Veikko Vierola on July 24, 2012 at 2:11pm

@Andreas


Yes, I have to add more waiting symbols to other lines too. Maybe the reason for the slow reacting speed could also be related to the fact that I'm using 38400 baud speed rate for communication. Maybe it means that I have to double the amount of waiting symbols if compared to 57600 speed...??


Developer
Comment by Andreas M. Antonopoulos on July 24, 2012 at 2:04pm

Excellent, I was just about to suggest that Veikko. 

The problem is not that the command takes too long, it is that the previous command wasn't quite finished. You may need to add a delay in the next command too. Also, try adding just 1 delay symbol at a time and find what the minimum necessary is. Each ~ is 500 msec (1/2 sec)

Comment by Veikko Vierola on July 24, 2012 at 2:02pm

@Larsen

Do you have 3g modem also in your computer? Or are you using fixed ADSL etc..

Comment by Veikko Vierola on July 24, 2012 at 2:00pm
I managed to get rid of the modem timeout error and got answer from the modem when I added some additional waiting symbols ( ~ ) in front of the AT+CSTT command.....

ORIGINAL:

"~~AT+CSTT=\"%a\",\"%u\",\"%p\"",   // AT+CSTT="APN","username","password" - login to service provider/carrier

CHANGED:

"~~~~~~~~AT+CSTT=\"%a\",\"%u\",\"%p\"",   // AT+CSTT="APN","username","password" - login to service provider/carrier

Comment by Veikko Vierola on July 24, 2012 at 12:17pm

I don't know why I always get this error?:

Comment by Tommy Larsen on July 23, 2012 at 1:00pm

Veikko, yes they are both in the aircraft. The RN-174 is connected to UART0/2 and wirelessly to the 3g router.

Social Networking

Contests

Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.

A list of all T3 contests is here

Advertisement

© 2013   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service