mgaman/pdulib

Encode/Decode PDU strings for use with most GSM modems. Both 7 bit and 16 bit alphabets are supported.

pdulib's Issues

PDU decoding doesnt work reliable

Hello, when I decode an sms with greek letters, it doesn't decode Sigma (Σ) or other characters. It just showing boxes instead.

Decode the outgoing message captured via serial, coming from a centralized system

Hi

I would need to decode the GSM 3.38 message sent from a centralized system because I need to make integrations with it.
the example message that the system sends is like this;

02919311000181F000000B3EC7690B0683C1603250D04D7FBBD36F90343D1E97D9EC34A8EA02F15A31182C3693C560329B6C46F3815A20282C060ACACBE11808454C01

however the library does not decode outgoing messages.
how can i fix this?

Thank you
Antonio

Decoding PDU with english characters sometimes is wrong.

Hello, during my tests I found that some pdu decodes using the english alphabet were a bit wrong.
I sent from my phone this message PUMP ON
This is the PDU I received 07910396539900F0040C9103968314168400002221317093738007D06A130A7A3A01

When I decode it, it prints this: PUMP ON@
It appears a "@" character at the end of mypdu.getText()

On the other side, if I send PUMP OFF, it prints just fine.

This shouldn't be a problem unless you compare strings to turn on or off things.

Library version I'm using is 0.5.7

Macro PM breaks GSM-7 translation

If the macro PM is set for Arduino compilations, translation of escaped GMS-7 characters is broken e.g. Euro, { }

Latin diacritic characters not recognized as GSM 7 bit

In scanning a message to decide if can be sent as a 7 bit or 16 bit alphabet, Latin diacritic characters are not recognized. Because of this a message that could be sent as a 160 character 7 bit string will be sent as a 70 character 16 bit string.
Not a problem if the message is less than 70 characters but annoying if greater than 70 characters.
In summation, sub-optimal adherence to the GSM standard.

first character lost in multipart GSM7 message

The character immediately following the UDH field in a mutltipart GSM7 message is skipped and not included in the final output.
This bug does not appear in UCS-2 16 bit messages

SCA number assumed to be an international number

The code assumes that the SCA number has the prefix +, may not always be true

Not an issue, but a question

This library works fine. I have a question though.
I recently found that on an arduino mega, encoding a simple 50-character sms comsumes about 700 bytes of ram.
This is not very good for big projects. The thing is, does this library consume heap ram or stack? If it's stack I guess it's fine, but if it uses the heap it's going to be problematic if the board has to work long time.

All parts of a multipart encoded message are prepended with a space

When encoding multipart messages, every part has a prepended space.
Also when a multipart with 1 parts is encoded, the space is prepended.
Verified on my smart phone by observing the received SMS
Verified using the encoded string on https://www.smspdu.be; by viewing the HTML source you also see the prepended space

Using version 0.5.7 (also tested with 0.5.5: same result)

Alphanumeric Origin Address too long

The origin address (OA) section of a PDU gives the length of field in Nibbles (4 bits). When the Address Type part of the OA is alphanumeric, the OA length must be converted to septets i.e. (length*4)/7

Compiler complains on fallthrough

Compiler for ESP32 in PlatformIO complains on fallthrough

.pio/libdeps/esp32dev/pdulib/src/pdulib.cpp: In member function 'int PDU::decodeAddress(const char*, char*, eLengthType)':
.pio/libdeps/esp32dev/pdulib/src/pdulib.cpp:963:22: warning: attribute 'fallthrough' not preceding a case label or default label
       [[fallthrough]];
                      ^

Removing the semicolon (;) after [[fallthrough]] seems to fix the issue.
Using 0.5.7

Encoding of UTF16 code points incorrect

Characters in the range range U+10000 to U+10FFFF should be converted to UCS2 surrogate pairs, which is not currently handled.

GetConcatInfo

The documentation is incorrect, the indices 1 & 2 in the returned vector were swapped.
The implication that any part of the returned vector being zero indicates a standalone message is incorrect as index 0 (reference number) may be zero. This is set by the originating device which sets the reference number as it see fit.

I can either change the documentation or the source code.

My decision is to change the documentation and leave the source unchanged.

Re-order defaults and priorities

The existing concept (up to version 0.5.4) is that the library is aimed at the desktop user and the Arduino user has to make adjustments to the IDE (PlatformIO or Arduino) to use it.
This has proved to be a source of confusion and generally a bad idea.
The concept will be inverted so that the Arduino user will use the library as-is and the Desktop user will have to make the necessary adjustments.

getSCAnumber may retrieve wrong value

getSCAnumber may be used in 2 circumstances.
1 Internally by encodePDU after it was initialised by setSCAnumber. In this case there is no problem.
2. By the user after calling decodePDU. In this case the wrong value is returned.

The bug is that there is a confusion between the SCA number for outgoing SMS and the SCA number of incoming SMS.

GSM7 encoding misses 2 characters

The check for a characters in the GSM7 default character set ignores carriage return/line feed. A message containing these characters gets treated as non-GSM7 so is sent in 16 bit rather than 7 bit format.
The message is sent correctly but is limited to 70 characters in length.

version 0.5.5 and 0.5.6 doesn't produce any output

As the title says these 2 versions of the library doesn't seem to encode and print the USC2 string. It prints nothing. I'm switching to 0.5.4 that seems to work fine.

Symbols repeated thus waasting space

The translation tables in pdulib.h should be moved to a new location to avoid multiple copies being generated.
This is not a bug that generates faulty code but it does waste space which is bad in the embedded e.g Arduino world

Encoding algorithm is wrong!

When u don't use

buildUtf();

function, it's works like a charm. So, then i did not understand why example includes this function.
All i need to get it to works:

char sms[240]="Hello"; // will be 7bit encoded
char sms[140]="Hello 明けましておめでとうございます。"; //will be 16 bit encoded
strcpy(msg,sms);
len = mypdu.encodePDU("+**********",msg);

Pls, tell me, why do i need buildUtf() and how it's works?

Library doesn't encode properly for SIM800

Hello and thank's for creating this library!

While I can encode some chinese or other utf8 characters, when I decode them on any on-line decoder everything is fine. But when I try to send the sms with your library's encoder, it doesn't sending. The modem gives back error. If I encode the same exact text on an online pdu encoding site, the sms is sending fine. I use the SIM800C module with arduino uno.

The actual site that encoded my message is this (https://www.smsdeliverer.com/online-sms-pdu-encoder.aspx)

You can see that with your library using phone number [phone] and this text 祝您有个美好的一天 the output is: 01A101000C91042143658709000812795D60A867094E2A7F8E597D76844E005929� (31 characters)

The link I provided above creates this output: 0011000C9104214365870900080B12795D60A867094E2A7F8E597D76844E005929 (32 characters)

Theres a small difference at the starting characters.

Decoding them, they are the same btw.

First character missing in all parts of multipart message

Library works fantastic on both single and multipart messages. But when I send a long message from my iPhone, the parts are longer (167 bytes) than for example multipart messages received from my provider and each part is missing the first character upon decoding.

This is a PDU that decodes wrongly: 07911326040040F5440B911300000000F0000022114180348240A005000300040182757AB90D22BFD96F79790E7A93D37450990E6AA7DDF539C85E6683DEE4F41B149EC3CB7277985E9783EA7417C8196E83E2F5741854C697E5E3343D4C4FBFDDE536284D06B9D3F334285CA7BB40D2F2B83E0FBBC9E132282C0695C3A0F49C5E0685EB74D03C4D07C1DFF379BA5D9F83E2F5B40B141C8FEBF370BB3E0791D3737ADA3DA6A7DF

It should have decoded into: Autem dolores odit et minus vel odio aspernatur ut. Nam quia exercitationem id nisi aut. Recusandae ab ea iste aut sit possimus qui. Accusamus distinctio
But instead it is decodes into: utem dolores odit et minus vel odio aspernatur ut. Nam quia exercitationem id nisi aut. Recusandae ab ea iste aut sit possimus qui. Accusamus distinctio

The first 'A' is missing upon decoding.

It does decode correctly on online decoders like https://www.smspdu.be and https://www.diafaan.com/sms-tutorials/gsm-modem-tutorial/online-sms-pdu-decoder/
Using library version 0.5.5
PDU is generated on a SIM800C on an ESP32 platform. In text mode, the message also reads correctly.

A GSM7 string 7 chars long incorrectly decoded

A GSM7 string 7 characters long was decoded to an 8 character UTF-8 string

Abbreviated number TON=6

Here is DPU i received:
07912460800065986004E18866000032114201032240A00500037C02019E531D08FAD43EA5A0E07258D481826B7ADA5E57D3CBA0791A543B0A41E4301DA40F83E6F0F2381D66BBD3A071D95D07C560B0E518A40EAFDFA027B95D76D741FA3028BCA6A7EDE1713A041286D9E971790D82BFE569729A5E06A9CB64F79B5C9F9741F632C81A9EA741D370FBFD16CFD9757D590712A7E92E76FE250EB3D3E3757E1A6C8250

Need a helper function to convert any Unicode codepoint to a UTF string

builtUtf16 needs to be extended to any codepoint, ASCII (< 0x7F), European and Semitic languages (< 0x7FF), Asian languages (<0xFFFF) and other symbols (emojis, gaming etc)

SMSC agument problem

Hi,

I'm writting multipart SMS sender using PDU mode.
From my understanding SMSC is an optional parameter (in this video multipart message has been sent without passing smsc: https://www.youtube.com/watch?v=wku1401Mc1w&t=765s)
Unfortunatelly pdulib encode method don't support multipart message encoding without smsc argument (returns -1), so I've decided to provide smsc gathered from modem using "AT+CSCA?" command.
But what my modem gives me as smsc is just a 11 characters phone number, like: [phone] and It simply cannot be used as unsigned short smsc argument because it's simply too long.

My question is: is there any way to encode multipart message without using smsc, or where can I find smsc matching encode method argument?
I'm sorry for my lack of knowledge but I'm just new to GSM modules.
Thank you in advance!

Best regards

Improve Error checking and reporting

Expand the granularity of encodePDU error checking. Instead of returning -1 that covers a multitude of errors.
Differentiate as follows:

Workbuffer size too small to encode a message into the final PDU format
GSM7 string > 160 characters long
UCS2 string > 70 octets long
SCA or recipient address not numeric or too long
Multipart parameters inconsistent
8 bit alphabet not supported.

getSCAnumber returns wrong value

Buffer Overflow

version 0.5.4
When decoding a single message of all GSM7 characters the decoded message buffer overflows into the timestamp buffer

Concatenated messages

Hi, thank you for your brilliant work.

You mention that "This implementation does not process the User Data Header (UDH). The practical implication of this is that concatenated messages or national language extensions are not supported."

Are there plans of supporting concatenated/multi-part-messages for sending and/or receiving? If not, there's probably some manual work required to be able to generate valid multipart messages (instead of several single messages) using your library.

Sender number incorrectly handled.

When decodeAddress is called with the NIBBLES argument, and the length of the address is odd, the number of characters to skip should be incremented by 1.

decoding Problem

Hello, and thank you for this helpful library.

I'm using sim800 and esp32. The platform is Arduino on PlatformIO.

I faced a problem when decoding SMS from a specific number. I guess it is using a different PDU scheme. Note that my SMS contains both Arabic and English characters.

The first message which is successfully being decoded is :

06918919015000
400C91
891982102030
00082270701161818
18C050003510201005500700064006100740065004000440065007600690063006500490064003D00320036003200370032004000440065007600690063006500550072006C003D0068007400740070003A002F002F00390034002E003100380032002E003100350034002E00320038002F006B00650079007000610064002F0068006F006D0065004000440065

The second message which PDUlib throws an "decoding rejected" for is:

06918919015000
640A80
8905003470
00082270701152148
18C050003CD0201005500700064006100740065004000440065007600690063006500490064003D00320036003200370032004000440065007600690063006500550072006C003D0068007400740070003A002F002F00390034002E003100380032002E003100350034002E00320038002F006B00650079007000610064002F0068006F006D0065004000440065

Both messages are continuous. I just segmented them into lines to better indicate the differences.

decodePDU is case sensitive

The *pdu parameter into decodePDU expects an upper case hex string.

My modem (SIM A7608E) returns lowercase hex from +CMT: notifications, resulting in a garbled text output.

This may not be considered a bug in pdulib, but it may be worth putting a note in the readme to save someone as slow as me a whole day of debugging!

Fantastic work otherwise... thanks for sharing!

Reduce RAM usage

Separate (and incorrectly sized) working buffers for Incoming and Outgoing messages need to be replaced by 1 user-defined size buffer.

Problem with decoding SMS from operator

Hello, your PDUlib is best!

Anyway I have problem with decoding SMS from operator and I have no idea why. This is example PDU string:

+CMGL: 0,0,,148
0791246020099990640681991976000832602111455580840500033107010044006F0073006C006500630068006C00690020006A0073006D0065002000730065002C0020007A006500200064006E006500730020006D00610074006500200063006F0020006F0073006C00610076006F007600610074002100200041002000700072006F0074006F007A006500200064006100720065006B00200070
+CMGL: 1,0,,148
079124602009999064068199197600083260211145558084050003310702006F007400650073006900200076007A006400790063006B0079002C0020006E00650063006F002000700072006F00200056006100730020006D0061006D0065002E002000530074006100760074006500200073006500200064006F002000330031002E0037002E0032003000320033002000760020006B007400650072
+CMGL: 2,0,,148
0791246020099990640681991976000832602111455580840500033107030065006B006F006C006900760020004F0032002000500072006F00640065006A006E0065002C0020006E00610068006C0061007300740065002000740061006A006E00650020006E00610072006F007A0065006E0069006E006F007600650020006800650073006C006F0020004E0043004E004E0046004D005A00460054

OK

I try decode many SMS from mobile, even same text like SMS from operator and everything is OK.

Can you check, where is the problem?

Many thanks! Pajates