8000 [BUG] Longer Response time commands do not execute properly · Issue #6 · veeso/ATtila · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
This repository was archived by the owner on Mar 16, 2025. It is now read-only.

[BUG] Longer Response time commands do not execute properly #6

Open
wildbiotiger opened this issue Feb 11, 2023 · 3 comments
Open

[BUG] Longer Response time commands do not execute properly #6

wildbiotiger opened this issue Feb 11, 2023 · 3 comments
Labels
bug Something isn't working

Comments

@wildbiotiger
Copy link
8000 wildbiotiger commented Feb 11, 2023

Describe the bug
It appears that longer executing commands do not collect all the information from the output, e.g. commands such as AT+CGDCONT? and AT+COPS=?. Most of the time, the parser only catches the echo of the command and not the full response.

To Reproduce

atrunenv = ATRuntimeEnvironment(abort_on_failure=True)
atrunenv.configure_communicator(port_name, baud_rate)
atrunenv.open_serial()

# returns ['AT+CGDCONT?'] or ['AT+CGDCONT?', '', '+CGDCONT: 1,"IPV4V6","","0.0.0.0.0.0.0.0.0.0.0'], not all results
cgdcont_result = self.atrunenv.exec('AT+CGDCONT?')
# fails as it parses only the shortened results
cgdcont_result = self.atrunenv.exec('AT+CGDCONT?;;OK;;;;5')

# sometimes times out, sometimes gets the response if a recent scan - inconsistent
cops_result = self.atrunenv.exec('AT+COPS=?;;OK;;;;900')

Expected behavior
CGDCONT should capture all data, there were 3 other PDP contexts displayed normally. COPS should wait for the operator scan to complete and return the data.

Desktop (please complete the following information):

  • OS: Debian 32-bit
  • Architecture ARMHF
  • Python version 3.7
  • ATtila version 1.2.2

Additional context
There may be an additional consistency bug. Some of the normal commands failed with no output, but repeating the command succeeds. The CGDCONT always fails however.
@wildbiotiger wildbiotiger added the bug Something isn't working label Feb 11, 2023
@lukipuki
Copy link

I've struggled with a similar problem and I've solved it by setting ATE0 . The setting ATE1 is nice for debugging but causes the modem to output two "batches" of data.

I've spent a couple of hours digging through the source code of ATtila and it seems it only expects one "batch" of data, so the two batches caused by a long running command is something that breaks important assumptions.

@nabeel-halo
Copy link

Have you tried setting a longer timeout on the communicator? The default is 10 seconds, but you can make it longer:

atrunenv.configure_communicator(port_name, baud_rate, 180.0)

I wonder if that would help it catch longer running commands.

@Cloolalang
Copy link
Cloolalang commented May 7, 2024 •
edited
Loading

This is a great project, thank-you Christian.

I am developing on a Seeed E5 LoRaWAN modem, I see that there are various AT command response formats;

  1. Simple single-line string.
  2. Long single-line strings with comma-separated values
  3. Multiple line strings, (some with comma-separated values)
  4. Multiple line strings with long time delays between receiving them.

To run the Regex over format-3 responses, In atsession.py, use join method to join combine the strings in each line before the re.search

To allow enough time to capture format-4 responses, adjust;

In atcommunbicator.py, Comment out: lines 213 & 214;

if self._device.in_waiting > 0:
               data_still_available = True
           #else:
               #data_still_available = False

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@lukipuki @wildbiotiger @Cloolalang @nabeel-halo and others
0