I have 3 Xbee modules 802.15.4 (series 1) and I am trying to do a Point-To-MultiPoint net:
1 Receiver (conected a PC). Serial com. at 57600
2 End-nodes which sends information to the receiver.
I am using API mode to identify the sender End-Node.
Using a single node, it works perfect. But when I connect the seccond End-Node, It starts lossing packet a lot (half of the all packets)
In addition, each End-Node is sending information from uC (which is conected with two wire UART). This information is an ADC converison of 10 bits at 600Hz. sampling frecuency.
I did the data rate calculation, and it seems to be OK. Each node will be having a RF thoughtput of 10 kbps.
A lot depends here on the finer details of how you’ve set this up, so I’ll have to make some assumptions here.
If you’re transmitting each sample as a separate API transmit request packet, then with 16-bit addressing the packet length will be 11 bytes. At 600Hz sampling rate that’s 6,600 bytes per second into the sender xbee, which would require a setting of at least 66,000 baud. That’s more than the 57600 baud rate, so even with a single xbee some data will be lost.
On the other hand, if you’re transmitting more than one sample per packet, the overhead goes down. With four samples per packet each packet would be 17 bytes long but you’d only be transmitting 2550 bytes per second into the xbee,
So the question is: how many samples per packet are you actually transmitting?
And incidentally, why are you doing it this way when the xbee itself has 10-bit ADCs on board? Well, maybe there are other things going on.
I haven’t addressed the question of the RF transmission overhead. Still, let’s start with the basics.
First, of al, I am using a uC and not the internal ADC because the end-node also is sending more information, so I create a Frame in the uC. The frame is:
Total Frame lengh: 100 bytes
Byte 1: Frame order number
Byte 2: Batery level (the end-node is batery powered) + some info.
Byte 3 to 100: ADC conversion. We are using 10 bits, so Byte 3: LSB 1st conversion and byte 4 MSB 1st conversion; byte 5 LSB 2nd conversion and byte 6 MSN 2nd conversion…etc.
The uC builds this frame, and it sends the 100 bytes to Xbee module with UART. The uC continue the ADC conversion and building the next frame. When the uC complete the next frame, it sends it to the Xbee…and this cycle continue forever.
If I did the correct calculation, the data rate is nearly 12 Kbps.
Hmm. Well, there are at least two reasons why packets can be lost. One reason is bandwidth: too high a sending rate will mean the xbees simply can’t cope. The other reason is that maybe the packet building algorithm isn’t always generating a legal packet, because illegal packets get silently dropped.
You could get a clue by lowering the sampling rate - say by a factor of 10. If things then work correctly you would assume it’s a bandwidth problem. Otherwise you’d be looking at the software.