[BitCloud] Problem sending data form ED to R

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

Hi!

I've established netvork like this:

cOORDINATOR -> ROUTER -> END DEVICE

I send data form COORDINATOR to ROUTER/RND DEVICE and vice versa.
Everything works as expected.

COORDINATOR CODE:

static ClusterId_t  coordInCluster[1] = {0x0001};	
static ClusterId_t coordOutCluster[1] = {0x0002};	


simpleDescriptor.endpoint 		= 0x01;	
simpleDescriptor.AppProfileId 		= 0x0001;						
simpleDescriptor.AppDeviceId 		= 0x0001;
simpleDescriptor.AppDeviceVersion 	= 0x0001;
simpleDescriptor.AppInClustersCount 	= 1;
simpleDescriptor.AppInClustersList 	= coordInCluster;
simpleDescriptor.AppOutClustersCount 	= 1;
simpleDescriptor.AppOutClustersList 	= coordOutCluster;

endpointParams.simpleDescriptor = &simpleDescriptor;
endpointParams.APS_DataInd = APS_DataIndCoord;

APS_RegisterEndpointReq(&endpointParams);


SENDING MESSAGE(COORD -> R/ED):

messageParams.profileId               = simpleDescriptor.AppProfileId;
messageParams.dstAddrMode             = APS_SHORT_ADDRESS;																			
		
messageParams.dstAddress.shortAddress = node_address;	
messageParams.dstEndpoint             = 0x02;
messageParams.clusterId               = 0x0002;
messageParams.srcEndpoint             = simpleDescriptor.endpoint;


messageParams.asduLength              = sizeof(zMessage.data);
messageParams.asdu                    = (uint8_t *)(&zMessage.data);
messageParams.txOptions.acknowledgedTransmission = 1;
messageParams.txOptions.fragmentationPermitted = 0;
messageParams.txOptions.securityEnabledTransmission = 0;
messageParams.radius                  = 0x0;
messageParams.APS_DataConf            = APS_DataConf;									

APS_DataReq(&messageParams);

ROUTER/END DEVICE CODE:

static ClusterId_t endeviceInCluster[1] = {0x0002};	
static ClusterId_t endeviceOutCluster[1]= {0x0001};	


simpleDescriptor.endpoint 		= 0x02;						
simpleDescriptor.AppProfileId 		= 0x0001;
simpleDescriptor.AppDeviceId 		= 0x0002;
simpleDescriptor.AppDeviceVersion 	= 0x0001;
simpleDescriptor.AppInClustersCount 	= 1;
simpleDescriptor.AppInClustersList 	= endeviceInCluster;
simpleDescriptor.AppOutClustersCount 	= 1;
simpleDescriptor.AppOutClustersList 	= endeviceOutCluster;

endpointParams.simpleDescriptor = &simpleDescriptor;
endpointParams.APS_DataInd = APS_DataIndCoord;

APS_RegisterEndpointReq(&endpointParams);



SNEDING MESSAGE(R/ED -> COORD):

messageParams.profileId               = simpleDescriptor.AppProfileId;
messageParams.dstAddrMode             = APS_SHORT_ADDRESS;


messageParams.dstAddress.shortAddress = 0x0000;					
messageParams.dstEndpoint             = 0x01;							
messageParams.clusterId               = 0x0001;
messageParams.srcEndpoint             = simpleDescriptor.endpoint;


messageParams.asduLength              = sizeof(zMessage.data);
messageParams.asdu                    = (uint8_t *)(&zMessage.data);
messageParams.txOptions.acknowledgedTransmission = 1;
messageParams.txOptions.fragmentationPermitted = 0;
messageParams.txOptions.securityEnabledTransmission = 0;
messageParams.radius                  = 0x0;
messageParams.APS_DataConf            = APS_DataConf;

APS_DataReq(&messageParams);

Above code works fine, no ERRORS.

My problem is sending data form END DEVICE to ROUTER.
Code for registering end point is the same, I change only parameters for sending message:


SNEDING MESSAGE(ED -> R):

messageParams.profileId               = simpleDescriptor.AppProfileId;
messageParams.dstAddrMode             = APS_SHORT_ADDRESS;


messageParams.dstAddress.shortAddress = node_address;					
messageParams.dstEndpoint             = 0x02;
messageParams.clusterId               = 0x0002;
messageParams.srcEndpoint             = simpleDescriptor.endpoint;


messageParams.asduLength              = sizeof(zMessage.data);
messageParams.asdu                    = (uint8_t *)(&zMessage.data);
messageParams.txOptions.acknowledgedTransmission = 1;
messageParams.txOptions.fragmentationPermitted = 0;
messageParams.txOptions.securityEnabledTransmission = 0;
messageParams.radius                  = 0x0;
messageParams.APS_DataConf            = APS_DataConf;

APS_DataReq(&messageParams);

Only changes I have made are:


R/ED -> COORD
messageParams.dstEndpoint             = 0x01;							
messageParams.clusterId               = 0x0001;

ED -> R
messageParams.dstEndpoint             = 0x02;
messageParams.clusterId               = 0x0002;

So when I send a message from ED->R,(ED requests some data form R) ,on ED I receive ERROR

APS_ILLEGAL_REQUEST_STATUS = 0xa3,

but I receive message form R correctley(APS_SUCCESS_STATUS = 0x00,).

All in all I know how to send data form COORD-> R/ED and R/ED->COORD, but I have this problem sending data ED -> R.

I hope you can understand me and help me.

Regards!
xtal_88

Last Edited: Fri. Oct 16, 2015 - 02:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You need ClusterID = 2 registered as out on ED as well. If you are sending data to In cluster, you need to have this cluster in your Out list.

Do you really need different clusters? For simple applications it is much easier to use only one.

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

Thank you, Alexru!

alexru wrote:

Do you really need different clusters? For simple applications it is much easier to use only one.

By that you mean :

static ClusterId_t I_O_Cluster[1] = {1};

simpleDescriptor.AppInClustersCount = 1;
simpleDescriptor.AppInClustersList = I_O_Cluster;				
simpleDescriptor.AppOutClustersCount = 1; 
simpleDescriptor.AppOutClustersList = I_O_Cluster;			

Another question Alex, which of simpleDescriptor parameters should be the same on all nodes in network(COORD,Rs and EDs)

simpleDescriptor.endpoint =
simpleDescriptor.AppProfileId = 							
simpleDescriptor.AppDeviceId = 								simpleDescriptor.AppDeviceVersion = 	
simpleDescriptor.AppInClustersCount = 
simpleDescriptor.AppInClustersList = 				
simpleDescriptor.AppOutClustersCount = 
simpleDescriptor.AppOutClustersList = 			

Thank you and Regards !

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

1. You may just omit specifying them. Simply set both ClustersCount to 0 and sent to any cluster you like, message will be indicated on the other side as is.

2. None of them. AppProfileId, AppDeviceId and AppDeviceVersion are not analyzed by the stack and can be set to arbitrary values (or to values specified by the profile description, in case if standard profile is implemented).

AppProfileId must be set to actual profile ID, but for simple applications, not using ZigBee Cluster Library, it can be set to arbitrary value, but it must be the same on devices that need to send data to each other.

Cluster lists are defined by the particular profile description, they are actively used in some advanced modes (like group addressing), but have limited use for simple applications.

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

Hi Alexru !

My network(3 nodes) look like this:

COORDINATOR -> ROUTER -> END DEVICE
(data sink)

all nodes are MeshBean AMP developement board.

My application(s) collects neighbour table of ROUTER and END DEVICE. Everything works fine, no errors at all.

I've made few custom boards with ZigBit AMP modules.
I'have tried to program these boards with same application(as MeshBean boards).

Network is established OK, I can see that (ZDO_CHILD_JOINED_STATUS raised on COORDINATOR), but when I try to send data from COORDINATOR to ROUTER or END DEVICE, that doesn't work I receive APS_NO_ACK_STATUS.

Thing works also when I program my boards to be ROUTER and END DEVICE, but COORDINATOR is MeshBean.

I'm working in BitCloud v.12. I've modified WSNDemo application.

I think maybe my problem is in Makefile and Configuration.h .
I don't know how to properly adjust these 2 files to my custom board with ZigBit AMP modules.

Please help !

Thnx !

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

That looks like hardware problem. Can you show pictures and/or design files of your board?

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

Alexru, sorry for waiting ! (temperature is killing me)

Yes, here is my boards schematic. I think it's not so complex, but I would like to hear your opinion.

It's 2nd design so I know I have to do it few more times to make it work.

My configuration file:
I only changed:

1. #define APP_DEVICE_TYPE DEV_TYPE_COORDINATOR
2. #define CS_UID 0x0LL
3. #define CS_NWK_UNIQUE_ADDR false
4. #define CS_NWK_ADDR 0x0000

with:

1. #define CS_DEVICE_TYPE what is needed here for every node
2. #define CS_UID 0x0LL different for every node
3. #define CS_NWK_UNIQUE_ADDR true
4. #define CS_NWK_ADDR 0x0000 for COORDINATOR
#define CS_NWK_ADDR 0x0001 ROUTER
#define CS_NWK_ADDR 0x0002 END DEVICE

#ifndef _CONFIGURATION_H_
#define _CONFIGURATION_H_

//-----------------------------------------------
// Disables board-specific peripherals support
//-----------------------------------------------
//#define APP_DISABLE_BSP 1
#define APP_DISABLE_BSP 0

//-----------------------------------------------
// Includes board-specific peripherals support in application.
//-----------------------------------------------
#include 

#define APP_INTERFACE_USART 0x01
#define APP_INTERFACE_VCP 0x02
#define APP_INTERFACE_SPI 0x03
#define APP_INTERFACE_UART 0x04

// Defines device role for boards witohut DIP switches. This parameter should not
// be confused with Library Type parameter. Device role must match library type if
// library type is not 'all'.
#define CS_DEVICE_TYPE DEV_TYPE_COORDINATOR
//Device is Router
//#define APP_DEVICE_TYPE DEV_TYPE_ROUTER
//Device is End Device
//#define APP_DEVICE_TYPE DEV_TYPE_ENDDEVICE

// Intervals in which coordinator and routers are sending state of their sensors.
#define APP_TIMER_SENDING_PERIOD 10000

// Maximum amount of failed transmissions before network rejoin procedure is
// initiated.
#define APP_THRESHOLD_FAILED_TRANSMISSION 4

// Configuring device caption support. Caption will be shown in WSNMonitor tool
// window.
#define APP_USE_DEVICE_CAPTION 0
//#define APP_USE_DEVICE_CAPTION 1

// Support Atmel RCB KeyRemote board
#define APP_RCB_KEY_REMOTE_SUPPORT 0
//#define APP_RCB_KEY_REMOTE_SUPPORT 1

//-----------------------------------------------
//APP_USE_DEVICE_CAPTION == 1
//-----------------------------------------------
#if (APP_USE_DEVICE_CAPTION == 1)
  // Device caption, shown in WSNMonitor. Must be less, than 15 characters.
  #define APP_DEVICE_CAPTION "Ghost"
#endif

// Defines primary serial interface type to be used by application.
#define APP_INTERFACE APP_INTERFACE_USART

// Defines USART interface name to be used by application.
#define APP_USART_CHANNEL USART_CHANNEL_1

//-----------------------------------------------
//BOARD_MESHBEAN
//-----------------------------------------------
#ifdef BOARD_MESHBEAN
  // Enable this option if target board belongs to MNZB-EVBx family
  #define BSP_MNZB_EVB_SUPPORT 1
  //#define BSP_MNZB_EVB_SUPPORT 0
#endif

//-----------------------------------------------
//BOARD_RCB
//-----------------------------------------------
#ifdef BOARD_RCB
  // Enable this option if target board suports controlling of TTL to RS232 converter
  // enable pin.
  #define BSP_ENABLE_RS232_CONTROL 1
  //#define BSP_ENABLE_RS232_CONTROL 0
#endif

//-----------------------------------------------
//AT86RF212
//-----------------------------------------------
#ifdef AT86RF212
  // Enables or disables Listen Before Talk feature.
  #define CS_LBT_MODE false
  //#define CS_LBT_MODE true
  
  // 32-bit mask of channels to be scanned before network is started. Channels that
  // should be used are marked with logical 1 at corresponding bit location.
  //  Valid channel numbers for 2.4 GHz band are 0x0b - 0x1a
  //  Valid channel numbers for 900 MHz band are 0x00 - 0x0a
  // 
  //  Notes:
  //  1. for small amount of enabled channels it is more convinient to specify list
  // of channels in the form of '(1ul << 0x0b)'
  //  2. For 900 MHz band you also need to specify channel page
  // 
  //  Value range: 32-bit values:
  //  Valid channel numbers for 2.4 GHz band are 0x0b - 0x1a
  //  Valid channel numbers for 900 MHz band are 0x00 - 0x0a
  // 
  //  C-type: uint32_t
  //  Can be set: at any time before network start
  #define CS_CHANNEL_MASK (1L<<0x01)
  
  // Channel page number defines band and modulation scheme that will be used for
  // communication.
  // 
  //  Value range:
  //  0 - 915MHz (BPSK-40, channels 0x01 - 0x0a), 868MHz (BPSK-20, channel 0x00)
  //  2 - 915MHz (O-QPSK-250, channels 0x01 - 0x0a), 868Mhz (O-QPSK-100, channel
  // 0x00)
  //  5 - 780MHz (O-QPSK-250, channels 0x00 - 0x03, Chinese band)
  // 
  //  C-type: uint8_t
  //  Can be set: at any time before network start
  #define CS_CHANNEL_PAGE 0
  //O-QPSK
  //#define CS_CHANNEL_PAGE 2
  //Chinese band
  //#define CS_CHANNEL_PAGE 5
#else
  // 32-bit mask of channels to be scanned before network is started. Channels that
  // should be used are marked with logical 1 at corresponding bit location.
  //  Valid channel numbers for 2.4 GHz band are 0x0b - 0x1a
  //  Valid channel numbers for 900 MHz band are 0x00 - 0x0a
  // 
  //  Notes:
  //  1. for small amount of enabled channels it is more convinient to specify list
  // of channels in the form of '(1ul << 0x0b)'
  //  2. For 900 MHz band you also need to specify channel page
  // 
  //  Value range: 32-bit values:
  //  Valid channel numbers for 2.4 GHz band are 0x0b - 0x1a
  //  Valid channel numbers for 900 MHz band are 0x00 - 0x0a
  // 
  //  C-type: uint32_t
  //  Can be set: at any time before network start
  #define CS_CHANNEL_MASK (1L<<0x0f)
#endif

// The parameter specifies the predefined extended PANID of the network to be
// formed (for the coordinator) or joined (for a router or an end device). For a
// router or an end device the parameter can equal 0 allowing them to join the
// first suitable network that they discover.
#define CS_EXT_PANID 0xAAAAAAAAAAAAAAAALL

// 64-bit Unique Identifier (UID) determining the device extended address. If this
// value is 0 stack will try to read hardware UID from external UID or EEPROM chip.
// at startup. Location of hardware UID is platform dependend and it may not be
// available on all platforms. If the latter case then UID value must be provided
// by user via this parameter. This parameter must be unique for each device in a
// network.
#define CS_UID 0x0LL

// Determines whether the static or automatic addressing mode will be used for the
// short address.
// 
//  If set to true, the CS_NWK_ADDR parameter will be used as the device's short
// address. Otherwise, the short address is assigned automatically by the stack. An
// actual assignment method is specified in CS_ADDRESS_ASSIGNMENT_METHOD.
//#define CS_NWK_UNIQUE_ADDR false
#define CS_NWK_UNIQUE_ADDR true

// Specifies short (network) address if CS_NWK_UNIQUE_ADDR equals true
// 
//  If static addressing is applied the stack uses the value of the parameter as a
// short address. Otherwise, the stack assigns the parameter to a randomly chosen
// value unique within the network. In both cases after the network start the
// parameter holds actual short address of the device. While the device is in the
// network its value must not be changed.
#define CS_NWK_ADDR 0x0000

// The maximum number of direct children that a given device (the coordinator or a
// router) can have.
// 
//  The parameter is only enabled for routers and the coordinator. An end device
// can not have children. If an actual number of children reaches a parameter's
// value, the node will have not been able to accept any more children joining the
// network. The parameter can be set to 0 on a router thus preventing it from
// accepting any children and can be help form a desired network topology. For
// example, if the parameter is set to 0 on all routers, then the coordinator will
// be the only device that can have children and the network will have star
// topology.
#define CS_MAX_CHILDREN_AMOUNT 8

// The maximum number of routers among the direct children of the device
// 
//  The parameter determines how many routers the device can have as children. Note
// that the maximum number of end devices is equal to CS_MAX_CHILDREN_AMOUNT -
// CS_MAX_CHILDREN_ROUTER_AMOUNT.
#define CS_MAX_CHILDREN_ROUTER_AMOUNT 2

// End device sleep period given in milliseconds.
// 
//  On an end device this parameter determines the duration of a sleep period.
// Falling asleep is performed with the ZDO_SleepReq() request. After sleeping
// period exceeds the node is awakened and the application receives an indication
// via ZDO_WakeUpInd(). If the parameter's value is 0, then after the node falls
// asleep it can only be awakened by a hardware interrupt; a callback for a given
// IRQ is registered via HAL_RegisterIrq().
// 
//  On a router or the coordinator, the parameter is used in two ways:
// 
//  1) To remove information about lost child end devices. If a parent receives no
// data polls or data frames from the child end device for
// CS_NWK_END_DEVICE_MAX_FAILURES * (CS_END_DEVICE_SLEEP_PERIOD +
// CS_INDIRECT_POLL_RATE) ms, then it assumes it to be lost and deletes all
// information about such child.
// 
//  2) To determine whether to store or drop a message addressed to a child end
// device. The parent estimates the time when its child end device will wake up by
// adding this value to the moment when the last poll request has been received. If
// the time till end device wake up is greater than CS_MAC_TRANSACTION_TIME the
// frame is stored. Otherwise, the frame is dropped.
#define CS_END_DEVICE_SLEEP_PERIOD 10000

//-----------------------------------------------
//HIGH_SECURITY_MODE
//-----------------------------------------------
#ifdef HIGH_SECURITY_MODE
  // The parameter enabled in the high security mode specifies the size of the APS
  // key-pair set. The APS key-pair set stores pairs of corresponding extended
  // address and a link key or a mster key. For each node with which the current node
  // is going to communicate it must keep an entry with the remote node extended
  // address and a link key. If the link key is unknown, the node can request the
  // trust center for it via APS_RequestKeyReq(). The trust center must store a link
  // key or a master key depending on the CS_SECURITY_STATUS used for each node it is
  // going to authenticate. Entries can also be added manually by APS_SetLinkKey()
  // and APS_SetMasterKey().
  #define CS_APS_KEY_PAIR_DESCRIPTORS_AMOUNT 8
  
  // The parameter is used to determine the security type.
  // 
  //  Value range: 0,3 - for standard security; 1,2 - for high security.
  //  0 - network key is preconfigured ;
  //  1 - network join without master key, but with a trust center link key, which
  // must be set via APS_SetLinkKey();
  //  2 - network join employs a master key, which must be set APS_SetMasterKey();
  //  3 - network key is no preconfigured, but rather received from the trust center
  // in an unencrypted frame. Value range: at least 1 \n C-type: uint8_t \n Can
  // be set: at compile time only \n Persistent: No
  #define CS_ZCL_OTAU_DISCOVERED_SERVER_AMOUNT 1
  
  // The number of clients that the OTAU server can server simultaneously If this
  // parameter equals 1, the OTAU server will upgrade devices in the network one by
  // one. However, the server can process more than one client sessions at a time, if
  // this parameter is greater than 1. The parameter is valid for OTAU servers only.
  // Value range: at least 1 \n C-type: uint8_t \n Can be set:
  // at compile time only \n Persistent: No
  #define CS_ZCL_OTAU_CLIENT_SESSION_AMOUNT 1
  
  // The interval in milliseconds between two attempts to find an upgrade server The
  // parameter is valid for OTAU clients only. Value range: any 32-bit value
  // \n C-type: uint32_t \n Can be set: at any time before an OTAU
  // start \n Persistent: No
  #define CS_ZCL_OTAU_SERVER_DISCOVERY_PERIOD 60000
  
  // The default address of an upgrade server The parameter indicates how the OTAU
  // client will search for OTAU servers in the network. If one of broadcast
  // addresses is specified, the client will attempt to find all devices supporting
  // the OTAU server cluster and will request new images from the first server that
  // will respond. Otherwise, the client will try to connect to a particular device
  // with the specified extended address. The parameter is valid for OTAU clients
  // only. Value range: any 64-bit value: \n \li \c 0x0000000000000000ull, \c
  // 0xFFFFFFFFFFFFFFFFull - a server discovery request is broadcasted \li otherwise,
  // the client tries to connect to a particular node C-type: ExtAddr_t \n
  // Can be set: at any time before an OTAU start \n Persistent: No
  #define CS_ZCL_OTAU_DEFAULT_UPGRADE_SERVER_IEEE_ADDRESS 0xFFFFFFFFFFFFFFFFull
#endif //


#endif // _CONFIGURATION_H_

My MakeFile is:

APP_NAME = WSNDemo
PROJECT_NAME = MeshBean
CONFIG_NAME = All_ZigBit_Atmega1281_Rf230_8Mhz_Gcc

I don't want to copy all from Makefile.

Why do you think that it seems like hardware problem (before you haven't seen my design :) )?

Attachment(s): 

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

I was asking more about PCB design. If one .hex file works on one set of boards and does not work on another then it is not a software problem.

Incorrect PCB design is the place where such errors usually show up.

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

alexru wrote:
I was asking more about PCB design. If one .hex file works on one set of boards and does not work on another then it is not a software problem.

Incorrect PCB design is the place where such errors usually show up.

Hi, me again !

Now I see where could be a problem.

Reading other posts regarding PCB design I found that there shouldn't be anything(lines and GND) on top nor on bottom layer at all under module.

But MeshBean board has GND layer on bottom layer under the module, that's for sure, but there are whole bunch of GND vias around module and I don't have them.

I also have a problem with my boards, some are "wrong"(PCB manufacture fault).

Seems like there's nothing else to do but "back to the drawing board".

Thnx Alex for answers !

Attachment(s): 

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

Your design does not look bad for me. I'm really not sure about the ground plane. I know that "regular" MeshBeans don't have the ground plane for sure. There is recommended design layout in the datasheet for ATZB-24-A2/B0.

I'm not an expert on RF design, so that is all I can say on this :)

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

Hi!

I have Coordinator and Router in network, BitCloud v12.

I can send message form Coordinator to Router without any problem, but problem appears when sending message form Router to Coordinator.

Error code is 0x80 ZDO_INVALID_REQUEST_STATUS raised in ZDO_StartNetworkConf() on Router.

What might be a problem?

Thanks !

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

You should call ZDO_StartNetworkConf() only once. ZDO_INVALID_REQUEST_STATUS is returned when you call it when the node is in the network already. And given that they can communicate it is in the network.

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