Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Sending larger files by SMS

Status
Not open for further replies.

techie

Advanced Member level 3
Advanced Member level 3
Joined
Feb 5, 2002
Messages
839
Helped
58
Reputation
116
Reaction score
9
Trophy points
1,298
Location
Pakistan
Activity points
7,805
I have an application where a remote station connected by a GSM modem wants to send / receive reports + config files which are about 2 to 4KB in size. I am using SMS for this because I have found that GPRS is not as reliable as SMS since the service provider sometimes switches off GPRS channels when voice circuit load is high. The SMS is very rarely turned off. While I can handle a delay of a few minutes (on SMS), I cant handle the hours when GPRS channels are choked.

I want to know if anyone can tell me a good method to break-up a large file in packets of 160byte each to be sent over SMS and re-assemble after reception. THe packetization has to be very low overhead. Thanks.
 

I think you can send the 160 byte with a normal sms!
else you can add a compression before sending wich make it smaller!
 

If you had read my post carefully, you would not have posted this question.

I need to transmit 2 to 4KB data by SMS.
 

Hi techie

Some years ago we had a similar problem. We had to update the software of stand-alone systems by SMS. We have done it in the following way:

- The first SMS contains the amount of data to be sent and the CRC of the full file (we also had additional infos that filled up this SMS, but you could also transmit data already in the 1st SMS)
- The 2nd to nth SMS contains the data. The first Byte is the packet number (used for re-assembling). The last two bytes contains a CRC-16 of the 157bytes sent
- When the last SMS was received, the client gives an acknowledge. This could also contain an info, which packet (=which SMS) has to be sent once again

Take care of the following things:
- The chance of corrupted data inside the SMS is high (so use a CRC in every SMS to determine if the content is OK)
- You have no guarantee that an SMS will reach the receiver (SMS could be lost. So from 10 SMS sent, it's possible that you lost SMS #3)
- The receiving order could be different than the transmitted order

Best regards
 

    techie

    Points: 2
    Helpful Answer Positive Rating
Thanks. It looks good to me. A few questions though.

1. Why is there a chance of data corruption within an SMS. Isnt it using the CRC checks of GSM protocols.

2. What happens if packet#3 is lost/corrupted. Did you put a mechanism to retransmit a lost packet or did you start transmitting the whole file again.

3. How large a file did you tranmist. I am asking from the point of view of how many SMS can be sent to the same number one after another without some kind of buffer overrun or SIM capacity full etc.
 

Hi techie

As far as I know (sorry, some years ago) an SMS is not sent over the data channel of the GSM link. There is also a signaling channel, which has not the same error detection algorithms. We had an error rate (byte errors) of about 10-6. So if the CRC of one block was wrong (happened from time to time) it's OK to send this block again.

In the ACK SMS from the client (at the end of the transmission) there are fields to request lost/corrupted packets once again. The reception of these packets are ACK'd again, so at the end of a successful transmission the sender has a 'clear' ACK without any resend request.

Our files were about 12kBytes long. You have to take care that your memory (SIM-card for example) can hold these SMS if you are not quick enough to get them out of the phone. We used an OEM GSM module which was capable of storing 100SMS, so there was no problem.

Best regards
 

    techie

    Points: 2
    Helpful Answer Positive Rating
Sounds like a mini TCP/IP stack. Just curious. How much time (man-hours or man-days) involved in this development.
 

Actually there is support for multiple sms for sms message sizes exceeding 160 for 7 and 140 for 8 bits coding scheme . You can dig 3gpp (gsm transferred to it ) specs and brand's sites to get better information .
Google on "multiple sms" can help you also. Personally i dont have practical experience with multiple sms.

SMS is sent over dedicated data channel (sdcch) but can be sent over gprs channels too if mobile operator does have equipment supporting this.

BTW, i have found that sending sms's is more costly and there is no delivery time specified (best effort by sms center). Of course sms will be peding if destiantion subscriber is absent and resent when it becomes available.
For me data calls look better alternative. Our operator charges 1 sms as 12 second conversation.
 

BTW, i have found that sending sms's is more costly and there is no delivery time specified (best effort by sms center).

It is cheaper on some packages for small files than GPRS. But what matters more here is the down time. While I have practically observed that SMS down-time is the same when voice channel is also down (something that mobile operators cant afford or lose customers) but GPRS down-time is quite common and mobile operators do not seem to take this too seriously. The other thing is that when communicating via GPRS, we are also involving a web-server which make one more point where something can go wrong.
 

For data call i meant mobile modem data call which is not going via gprs network.

BTW , it seems your operator is very relaxed)
 

I think Artem brothers would say CSD conexion, where Your "remote" device make/attend a data call from "host" device...It´s better than SMS, because You can transfer large files without the needs of dismembering the archieve...

gorkin
 

artem wrote:
For data call i meant mobile modem data call which is not going via gprs network.
gorkin wrote:
I think Artem brothers would say CSD conexion, where Your "remote" device make/attend a data call from "host" device...It´s better than SMS, because You can transfer large files without the needs of dismembering the archieve...
Right! If you don't like GPRS, CSD is better than SMS. SMS is not suitable for long message transmission.

The General Packet Radio Services (GPRS) standard permits DATA transfers in a completely different way with respect to previous point to point communications made with Circuit Switch Data (CSD) GSM modems.

In CSD operations the modem establishes a connection with the other party (another modem) in such a way that all the Network devices in between are transparent to the data exchanged, simulating a real point to point connection, just as if the other party is directly connected with the controlling application of the modem. The other party can be either an Internet Service Provider (ISP) or a private server, but in any case, the arrival point must have a modem to connect to (Landline, ISDN or GSM CSD). The connection establishment procedure defines a particular path where all the information exchanged between the two peers flows and this path is reserved for exclusive use of these 2 peers for all the time the connection is active.

The speed of the data transfer is limited to 14400 bps.

With CSD you can use normal Voice Modem connected to regular telephone line (PSTN) on the other party computer, so it with established direct data link from your embedded system to the other party computer.
 

CSD connections require "data enabling" the SIM. Some operators discourage its use and I was unable to get it from my operator. But I do agree that this mode is the simplest and cheapest method.
 

Hi
I think you should make a software that take your file and encode this data to ascii codes then send them with sms and in receiver decode this ascii codes again.
 

i hope it can help you a lot...
Mobile.Messaging.Technologies.and.Services.SMS.EMS.and.MMS.2ed
**broken link removed**
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top