Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Bad response #3

Closed
jocelynke opened this issue Mar 9, 2020 · 2 comments
Closed

[BUG] Bad response #3

jocelynke opened this issue Mar 9, 2020 · 2 comments
Assignees
Labels
bug Something isn't working

Comments

@jocelynke
Copy link

Describe the bug
I often get bad response to the same command :

Exception :  "Command 'AT+CSQ' got a bad response: '['AT+CSQ']' (and hasn't any doppelganger)!"

To Reproduce
Run the following code

atrunenv = ATRuntimeEnvironment(True)
atrunenv.configure_communicator(serial_port="/dev/ttyUSB2", baud_rate=9600, timeout=5)
atrunenv.open_serial()
while True:
	print("Running command")
	try:
		response = atrunenv.exec("AT+CSQ;;OK;;0;;5;;['AT+CSQ=?{rssi},','AT+CSQ=${rssi},?{ber}']")
		print(response.full_response)
	except Exception as e:
		print("Exception : ", e)
	time.sleep(1)

Expected behavior
No exception since the command is correct and a timeout of 5 seconds should be sufficient. The sleep(1) makes sure to not run too many commands.

Desktop:

  • OS: Linux
  • Architecture ARM
  • Python 3.7.4
  • ATtila 1.1.4
@jocelynke jocelynke added the bug Something isn't working label Mar 9, 2020
@veeso
Copy link
Owner

veeso commented Mar 9, 2020

Hi,

thank you for reporting the issue.

Let me explain the problem here:
With a multi threading system you could just have one thread reading and providing the buffer to the main thread, while here there's no multi threading and when you write the process will start reading and then it waits for the other endpoint to finish writing.

This is fine, except for the fact that sometimes pyserial, which is used by ATtila to interface with serial devices, says there's nothing to read and the read returns. The timeout indeed is only used when no data has been read.

The last fix, improved a lot the performance, but in many cases it missed the bytes. This happens especially when using a low baud rate (such as 9600 indeed).

I've managed to fix this issue, but yep, the performance is lower. Still fast, but not superfast.
The problem is that I want to guarantee my read function to wait for the endpoint to finish, but this involves delays, which are annoying. In my opinion it's not too slow, and should be fine. I don't think I want to make other fixes for this issue, since here I can choose between:

  • better performance, but lower reliability
  • higher reliability, worse performance
  • multi threading, which is OK, but implies many things. I don't know if it's worth or not for this project tbh.

If you want to give it a try, there's a patch 1.1.5.

Let me know if it's ok for you.

@veeso veeso closed this as completed Mar 9, 2020
@jocelynke
Copy link
Author

OK thanks for the explanation. I will give it a try!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants