Exploring opportunities with Atmel wireless

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

Hi!

I'm not new to Atmel AVR micros, but so far I haven't looked at the wireless products.
First a bit of information, what I'm trying to achive: I would like to build a small home automation network, preferably with Zigbee protocoll, because I have already PCBs with xBee (but not the programmable type) on it, but I need also programmable nodes on my network(so just one cpu, smaller pcb, longer battery life). Since I'm familiar with AVR, and I also have the tools, it seems to be a good idea to go with Atmel based modules.

I have a few questions related to it:

- BitCloud seems to be an implementation of ZigBee stack, but only for limited combination of cpu+radio IC (and of course rtmcu). Is there any support from the Atmel side (or any other opensource solution) to get a working ZigBee on an STM32 + Atmel radio chip for example? ( I suspect no, since I haven't found any evidence, but maybe I'm missing something )

- I see there is a MAC stack, which is the very basis of communication between two nodes - but it supposed to be compatible with xBee's S1 line (non Zigbee) modules. Am I right?
Is the source code provided for this?

- There's also a LWMesh Stack - but it won't work with other Zigbee? Since I guess this uses some proprietary protocol?

- So far what I have found the BitCloud would be the best soulution for me. I would like to use the wireless modules as a standalone solution (not as a serial-to-wireless module). Doing my own program on top of BitCloud.
Since the modules I'm looking at (from an-solution.de) have different hardware(for different antenna, and transmit power) inside: one is coming wiht a ATmega1281 and AT86RF230, the other one is coming with a single chip - ATmega128RFA1.
How easy is to port the code between these two one?

- And the last question. Digging around on the net I found this on Avian's Blog:

Quote:
However I have been investigating one important issue for around two months now and I'm confident that there is something seriously wrong with these modules. I strongly suspect there is a race condition somewhere in Atmel's (proprietary and closed-source, of course) code that causes some kind of buffer corruption when a packet is received over the radio at the same time as the module receives a command over the serial line. This will cause the module to lose bytes on the serial line, making it impossible to reliably decode the communications protocol.

Read the full story
http://www.tablix.org/~avian/blo...

Did anyone experience such problems with BitCloud?

Thanks for the answers,
Miklos

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

Zigbee is a PITA. No matter the vendor. If you MUST have cross-vendor interoperability, AND you MUST have a mesh network rather than one or more star-topology networks, then Zigbee with some application profile is the way to go.

Otherwise, for simple star networks, or ones where the nodes don't move and you can do static forwarding in your app, then just use 802.15.4. And you get interoperability without the hassle of Zigbee or a proprietary network layer.

At one time, it was said that 80% of the 802.15.4 radios in use did not use a mesh, nor any routed network layer that's proprietary.

That's been my approach too.

With Atmel, one issue is the legacy with Meshnetics.

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

lammelm wrote:
- BitCloud seems to be an implementation of ZigBee stack, but only for limited combination of cpu+radio IC (and of course rtmcu). Is there any support from the Atmel side (or any other opensource solution) to get a working ZigBee on an STM32 + Atmel radio chip for example? ( I suspect no, since I haven't found any evidence, but maybe I'm missing something )
No, because radios a a way to sell MCUs. Who wants to sell competitors' MCUs?

lammelm wrote:
- I see there is a MAC stack, which is the very basis of communication between two nodes - but it supposed to be compatible with xBee's S1 line (non Zigbee) modules. Am I right?
Is the source code provided for this?
I don't think there is a complete source code, but if you search this forum, you will find quite a few people who have tried with varying degrees of success.

lammelm wrote:
- There's also a LWMesh Stack - but it won't work with other Zigbee? Since I guess this uses some proprietary protocol?
Yes, LwMesh won't work in ZigBee networks.

lammelm wrote:
- So far what I have found the BitCloud would be the best soulution for me.
stevech is right - ZigBee is PITA. Avoid it if you can, especially for hobby projects.

lammelm wrote:
Since the modules I'm looking at (from an-solution.de) have different hardware(for different antenna, and transmit power) inside: one is coming wiht a ATmega1281 and AT86RF230, the other one is coming with a single chip - ATmega128RFA1.
How easy is to port the code between these two one?
BitCloud has libraries for both. For ATmega1281 and AT86RF230 you might need to make changes to HAL (RF connection might be different). DE usually provides patches for BitCloud to work on their hardware if necessary. From application point of view no porting is required.

lammelm wrote:
- And the last question. Digging around on the net I found this on Avian's Blog:
It looks like he had problems with SerialNet, which is quite possible. People often abuse the stack and then complain. BitCloud itself is very stable if used correctly.

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 your answers!

Somehow I thought ZigBee would be an easy solution - I have been having an eye on it since a few years, so I thought it might be ripe for a try.

What about using a standalone ZigBee module (like XBee, or any other) and interfacing it through it's serial port?
Is it still PITA? If then, what are the possible caveats?
I understand that ZigBee is a highly complex code, for a complex system, so digging in the code might not be trivial. But to interface it, with serial AT commands or something should not be that hard. Am I wrong?

What are your thoughts about Contiki and 6LoWPAN mesh network? PITA also?

The reason I consider ZigBee (preferably, because then I'm not bound to one vendors module, but other mesh networks could play) is, that the range of my battery powered devices might not be enough, and the message routing that is offered by mesh networks would come in handy.
Or is there an other way to extend the range with the help of an other module?

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

lammelm wrote:
What about using a standalone ZigBee module (like XBee, or any other) and interfacing it through it's serial port?
AT interface is limited to sending data to similar devices over proprietary frame format. It is of no use for any other applications.

lammelm wrote:
What are your thoughts about Contiki and 6LoWPAN mesh network? PITA also?
I have not worked with them, but simple fact that source code is open makes it much better option. But you loose interoperability with ZigBee devices, and protocol still might br too complicated.

lammelm wrote:
The reason I consider ZigBee (preferably, because then I'm not bound to one vendors module, but other mesh networks could play) is, that the range of my battery powered devices might not be enough, and the message routing that is offered by mesh networks would come in handy.
Migrating to a different vendor is usually comparable in effort for complete redesign, with lots of potential interoperability issues. So it only makes sense if you want to use modules from two vendors in the same network.

lammelm wrote:
Or is there an other way to extend the range with the help of an other module?
Use simple proprietary protocols, like LwMesh, or implement your own (essentially proprietary) protocol, or struggle with ZigBee.

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