Git Product home page Git Product logo

libxbee3's People

Contributors

attie avatar christophertfoo avatar olewolf avatar skalkoto avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

libxbee3's Issues

Support for Digi SX / SX Pro?

Hello,

Is there a "mode" for the Digi SX / SX Pro (XB[P]9X) range of part numbers? I've been trying to use xbee3 but I've not been able to get one of the sample applications to run properly that way.

Thanks,
Eric

xbee instance shutdown log message not suppressed

In xbee.c:xbee_free(...) a call to xbee_log is made after freeing the xbee data structure and its log member.
The call in xbee_log(...) that checks the log level then is unpredictable because the referenced memory has been freed.

This results in the log message being displayed sometimes even if the log level for that instance was set to less than the value associated with the call printing "Completed shutdown procedure....".

Overflow in libxbee::Pkt::getData() when handling large PAN ID values?

Hi,

when reading (or writing/setting) the PAN ID value of any xbee1 device (in my case a Digi ConnectPort X2D), I'm experiencing what I think is a bug whenever the value of any of the two fields used to represent the PAN ID is >= 0x80. Example: If the PAN ID is set to 0x7f00, then reading this will result in a bit-representation of the first of the two fields (representing the 0x7f part; on my machine) that reads:
00000000000000000000000001111111
When altering the ID to (e.g.) 0x9000, this first field becomes
11111111111111111111111110010000
The expected value would have been
00000000000000000000000010010000

Speculation about the origin: In libxbee::Pkt::getData(), the data stored as "unsigned char" inside the xbee_pkt struct is cast to a char*, so we lose half the range of allowed values.

A workaround is to access the underlying data from the struct by ::getHnd()->data. Still I guess it would be nice to have the getData() method working for all values, hence I wanted to report.

I hope any of the above makes sense.

Integrating linxbee

When I compile after including header and source files in my project, there is error:

error: redefinition of 'sruct timespec'

xbee2/data Transmit Options field is not configurable.

Callback for any remote address

Hello,

How can I create a callback in C++ or C that will be called if a packet from any address arrives? I could only find a way to create a callback for a specific unicast address or broadcast, but not any address. How is my module supposed to communicate with an other modules that has sent data to it It doesn't a priori know its address?

windows release x64 make

I followed your website instructions for compiling as x64 in windows 7. It compiles fine, yet x64 DLL projects fail to link with x64 libxbee3.dll The compiled x64 libxbee3.dll links fine with x86 DLL projects. I assume the make file is the issue. I tried multiple times. The issue was solved by compiling libxbee3 in visual studio.

"net" mode not working?

I'm trying to get the "net" mode running. First some info about the setup:

  • I have a Digi ConnectPort X2D attached via Ethernet to my laptop and some other XBee chip to which I want to talk
  • If I create a serial interface on my laptop using socat to transport data sent to this serial interface via ethernet to the Connectport, I can talk to the remote XBee chip using the "xbee1" mode. No problems here at all

This serial interface seems unnecessary, so I naively assumed that replacing the line
if ((ret = xbee_setup(&xbee, "xbee1", "/path/to/serial/socket", 115200)) != XBEE_ENONE) {
by
if ((ret = xbee_setup(&xbee, "net", "10.42.0.2", 2101)) != XBEE_ENONE) { //IP and port are similar to what was given to socat as parameters
should work just fine, but it doesn't work at all. Using wireshark to look at the traffic on my laptop's ethernet interface I saw that indeed some TCP (SYN, ACK, PSH, ...) traffic is going on, but after a few seconds I always get this message:

0#[modes/net/mode.c:111] prepare_backchannel() 0x1f99030: Failed to initialize connection to server for an unknown reason...
ret: -17 (A timeout occured)

Do you think this is a bug? Or am I doing it wrong (I hope not - if so, sorry for bothering you!)? I'd be grateful for any reply, especially since I also couldn't find documentation about the "net" mode online.

How to get RSSI using C++ library?

Using the C++ Library with an XBee1. I can get RSSI using the C library, but the rest of my project is in C++ and would like to remain consistent. Thanks

xbeeZB source route packet is corrupt

The current xbee_sZB_createSourceRoute_tx_func in master overwrites the last byte of the last 16-bit address in the source route list as well as the last byte of the 16-bit destination address.

The offset 11 should be 12 as far as I can tell, and I am not sure why the last byte was overwritten by 0. The spec doesn't seem to indicate that.

This is the diff of my change.

diff --git a/modes/xbeeZB/route.c b/modes/xbeeZB/route.c
index cede0a9..1c94638 100644
--- a/modes/xbeeZB/route.c
+++ b/modes/xbeeZB/route.c
@@ -51,8 +51,8 @@ xbee_err xbee_sZB_createSourceRoute_tx_func(struct xbee *xbee, struct xbee_con *
        iBuf->data[0] = identifier;
        iBuf->data[1] = 0; /* the datasheet specifies that the frameID is always zero */
        memcpy(&(iBuf->data[2]), buf, len);
-       iBuf->data[11] = 0; /* the datasheet specifies that this is zero */
-       iBuf->data[bufLen - 1] = '\0';
+       iBuf->data[12] = 0; /* the datasheet specifies that this is zero */
+       //iBuf->data[bufLen - 1] = '\0';
 
        *oBuf = iBuf;
 

timeout

When running the library on an ARM board (compiled with arm-linux-gnueabihf-). The program starts correctly but when sending a command to the xbee I always receive a timeout.
The xbee does receive the command and reacts to it, it seems the library does not read the response from the xbee.
I'm trying to debug the threads but I can't confirm that they are running. Any pointers would be appreciated!

Get rid of __attribute__((constructor))

I am using libxbee3 inside http://github.com/fluent/fluent-bit. Fluent Bit is a data collector and it provides an input plugin to listen for messages from XBee devices. The thing is that Fluent Bit links all it plugins statically and just initialize the required one by the user.

Before our next release I have been testing memory usage and I found that for some cases where the libxbee3 is not used, the constructor is invoked leaking memory. This is a big problem because Fluent Bit can be used as a static/shared library and having memory allocations when the lib is not being used is not ideal.

Would you please get rid of the attribute((constructor)) ?

==27348== 
==27348== HEAP SUMMARY:
==27348==     in use at exit: 432 bytes in 6 blocks
==27348==   total heap usage: 40 allocs, 34 frees, 30,653 bytes allocated
==27348== 
==27348== 72 bytes in 1 blocks are still reachable in loss record 1 of 6
==27348==    at 0x4C2DB95: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27348==    by 0x497270: xbee_ll_alloc (ll.c:63)
==27348==    by 0x49624D: xbee_init (prepare.c:35)
==27348==    by 0x4AE86C: __libc_csu_init (in /home/edsiper/coding/fluent-bit/build/bin/fluent-bit)
==27348==    by 0x57A09CE: (below main) (libc-start.c:245)
==27348== 
==27348== 72 bytes in 1 blocks are still reachable in loss record 2 of 6
==27348==    at 0x4C2DB95: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27348==    by 0x497270: xbee_ll_alloc (ll.c:63)
==27348==    by 0x4962A0: xbee_init (prepare.c:38)
==27348==    by 0x4AE86C: __libc_csu_init (in /home/edsiper/coding/fluent-bit/build/bin/fluent-bit)
==27348==    by 0x57A09CE: (below main) (libc-start.c:245)
==27348== 
==27348== 72 bytes in 1 blocks are still reachable in loss record 3 of 6
==27348==    at 0x4C2DB95: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27348==    by 0x497270: xbee_ll_alloc (ll.c:63)
==27348==    by 0x4962F3: xbee_init (prepare.c:41)
==27348==    by 0x4AE86C: __libc_csu_init (in /home/edsiper/coding/fluent-bit/build/bin/fluent-bit)
==27348==    by 0x57A09CE: (below main) (libc-start.c:245)
==27348== 
==27348== 72 bytes in 1 blocks are still reachable in loss record 4 of 6
==27348==    at 0x4C2DB95: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27348==    by 0x497270: xbee_ll_alloc (ll.c:63)
==27348==    by 0x496346: xbee_init (prepare.c:44)
==27348==    by 0x4AE86C: __libc_csu_init (in /home/edsiper/coding/fluent-bit/build/bin/fluent-bit)
==27348==    by 0x57A09CE: (below main) (libc-start.c:245)
==27348== 
==27348== 72 bytes in 1 blocks are still reachable in loss record 5 of 6
==27348==    at 0x4C2DB95: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27348==    by 0x497270: xbee_ll_alloc (ll.c:63)
==27348==    by 0x496399: xbee_init (prepare.c:47)
==27348==    by 0x4AE86C: __libc_csu_init (in /home/edsiper/coding/fluent-bit/build/bin/fluent-bit)
==27348==    by 0x57A09CE: (below main) (libc-start.c:245)
==27348== 
==27348== 72 bytes in 1 blocks are still reachable in loss record 6 of 6
==27348==    at 0x4C2DB95: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27348==    by 0x497270: xbee_ll_alloc (ll.c:63)
==27348==    by 0x4963EC: xbee_init (prepare.c:50)
==27348==    by 0x4AE86C: __libc_csu_init (in /home/edsiper/coding/fluent-bit/build/bin/fluent-bit)
==27348==    by 0x57A09CE: (below main) (libc-start.c:245)
==27348== 
==27348== LEAK SUMMARY:
==27348==    definitely lost: 0 bytes in 0 blocks
==27348==    indirectly lost: 0 bytes in 0 blocks
==27348==      possibly lost: 0 bytes in 0 blocks
==27348==    still reachable: 432 bytes in 6 blocks
==27348==         suppressed: 0 bytes in 0 blocks
==27348== 
==27348== For counts of detected and suppressed errors, rerun with: -v
==27348== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Timeout with sample/xbee1/0.simple_at

Hi all,
I keep getting this incorrect result when running the main.c in 0.simple_at
tx:17
txRet:0
Although i knew someone else has asked this question, but i still can't figure out the solution that was provided, after i do XBEE_LOG_LEVEL=100 make run i get the result of
LD_LIBRARY_PATH=../../../lib ./main
20#[xbee.c:160] xbee_vsetup() 0x16521f0: Created new libxbee instance @ 0x16521f0
6#[conn.c:530] _xbee_conNew() 0x16521f0: Created new 'Local AT' type connection @ 0x1657050
15#[thread.c:71] threadFunc() 0x16521f0: starting thread 0x1656ae0, function xbee_rx()...
15#[thread.c:71] threadFunc() 0x16521f0: starting thread 0x1656ca0, function xbee_rxHandler()...
15#[thread.c:71] threadFunc() 0x16521f0: starting thread 0x1656e60, function xbee_tx()...
tx: -17
txRet: 0
6#[conn.c:1079] xbee_conEnd() 0x16521f0: Closed connection @ 0x1657050
20#[xbee.c:200] xbee_shutdown() 0x16521f0: Started shutdown procedure for libxbee instance @ 0x16521f0
15#[thread.c:71] threadFunc() !0x16521f0!: starting thread 0x1657050, function xbee_shutdownThread()...
Can someone explain what is going wrong now? i have tried close or open flow control in config.mk but i still got this error.

open(): No such file or directory

running a XbeeZB board, raspberry pi, raspbian jessie,

make and install for library completed

trying to run /sample/3.simpledata

make
chmod a+x main
./main

open (): no such file or directory
ret: -6 (an I/O request failed)

why does this happen how to fix it ?

typedef redefinition with different types

During the installation of libxbee3 on MAC OSX 10.13.4, I get the following error and 5 warnings.

1error

Does somebody know how to fix this error? Many thanks for the help in advance!!!

issues with radio initialization: flock() resource temporarily unavailable - xbee3

I'm using the 900MHz XBee digimesh radio and sometimes I'm seeing issues where either right at startup of my application or sometimes after heavy usage of the radio it becomes unresponsive.

When I get to xbee_setup(...) the libxbee3 library prints out flock(): Resource temporarily unavailable and returns error code -19 which prints with xbee_errorToStr(...): A the item requested is currently in use.

I have no other instances of applications on the system running and in some cases everything is fine until after a few minutes of heavy radio usage, then it seems to loose its session with the radio and when it tries to reconfigure, gets these errors. Other times these errors happen right at startup of the application.

Has anyone else experienced this type of issue and know what the resolution is?

The only thing I've found that works is to restart my application and wait. However, this is not a good solution as I run this on remote mobile sensor nodes and I can't manually restart the application if my only communication link to the node has gone down.

Memory Leak on Transmit

Great work on the library!
We have been using it on a project and there seems to be a memory leak which makes the process be killed by the OS.

The program to replicate what we see is a modification of one of the examples making settings.disableAck = 1. I changed that to be able to send faster.
After around 2000 samples are sent, the OS kills the program due to what seems a memory leak.
The code is blow:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <xbee.h>

int main(void) {
	
	// variables
	void *d;
	struct xbee *xbee;
	struct xbee_con *con;
	struct xbee_conAddress address;
	struct xbee_conSettings settings;
	xbee_err ret;

	// memory allocation
	memset(&address, 0, sizeof(address));
	address.addr64_enabled = 1;
	
	// xbee address
	address.addr64[0] = 0x00;
	address.addr64[1] = 0x13;
	address.addr64[2] = 0xA2;
	address.addr64[3] = 0x00;
	address.addr64[4] = 0x00;
	address.addr64[5] = 0x00;
	address.addr64[6] = 0x00;
	address.addr64[7] = 0x00;
	
	// establish connection to xbee
	if ((ret = xbee_setup(&xbee, "xbeeZB", "/dev/ttyO4", 115200)) != XBEE_ENONE) {
		printf("ret: %d (%s)\n", ret, xbee_errorToStr(ret));
		return ret;
	}
	
	// create new connection
	if ((ret = xbee_conNew(xbee, &con, "Data", &address)) != XBEE_ENONE) {
		xbee_log(xbee, -1, "xbee_conNew() returned: %d (%s)", ret, xbee_errorToStr(ret));
		return ret;
	}
	
	// disable acknowledge
	if (xbee_conSettings(con, NULL, &settings) != XBEE_ENONE) return;
	settings.disableAck = 1;
	if (xbee_conSettings(con, &settings, NULL) != XBEE_ENONE) return;

	// associate data with connection
	if ((ret = xbee_conDataSet(con, xbee, NULL)) != XBEE_ENONE) {
		xbee_log(xbee, -1, "xbee_conDataSet() returned: %d", ret);
		return ret;
	}
	
	// infinite loop
	for (;;) {
		// transmit
		xbee_conTx(con, NULL, "Hello\r\n");
	}

	// disconnect
	if ((ret = xbee_conEnd(con)) != XBEE_ENONE) {
		xbee_log(xbee, -1, "xbee_conEnd() returned: %d", ret);
		return ret;
	}

	// shutdown
	xbee_shutdown(xbee);

	return 0;
}

I ran a memory trace on the program and got the following output:
addresses

The indications of memory leak using mtrace keep repeating itself as the picture show.
I am having a hard time translating the code addresses since it is in a .so file.

One thing I noticed is that the mtrace line that indicates 0x8 of possible memory leak corresponds to line 658 on conn.c due to the test shown on the image below.
image
When we change that line to allocate a fixed amount of memory, its value is reflected on the mtrace result.

My team and I would like to continue using the library.
Would you have any guidelines on fixing the issue I am observing?

Thank you very much for the help and great work on building this!

send frame

Hi,
thank you for the libxbee c library, i would like you to show me an example of using frame.h to send a frame or a packet with API mode, i had tried to use it but i couldnt.

Digi Xbee Pro S1 test module problem

I have checked my Xbee pro s1 module on xXCTU is working I tried the test program But i'm not having the incorrect output. Please be kind enough to explain me.

venushka-pc@venushkapc-ThinkPad-E460:~/my_libxbee/libxbee3/sample/xbee1/0.simple_at$ make 
gcc main.c -g -o main -I/home/venushka-pc/my_libxbee/libxbee3/include -L /home/venushka-pc/my_libxbee/libxbee3/lib -lxbee -lpthread -lrt
venushka-pc@venushkapc-ThinkPad-E460:~/my_libxbee/libxbee3/sample/xbee1/0.simple_at$ ./main 
tx: -17
txRet: 0

Transmission Times out After a While Randomly

Hello,

I'm currently trying to send data using the xbee_connTx(...) method to send data between two series three XBees, both at 57600 baud on an Ubuntu 13.04. The code that I am using can be found here. I have been testing with the XBees stationary and right next to each other.

The transmission code is roughly as follows:

for (;;) {
    /* do stuff to the buffer */
    if ((ret = xbee_connTx(con, &retVal, buf_start, buf_size)) != XBEE_ENONE) {
        if (ret == XBEE_ETX) {
            printf("tx error (0x%02X)\n", retVal);
        } else {
            printf("error: %s\n", xbee_errorToStr(ret));
        }
    }
    usleep(500000); //500ms

}

I'm currently running into an issue where, inconsistently after a few hundred transmissions or so, transmission returns an error of XBEE_ETIMEOUT. It works again if I terminate the program and restart it. Each time, the number of transmissions that go through vary: sometimes 50 might work, other times >300. Even though transmission is timing out, packets can still be successfully received.

I have already tried:

  • Increasing/decreasing the delay in the infinite loop. (50ms-1000ms)
  • Sending only one byte at a time.
  • Disabling and enabling ACK.

I saw your documentation on status reports and have figured out that the semaphore in xbee_framewait is timing out after the default 1 second, but I am not sure how to further debug the issue or what the root cause might be.

Any help would be greatly appreciated!

free(): invalid next size (normal)

Trying to compile the code with g++ and after a few rounds of xbee_conTx(...) I get a gllibc error saying that: free(): invalid next size (normal).

Any idea what might be wrong?

OSX support

I'm trying to use libxbee3 on OSX 10.10 (works ok on Linux).

For example generic/3.log hangs:

ioctl(0x2, 0x4004667A, 0x7FFF5786E80C)       = 0 0
sem_open(0x1083C516B, 0xA00, 0x1B6)      = 259 0
sem_unlink(0x1083C516B, 0xA00, 0x1B6)        = 0 0
sem_open(0x1083C516B, 0xA00, 0x1B6)      = 260 0
sem_unlink(0x1083C516B, 0xA00, 0x1B6)        = 0 0

Is it supported?
Thanks

For xbee2/data the Transmit Options are wrongly masked with 0x08.

For xbee2/data the Transmit Options is masked with 0x08.
While the documentation says;

Transmit options
0x01 = Disable ACK
0x02 = Disable network address discovery
Set all other bits to 0.

Others bits seems to also be used
to enable NACK messages (bit 2) and the Trace Route option (bit ?).

solution:
removing line 110 in /modes/xbee2/data.c
if (settings->broadcast) iBuf->data[pos] |= 0x08;

ref:
https://www.digi.com/resources/documentation/Digidocs/90000991/Default.htm#reference/r_frame_0x10.htm%3FTocPath%3DOperate%2520in%2520API%2520mode%7CAPI%2520frame%2520overview%7C_____5

https://www.digi.com/resources/documentation/Digidocs/90000991/Default.htm#reference/r_nack_msg.htm?Highlight=nack

https://www.digi.com/resources/documentation/Digidocs/90000991/Default.htm#reference/r_dm_trace_routing.htm?Highlight=Trace%20Route%20option

SH Command failure Local AT without callbacks

Using C++, most AT commands work fine. Testing with the XBee 1 10.c++ sample, but changing the command to "SH" or "SL" gives a timeout.

// Works fine:
                /* send data */
                //con.Tx("NI"); /* like this */
                con << "NI";    /* or like this */
// ...
// Timeout:
                /* send data */
                //con.Tx("NI"); /* like this */
                con << "SH";    /* or like this */
// ...

Retrieve the MAC address of a module

Hello,

Is there a way to retrieve the mac-address of a module? I python you can just call get_64bit_addr() on the device after you open it. What about in libxbee3?

Thank you in advance,
Nikos

No more open frames

Hey Attie,

Love your library, I only had a slight problem with it. The situation is as follows:

Mesh network of 104 nodes, 88 are always on, reset will power off during daytime. The system is always powered and will send messages to the nodes on request.
After about 4 to 5 days, the libxbee returns error -22 (XBEE_ENOFREEFRAMEID).

At this moment this is my theory:

When a message is sent to a node a frameID is used (max frameID's is 255) when the message is sent the frame is locked (busy) when the message is received (ACK is received by sender) the frame is unlocked (free). Because there are nodes on the network that turn on and off, the 16 bit address of those nodes can change (unlikely according to Digi, but it is possible). I think that when a node is switched off and changes it's 16 bit address, the system tries to send the message (locking the frame) and the message is never returned, the frame is then still locked. Then my system tries again without the 16 bit address (64 bit address only) and the message is sent successfully (new frameID), the last frameID is still locked. If this happens ofter (with 104 nodes in a network it happens fairly quickly) all frameID's are locked and the error -22 is returned.

My solution is to clear all frames that are set to busy every time I start sending messages (every 150 seconds) with this, there is a chance of removing a frame that was in use, but that frame will have been in use for 150 seconds, therefor I think it is not that bad of clearing the frames.
The solution is crude to say the least, but my lack of knowledge of the way the library handles frameID's causes me to resort to a less desired solution.

What do you think of this problem, is there anything I did wrong?

Greetings,

Junky

Receiving timeout (-17) on simple AT command on ARM

Hello,

Using the sample software to test AT-connection with my XBee API enabled module.
Cross-compiling went fine, but whenever the application has completed i have recieved:

tx: -17
txRet: 0

Which according to xbee.h should mean a timeout error. I have tried to un-comment flow-control in config.mk without succes (saw it in another issue-thread), but unfortunately it didn't work for me.
Still getting the same error.

Does anyone have any suggestions?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.