Closed George9435 closed 2 years ago
If you look closely, these are the same 12795D60A867094E2A7F8E597D76844E005929
These are not: 01A101000C910421436587090008 / 0011000C9104214365870900080B
So it has to do something with the number encoding
The bit at the beginning refers to the SCA number, not the targets phone number. The SCA number will be different for each phone carrier company. The 1st byte if the PDU is the length of the encoded SCA, your examples show 00 and 01, something quite unlikely.
AT+CSCA? and use the output in the SetSCAnumber() function, which MUST be called before using the Encode() function.
Please read the README section of my github page
Let me know how it goes, I also want your SCA number so I can run my own test.
Best Regards David
On Sat, Jul 2, 2022 at 7:30 PM George9435 @.***> wrote:
If you look closely, these are the same 12795D60A867094E2A7F8E597D76844E005929
These are not: 01A101000C910421436587090008 0011000C9104214365870900080B
So it has to do something with the number encoding
— Reply to this email directly, view it on GitHub https://github.com/mgaman/PDUlib/issues/20#issuecomment-1172924386, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3KSTX2IKTXNUFUGZEDDFTVSBVBHANCNFSM52PGWLYQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Hello David,
I read the README section and Idid make some experiments and here I'm telling you how they went.
First of all I went back at the online converter and put the SCA number I fount from SIM800 (SCA is 8digit in my case), my phone number and the chinese character. I then made a PDU array using only the letter 祝 in order to get the message as short as possible for debugging reasons. After that, I tried to send it via SIM800 and I still got an error. Then I did the same but I didn't add the SCA number in the form, and finaly the message was sent with no problems.
Here are the exports of the online converter using SCA (12345678), mobile (1234567890) and message (祝)
With SCA: 05812143658711000A81214365870900080B02795D (15 characters) Without SCA: 0011000A81214365870900080B02795D (15 characters)
It comes to my mind that maybe the SCA in some cases shouldn't be translated when making the pdu.
Then again I did the same with your library.
I made a simple code for fast debugging:
`#include
PDU mypdu = PDU(); void setup() {
Serial.begin(115200); //mypdu.setSCAnumber("12345678"); int len = mypdu.encodePDU("1234567890", "祝"); Serial.print("SMS: "); Serial.println(mypdu.getSMS()); Serial.print("Length: "); Serial.print(len); }
void loop() { }`
I commented the line "SetSCAnumber()" and generated the exact same message using only the chinese character and my mobile number. I tried to send it with no sucess. I found out that every time your library generates PDU at the end of the array, there is a box like character that on the online converter doesn't exist. I also generated the pdu with the SCA but with same results.
Check the exports of your library with the same SCA, number and letter
With SCA: 05A12143658701000AA12143658709000802795D (14 characters) Without SCA: 01A101000AA12143658709000802795D (14 characters)
I still think there's some difference between your library and that online converter. You see, the pdu's aren't the same even if they contain the same values.
The SCA is an integral part of the PDU. Without it the modem (SIM800 or whatever) doesn't know where to send the PDU. Note you don't send an SMS directly to the target number. You send it to the SCA which then forwards it on to the target. Please run my encode sample , edit the Credentials.h file with your SCA and target numbers. The messages should arrive. Keep me posted.
On Sun, Jul 3, 2022 at 5:50 PM George9435 @.***> wrote:
Hello David,
I read the README section and Idid make some experiments and here I'm telling you how they went.
First of all I went back at the online converter and put the SCA number I fount from SIM800 (SCA is 8digit in my case), my phone number and the chinese character. I then made a PDU array using only the letter 祝 in order to get the message as short as possible for debugging reasons. After that, I tried to send it via SIM800 and I still got an error. Then I did the same but I didn't add the SCA number in the form, and finaly the message was sent with no problems.
Here are the exports of the online converter using SCA (12345678), mobile (1234567890) and message (祝)
With SCA: 05812143658711000A81214365870900080B02795D (15 characters) Without SCA: 0011000A81214365870900080B02795D (15 characters)
It comes to my mind that maybe the SCA in some cases shouldn't be translated when making the pdu.
Then again I did the same with your library.
I made a simple code for fast debugging:
`#include
PDU mypdu = PDU(); void setup() {
Serial.begin(115200); //mypdu.setSCAnumber("12345678"); int len = mypdu.encodePDU("1234567890", "祝"); Serial.print("SMS: "); Serial.println(mypdu.getSMS()); Serial.print("Length: "); Serial.print(len); }
void loop() { // put your main code here, to run repeatedly:
} `
I commented the line "SetSCAnumber()" and generated the exact same message using only the chinese character and my mobile number. I tried to send it with no sucess. I found out that every time your library generates PDU at the end of the array, there is a box like character that on the online converter doesn't exist.
Check the exports of your library with the same SCA, number and letter
With SCA: 05A12143658701000AA12143658709000802795D� (15 characters) Without SCA: 01A101000AA12143658709000802795D� (14 characters)
I still think there's some difference between your library and that online converter. You see, the pdu's aren't the same even if they contain the same values.
— Reply to this email directly, view it on GitHub https://github.com/mgaman/PDUlib/issues/20#issuecomment-1173105215, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3KSTUTTF7DG3GLUWUK73TVSGSDXANCNFSM52PGWLYQ . You are receiving this because you commented.Message ID: @.***>
Unfortunatelly still I can't make the module send the pdu created by the library. I did exactly as you said but doesn't work.
I finally solved it!
You must put your country's number before each telephone number (eg +40) even if it is going to be a country-local sms. I wasn't using it so it probably bricked the pdu.
Now that I made it work, is there a function that makes a new line, or carriage return?
I want to send something like this "temp: 34, temp2: 43, temp3: 22" but I want it to print on my cellphone like this: temp: 34 temp2: 43 temp3: 22
Yes of course. Just put \n (new line) in the string. "temp:34\ntemp2: 43\ntemp3: 22"
On Sun, Jul 3, 2022 at 11:17 PM George9435 @.***> wrote:
Now that I made it work, is there a function that makes a new line, or carriage return?
I want to send something like this "temp: 34, temp2: 43, temp3: 22" but I want it to print on my cellphone like this: temp: 34 temp2: 43 temp3: 22
— Reply to this email directly, view it on GitHub https://github.com/mgaman/PDUlib/issues/20#issuecomment-1173164898, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3KSTV7KSBMFHLRSFWMAELVSHYNDANCNFSM52PGWLYQ . You are receiving this because you commented.Message ID: @.***>
Works like a charm!
Thank's David
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 +40 1234567890 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.