GSM module as UART peripheral: sending SMS with GPS coords in case of emergency landing

[nzs001]

Goal: Flight controller to send the GPS coordinates in SMS using AT commands on UART to the preset phone number with the connected GMS module in case of emergency situation, landing etc. to support finding the lost aircraft.

Purpose: During waypoint mission or long range autonomous flight out of RX or VTX range the in case of emergency landing, finding the aircraft is hard. In GSM coverage area, with a smart phone it would be possible. If this UART feature would be coded in the FC no additional MC is needed to process telemetry data and to send AT commands to the GSM module

Implementation: GSM module is connected directly to a UART port of the FC. Emergency conditions to be defined and configured in INAV: emergency landing performed, 0 ground speed for a while, call received on the GSM module, etc. SMS receiving phone number to be preset in INAV

If anyone is willing to make this a reality, I would be more than happy to test it!

Thanks, Zsolt Nagy

[digitalentity]

We were just recently discussing such thing amongst core developers.

[wx4cb]

I already have a number of these devices around somewhere. if i can find one, i'll be willing to donate to the cause - obviously you'd need to supply your own sim card LOL

[digitalentity]

I purchased this device - https://www.aliexpress.com/item/mini-A6-GPRS-GSM-Kit-Wireless-Extension-Module-Board-Antenna-Tested-Worldwide-Store-for-SIM800L/32714639345.html

Adding GPS/GPRS functionality to INAV is a rather big project, so don't expect this to be implemented very fast

[wilco1967]

Would be a nice project, but keep in mind, as a lost model finder, it depends on the FC still 'alive' after the crash. It won't work if the battery got disconnected in the crash.

Some idea: Perhaps some GSM modules exist, that have a possibility to connect a small battery (100mAh 1S or so), and can be programmed (by the FC, over a UART) to sent out an delayed SMS with the GPS coordinates after a delay of say 10 seconds. If everything is still flying ok, have the FC cancel sending the SMS before the 10 seconds have expired, so it never actually gets send. However, If the FC 'dies' (lost battery in a crash or so), or otherwise detects there is a problem, the GSM module would sent out the SMS, with the last 'good' GPS coordinates, using it's own battery power, once the 10seconds have expired (and it didn't get the command to cancel the last SMS).

If the FC is still happy and flying, it simply 'tells' the GSM module to forget about the last message, and prepare a new SMS, with new coordinates, to be sent 10 seconds later (which will also be cancelled before it actually gets send if everything is alright).

This would require a GSM module that can be programmed with a delay, and accepts cancelation of a SMS already prepared... don't know if something like that exists, but it would be a great feature...

kind of a tBeacon, but then using SMS / GSM.

[wx4cb]

If you were going to go with that complexity you might as well just use a small Arduino board with it that takes a a pwm input from the flight controller on a spare Channel.

when that disappears it just sends the GPS coordinates out.

I've actually done something similar vehicle tracking

[digitalentity]

Most GPS modules out there have pads for connecting a 1S LIPO.

Possibilities to use this feature:

1. Use GSM/GPRS to send telemetry to a user-defined web-service while FC is still alive
2. Use GSM to periodically send SMS messages on certain FC events

This is definitely not a proper replacement for lost model finder. An extension board that is smarter than FC and has it's own backup battery is a better solution, but no such board exist yet

[potater1]

Alright, I'm now testing a piece of GSM telemetry code that i added to INAV. It sends you a text message with the GPS coords and other info and is able to respond to an incoming phone call.

I haven't been able to figure out the configuration system yet, so all settings for this are hard coded at the moment. If anybody can explain how the port configuration and CLI variables are handled, I can maybe get something usable done fairly quickly.

[giacomo892]

@potater1 nice work! You can check how to add a setting from another PR (like https://github.com/iNavFlight/inav/pull/3349/files for instance)

[digitalentity]

Nice! I have some GSM related code in the works, but it's far from being ready. If your code is already functional it might be worth improving it 😄

[potater1]

Well the port opening part wasn't too hard after all... the alpha version is now done. See the gsm branch in my repository.

It's very simple to use, no settings required except the port and the PIN on the sim card (it has to be 0000). You make a phone call to the module, and you get back a text message like this:

VBAT:0 ALT:0 DIST:0 SPEED:0 SATS:0 GSM:27 google.com/maps/@65.1231237,24.3213216,500m

the coordinates being given as a Google maps link.

[shellixyz]

@potater1 Nice !

You could just require the PIN protection to be disabled. It is just as good as requiring a 0000 PIN. Why not waiting for a SMS instead of waiting for a call ?

[potater1]

Yeah didn't even think of disabling the PIN... it should work either way, I don't think the module minds it if you give it an unnecessary PIN.

Just calling the number may be quicker than sending a message, and it's free because the module doesn't answer the call. I'll add a text message receiving function if there's interest. I guess it would be for changing settings in mid flight?

[shellixyz]

In my country SMS are "free". I don't know any service subscription that doesn't allow the unlimited use of them. My idea was not to use them for changing settings but why not. The idea was only to use them to send a command/code instead of a call to prevent it from sending unwanted messages in case it receives an unwanted call/message.

[potater1]

I have a super cheap plan with unlimited data but calls and messages cost money.

Good point about unsolicited calls, you may end up sending messages to telemarketers. Of course we can make the ground station number configurable and only send messages to the configured number.

One useful thing would be sending a RTL command via gsm in case you want to abort the mission outside of transmitter range. I think this would have to be done by setting a given channel to a given value?

[shellixyz]

Of course we can make the ground station number configurable and only send messages to the configured number.

Indeed that would be an option

One useful thing would be sending a RTL command via gsm in case you want to abort the mission outside of transmitter range

Would be nice yes.

I think this would have to be done by setting a given channel to a given value?

You could do that but the best would probably be to change the mode switching logic to be able to force RTH on command.

[wx4cb]

One useful thing would be sending a RTL command via gsm in case you want to abort the mission outside of transmitter range

Would be nice yes.

I think this would have to be done by setting a given channel to a given value?

You could do that but the best would probably be to change the mode switching logic to be able to force RTH on command.

couldn't you just configure it to send a failsafe command?

[shellixyz]

@wx4cb Could be useful at some point but for now you can configure iNav to ignore FS during WP missions

[potater1]

A quick update... I added the capability to receive text messages, and it looks like we could use the activateForcedRTH() function to implement the RTH command in a very simple manner... not sure if we're supposed to call that function from outside the navigation system though.

I think it's time for field testing as soon as weather allows.. only thing left to add for a version 1 is the ground station number configuration parameter but it's not necessary for operation.

[potater1]

Well I think this thing is about done. I put in a config parameter for the phone number. Still haven't got a plane ready to test it in the air so not sure if the altitude and speed is reported correctly. Should happen pretty soon.

Do I just make a pull request now to get it to a branch that people use for testing?

The next feature I want to add is a notification message after landing/crashing. Is there a function or state flag in Inav that tells you when you've landed? In navigation_fixedwing.c there is the function bool isFixedWingLandingDetected(void) but it always returns false.

[teckel12]

@potater1 I don't believe there's an "is flying" flag. There's been discussions on creating this flag, as it would be useful with many other features as well.

[hali9]

At the moment, landing detection works for multicopter. For aircraft, there is no landing detection. But I think it can be done very simply. If the plane:

• has a motor off or in idle mode (flag NAV_MOTOR_STOP_OR_IDLE)
• does not move horizontally or vertically (posControl.actualState.velXY < 1 and posControl.actualState.abs.vel.z < 1)
• position (roll / pitch / yaw) does not change (attitude.values.roll, attitude.values.pitch, attitude.values.yaw)

for some time, for example 5s, it can be considered that the plane is not flying and that it is on the ground (or hanging on the tree :-)).

[teckel12]

@hali9 For multi-rotor, I believe landing detection is only for RTH? If you manually land or there's a crash, I don't think multi-rotor knows it's not flying.

But I agree with the logic. And creating an "is flying" flag would be super useful. Like being able to hit "Home Reset" and depending on if it's flying or not it would either reset home in 2D or 3D (altitude also if "not flying").

[shellixyz]

@potater1 Did you have time for field testing ? If you think it is ready please make a PR. We can add the landed/crashed notification latter. As @teckel12 there is no such flag available yet

[potater1]

Hi, I was delayed by a bug here for a while, fixed it today and will be putting the plane together tomorrow. I have some time off work next week so a test flight should happen if nothing goes wrong.

I'll be looking into doing landing/crash detection. I tried checking the accelerometer readings, looks like that could be a simple solution, for example just report a landing whenever >3g acceleration is detected.

[hali9]

Using acc is good idea. But I think >3g it is passible also during acrobatic or hard manevrous. When plane land I see in log that acc quick increse to >2g and then quick decrese to <-2g, So maybe detection of change acc about 3-4g in some short time.

There are issue for detection of fly https://github.com/iNavFlight/inav/issues/2331

[wx4cb]

you could probably do that and also check to make sure that the gps isn't changing and/or the speed/alt isn't changing.

On Sat, 2 Feb 2019 at 14:59, hali9 notifications@github.com wrote:

Using acc is good idea. But I think >3g it is passible also during acrobatic or hard manevrous. When plane land I see in log that acc quick increse to >2g and then quick decrese to <-2g, So maybe detection of change acc about 3-4g in some short time.

There are issue for detection of fly #2331 https://github.com/iNavFlight/inav/issues/2331

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/3948#issuecomment-459994662, or mute the thread https://github.com/notifications/unsubscribe-auth/ABbRARnUIPib7VAU0ZA3elBOvb5OUH1kks5vJe4SgaJpZM4X2k6V .

[shellixyz]

@potater1

I'll be looking into doing landing/crash detection

Very nice

Only testing for the acc > 3g doesn't seem enough to me. The flying detection needs to be robust enough and not trigger false negatives if we want to really use it. #2331 lists some of the potential uses for it and ideas on how to implement it.

You can also take a look at how it is done in ArduPilot for inspiration:

• Planes: https://github.com/ArduPilot/ardupilot/blob/master/ArduPlane/is_flying.cpp
• MRs: https://github.com/ArduPilot/ardupilot/blob/master/ArduCopter/crash_check.cpp

[potater1]

@shellixyz Yes, if we're gonna disarm based on this the threshold for acc must be set quite high.

I tried gyro readings also, this might be the best way to do it. Looks like the gyro on the SPRacing F3 can reliably tell whether the plane is lying still or moving even very slightly. But here you need to take an average of rad/s over a period of time, so landing detection is not instantaneous.

ArduPlane seems to have a pretty complicated logic for this, I'm thinking something simpler would be nice... If the acc and gyro readings are found to be reliable enough, I would just go with those, no need to even use GPS at all.

[hali9]

@potater1 I built and flash Your gsm branch. But unfortunately it did not work. I am using a modem to which the link has been provided by @digitalentity above. I made some corrections and finally managed it to work. If you feel like you can look (branch of gsm_telemetry). I have:

• improved the sending of AT commands. \r\n instead of \n.
• added 10s time to initialize the modem,
• added ATE0 to turn off the echo,
• merged the function into one main,
• change definition of gsmGroundStationNumber,
• remove atCommandStatus uses nowhere,
• improved the google link, now it points to the point with a pin.
• added checkGroundStationNumber to check if incoming call or SMS is from my phone.

Now a modem is connected to the softserial and I use a baudrate of 19200. When I call or sent SMS about content "T" then I get an SMS with telemetry and google link.. SMS is send also 10s after failsafe and then every minute.

[potater1]

@hali9 Hi, sorry I didn't reply earlier, somehow I missed this message. Thanks for the update! I just prepared and pushed a new version with a couple additional features: SMS sending at regular intervals (can be configured in cli and switched on an off during flight), and accelerometer based crash/landing detection + low g detection, also with cli parameters.

What was the fix that made it work for you? These modules seem to come with varying factory settings, so it's not a surprise that it didn't work out of the box. I didn't notice AT commands should be terminated with \r, somehow \n worked on my modules.

Failsafe reporting and caller number checking -- good ideas! And having the pin on the map is great.

Is it clearer to have all the code in one function? I thought it's getting pretty long.

[hali9]

What was the fix that made it work for you?

main fix is \r\n instead of \n also rebuilt code whitch reading data to gsmResponse, then it was works. modem sometimes don't response when push command before init, I have 2 cases, so I add 10s time to init (modem need 8-9 to be ready to work and report it by +CREG: 1)

Then I change sending SMS after +CLIP not RING because when incoming call then first is RING but don't know who call, then next is +CLIP: "ddxxxxxxxxx",145,,,,1 with number, and then is more RING. So better way is react on CLIP.

When modem receive SMS it sent +CMT: "+ddxxxxxxxxx",,"yyyy/MM/dd,hh:mm:ss+xx"<CR><LF>T<CR><LF> There is + before number so I change &gsmResponse[7] to &gsmResponse[8] but better way is find first " and then check if there is + and ignore it.

I didn't notice AT commands should be terminated with \r, somehow \n worked on my modules.

I think \r\n it is more universal and more common

Is it clearer to have all the code in one function? I thought it's getting pretty long.

For me yes

[teckel12]

By the way... What's the all-in cost for this? I ask because there's some small fully-contained IoT systems that could do this fairly easily that cost about $60. Something simple like getting the latest info packet from the flight controller every so many seconds which could be used as a deadman switch to initiate a text message with the last good info packet. Or request the last info packet.

[potater1]

@teckel12 I think this is the cheapest telemetry system available at less than $5 from Ebay. Cost is one reason I like this, I'm trying to keep it low overall for a long range build as the risk of losing a plane is higher at greater distances.

[potater1]

@hali9 I incorporated your suggestions in my version, thanks again!

When testing, did you get stuck in a nonfunctioning state, or did it recover eventually with a new AT command cycle?

Phone number format: should we use + or not? I guess we can require international format from the user, is the + always there as standard?

[wx4cb]

@potater1 for the most part, the +xx is required for cellular service. as you see that in the CID that you get from your carrier.

It harks back form the day when a mobile network didn't know what was local and what wasn't. I would personally require the +xxx to provide the best compatibility between networks.

[hali9]

When testing, did you get stuck in a nonfunctioning state, or did it recover eventually with a new AT command cycle?

Yes, these two times I wrote about earlier. Need modem power off and on. After adding 10s to the initialization, this did not happen anymore.

Phone number format: should we use + or not? I guess we can require international format from the user, is the + always there as standard?

I think that the format without a + should be written in gsm_ground_station_number (ddxxxxxxxxx). We should only check if CMT and CLIP contain + and if contain + then ignore it.

for the most part, the +xx is required for cellular service. as you see that in the CID that you get from your carrier.

I do not think so. I call and send SMS without +, and get call also without +, only SMS is incoming with +. Of course, we can send an SMS with +

sendATCommand("AT+CMGS=+\"");
sendATCommand((char*)telemetryConfig()->gsmGroundStationNumber);
...

But we must expect that the modem can send to us phone number without +.

[teckel12]

@potater1 Is GSM still active? In the US I believe it's short-lived. The $60 option I was looking at was LTE. I'm not sure what kind of SIM card I'd put in that $5 module, I'm fairly sure none of the major carriers would support it. Maybe this is an Europe-only thing?

[wx4cb]

GSM is still used by ATT and TMobile

[potater1]

That's sad to hear that 2G networks are getting shut down soon! I didn't know anything about it, to be honest I was under the mistaken impression that GSM was a part of the newer standards, and was gonna exist forever. This explains why the modules are now dirt cheap, industrial users aren't buying them anymore.

Looks like ATT ended GSM service but T-Mobile still has it to the end of 2020. The card they give you for the phone should work in the SIM800 module.

I think in many countries GSM will exist for a couple more years, here it should last at least 4, mandated by the government.

The SIM5320e module offers 3G and seems to have a very similar AT command set to the SIM800, so this code can probably be adapted easily for it as well. I saw a couple 5320e boards on eBay at around $20.

[teckel12]

Personally, I'd use the following, at least in the US: https://store.particle.io/products/boron-lte-kit

It would be a fairly simple process to communicate with the FC with this via UART and Particle's Device Cloud allows for very simple communications. For example, creating an iOS/Android app to track your model would be fairly simple. Actually, a mobile app could be used to control the model as well. Probably not actually fly it, but you could initiate a RTH, land or setup waypoints for example.

I've written a few mobile apps using Particle's Device Cloud and it's very powerful for not lot of effort or cost. LTE cellular is more expensive, obviously.

Now look what you've done! I'm now considering spending $60 to create an INAV mission planner/tracker/rescue mobile app.

[wx4cb]

@teckel12 hmmm not too bad... but don't you have to pay for their cloud services?

your board btw is 50 bucks at sparkfun: https://www.sparkfun.com/products/15069, there's also a lte and mesh network one too: https://www.adafruit.com/product/3998

There's also this: https://www.adafruit.com/product/3612 - thsi can also use SPI and I2C as well as uart.

I have a number of sim800 boards for arduinos that I can nolonger use cus they don't work any more cellular wise (att devices)

[teckel12]

@wx4cb For their WiFi products no. For cellular it's free for the first 3 months and something like $3/month after that. I've never used their cellular products, but they all work the same on their cloud network.

The mesh network is from device to device, and the Boron support it. But it's not useful for INAV purposes. I'm fairly sure you could do I2C with Particle's Boron. It includes Bluetooth as well, which could be used for ground control of waypoint missions without using cellular.

[wx4cb]

@teckel12 ahh that makes sense... but i was thinking. mesh network you could use it to talk to other AC in the air with you and then have the code send coords of other aircraft it can hear in case they can't communicate back cus they're in a ditch out of cellular range for example. If that makes sense.

[teckel12]

I use their mesh technology and it's low powered as it's designed to be in close proximity (like several sensors in your home). I imagine the range is only a few hundred feet in the air. Think of it as more of a proprietary bluetooth communication, with very limited range. Also, as it's 2.4 GHz, you could be causing transmitter interference.

What it's designed for is something like this. Imagine a remote cabin that doesn't have Internet. You could use one cellular Boron and then several cheap mesh systems monitoring different things, like the temperature, water leaks, security, fuel tank levels, etc. This greatly lowers the cost to monitor different things in different locations of the cabin as only one cellular connection is needed. Not really useful for flying models.

[potater1]

Hey look up the SIM7000 also, it's available at around $30. Looks to be compatible with the SIM800 for messaging, and it has LTE Cat M1 (375 kbps) and NB-IoT for low power data comms. With this module you could post updates to the cloud, or possibly have a MSP stream open continuously? SIM7000 also has GNSS, but I'm not sure it can be used to provide NMEA data to the FC while issuing AT commands at the same time.

Actually we could try cloud updates using HTTP on the SIM800 already. I thought SMS sending would use less power, but maybe not? I saw a test of the SIM7000 where the power consumption was about the same for sending an SMS vs. a HTTPS request.

[wx4cb]

hey guys... what's the carrier most people are using for their sim808 modules. I have a couple of modules here, but i can't get them to work on verizon, i checked and they said, they pretty much have no more gsm service now.

[wilco1967]

I finally got myself a SIM800L module, and did some flight testing today.

Seems to work fine, but 2G coverage is spotty it seems where I fly. Sometimes it works, sometimes I get a busy signal, SMS messages sometimes never arrive, sometimes late. Guess that is to be expected.

But I found one potential problem. When I send RTH command through SMS, the plane started to come back. But there seems to be no way, of canceling the RTH, from the transmitter. I tried sending another SMS RTH to cancel, but no response. This may just be a missed SMS, but I could not get it to cancel RTH, and it kept circling above the safehome location after it came back, without me having any control.

I finally disarmed in flight, and re-armed again, to get control back, That cancelled RTH, and I could land safely.

Sure there must be some way of regaining control, from the transmitter, without disarming, and without sending another SMS (which may never arrive). For example, A toggle from RTH to another flightmode (and back) from the Tx should do the trick ?

I only tried one other SMS RTH to try to cancel it. maybe another attempt would have worked, but I put all my efforts to cancel it from the Tx as it was circling above home.

[potater1]

Thanks for the input! Yes, another RTH SMS should cancel it.

Good point that there is no way to get out of forced RTH if the cancel message doesn't go through. Maybe the RTH message should be redefined to be a "go into failsafe" message instead, having the same effect as losing radio signal?

Btw I noticed a problem when looking at the failsafe code: if you cancel RTH with a second SMS while failsafe RTH is in progress, it should case a landing to happen!