I have an issue with receiving long (> 150 B) payloads, specifically, when subscribing to a topic and sending a downlink payloads. I get the error:
00:03:31.543 WARN OwlModemAT.cpp:78:spinProcessTime() Command timed out. Time now: 211543, start time: 210419, timeout time: 1000
When I increase the timeout value in OwlModemSocket.cpp from the default 1000 ms, I can increase the message length, but I would need to make the timeout value very long for larger payloads.
atModem_->commandSprintf("AT+USORD=%u,%u", socket, len);
int result = (atModem_->doCommandBlocking(1000, &socket_response) == AT_Result_Code__OK);
Eyeballing spin() subfunctions, seems the timeout error is generated based on receiving "OK" response from the modem. In case of receive command, this causes the problem since the payload reception takes time, delaying "OK" response beyond the timeout. I think the timeout should be extended whenever new data comes in to prevent this.
Here is the modem interface interaction. The data gets in OK, but the timeout error is still being flagged.
+UUSORD: 0,213
AT+USORD=0,213
+USORD: 0,213,"0057646576696365732F3430303030302F6D657373616765732F646576696365626F756E642F2532342E746F3D253246646576696365732532463430303030302532466D65737361676573253246646576696365426F756E6400994C6F72656D20697073756D20646F6C6F722073697420616D65742C20636F6E73656374657475722061646970697363696E6720656C69742C2073656420646F20656975736D6F642074656D706F7220696E6369646964756E74207574206C61626F726520657420646F6C6F7265206D61676E6120616C69717561"
OK
Aside from the timeout issue (assuming it gets fixed), how exactly should the memory allocation should be sized? There are 4 parameters. What are their impacts and relationship with each other?
define AT_INPUT_BUFFER_SIZE 64
define AT_LINE_BUFFER_SIZE 256
define AT_RESPONSE_BUFFER_SIZE 1024
define AT_COMMAND_BUFFER_SIZE 1200
Increasing AT_LINE_BUFFER_SIZE allowed for longer downlink payloads.
I have an issue with receiving long (> 150 B) payloads, specifically, when subscribing to a topic and sending a downlink payloads. I get the error: 00:03:31.543 WARN OwlModemAT.cpp:78:spinProcessTime() Command timed out. Time now: 211543, start time: 210419, timeout time: 1000
When I increase the timeout value in OwlModemSocket.cpp from the default 1000 ms, I can increase the message length, but I would need to make the timeout value very long for larger payloads.
Eyeballing spin() subfunctions, seems the timeout error is generated based on receiving "OK" response from the modem. In case of receive command, this causes the problem since the payload reception takes time, delaying "OK" response beyond the timeout. I think the timeout should be extended whenever new data comes in to prevent this.
Here is the modem interface interaction. The data gets in OK, but the timeout error is still being flagged.
+UUSORD: 0,213 AT+USORD=0,213 +USORD: 0,213,"0057646576696365732F3430303030302F6D657373616765732F646576696365626F756E642F2532342E746F3D253246646576696365732532463430303030302532466D65737361676573253246646576696365426F756E6400994C6F72656D20697073756D20646F6C6F722073697420616D65742C20636F6E73656374657475722061646970697363696E6720656C69742C2073656420646F20656975736D6F642074656D706F7220696E6369646964756E74207574206C61626F726520657420646F6C6F7265206D61676E6120616C69717561" OK
Aside from the timeout issue (assuming it gets fixed), how exactly should the memory allocation should be sized? There are 4 parameters. What are their impacts and relationship with each other?
define AT_INPUT_BUFFER_SIZE 64
define AT_LINE_BUFFER_SIZE 256
define AT_RESPONSE_BUFFER_SIZE 1024
define AT_COMMAND_BUFFER_SIZE 1200
Increasing AT_LINE_BUFFER_SIZE allowed for longer downlink payloads.