GSM integration for spark core

I am working on little project that would act as security system powered by Spark Core. It would need to have GSM connection to provide internet/ WiFi. Any suggestions how to approach this ? As is now I am using MiFi modem that shares WiFi for Core - any other solutions/suggestions to use some extension/shield etc ?

Something like this will work and you need a shield shield to use the shield with the :spark: core :slight_smile:

Thank you for quick reply, look promising. Bit expensive tho but that is not an issue at ATM.

Yeah they are pricey. Sadly there was a buzz about gsm :spark: cores but I don’t think they will be available soon :slight_smile:

Would this thing do what I expect tho ? I will be using a REST API so I need constant mobile internet connection, will this handle serving it to spark core ? Browsing the specs I can’t see that happening. Does spark core support receiving data any other way than wifi ? If not this is not going to work. I am not interested in using shield to only send SMS messages or make calls, I need to have spark core connected to a device so it would have same functionalities as being connected to WiFi

This looks more like it:

but still don’t know if there is communication for spark core going on

Looks good! As long as the shield can handle Tcp/IP it should be fine :slight_smile:

Arduino shields are compatible with the :spark: core but library porting might be an issue if there’s some platform specific code inside.

@kennethlimcp could you provide some examples/tutorials/projects you know of using this configuration I mentioned. Also is there some specification from spark core that would treat about this kind of solution ? Thanks in advance!

It’s not official but mentioned it somewhere so I have to see if I can find it.

@dave this thread needs your input since i can’t hunt down the post you made regarding being networks that can allow TCP/IP will get us connected to the :spark: cloud. :smiley:

Hey guys!

Sorry about the slow reply!

Our protocol with the core is based on CoAP, which is designed to be connectionless. We’ve talked about using UDP instead of TCP in situations like GSM, and ultimately the protocol is designed to handle radio changes like this. It might take some firmware changes to make it rock solid, but I think it’s something we would love to see happen. :slight_smile:

If you wanted to rebuild or extend your core to use GSM, I think this is possible, but it may be a lot of work currently. If you’re using the core currently as-is, I’m guessing you wouldn’t necessarily want your core to be thinking it can get online both via Wifi and GSM, since resources are constrained. So I imagine you would need to tweak your firmware to use the GSM drivers and libraries to control that other GSM radio module, and you’d want to expose the tcp/udp functionality to the rest of the Core firmware.

I’m excited about the idea of Core + GSM, so I hope you share your build!


about one year is spent from the last answer in this post…
@jrlawniczak how did you resolve the issue?

I have a similar problem:
I have programmed my core to be connected to a SIM908 gps/gsm/gprs module by serial interface, using AT command to make HTTP request (GET and POST) to my Server.
All works satisfactorily, but now it became necessary that the Server must send a command to my core (client) occasionally during the normal communication already tested as described above.

How can I do it ? How can I configure my Client’s gsm modem ?
Must a request start always from Client necessarily so that the Server send a command to Client?

I think you have already faced this problem… which technique have you used ?


I know with new Spark Electron will not have this problem and I’ve already take a part in crowdfunding campaign ;), but I need to resolve this issue asap, I can’t to wait to october!

Hi @antonioaffi,

It depends if your project can tolerate some delay when the server needs to send the request, or if it needs to be near-realtime.

If delay is okay, I’d recommend having your GSM project connect on some regular interval and see if there are commands pending, and then stay online and wait for those, or otherwise go back to sleep.

If you need realtime, you can try to keep a TCP session open to a server somewhere and let your server push back down commands.

If your device supports low-power texting/paging sleep mode, you could sleep it and have your server send a wakeup text, and then have your device start a session. :slight_smile:

The low-bandwidth cloud and firmware stuff for the electron should also be available for other spark devices (I would assume), so that might help down the road as well.


Thanks for your answers! :blush:

the Server must send a command to my core (client) jsut occasionally (maybe one in a day or one in month) and in this case I will have a lot of useless requests, that generates more useless gprs data traffic (useless costs)

In this other case I can’t use HTTP request with standard Client-Server paradigm (standard communication model) but I need to open a TCP socket and leave open it to have a fullduplex communication. So I have to program a changing of communication layers,from the Application Layer (HTTP) to Transport Layer (TCP).
Is it right?

Hi @antonioaffi,

If you’re wanting to keep a session alive with the least possible data being sent, a UDP or TCP socket is probably the way to go. You’d need something on your server side to coordinate that, yeah.

What kind of time-scale are you on? This is essentially the same kind of problem we’re solving for the electron (keeping a realtime session open with absolute minimum data requirements). I’m thinking I’ll have a prototype of this available for a select beta over the summer if that timing works.


Hi @Dave,
I need to resolve this issue asap, I want to complete my project before summer.
When I will receive electron I will test comparing its connections performance with my project.

Thanks for support

Hi @antonioaffi,

Sure, makes sense, good luck! I hope you keep us posted / let us know if we can help :slight_smile: