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

Receive Timeout doubt #124

Open
aang7 opened this issue Apr 12, 2018 · 6 comments
Open

Receive Timeout doubt #124

aang7 opened this issue Apr 12, 2018 · 6 comments

Comments

@aang7
Copy link

aang7 commented Apr 12, 2018

Hi, I have a doubt when working with the receive timeout parameter. I'm trying to get a parameter from a remote XBee using Digimesh protocol, with the XBee PRO model. Before I request the parameter value, I set the receive timeout of my local XBee device as this:
myDevice.setReceiveTimeout(300000);

Then I request the value:
remoteXBeeDevice.getDIOValue(IOLine.DIO11_PWM1);

But I receive an exception:

There was a problem sending the AT command packet. > TX failure

Why I'm getting this error too fast if I have a longer receive timeout ?

TX failure It's an error of trying to send the command, but why if with others remotes the same code works?

@rubenmoral
Copy link
Member

Hi @aang7,

What type of modules are you using? Could you please send us the hardware and firmware versions (HV and VR)?

Also, are you able to read any other parameter from that remote module (PAN ID or other IO line for example), or you always get that error?

Thanks.

@aang7
Copy link
Author

aang7 commented Apr 13, 2018

I'm using
Firmware version: 9000
Hardware version: 2D42
DigiMesh 2.4 TH PRO

And so far, I'm not able to read another parameter.

@rubenmoral
Copy link
Member

Thanks @aang7,

Are you sure the two XBee modules are in the same network and can communicate each other? Can you verify with XCTU that you can discover the remote module from the local one?

How do you obtain the remoteXBeeDevice object?

Thanks.

@aang7
Copy link
Author

aang7 commented Apr 13, 2018

Are you sure the two XBee modules are in the same network and can communicate each other?

I'm sure that the modules are in the same network.

Can you verify with XCTU that you can discover the remote module from the local one?

The XCTU can discover the remote module from the local one. But after a few re-scanning.

How do you obtain the remoteXBeeDevice object?

Instantiating the remoteXBeeDevice by the MAC address.
As this:
RemoteXBeeDevice remoteXBeeDevice = new RemoteXBeeDevice(myDevice, new XBee64BitAddress("0013A200410A24FB"));

@rubenmoral
Copy link
Member

Hey @aang7,

If XCTU takes several scans to discover that remote device, it could be because the communication with it is very poor. A TX failure error means that the packet could not reach the remote device, either because it does not exist on the network or it is too far so the packet is lost.

With the information you have provided, we are not able to reproduce the problem. Could you please give us more information about your network (number of modules, distance between them...)?

Thanks.

@aang7
Copy link
Author

aang7 commented Apr 16, 2018

The distance approximately it's around 3 km (~ 1.86411 miles). But there are nodes between them (at most 300 metes ~ 0.186411 miles). So I think, due to I'm using DigiMesh protocol, the packet can be repeated until it reaches the final node and so on.

Each node has an antenna to amplify the signal.

Also I have been watching some paramaters that can help, like the NO, NT, TO, MR and RR but I really dont't know exactly what I have to change or if I have to.

Also I'm using an ekm push, where a determinate quantity of nodes (20) are associated with each one and those nodes have a destination address which is the ekm push related to it.

Modules in the network: 500
Max Distance between nodes: 300 mts ( 0.186411 miles )
Channels in the network: 1
Antenna setup: 9 DBI with 4W booster.

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

No branches or pull requests

2 participants