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 Asaak on May 13, 2012 at 11:43am
I subscribe the idea of integrating the set up of the gprs parameters on the mission planner to make it more user-friendly.i am testing the system with an arduino shield.

Thanks for this good job Andreas!
Comment by Devin Johnson-Kinlaw on May 13, 2012 at 10:32am

One intention is to simulate the current binary setup that Xbee or the 3DRobotics radios utilize in telemetry feedback for the Mission Planner. Honestly, I don't see how Xbee or 3dr wireless data couldn't be routed over a data server on DroneCell; of course taking into account the appropriate bit rate/bps. Is transferring data not that basic? Now if the APMs already packet the data accordingly to MP standards, setup may be as simple as a hardware connection on APM telemetry ports. For reference:

"http://code.google.com/p/arducopter/wiki/APM2telemetry"

"http://code.google.com/p/ardupilot-mega/wiki/APM2Wireless" <Arducopter & Arduplane, respectively (Same)>

What I need to know about the radios is exactly whether they are just processing the information into the required transmission frequency or if there is some additional hardware implications. Of course, for full telemetry a base station DroneCell or generic cell for data transmission is needed. From what I've gained, one of the features in dynamic DNS is IP transmission of data rather than GSM/GPRS eliminating the need for the aforementioned base station cell phone and just an internet interface computer. Whichever the case, there shouldn't be much to it.


Developer
Comment by Andreas M. Antonopoulos on May 10, 2012 at 8:47pm

Devin - re: dynamic DNS

Dynamic DNS is not necessary, but makes things a lot easier. The flying cellular modem will attempt to establish a UDP or TCP connection to a specified address. The problem is that this address is specified in the code, and not yet easily configurable in Mission Planner or MAVLink (hope to get to this very soon). As a result, unless you compile the code in the field, you will need to set this well in advance of your flight. Now, imagine you set it to an IP address, but then take your laptop out to the field and end up with a different IP on the Wifi... Oooops, now your flying modem is trying to call the wrong IP. 

Dynamic DNS is not necessary, but it allows you to set your test copy to a fixed named address (not IP) - in my case it is something like uavXyZ.dronecloud.net, which is a domain I own and have dynamic DNS. Wherver I go, my laptop is always reachable also as  "uavXyZ.dronecloud.net" by dynamically "calling in" it's new IP address any time it changes and updating the DNS server.

 drone modem -> uavXyZ.dronecloud.net -> 10.1.2.3 -> my laptop.


Developer
Comment by Andreas M. Antonopoulos on May 10, 2012 at 8:40pm

I introduced a bug in the last version that means the APM2 support never worked and the APM1 support got worse. Ooops. I will be working on it over the next several days to repair. Until then, consider the test code inoperable. I will update on the next release, soon.

Comment by Devin Johnson-Kinlaw on May 10, 2012 at 8:34pm

I will be receiving a DroneCell within 48 hours. Then intend on participating in APM 2.0 testing. Also, I am not so much aware of the proposed Dynamic DNS architecture. Is this software or hardware that has yet to be developed. More so, is this medium between the computer necessary when comparing XBee systems and such? I have a moderate background in hardware dev, but not much else to date, esp with software, progging, scripting, etc. If anyone can clarify, please do.

Comment by ContraSpec on May 8, 2012 at 2:37am

i know this question may sound a bit on the off topic, but instead of these arb dynamic dns systems that sometimes tend to be slow on updates (up to 5 min) between ip changes, wouldnt it be safer to have the drone connect via a vpn connection?


Developer
Comment by Andreas M. Antonopoulos on May 5, 2012 at 2:24pm

Code has been updated.

Changes for cellular_modem_0.5:

- Now compiles and runs on APM2, not tested in the field yet

- Now runs on ArduPlane, as well as ArduCopter. It can easily be converted for ArduBoat or Rover, if anyone asks

- Code is in a cloned repository, separate from main repository now for testing and development. 

Comment by Asaak on May 5, 2012 at 1:23am

Andreas,

How are you doing with telemetry on APM 2.0? are we ( users of ardupilot ) going to be able to use it? please let us know your progress because there is a bunch of peopel really interested in this!

Thanks a lot for your work!

Comment by Matthew Peter on May 2, 2012 at 4:38am

Thank you for providing the link to this!
I will be purchasing the 3G module and begin testing next week.

I will let you know how i go :)

 

Comment by Asaak on April 25, 2012 at 10:53am

Thanks for the repply Andreas!

this is the one I have --> http://iteadstudio.com/store/index.php?main_page=product_info&c...

it works with a sim900 module, so as soon as I get the shield, I will start testing on my netduino!

I will keep you posted!

Thanks again!


Developer
Comment by Andreas M. Antonopoulos on April 25, 2012 at 10:27am

Asaak,

Standby, this week on early next week I will have APM2 code going! I'm glad you asked!

What model is the GSM/GPRS shield? Is it a SIM900 module?

Comment by Asaak on April 24, 2012 at 1:13pm

I have an APM 2.0 and a netduino + gsm/gprs shield. Please, I would like to try this on APM 2.0 and I read you said "let me know and I will accelerate dev"..so...please! :)

Thanks!

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service