Znet 2.5 ADC sampling rate issue

Hello everyone,

I am trying to sample 3 ADC inputs which are connected to xbee s2.

I have used the firmware xb24B version 1247 for the znet end device.The coordinator is API enabled to recive the data frames and all goes well except the slow data sampling rate.

The minimum sample rate I am after is 60Hz.But the joke is the maximum proper sample rate I am getting at the moment is 1Hz.

I call it a joke because according to my knowledge the xbee data communication rate is 250kbps. Which means .004ms per byte.

Since I have enabled 3 ADCs , the entire packet size is 28 bytes including check-sum. Allowing another extra 32bytes (the number 32bytes doesn’t have any basis) in average , this makes when sending every ADC data frame , a transaction of 60bytes.So in that case the transaction time is .24ms.

I have set the “IR” to 1 , which means at every 1ms the xbee will automatically start sampling the ADC data and send them to the coordinator.Which means you have 1ms to sample the data and send the data, so that the next data will be ready.Providing that data sending time is .24ms you are left with .76ms to sample the ADC inputs.

I have come to the understanding the xbee has just one ADC module inside and it uses multiplexer to sample multiple inputs.Which means it has to be sampled one at a time.But .76ms is a long time in computer terms.But how the ADC sampling firmware is written is unknown ,specially whether the firmware coders have included settling time for the ADC inputs is not stated in the documentation.

Ok hopefully you understood what I am ranting about in the above.So now I come to the question. Why I am getting 1Hz of sampling rate when I should get theoretical amount of 1000Hz.Even if I assumed the firmware coders have used a massive settling time for the multiplexed ADC inputs, still that doesn’t explain the such a low data output I am getting.Mind you I am happy with 60Hz of sampling rate.

One more thing I have to mention is this is xbee s2 , which I believe is made for mesh network, may be coordinator is busy with scanning for other nodes and miss the data?(Just a wild guess).And also I have to mention I have used this one in an area where other 2.4ghz band signals aren’t present, so background noise cannot be the cause.

I would be grateful if anyone can point out the issue in here. (my email: asys629@gmail.com). Thanks in advance.

You’re right (or at least, I think so) in your quote about the raw transmission rate of 250kbps.

That’s 0.004mS per bit - not per byte.

So now we’re down to a little over 30,000 bytes per second.

Every transmission needs some overhead. The data has to be wrapped in a packet, and the packet has to be acknowledged. Otherwise we couldn’t get reliable data transfer. And then, if a packet was transmitted but the transmission was interrupted by interference, the transmitter must wait a while until it decides the acknowledgement it was expecting hasn’t arrived, and then try the transmission again. More delay - but good delay, because it’s what makes the communication reliable.

That’s enough in itself to slow the data transmission rate to a small fraction of the raw transmission rate. But there’s more.

You’re using series 2 XBees, which means you’re using the ZigBee protocol. That’s fine, and it lets you have a network that’s much more geographically widespread than 802.15.4 (series 1) can manage. The cost is that every transmission must potentially discover a route to its destination - a considerable overhead.

You say you’d be happy with 60Hz sampling. Maybe you could get that with series 1, but I’m not sure that you’ll get it with series 2 given the routing overhead.