[BitCloud] New version arrived

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

Hi!

For those who don't know new version of BitCloud 11.1 arrived

[url]
http://www.atmel.com/dyn/product...
[/url]

Regards !
Mesko

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

For sure its off-topic, but does anybody know if there is a singlechip transceiver for 800/900MHz upcoming?

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

Hm this release breaks my application :-(

What happend to the aib attributes? Now there is only the AIT_t struct with two members trustCenterAddress and nonMemberRadius. How can i query the other attributes?

BitCloud 1.10 had no MgmtBind_req so I implemented my own with the functions of apsBindManager.h now this header is gone there is a apsBinding.h but functions are prefixed with APS_PRIVATE and defining a empty APS_PRIVATE leads to "expected a declaration" error.

sad. :-(

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

manuelp wrote:
What happend to the aib attributes?
What attributes do you need and how have you used them earlier?

manuelp wrote:
but functions are prefixed with APS_PRIVATE and defining a empty APS_PRIVATE leads to "expected a declaration" error.
That's because they are private to APS. Use corresponding ZDO functions as a public interface.

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

I need the 'designated coordinator' and 'channel mask'
the channel mask I found in the config server I can live with that for now.

It seems that the ZDO has no way to get the binding table information? My application needs the binding table entries to display the binding links between nodes.

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

manuelp wrote:
I need the 'designated coordinator'
Please show the code that it working know. I've never heard of such parameter.

manuelp wrote:
and 'channel mask'
The only proper way to set channel mask is config server.

manuelp wrote:
It seems that the ZDO has no way to get the binding table information?
No, there is no such functionality in specification.

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

Quote:
Please show the code that it working know. I've never heard of such parameter.

apsDesignatedCoordinator TRUE if the device should become the ZigBee Coordinator on startup, FALSE if otherwise.

here is the snipped for 1.10

APS_GetReq_t req;
req.aibAttribute = APS_AIB_DESIGNATED_COORDINATOR;
APS_GetReq(&req);

if (req.confirm.aibAttributeValue.apsDesignatedCoordinator == true)
{
 ...
}

Quote:
No, there is no such functionality in specification.

It's not in the ZDO but the binding table is a AIB attribute too and in 1.10 it was possible to query the binding table and now in 1.11 this functionality has become explicit private (I think it was private before too but there was a chance to access it).

Workaround might be to maintain my own binding table by listening to bind/unbind indication but this looks more like a hack and a not necessary waste of memory.

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

manuelp wrote:
here is the snipped for 1.10
Just use this code:

DeviceType_t deviceType = NWK_GetDeviceType();

if (DEVICE_TYPE_COORDINATOR == deviceType)
{
 ...
}

or simply read CS_DEVICE_TYPE value.

manuelp wrote:
It's not in the ZDO but the binding table is a AIB attribute too and in 1.10 it was possible to query the binding table and now in 1.11 this functionality has become explicit private
When used as intended you don't need to know binding table. But you can get pointer to a memory occupied by this table using this code:

CS_GetMemory(CS_APS_BINDING_TABLE_ID, (void *)&firstEntry);
CS_ReadParameter(CS_APS_BINDING_TABLE_SIZE_ID, (void *)&tableSize);

Just remember, that this is not official API and it may change.

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

CS_APS_BINDING_TABLE_ID, what is the purpose of this, is it to decide who joins and who does not.

DJ

Thanks

Regards

DJ

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

djoshi wrote:
CS_APS_BINDING_TABLE_ID, what is the purpose of this, is it to decide who joins and who does not.
No, it is just a pointer to a binding table, that allows Binding feature to work, it has nothing to do with joining.

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

I dont know if this the best way, one of my requirements is have multiple networks in a area and a node(with users approval) can join any of the networks on the fly.

So what I have done is use each cord UID as its unique 64-bit network ID.

Then I would get a node to go close to Cord and press a RST with a 2nd botton that lets me join the network, once its joined, the node saves the network ID in the EEPROM so it always joins this network only. For it to join any other network it need to hold the 2nd button and do a rst.

DJ

Thanks

Regards

DJ

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

Thanks alexru I will rewrite the related parts in my app with your infos.

Quote:
Just remember, that this is not official API and it may change.

Yes but it's better than nothing. Thanks to the STACK_VERSION macro i can switch between different versions. And maybe some day MgmtBind_req will find it's way into BitCloud ;-)

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

Can you explain what the stack_version macro does?

DJ

Thanks

Regards

DJ

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

it's just a number and does nothing just telling you which version the stack is :-)

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

Does it also TX this to the Cord, how would this be obtained from a device?

DJ

Thanks

Regards

DJ

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

djoshi wrote:
Does it also TX this to the Cord, how would this be obtained from a device?
It's just a define. Look at ConfigServer\include\stackVersion.h and see for yourself what you can do with it.

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

Alex, I know this off topic slightly.

Do you know the stack up the RAVEN boards are using?

DJ

Thanks

Regards

DJ

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

djoshi wrote:
Do you know the stack up the RAVEN boards are using?
No, I have no idea.

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

Just found it, thanks

Thanks

Regards

DJ

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

another question according the extended NwkAddr_req which still does not work for me.

I try to discover the network topology by sending a NwkAddr_req with extended response enabled to the coordinator first.

(The network contains a coordinator a router and a end-device)

The coordinator now should response with a list of it's associated devices. But this doesn't work the response only contains the end-device but not the router.

With one exception: then the router is very recently joined the network it will be shown once in the NwkAddr_rsp. But in later requests the response only contains the end-device.

The same problem I had with the last BitCloud version 1.10
as described in the following post I think BitCloud only copy's device addresses from the neighbor table in the response there (neighbor.relationship == RELATIONCHIP_CHILD).
In the Mgmt_LqiRssi_rsp routers have (neighbor.relationship == RELATIONCHIP_NONE_OF_ABOVE).

https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=103486

Is there any solution to this? The Mgmt_LqiRssi_req doesn't work always then i have more nodes in the network (i don't know why maybe a config problem).

The NwkAddr_req and IeeeAddr_req are mandatory and Mgmt_LqiRssi_req is optional it would be nice that these two work as expected since there is no other standard way to discover the network.

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

manuelp wrote:
With one exception: then the router is very recently joined the network it will be shown once in the NwkAddr_rsp. But in later requests the response only contains the end-device.
Correct, this timeout is 15 seconds. This is intended behavior, no need to waste memory on parent for records that are not needed, I don't think that this will ever be "fixed" because it is just stupid.

manuelp wrote:
Is there any solution to this?
Use application level requests and do whatever you want there.

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

I don't think this is intended from the standard's point of view and that the routers must be listed in the extended response too (since they are associated devices).

Given the following topology Coordinator --> Router --> (End-Device, End-Device, ....) :

Imagine a device which joins as the last device in the network and wishes to discover all nodes. The standard recommends the IeeeAddr_req/NwkAddr_req to discover the network but with the above behavior that is just impossible.

The limititation to end-devices simply makes no sense and is not what standard intends by saying.

"[...]The Remote Device shall also supply a list of all 16-bit NWK addresses in the NWKAddrAssocDevList field, starting with the entry StartIndex and continuing with whole entries until the maximum APS packet length is reached, for its associated devices.[...]".

Quote:
Correct, this timeout is 15 seconds. This is intended behavior, no need to waste memory on parent for records that are not needed, I don't think that this will ever be "fixed" because it is just stupid.

Nothing is wasted the routers are already in the neighbor table (and don't disappear after 15 seconds) they are just filtered out by not including the (neighbor.relationship == RELATIONSHIP_NONE_OF_ABOVE) devices (aka routers) into the response and this is according to the standard wrong. So what's the point of not *fixing* it to provide more standard conformance? (my guess is that such a fix is a one liner in the loop building the list...)

Don't get me wrong but this is really a problem for long running real world setups and late joining devices which need the network topology (like a monitor) by using the standard's recommended way of using the IeeeAddr_req (such a device might come from some vendor with a zigbee stack not implementing the optional Mgmt_LqiRssi_req. This device although not doing anything wrong is just useless in a environment containing BitCloud routers).

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

manuelp wrote:
The limititation to end-devices simply makes no sense and is not what standard intends by saying.
I've read specification. And I know that what we did here makes sense for most applications. Discovering network topology is the least concern. Why do you need it anyway?

manuelp wrote:
Nothing is wasted the routers are already in the neighbor table (and don't disappear after 15 seconds) they are just filtered out by not including the (neighbor.relationship == RELATIONSHIP_NONE_OF_ABOVE) devices (aka routers) into the response and this is according to the standard wrong.

No, in neighbor table there are all devices that are in direct link range from the current device, not ones that joined to the current device. To keep list of what devices are joined we'll need another table.

manuelp wrote:
Don't get me wrong but this is really a problem for long running real world setups and late joining devices which need the network topology (like a monitor)
Collecting network topology is not really indented by ZigBee, you can't reliably build it based on neighbor table alone anyway.

If you need to discover particular devices, supporting particular profiles, there are other requests.

I agree, it is not strictly standard behavior, but it is there for a reason. You are free to complain to official support and if you'll convince them, I'm sure we'll implement 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

Quote:
Discovering network topology is the least concern. Why do you need it anyway?

My app is used to show the devices in the network and hence need to discover them starting with the known nwk address of the coordinator. And for stack independence relying to standard only requests (mandatory preferred) :)

Quote:
No, in neighbor table there are all devices that are in direct link range from the current device, not ones that joined to the current device. To keep list of what devices are joined we'll need another table.

Ah ok I understand this know. In my case I don't need the full topology with sibling information but it would be nice to know which node belongs to which parent (for visual representation like in WSNDemo). (sadly there is no getParent request in the specification). For enddevices I get the parent-child relationship in BitCloud with the NwkAddr_req for Routers only with Mgmt_Lqi_req.

Quote:
If you need to discover particular devices, supporting particular profiles, there are other requests.

In the last days i tried this approach with the match descriptor request.
Searching for the mandatory clusters in a specific profile seems to work quite good and i could collect all devices which follow the ZCL guidelines :-) (my app is used to discover, monitor and control the ZCL clusters and attributes hence it depends on specific profiles and clusters. The match descriptor request is quite good for that and has filtering inclusive) :-)
The only thing I couldn'd get to work is a match request for the ZDP profile which would be nice to figure out what requests are supported on a node.

Quote:
You are free to complain to official support and if you'll convince them, I'm sure we'll implement this.

I will do this in the next days but first need some more research on this topic and behavior in other stacks.

Some other thing related to the ZCL reading the attributes works really well for most attribute types but I got a (again not so common) problem with octed string data type:

I added the optional manufacturerName attribute to the Basic cluster as octed string (character strings seems not to be supported yet).

{
    ZCL_AttributeId_t id,
    uint8_t           type,
    uint8_t           reportable,
    char              value[1 + 32];
}

// example fill
value[0] = 3;
value[1] = 'A';
value[2] = 'B';
value[3] = 'C';

Reading this attribute works!

The problem is that all attributes after this become unreachable until i change the value length.

Quote:

- char value[1 + 32];
+ char value[OCTET_STING_MAX_SIZE];

I guess this is so to get the proper size of the attribute struct inside the BitCloud ZCL lib and jump from one to the next?! Or I do it wrong?

The basic cluster has 4 string attributes (optional...) means 4 * 255. 8-)

So it would be nice if the attribute struct would carry sizeof(value) in a extra field for internal jumping or a pointer to the next attribute.
And therefore make it possible to have shorter than OCTET_STING_MAX_SIZE arrays (which shall be true in many cases).

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

Quote:
The only thing I couldn'd get to work is a match request for the ZDP profile which would be nice to figure out what requests are supported on a node.
Match descriptor does not work for ZDP requests.

From the stack's ZCL code I see that your code should work, but I can't really check it right now, for a couple of weeks I'm on a business trip.

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