Data exchange over a GSM voice call

[pozz]

I know there is the CSD call (Circuit Switched Data) to make a 9600bps
digital communication between two mobile phones or between a PSTN analog
modem and a mobile GSM modem, but it is difficult to use for normal user.

First of all, the SIM that you can purchase from the local shop isn't
usually enabled by default for CSD. You have to ask (and pray) the
operator to enable data communcation on the SIM. In most cases, the
operator assigns one or two additional numbers to the SIM: one for CSD
(data) and one for fax. Some operators don't allow this kind of calls
with prepaid SIM cards.

Another problem is with Android apps. I'd like to develop an
Android-based app that make a call to an embedded object that integrates
a GSM modem (actually SIM900 from SimCom) for data exchange. I'm
starting with Androdi development and it seems it isn't simple to make
CSD calls.

So I'm thinking to avoid CSD at all and reinvent another data
communication system over a normal voice call that all GSM operators
support and it simple to make in Android.

The first solution that came to my mind was DTMF. SIM900 modem has an
embedded DTMF decoder and is able to generate DTMF tones over a voice
call. Moreover I think it's possible to have the same things (DTMF
generation and decoding) in a app based on Android.
I'll have to make some tests, but it seems a DTMF decoder could
correctly detect a tone if its duration isn't less than 40-50ms. This
means about 4/0.05=80bps.

I don't need a high bitrate, but it would be interesting if there are
other solutions that allow a higher bitrate than 80bps.

I was thinking about a modulation scheme of the analog voice signal, but
GSM is a digital system oriented for voice transportation, so the phone
immediately digitize the analog voice and *compress* it loosing many
informations. I think I'll have an analog signal completely different
to the other end of the communication.

Any good solutions?

[Dave Nadler]

CSD is not available in most markets internationally,
and is being discontinued in many markets where it
still exists. Don't use it...

Why not use a separate connection for data?
Either SMS or GPRS?

If you use a data connection like GPRS, be aware that
the connection will be NAT'd in telecom connection,
so invisible to other parties (you'll need to connect
to a known address). I did a project using OpenVPN
over GPRS and solved this issue with a "gateway" server
so technicians (also with NAT'd connection) could
connect to the device - worked well.

Hope that helps a bit,
Best Regards, Dave

[pozz]

Il 27/09/2014 16:44, Dave Nadler ha scritto:
> CSD is not available in most markets internationally,
> and is being discontinued in many markets where it
> still exists. Don't use it...

You confirm my first impression on CSD.

> Why not use a separate connection for data?
> Either SMS or GPRS?

SMS and GPRS are expensive both for sender and destination SIM.

If data could be exchanged over a voice call, only the SIM that
originates the voice call will pay. This is extremely useful when the
remote device uses a prepaid SIM card that doesn't pay any constant fee.

[David Brown]

If you are using any sort of quantity, it will almost certainly be
cheaper to get data-only SIM cards and use data rather than voice on the
embedded system.

[pozz]

Il 27/09/2014 17:16, David Brown ha scritto:
> If you are using any sort of quantity, it will almost certainly be
> cheaper to get data-only SIM cards and use data rather than voice on the
> embedded system.

What do you mean with "data-only" SIM cards? GPRS or UMTS connectivity?
At least in Italy, you have to pay a monthly fee for this type of SIM
cards, no less than 5€ per month.

With voice only calls, I could use super simple prepaid SIM cards that
is charged only when the call is generated by the SIM card and not when
the call is *terminated* to the SIM card.
In my application, the embedded object never initiates a call, but it
only answers to incoming calls. In this scenario, the SIM card in the
embedded object is never charged. I only have to remember the
expiration date (usually 11-12 months after the last recharge).

The SIM card in the mobile phone is also used for "personal"
communication and usually already pays a monthly fee for a big amount of
voice calls minutes. For example, 500 minutes per month for 10EUR. In
this scenario, the communication between mobile phone and my embedded
object doesn't add any cost at all to the user.

[David Brown]

On 28/09/14 07:35, pozz wrote:
> Il 27/09/2014 17:16, David Brown ha scritto:
>> If you are using any sort of quantity, it will almost certainly be
>> cheaper to get data-only SIM cards and use data rather than voice on the
>> embedded system.
>
> What do you mean with "data-only" SIM cards? GPRS or UMTS connectivity?
> At least in Italy, you have to pay a monthly fee for this type of SIM
> cards, no less than 5€ per month.

I didn't pay anything - the customer organised it. But I'm guessing
that quantities can have a large influence on the price.

In many countries, it costs to have a "normal" telephone number, since
there is a limited range for them. The cost might be hidden for normal
users, and is covered by the monthly fee, a one-off cost, minute price,
or whatever. But a data-only SIM card does not need a telephone number,
and therefore the telephone companies prefer it.

Very often, such SIM cards are used in connection with a system that
already has some sort of monthly fee (alarm system, tracking system, etc.).

You haven't said whether you are building one system or ten thousand
systems, or anything else about how often you want contact, which makes
it very hard to give advice.

[pozz]

Il 28/09/2014 11:58, David Brown ha scritto:
> On 28/09/14 07:35, pozz wrote:
>> Il 27/09/2014 17:16, David Brown ha scritto:
>>> If you are using any sort of quantity, it will almost certainly be
>>> cheaper to get data-only SIM cards and use data rather than voice on the
>>> embedded system.
>>
>> What do you mean with "data-only" SIM cards? GPRS or UMTS connectivity?
>> At least in Italy, you have to pay a monthly fee for this type of SIM
>> cards, no less than 5€ per month.
>
> I didn't pay anything - the customer organised it.

Someone, you or your customer, pays. I'm not interested who pays.

> But I'm guessing
> that quantities can have a large influence on the price.

In my application I prefer to let the customer choose the mobile
operator he wants, but the customer has only a few systems.

> In many countries, it costs to have a "normal" telephone number, since
> there is a limited range for them. The cost might be hidden for normal
> users, and is covered by the monthly fee, a one-off cost, minute price,
> or whatever. But a data-only SIM card does not need a telephone number,
> and therefore the telephone companies prefer it.

Are you sure data-only SIM cards don't need a telephone number? I know
they can receive and send SMS and there's a real telephone number
associated with them.

> Very often, such SIM cards are used in connection with a system that
> already has some sort of monthly fee (alarm system, tracking system, etc.).

You think about a company that rents an all-in-one system (for example,
an alarm system) to a customer that pays a monthly fee to the company
(not to the mobile operator). It's the company that purchase a lot of
SIM cards from the mobile operator and they are M2M SIM cards. The end
customer doesn't care about SIM cards (expiration date, residual credit
and so on).

I'm going to contact some mobile operators to discuss the business of
M2M SIM cards, but in my actual systems it's the end customer that
purchase and install and recharge the SIM card. He doesn't want to pay
a lot for that SIM card and this is the reason why I was thinking about
data exchange over a voice call.

It seems you already worked with M2M SIM cards. COuld you give me an
idea about the monthly fee of those SIM cards? I think it depends on the
maximum amount of data that can be exchanged.

> You haven't said whether you are building one system or ten thousand
> systems, or anything else about how often you want contact, which makes
> it very hard to give advice.

As I explained, I could build 10kpcs but it doesn't change the scenario.
The end customer will have to purchase the SIM card.

[upsid...@downunder.com]

On Sat, 27 Sep 2014 16:34:05 +0200, pozz <pozz...@gmail.com> wrote:

>So I'm thinking to avoid CSD at all and reinvent another data
>communication system over a normal voice call that all GSM operators
>support and it simple to make in Android.
>
>The first solution that came to my mind was DTMF. SIM900 modem has an
>embedded DTMF decoder and is able to generate DTMF tones over a voice
>call. Moreover I think it's possible to have the same things (DTMF
>generation and decoding) in a app based on Android.
>I'll have to make some tests, but it seems a DTMF decoder could
>correctly detect a tone if its duration isn't less than 40-50ms. This
>means about 4/0.05=80bps.
>
>I don't need a high bitrate, but it would be interesting if there are
>other solutions that allow a higher bitrate than 80bps.
>
>I was thinking about a modulation scheme of the analog voice signal, but
>GSM is a digital system oriented for voice transportation, so the phone
>immediately digitize the analog voice and *compress* it loosing many
>informations. I think I'll have an analog signal completely different
>to the other end of the communication.

While it is very hard to transfer any random audio waveform (such as
modem signals) over a cell phone, in which the codec is designed to
compress _speech_ effectively, the 80 bps for DTMF sounds a bit low.
DTMF is essentially two 4FSK signals. You may have to experiment with
more or perhaps less frequencies with different frequency spacing to
find the best throughput.

[David Brown]

On 28/09/14 16:00, pozz wrote:
> Il 28/09/2014 11:58, David Brown ha scritto:
>> On 28/09/14 07:35, pozz wrote:
>>> Il 27/09/2014 17:16, David Brown ha scritto:
>>>> If you are using any sort of quantity, it will almost certainly be
>>>> cheaper to get data-only SIM cards and use data rather than voice on
>>>> the
>>>> embedded system.
>>>
>>> What do you mean with "data-only" SIM cards? GPRS or UMTS connectivity?
>>> At least in Italy, you have to pay a monthly fee for this type of SIM

>>> cards, no less than 5� per month.

>>
>> I didn't pay anything - the customer organised it.
>
> Someone, you or your customer, pays. I'm not interested who pays.

Someone /always/ pays :-)

If you want to use a special method of communicating over voice calls,
then the development time compared to standard TCP/IP over data must be
taken into account. I expect you have already spend more money thinking
about this than it would have cost for the lifetime of the project at �5
per month.

>
>
>> But I'm guessing
>> that quantities can have a large influence on the price.
>
> In my application I prefer to let the customer choose the mobile
> operator he wants, but the customer has only a few systems.
>

If it is only a few systems, then consider the �5 per month per system
as part of the budgeted costs, along with development time. And if
reliability and maintainability is an issue, then when that is factored
in the decision becomes a no-brainer.

>
>> In many countries, it costs to have a "normal" telephone number, since
>> there is a limited range for them. The cost might be hidden for normal
>> users, and is covered by the monthly fee, a one-off cost, minute price,
>> or whatever. But a data-only SIM card does not need a telephone number,
>> and therefore the telephone companies prefer it.
>
> Are you sure data-only SIM cards don't need a telephone number? I know
> they can receive and send SMS and there's a real telephone number
> associated with them.

Yes - M2M cards do not need a telephone number. They have various other
numbers (SIM card number, ICCID number, etc.) but not a "normal"
telephone number. For the ones that I have tried, you can send SMS to
and from the card - but not directly. SMS works between the cards and
the provider's central servers. So to use SMS with such cards, you have
to log on to the provider's servers and go via them (there will be API's
in place to automate this, along with web interfaces for testing).

It is quite possible for a provider to make SIM cards that are normal
SIM cards, but for which voice calls are disabled (just as they make
such cards with data traffic disallowed). That's a different matter -
they are not true M2M cards, but simply limited normal cards.

>
>
>> Very often, such SIM cards are used in connection with a system that
>> already has some sort of monthly fee (alarm system, tracking system,
>> etc.).
>
> You think about a company that rents an all-in-one system (for example,
> an alarm system) to a customer that pays a monthly fee to the company
> (not to the mobile operator). It's the company that purchase a lot of
> SIM cards from the mobile operator and they are M2M SIM cards. The end
> customer doesn't care about SIM cards (expiration date, residual credit
> and so on).

Correct.

>
> I'm going to contact some mobile operators to discuss the business of
> M2M SIM cards, but in my actual systems it's the end customer that
> purchase and install and recharge the SIM card. He doesn't want to pay
> a lot for that SIM card and this is the reason why I was thinking about
> data exchange over a voice call.

End-users don't get M2M SIM cards, and they don't negotiate with the
providers or access their servers.

If the end user wants to handle the SIM card then he must buy normal SIM
cards, but perhaps with limited features.

Ask your customer if he wants to pay you thousands of euros to implement
a data-over-GSM-voice system to save him a couple of euros a month.

>
> It seems you already worked with M2M SIM cards. COuld you give me an
> idea about the monthly fee of those SIM cards? I think it depends on the
> maximum amount of data that can be exchanged.

Sorry, I've no idea about the pricing (the customer arranged it :-) -
but in this case, the customer arranged it for many thousands of
systems). I just know a little about the technicalities, and I know
that having a normal telephone number and being accessible from other
phones (by SMS or voice) costs money for the operator - and it is
therefore cheaper if it can be avoided.

But I believe that true M2M SIM cards will not be an option for you,
because end-users can't get them.

>
>> You haven't said whether you are building one system or ten thousand
>> systems, or anything else about how often you want contact, which makes
>> it very hard to give advice.
>
> As I explained, I could build 10kpcs but it doesn't change the scenario.
> The end customer will have to purchase the SIM card.
>

It makes a world of difference if the SIM card purchaser is a single
customer who buys 10K and then re-sells on to the actual end-user, or
the end-user who buys just one card for their own use.

[Dimiter_Popoff]

Perhaps 2400 Hz would make it through? If so doing the ancient
"Kansas City" encoding (4 periods 1200 Hz a 0, 8 periods 2400 Hz a 1)
would do 300 bps .... (IIRC). Implementing that would be a negligible
effort. A 532 byte PPP packet would take what, around 15 seconds...

I wonder how many of us remember that sort of thing.... :D . I do
because I did it a few times for the 6800 and 6809 (tape interface....).

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

[Boudewijn Dijkstra]

Op Mon, 29 Sep 2014 09:52:00 +0200 schreef Dimiter_Popoff <d...@tgi-sci.com>:

> On 28.9.2014 г. 18:01, upsid...@downunder.com wrote:
>> On Sat, 27 Sep 2014 16:34:05 +0200, pozz <pozz...@gmail.com> wrote:
>>
>>> So I'm thinking to avoid CSD at all and reinvent another data
>>> communication system over a normal voice call that all GSM operators
>>> support and it simple to make in Android.
>>>

>>> [...]

>>
>> While it is very hard to transfer any random audio waveform (such as
>> modem signals) over a cell phone, in which the codec is designed to
>> compress _speech_ effectively, the 80 bps for DTMF sounds a bit low.
>> DTMF is essentially two 4FSK signals. You may have to experiment with
>> more or perhaps less frequencies with different frequency spacing to
>> find the best throughput.
>
> Perhaps 2400 Hz would make it through? If so doing the ancient
> "Kansas City" encoding (4 periods 1200 Hz a 0, 8 periods 2400 Hz a 1)
> would do 300 bps .... (IIRC). Implementing that would be a negligible
> effort. A 532 byte PPP packet would take what, around 15 seconds...
>
> I wonder how many of us remember that sort of thing.... :D . I do
> because I did it a few times for the 6800 and 6809 (tape interface....).

There's even a Wikipedia article about it:
https://en.wikipedia.org/wiki/Kansas_City_standard


--
(Remove the obvious prefix to reply privately.)
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/

[Randy Yates]

Yes, use the built-in data services that are omnipresent. This seems
like a self-imposed problem. Why not use GPRS? As long as the two ends
have "data" service, you're done.
--
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

[Randy Yates]

A class B device would serve your needs. Even at CS-1 you get 8 kbit/s
per time slot.

http://en.wikipedia.org/wiki/General_Packet_Radio_Service