Skip to content
This repository has been archived by the owner on Sep 16, 2024. It is now read-only.

Adding support for AT commands that are longer than 124 bytes. #429

Closed
wants to merge 3 commits into from

Conversation

ftylitak
Copy link
Contributor

@ftylitak ftylitak commented Apr 6, 2020

This Pull Request adds support AT commands of arbitrary length.

The current implementation has an AT command length limit of 124 bytes (LTE_AT_CMD_SIZE_MAX - 4) which is a blocking point when trying to use the complete AT command reference of SEQUANS modem.

The issue has already been reported through #411 and tried to be solved by #414 though not a proper solution has been found. @robert-hh pointed out that bigger buffers would solve the problem though this would affect the buffer handling.

My approach allows to send long AT command in chunks of max size 124. In case the command is smaller than 124 byte long, it will behave as it previously did.

A good example of its usage would be the case of sending byte data through a UDP socket.

from network import LTE
lte = LTE()

# set the socket option to expect the TX bytes to be provided in the form of HEX values.
lte.send_at_cmd('AT+SQNSCFGEXT=1,1,0,0,0,1')

# Open UDP socket in command mode. Google DNS IPv6 address is used of demonstration
lte.send_at_cmd('AT+SQNSD=1,1,5683,"2001:4860:4860::8888",0,8888,1')

# Request the transmission of 70 bytes (which will be 140 long HEX string)
lte.send_at_cmd('AT+SQNSSENDEXT=1,70')

# 140 characters -> 70 bytes. This messages could not be sent with the default implementation.
lte.send_at_cmd('A343164303A3730313A313130303A303A303A303A32303630886368A343164303A3730313A313130303A303A303A303A32303630886368A343164303A3730313A313130303A3')

# Shutdown socket
lte.send_at_cmd('AT+SQNSH=1')

Also allows to pass the 'delay' parameter to the send_at_cmd. It is documented in https://docs.pycom.io/firmwareapi/pycom/network/lte/ though it seems the delay was never actually passed to the underlying code.

Tested and working on gpy device.

@amotl
Copy link
Contributor

amotl commented Apr 6, 2020

Thanks for solving this appropriately, @ftylitak!

cc @larox11

Copy link
Contributor

@peter-pycom peter-pycom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ftylitak Thanks for this!

Generally looks ok. Just some small nitpicking. And please rebase on latest Dev

esp32/lte/lteppp.c Show resolved Hide resolved
esp32/mods/modlte.c Outdated Show resolved Hide resolved
esp32/mods/modlte.c Show resolved Hide resolved
@ftylitak
Copy link
Contributor Author

@peter-pycom thank you for your review.

I have made the changes in the branch and I hope that I have addressed your comments.

It am a bit pussled though because I have pushed the commits in my branch and those commits are not shown here. Normally those are updated automatically in the PR. Any way, I will look it up.

@ftylitak ftylitak force-pushed the support-long-at-commands branch from dd1dff1 to 1fde1a6 Compare July 16, 2020 08:01
@ftylitak ftylitak force-pushed the support-long-at-commands branch from 1fde1a6 to 12b7177 Compare July 16, 2020 08:13
@ftylitak ftylitak requested a review from peter-pycom July 16, 2020 08:17
@peter-pycom
Copy link
Contributor

We just merged it internally, so I'm closing this PR. It will be released with next release candidate. Thanks again for the PR @ftylitak !

@razvandragomirescu
Copy link

We are experiencing this issue with the latest released firmware, could this please be merged? What is missing? We are sending long APDUs to the SIM via AT+CSIM and it appears that commands of less than 128 bytes work fine, commands over 128 bytes are silently ignored and the response of the previous AT command is returned as the response (very strange) and commands that are exactly 128 bytes appear to freeze the modem (it never replies).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants