-
Notifications
You must be signed in to change notification settings - Fork 45
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
xbee.wait_read_frame() timeout issue #59
Comments
Is this the same issue described in #49 ? |
Yes they are related, but Issue 49 talks about the case where an incomplete frame is received. For this issue the timeout is for when no data is received at all |
One of the most common reasons for unpredicted frames is when the Xbee API settings are not correct. What AP and AO settings have you got? Try: Depending on what the above is you may also need to play with the ‘escaped=true’ setting when when constructing in Python. ser = serial.Serial('/dev/ttyUSB0', 9600) Also see: #26 |
Did you find the solution/fix? |
yeah it was more of a workaround, i used another older version of the library that can be found here: https://github.com/thom-nic/python-xbee, with this library the timeout works fine and the line |
Ah, interesting, we should probably work out what the difference is in the @thon-nic version and get the fix encorporated back upstream. |
Maybe something along the lines of this, i looked into the change history of xbee/thread/base.py and its predecessor: xbee/base.py, in neither was the version of _wait_for_frame with self and timeout=None as args, so probably it wasn't in there since the beginning
|
So after reading the PR & thon-nic addition it sure seems as though this is a feature request. From what I can tell, this implementation was designed to be used in one of two ways. 1) as a blocking call, where calls to That said, I don't necessarily have an issue with this fix. My only complaint would be that the threading mode, and tornado implementations would have different function signatures. We'd probably want to update the tornado side of this as well to properly raise the exception if a frame is not received within the timeout window. |
@jamesleesaunders I can next week sometime, unless @XYR010 if you're familiar/interested in applying this feature to the tornado side. |
I didn't work on the tornado version yet, but i will try. when reading
through thom-nics version i noticed that he uses a new timeout once the
start-byte was read, so that incomplete frames timeout, maybe something
like this should be added as well later on
2018-03-15 21:48 GMT+01:00 David Walker <notifications@github.com>:
… @jamesleesaunders <https://github.com/jamesleesaunders> I can next week
sometime, unless @XYR010 <https://github.com/xyr010> if you're
familiar/interested in applying this feature to the tornado side.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#59 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGdE9nhqLvzHkcMUjebMXSIQWgzUMDz5ks5tetOEgaJpZM4QIlj3>
.
|
This issue has been merged into master. |
Hello,
it seems that xbee.wait_read_frame() is not timing out when a timeout is specified
Here's what i have tried:
data = xbee.wait_read_frame(1)
Traceback (most recent call last):
File "<pyshell#32>", line 1, in
data = xbee2.wait_read_frame(1)
TypeError: wait_read_frame() takes exactly 1 argument (2 given)
ser = serial.Serial('COM5', 9600, timeout=1)
xbee=DigiMesh(ser)
data = xbee.wait_read_frame() ##stuck here until a packet is recieved
any help would be appreciated !
The text was updated successfully, but these errors were encountered: