Telstra SMS "Text Buddy" has some bug in the counter + "allow long SMS messages"?

After being charged extra , I discovered a bug in " Text Buddy
Software" which may explain my overcharge.
see posting
"Telstra SMS text buddy has a secret cost of 24 cents on the top of 25
cents?"

http://groups.google.com/group/aus.c...853533881b85d8

"Text Buddy" Tools > Message Sending > Allow long SMS messages

If " Allow long SMS messages" is ticked the counter shows one number
plus an other one in bracket on a blue or red background.

When " Allow long SMS messages" is ticked, if I write text until the
counter goes to and the counter going to 0(1) with blue background
something strange happen.
By adding one more character to the text message the counter will jump
from
0(1) with blue background to 143(2) on the red background.

Could any one explain why 143(2)? and NOT 159(2) on red background?

What's happening to the 17 characters between 160 and 143?

I am getting charged for an other empy page when the counter is at
0(1)?

Conned by Telstra

---

› See More: Telstra SMS "Text Buddy" has some bug in the counter + "allow long SMS messages"?

[email protected] wrote:
> After being charged extra , I discovered a bug in " Text Buddy
> Software" which may explain my overcharge.
> see posting
> "Telstra SMS text buddy has a secret cost of 24 cents on the top of 25
> cents?"
>
> http://groups.google.com/group/aus.c...853533881b85d8
>
> "Text Buddy" Tools > Message Sending > Allow long SMS messages
>
> If " Allow long SMS messages" is ticked the counter shows one number
> plus an other one in bracket on a blue or red background.
>
> When " Allow long SMS messages" is ticked, if I write text until the
> counter goes to and the counter going to 0(1) with blue background
> something strange happen.

I tested the "text Buddy " counter with a string of 160 characters.
You are welcome to paste it inside "Text Buddy".

1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890

Just add and delete one character at the time and see how the counter
jumps to more than one character.

George

[email protected] wrote:

>
> [email protected] wrote:
>> After being charged extra , I discovered a bug in " Text
>> Buddy Software" which may explain my overcharge.
>> see posting
>> "Telstra SMS text buddy has a secret cost of 24 cents on the
>> top of 25 cents?"
>>
>>
http://groups.google.com/group/aus.c...853533881b85d8
>>
>> "Text Buddy" Tools > Message Sending > Allow long SMS
>> messages
>>
>> If " Allow long SMS messages" is ticked the counter shows
>> one number plus an other one in bracket on a blue or red
>> background.
>>
>> When " Allow long SMS messages" is ticked, if I write text
>> until the
>> counter goes to and the counter going to 0(1) with blue
>> background something strange happen.
>
> I tested the "text Buddy " counter with a string of 160
> characters. You are welcome to paste it inside "Text Buddy".
>
>
1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
>
> Just add and delete one character at the time and see how the
> counter jumps to more than one character.

I'm not familiar with Text Buddy. But there is a limit of 160
characters per SMS message. Does Text Buddy add any text of
its own to your message? If so, that becomes part of the
160-character limit.

Once that limit is reached the message can be split into parts.
When such a split is done, each part can carry only 153
characters because some character positions get taken up by the
cross-referencing information (a "user data header").

If you want to see the technical standard covering this, search
for "GSM 03.40".

John

On 28 Sep 2006 20:03:53 -0700, "[email protected]" <[email protected]>
wrote:

>After being charged extra , I discovered a bug in " Text Buddy
>Software" which may explain my overcharge.
>see posting
>"Telstra SMS text buddy has a secret cost of 24 cents on the top of 25
>cents?"
>
>http://groups.google.com/group/aus.c...853533881b85d8
>
>"Text Buddy" Tools > Message Sending > Allow long SMS messages
>
>If " Allow long SMS messages" is ticked the counter shows one number
>plus an other one in bracket on a blue or red background.
>
>When " Allow long SMS messages" is ticked, if I write text until the
>counter goes to and the counter going to 0(1) with blue background
>something strange happen.
>By adding one more character to the text message the counter will jump
>from
> 0(1) with blue background to 143(2) on the red background.
>
>Could any one explain why 143(2)? and NOT 159(2) on red background?
>
>What's happening to the 17 characters between 160 and 143?
>
>I am getting charged for an other empy page when the counter is at
>0(1)?
>
>Conned by Telstra

The messages are still sent as seperate 160 character messages. The 17
characters are what links them together and aids the phone in getting
them in the right order at the end. When the phone re-assembles the
messages it doesn't show what is contained in those 17 characters. It
is the same when you send a long message from a handset too and my
Nokia certainly shows the counter drop to take this into account.

AJ wrote:

> The messages are still sent as seperate 160 character
> messages. The 17 characters are what links them together and
> aids the phone in getting them in the right order at the end.
> When the phone re-assembles the messages it doesn't show what
> is contained in those 17 characters. It is the same when you
> send a long message from a handset too and my Nokia certainly
> shows the counter drop to take this into account.

Only 7 character positions are used for the concatenated SMS
referencing overhead.

6 octets (48 bits) are required for the user data header itself
of a concatenated SMS.

An additional bit (value zero) is required to take the user data
header to the next septet boundary (7 characters = 7 septets =
49 bits). This is so that an old phone which doesn't
understand SMS concatenation will show uncorrupted text after 7
"rubbish" characters of misinterpreted user data header.

John

> I tested the "text Buddy " counter with a string of 160 characters.
> You are welcome to paste it inside "Text Buddy".
>
> 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
>
> Just add and delete one character at the time and see how the counter
> jumps to more than one character.
>
> George

On the replies above I can see no one in the answers has tested "text
Buddy" or their Mobile.

Everyone has repeated something about octet and header.
header of what?
If you go that way you forgot the data for the handshaking between the
mobile and the tower.

How do you know if the phone transmit Words or Dwords?
Your are just guessing!
Is the transmission a 8 , 16 or 32 bits transmission?
Size of the packets?

>> The 17 characters are what links them together and
> >aids the phone in getting them in the right order at the end
This is just a myth that some characters are needed to re-arranged the
data at departure & arrival.

Where did you get this information from?
Any URL to back it up?
a very fertile mind.

You have given some explanation but have not produced any data and no
backed up any of yoiur "fertile evidences".

On my email I purposely omitted some strange behavior on the counter
jumping more than one count when adding or subtracting one character
when in page 2 , 3 and 4 etc...

But no one has mentioned going above 2 or 3 or 4 pages of text and
what's happening to the counter.

I can see no one has checked anything.

Just activate the Netmonitor on your mobile phone and learn how your
mobile phone works before given Harry Potter fairy tales stories as
answers
and compare it with "Tesltra Text Buddy"

Ciao bambinos

George

[email protected] wrote:

> On the replies above I can see no one in the answers has
> tested "text Buddy" or their Mobile.

We're leaving some of the work to you.

> Everyone has repeated something about octet and header.
> header of what?

The header within the User Data field, that's implied by the
Used Data Header Indicator (UDHI) bit being turned on back in
the PDU-type field (GSM 03.40, clause 9.2.2).

> If you go that way you forgot the data for the handshaking
> between the mobile and the tower.

It simply has no relevance.

> How do you know if the phone transmit Words or Dwords?
> Your are just guessing!

I'm not sure what you're asking, and what relevance it might
have.

> Is the transmission a 8 , 16 or 32 bits transmission?
> Size of the packets?

Octets (8 bits). The septets of text from the 7-bit default
alphabet (GSM 03.38, clause 6.2.1) get packed into octets
(clause 6.1.2.1.1) for all store-and-forward purposes.

> This is just a myth that some characters are needed to
> re-arranged the data at departure & arrival.
>
> Where did you get this information from?

GSM 03.40, clause 9.2.3.24 is the primary source.

> Any URL to back it up?
> a very fertile mind.

www.etsi.org or www.3gpp.org - take your pick.

> You have given some explanation but have not produced any data
> and no backed up any of yoiur "fertile evidences".
>
> On my email I purposely omitted some strange behavior on the
> counter jumping more than one count when adding or subtracting
> one character when in page 2 , 3 and 4 etc...
>
> But no one has mentioned going above 2 or 3 or 4 pages of text
> and what's happening to the counter.
>
> I can see no one has checked anything.

No need - the standards don't suddenly change because it's
September 2006.

> Just activate the Netmonitor on your mobile phone and learn
> how your mobile phone works before given Harry Potter fairy
> tales stories as answers and compare it with "Tesltra Text
> Buddy"

Does your use of Netmonitor give you an alternative explanation
for the sudden loss of character-carrying capacity per SMS once
the SMS concatenation mechanism comes into play?

John

[email protected] wrote:
>
>> I tested the "text Buddy " counter with a string of 160 characters.
>> You are welcome to paste it inside "Text Buddy".
>>
>> 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
>>
>> Just add and delete one character at the time and see how the counter
>> jumps to more than one character.
>>
>> George
>
> On the replies above I can see no one in the answers has tested "text
> Buddy" or their Mobile.
>
> Everyone has repeated something about octet and header.
> header of what?
> If you go that way you forgot the data for the handshaking between the
> mobile and the tower.
>
> How do you know if the phone transmit Words or Dwords?
> Your are just guessing!
> Is the transmission a 8 , 16 or 32 bits transmission?
> Size of the packets?
>
>>> The 17 characters are what links them together and
>>> aids the phone in getting them in the right order at the end
> This is just a myth that some characters are needed to re-arranged the
> data at departure & arrival.
>
> Where did you get this information from?
> Any URL to back it up?
> a very fertile mind.
>
> You have given some explanation but have not produced any data and no
> backed up any of yoiur "fertile evidences".

Your an idiot.

"Larger content (known as long SMS or concatenated SMS) can be sent
segmented over multiple messages, in which case each message will start
with a user data header (UDH) containing segmentation information. Since
UDH is inside the payload, the number of characters per segment is
lower: 153 for 7-bit encoding, 134 for 8-bit encoding and 67 for 16-bit
encoding."

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

Nick Adams wrote:
> [email protected] wrote:
> >
> >> I tested the "text Buddy " counter with a string of 160 characters.
> >> You are welcome to paste it inside "Text Buddy".
.....
> "Larger content (known as long SMS or concatenated SMS) can be sent
> segmented over multiple messages, in which case each message will start
> with a user data header (UDH) containing segmentation information. Since
> UDH is inside the payload, the number of characters per segment is
> lower: 153 for 7-bit encoding, 134 for 8-bit encoding and 67 for 16-bit
> encoding."
>
> http://en.wikipedia.org/wiki/Short_message_service

Thanks Nick for your reply and interesting URL]

http://en.wikipedia.org/wiki/Short_message_service (great URL)

The URL mentions 153 which is a jump of 7 characters, but this is NOT
what I am seeing on my counter.

My counter jumps from 0(1) to 143(2) = 17 characters . ( I have NOT
mentioned anything about 153)

Can you or anyone else explain why it jumps 17 characters?

Ciao bambinos

George

[email protected] wrote:

> The URL mentions 153 which is a jump of 7 characters, but
> this is NOT what I am seeing on my counter.
>
> My counter jumps from 0(1) to 143(2) = 17 characters . ( I
> have NOT mentioned anything about 153)
>
> Can you or anyone else explain why it jumps 17 characters?

As I asked earlier, does Text Buddy add any text of its own to
your message? A small banner perhaps?

John

"John Henderson" <[email protected]> wrote in message
news:[email protected]...
> [email protected] wrote:
>
>> The URL mentions 153 which is a jump of 7 characters, but
>> this is NOT what I am seeing on my counter.
>>
>> My counter jumps from 0(1) to 143(2) = 17 characters . ( I
>> have NOT mentioned anything about 153)
>>
>> Can you or anyone else explain why it jumps 17 characters?
>
> As I asked earlier, does Text Buddy add any text of its own to
> your message? A small banner perhaps?
>
> John

I've just sent a 160 character message and 160 characters were received as
one message. There was no banner. If you go over 160 characters and you
enter the 161st character it tells you that you have 143 characters left.

Frank wrote:

> I've just sent a 160 character message and 160 characters were
> received as one message. There was no banner. If you go over
> 160 characters and you enter the 161st character it tells you
> that you have 143 characters left.

OK, once the 161st character was typed I'd expect there there to
be 145 characters left in part 2 of 2.

This is because part 1 of 2 contains 153 characters (it was 160
immediately before this, when it was part 1 of 1). The last 7
of the first 160 characters now become the first 7 of part 2.
The 161st character becomes the 8th character of part 2,
leaving (153 x 2) - 161 characters before part 2 fills.

Note that 8-bit numbering is generally used for concatenated
messages. If Telstra was using 16-bit numbering, only 151
7-bit characters are posible in each part, and I'd then expect
the remaining count to drop to 141 instead of to 145.

At the moment, I can't explain a drop to 143 on the 161st
character.

John

"John Henderson" <[email protected]> wrote in message
news:[email protected]...
> Frank wrote:
>
>> I've just sent a 160 character message and 160 characters were
>> received as one message. There was no banner. If you go over
>> 160 characters and you enter the 161st character it tells you
>> that you have 143 characters left.
>
> OK, once the 161st character was typed I'd expect there there to
> be 145 characters left in part 2 of 2.
>
> This is because part 1 of 2 contains 153 characters (it was 160
> immediately before this, when it was part 1 of 1). The last 7
> of the first 160 characters now become the first 7 of part 2.
> The 161st character becomes the 8th character of part 2,
> leaving (153 x 2) - 161 characters before part 2 fills.
>
> Note that 8-bit numbering is generally used for concatenated
> messages. If Telstra was using 16-bit numbering, only 151
> 7-bit characters are posible in each part, and I'd then expect
> the remaining count to drop to 141 instead of to 145.
>
> At the moment, I can't explain a drop to 143 on the 161st
> character.
>
> John

The 1st character of the 3rd part shows 151 characters remaining , if that
helps.

Frank wrote:

> The 1st character of the 3rd part shows 151 characters
> remaining , if that helps.

I'll give it some thought, but all the concatenated messages
forming the one larger message must be either 8-bit or 16-bit
numbering. That can't be changed mid-stream.

There are various complications possible, like including
characters from the GSM 03.38 extension table, each of which
requires 2 character positions. SMS software I've written
handles these correctly, but there's other evidence that
Telstra doesn't.

John

John Henderson wrote:
> Frank wrote:
>
> > The 1st character of the 3rd part shows 151 characters
> > remaining , if that helps.
>
> I'll give it some thought, but all the concatenated messages
> forming the one larger message must be either 8-bit or 16-bit
> numbering. That can't be changed mid-stream.
>
> There are various complications possible, like including
> characters from the GSM 03.38 extension table, each of which
> requires 2 character positions. SMS software I've written
> handles these correctly, but there's other evidence that
> Telstra doesn't.
>
> John

John

Telsttra is NOT the first carrier in Australia or in the world to
allow people to send SMS from their PC.
A freind of mine has VODAFONE PC and the price is Free or 25 cents
depending if the othe rmobile is on VODAFONE or NOT.

a few website of interest:


WEB2TXT from vodafone
http://www.vodafone.com.au/foryou/se...ces&ss=web2txt

http://www.geekzone.co.nz/content.asp?contentid=1021

http://business.three.com.au/index.c...&parentid=3241

http://www.traitel.com.au/sms.html

Why would the transmission protocol between carriers be different?
It make no sens.

As I say, there is a BUG in Telstra "Text Buddy".

George