Thales' cellular IoT products business is now part of Telit Cinterion, find out more.

You are here

Community > Forum > Cellular Hardware > AT^SISR strange behavior on BGS1-E

AT^SISR strange behavior on BGS1-E | Telit Cinterion IoT Developer Community

Like
0
3
vinhlq's picture
vinhlq

November 30, 2017 - 11:55am, 2296 views

It return diffirent with 2 kind of internet profile:

With SOCKET+FTP profile it return 1 line "^SISR: <srvProfileId>, <cnfReadLength>" and then exactly <cnfReadLength> bytes and then 1 line of result "OK\r\n"

But with HTTP profile it return "^SISR: <srvProfileId>, <cnfReadLength>" and then 1 emty line "\r\n" and then <cnfReadLength> bytes and then 1 line of result "OK\r\n".

Why HTTP profile need an emty line for? Is it a bug or what?The document did not mention it. May be the empty line is removed in the future? I am so confusing. Please help!

3
Comment
Log in or register to post comments
Bartłomiej Gemalto Moderator's picture
Bartłomiej Gema...
Nov 30 2017 - 1:09pm

Hello,

Are you sure that this empty line is not a part of data? Can you check the firmware version with ATI1 command?

Regards,

Bartłomiej

vinhlq's picture
vinhlq
Dec 1 2017 - 5:21am

Hi, Bartłomiej

Yeah, im sure you can see my console dumping below, i try to GET 4 bytes form http (note: not printed character is in escape sequence \xhh):

AT^SISR=9,4<CR>
<CR>
<LF>
^SISR: 9, 4<CR>
<LF>
<CR>
<LF>
\x00\x00\x00\x00<CR>
<LF>
<CR>
<LF>
OK<CR>
<LF>
<CR>
<LF>
^SISR: 9, 1<CR>
<LF>
AT^SISR=9,4<CR>
<CR>
<LF>
^SISR: 9, 4<CR>
<LF>
<CR>
<LF>
\x02\xFF\xCD;<CR>
<LF>
<CR>
<LF>
OK<CR>
<LF>
<CR>
<LF>
^SISR: 9, 1<CR>
<LF>

And ATI1 command return:

ATI1<CR>
<CR>
<LF>
Cinterion<CR>
<LF>
BGS1-E<CR>
<LF>
REVISION 02.000<CR>
<LF>
A-REVISION 02.000.02<CR>
<LF>
<CR>
<LF>
OK<CR>
<LF>

Thank you for your quick reply!

Regards,

Vinh

Bartłomiej Gemalto Moderator's picture
Bartłomiej Gema...
Dec 6 2017 - 3:41pm

Hello,

It seems that you have the latest firmware now. 

I can't see any example for http in the BGS1 AT commands specification. It looks like it has been implemented that way.

If it's not consistent with other types of connections I suppose that we can't exclude that it might be changed in some future release.

Regards,

Bartłomiej