Castrated performance of AT^SISW ? Surely this can't be the only way to use HTTP ? | Telit Cinterion IoT Developer Community
February 9, 2019 - 8:22pm, 1943 views
Is it really true that the only way to send data to the HTTP service is using the castrated performance of the AT^SISW command? This only allows 1460 bytes per command and means that uploads of megabytes of data takes magnitudes more time to transmit to the Gemalto module than it does to go OTA.
This seems a completely ridiculous situation for such an advanced module. Surely there must be a way to use a feature such as AT^SIST to bulk-stream data in to the HTTP service? As it is, I'm faced with the situation of having to use transparent sockets and implement all of HTTP myself in my external code, which seems crazy.
I have actually tried fairly hard (tried lots of different ways) to see if AT^SIST can be used instead of AT^SISW for HTTP connections but everything I've tried fails. I am very, very disappointed.
This demonstrates the issue. At the top UART speed available (3MBaud) and responding as quickly as possible to the PLS62-W's URC to each SISW, this is the bus utilisation -- absolutely terrible! The enforced 100ms delays between packets is criminal, nevermind the AT command overhead every 1460 bytes. This surely cannot be the only way to send data to the module?
Not only is there a "disappointing" amount of time for the status URC after data transmission, it takes the PLS62-W 24milliseconds even to bother responding at all to the AT^SISW command itself, before data transmission can begin. This seems completely unforgiveable.
Hello Ian,
In case of IP services over AT commands the transparent mode is only available for socket connections. In this mode AT commands are not needed for sending and receiving data but your application is then responsible for everything that is transmitted including HTTP or any other application layer protocol. The built in HTTP implementation can only work in AT command mode.
This module also provides Java virtual machine. You can write Java application for it and use HTTP implementation available with Java API.
Best regards,
Bartłomiej
Was that a long way of saying "Yes, our HTTP implementation is fundamentally unbearably slow" ? I think so. This is a massive headache for me now. Incredibly disappointing.