I use Xbee series 1 and Arduino Uno to control them. I put a code that analyse Rx and than send to another to get the "coordinator". All data are send in API mode to get all information.
I have a network of Xbee in my office (one per room) and I use another Xbee that broadcast some data. but sometimes, the Xbee in the same room can't send data instead of some that are in other room. The problem is that I need the information of all device in my field of area.
Is it possible that the fact the Arduino must send some data from other Xbee to the coordinator may cause him not to send the data he receive ?
Thank's , Thana
In fact, the buffer of an Xbee is limited but in my case, the Xbee receive 3 api message and than transfert a new message to the end one which is connected to a computer.
The problem is that i needed to slow down the speed of transmission due to the overflow of buffer.
My solution was sending the message after X sec where X depends on the RSSI so the channel was free and I see that every Xbee can now send what they see.
If someone is on the same case, he can reply on this to have my help
Related
I'm working on Linux system that using modbus rtu RS485 to send and receive data. My device is master and just send "request latest data"(8Bytes include 2Byte CRC) to slaver (from now is only 1 slaver) every 1second. when Slaver receive request, they will prepare data (71Bytes include CRC) and send back to Master. I can't see the source of Slaver because this is commercial product.
Both of Master and Slaver using same baud rate 38400.
Result:
When check communication between Master and Slaver, sometimes (average is 1-2hours) data from Slaver is lost some first Bytes, and first Byte that received has been modified with other value that sent from Slaver (sometime lost some first Bytes only)
Sometime data from Slaver not come (timeout but do not receive any data). I tried to increase timeout by 500ms or 1sec but still occurs without any change
I tested Slaver by communication with Teraterm and there is no error like above. Data that sent and received are OK. With Master, I also tested with Teraterm and there is no error.
When I try to catching data while Master and Slaver send & receive data, when problem are occurred(not receive any data or lost some first bytes) on both of Master side and on my PC side (try to catching data byte Teraterm on PC).
I believe that problem is on Master side, and maybe on serial port setting, but I don't know where were wrong. Please help.
Sorry for my poor English!
I used to work with RS485 bus a lot. And one problem that sometimes appeared was very similar to your. Because RS485 is half duplex bus, there is mechanism that switching receive mode and transmit mode on RS485 bus driver. And this was exactly cause of my problems.
When master device sent some data, slave was ready to reply (and replied) before bus driver (on master side) was switched to receive mode. This behavior ended with data loss.
May I suggest you to check, using oscilloscope, that slave sent data correctly? If so, you probably don't have too much options to do as possible solutions are:
Slave have to wait some time before sending reply to master.
Change HW, some RS485 driver that will be faster in switching modes or use different BUS.
I am currently evaluating the board of Maxim Integrated MAXREFDES100#. As part of my thesis, I would like to examine whether there is the possibility of using BLE for data streaming.
The supplied software is fully functional and can already transfer data. Of course, only smaller data packets over a longer period like Temperature or precalculated Heart Rate values. I am aware that BLE is not suitable and has not been designed to transmit data continuously. Nevertheless, I would like to try to transfer the ECG raw data also via the BLE interface. So that I can check whether my data has been arrived completely and correctly in time (prerequisite for ECG data), I have developed the following test setup:
Currently, I store data of a sine wave to a large FIFO and transfer 20-byte sine packets to a characteristic. So far everything works wonderfully. Using an Android device and a BLE sniffer I catch the data packets and check if the sine has any interruptions. The following graphic is taken from a longer measurement: (I have tested my FIFO and the sine datas are complete without any inerruption): This is a capture of my Android and my BLE Sniffer: Data packets are missing.
Sine & Spektrogram Image
Further measurements show that the errors do not occur sequentially, they can always be found at different times. (The Fifo Implementation must be correct)
Sine & Spektrogram Image 2
Since my phone and my Adafruit BLE sniffer have identical errors in the same place, the data packages on the board-side must be corrupt. I suspect they are lost at some protocol level (GAP maybe?). Interestingly, errors affect at least 200 following bytes (256 bytes data are a complete sine). This means that at least 10 data packets each 20 Bytes would have to be in order to get such a graphic.
What options are there for continuously sending data via the BLE interface?
Is it possible to send the data directly via L2CAP without GATT/ATT?
Are there any more wireless, low power protocols that allow data streaming? (So with acknowledgment like TCP for completeness and chronological correctness)
Best regards, Emin
What options are there for continuously sending data via the BLE interface?
Is it possible to send the data directly via L2CAP without GATT/ATT?
BLE v4.1 introduced LE Connection-Oriented Channels which is a way to send data directly via L2CAP without GATT/ATT (think about network sockets). See also Bluetooth Core Specification Vol. 3 Part A Section 3.4.
The board you are using has a EM9301 BLE chip which seems to support BLE v4.1. However, the mbed library you are using doesn't allow you to use them. See here, you have an interface for connect/disconnect callbacks and GATT characteristics read/write/notification. Nothing about LE Connection-Oriented Channel.
i have a portable device that consist of
arduino leonardo board,xbee series 2 as router( AT mode ) and different sensors.This portable device acts as a remote device and can be used upon power up.
The other side, i have a host controller that consist of arduino uno board, arduinoxbee shield v1.1, and xbee series 2 as coordinator( AT mode ). This host controller is plug through USB into my PC.
The aim of my project is to send the sensor data from the portable device using xbee wirelessly over to my host controller and displaying out on the arduino serial monitor.
I've managed to configured the two xbees. But now, i'm unsure of how im going to transmit and receive the data. I need a transmitter and receiver program for both xbees that is connected to the arduino. Anyone can help please?
There are a couple different options for how you can do this, but the simplest is to set up your sensor XBee either in change detect (IC) mode, or set a sample rate (IR). In either case you'll need to handle the RX Indicator frame at the controller, which will contain the sampled data.
I wrote a C# stack that can configure all this, but for what you're trying to do it would probably only be useful as a reference (https://github.com/jefffhaynes/XBee).
I want to send a UDP broadcast datagram to multiple devices on the network, including the sender device itself. The goal is to have all devices receive the data at the EXACT same time (well, +/- 5ms is OK).
The problem is that the network interface on the sending device is looping the data back, so it is received immediately (in contrast to the other devices where network latency comes into play - quite a bit for Wifi for instance)
Any idea how I can disable my network interface to loop the data back directly?
Another idea I had: Is it possible to create a virtual network interface to send the broadcast packet and listen on another interface which only receives it via the network?
I am trying to do that in C on a Linux machine. Any help would be greatly appreciated!
UDP are sent as IP-payload. The routing of IP packets is a domain of the IP stack. It decides how a packet is transferred to the destination. When you IP stack detects that the destination is the local host it will enqueue the packet in the receive queue and the packet will be available immediatly. If your adapters' send queues are filled that you will have a delay. So you can't make a synchronization with this concept.
If you need a hard synchronization you should utilize NTP or SNTP tro synchronize the clocks and define a comment start time for your desired common operation.
Edit:
The (S)NTP protocol is designed to synchronize at millisecond Level. You will get a precision that you can't achieve with any Transmission of UDP packets due to the reason I described above.
How can I make multiple nodes communicate to a coordinator without loss of data?
When more number of XBee nodes send their data simultaneously to the same XBee coordinator won't there be problems of congestion? To my knowledge, it's an yes.
In such case, how can I avoid this congestion? Also, I want the system to work in real time. So there should not be any delay.
I came across Stack Overflow question XBee - XBee-API and multiple endpoints. I deal with a similar problem.
How was this was solved?
As you add devices on a network, the only way to avoid congestion is to transmit less frequently.
If you look at the XBee documentation, most of the modules have a "Transmit Status" frame that the host receives once the message has been successfully delivered (or abandoned due to errors). I believe the success response is triggered by a MAC-level ACK on the network.
If you have smart hosts on your nodes, they can adjust their transmit frequency by waiting for an ACK before sending their next frame, and maybe even using the retries counter in the Transmit Status frame to set a delay before sending.
While the 802.15.4 protocol sends data at 250 kbit/s, the overhead of headers, relaying of messages across a mesh network, and dealing with collisions brings that down to around 100 kbit/s of useable bandwidth. Try to maximize the payload from your devices, to increase the data-to-headers ratio. Sending five pieces of data in a single frame every five seconds is better than one piece in a frame every second.
How much data do you need to send, and what is your definition of "real time"? Is a 10 ms delay acceptable? How about 100 ms? 500 ms? How many devices will try to send at the same time? How often will they send?
All of those questions will figure into your design, and you may find that 802.15.4 isn't suited for what you need to do.
I have setup 15nodes of Series 2 XBee.Node will have multiple sensor like Light,motion etc. XBee placed on Fio board and send data for every 3 min.
Node will be in AT mode and Co-ordinator in API mode.Nodes go through few Router XBee ( AT mode). Co-ordinator collects data (Connected to R'pi) and upload data to server.
It is not mesh network and Xbee will not sleep.
So,i did not encounter any congestion issue at this level.
Hope this helps.