Network Problem with Bitcloud 3.2

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,
 
We recently migrated from Atmega128RFA1 (BitCloud 1.14) to SAMR21 using BitCloud3.2.  Our earlier network had one coordinator, 26 routers and 24 end devices, with end devices being allowed to connect only to routers.  Our current SAMR21 network has one coordinator, 20 routers and 12 end devices, again end devices allowed to connect only to routers.  The only change we made was to update Coordinator and router network parameter to support bigger network.
 
With the Atmega128RFA1 running BitCloud 1.14, our connectivity was excellent and even in case of issues, devices would just not connect.  However, with SAMR21 and BitCloud 3.2, we face lot of issues like network congestion, packet loss, and even worse, end devices connect and leave the network as soon as they join.   We would like to understand if this is a problem that only we face or if others have also seen such behavior.  And, is there something specific that we need to do in 3.2  to avoid such a situation?
 
To complete the picture, all our Atmega128RFA1 boards were same whereas the SAMR21 HW boards are of different form factor to meet product aesthetics.  And we use RFMD IC on coordinator for antenna diversity.
 
It would be great if we can get some advice on this tricky situation we find ourselves in.
 
Thanks & Best Regards,

This topic has a solution.
Last Edited: Fri. Oct 16, 2015 - 12:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

A lot of customer use BC v3.2 without any problems and there were no big changes compared to v1.14 that would affect performance in this way.

 

I'd say look at the hardware design. Run FCC test software (appnote AT12459: FCC Test for IEEE 802.15.4 Transmitters) and look on a spectrum analyzer how it looks.

 

Also, have you enabled AD in BitCloud?

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

It would be helpful to see the RF part of the schematic.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the response. On the device with RFMD we are using Antenna Diversity. And we are doing studies for FCC and spectrum analyzer to get better picture of the signal.

 

While doing some testing I found that if I get a response for ZDO_NETWORK_LOST_STATUS I don't get ZDO_NETWORK_LEFT_STATUS even after some time and my system gets reset due to WDT. I thought something and on entering ZDO_NETWORK_LOST_STATUS  I called SYS_DisableSleepWhenIdle() and SYS_EnableSleepWhenIdle() on entering ZDO_NETWORK_LEFT_STATUS  and my system works fine.

 

My problem is on entering ZDO_NETWORK_LOST_STATUS as per the documentation for end-devices the ZDO layer tries for some times to connect again and on connection or time-out response with ZDO_NETWORK_LEFT_STATUS or ZDO_NWK_UPDATE_STATUS. But instead of trying this our system goes to sleep. Is this OK what I'm doing regarding sleep on idle? And why system goes to sleep when it's supposed to search and join network.

Last Edited: Fri. Jul 24, 2015 - 06:11 AM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

This system sleep on idle is a pretty sketchy stuff. I personally would not use it at all.

 

If you use any non-default (provided with BitCloud) interrupts, you need to have them notify the stack that wakeup has happened. Apart from this, I can't really help.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.