Meshnetics ZigBit module + atmel IEEE 802.15.4 MAC stack

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

Hi,

Can I use the atmel IEEE 802.15.4 MAC for AT86RF230 on a meshnetics zigbit module?

Im running the coordinator example program ( i modified the source so it sends me debug messages over the uart so i can track what functions get called) but i never get a call to the reset callback function.

// callback for reset function
void usr_mlme_reset_conf (uint8_t status)
{
    uart1_tx_ptr("usr_mlme_reset_conf",sizeof("usr_mlme_reset_conf"),ADDCRLF);
	LED0(BLINK);
    if ((status == MAC_SUCCESS) && (c_status.state == PEND_RESET))
    {
        mac_set_short_addr(PANCOORD_SHORT_ADD);
    }
    else
    {
        mac_do_reset();
    }
    return;
}

so the state machine does not advance to setting the short_addr etc..

Maybe the SPI link is different on the Meshnetics module and the stack waits for valid data from the AT86RF230 ? or am I overlooking something?

Thanks in advance,
Koen

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

Hello Koen,

It looks like ZigBit modules have a different SPI link from Atmel modules. It could be like this (this is only based on my investigations) :
Mega1281 AT86RF230
PA7 -> RST
PB0 -> SEL
PB4 -> SLP_TR
PD6 -> CLKM
PE5 -> IRQ

Best regards.

Jean-Pierre

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

Hi Jean-Pierre

I have modified the defines and recompiled the library but still no success :( What stack are you using ?
I tried the meshnetics openMAC but I'm getting corrupt uart baudrates, but the connection with the RF230 seems to work :)

Regards,
Koen

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

Hello Koen,

If SPI communication between ATMega1281 and AT86RF230 is correct, we are on the right way. Concerning UART communication you need to set FOSC at 4 MHz and it should be OK (at least it worked for me with MeshBean module).

I did not use any communication stack for this test.

Best regards.

Jean-Pierre

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

Hi JP,

Im using Meshnetics eZeeNet stack now.

I have replaced the F_OSC 4000000 defines with 8mhz because Im using internal RC osc on the zigbit module.

It was still not working, but I found out (after 2 days of messing around) it was beacuse of the lib zigbitint.. so I removed it from my makefile and the uart is working!

Now I can try to get my zigbee network up and running!

Koen

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

Hello Koen,

Following my last email exchange with MeshNetics, they told me that they won't continue to improve eZeeNet. Instead they proposed ZigBeeNet stack. So I think it's better to start working with ZigBeeNet now.

Best regards.

Jean-Pierre

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

Thank you for the information Jean-Pierre, but unfortunatly Meshnetics only sells their new ZigBeeNet or BitCloud stack with the development kits according to their website:

Quote:
Availability and Support

The new stack is available as part of MeshNetics ZigBit Development Kit and MeshNetics ZigBit Amp Development Kit.

I have only bought the ZigBit modules (ZDM-A1281-A2) so I will have to work with the old but free eZeeNet stack.
I think it will be fine for now since the application is fairly simple ( 1 coordinator and some enddevices in a star topology ).

ps: I had to put everything back to 4mhz because i had timing issues at 8mhz! The fw_joinNetwork() call did not invoke the callback functions joined() or lost().

Best Regards,
Koen

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

Unfortunately the new ZigBeeNet/BitCloud/whatever they call it today stack lacks the source code for HAL/atmega1281 library. All that source code was previously available with eZeeNet.

We had huge problems with the i2c implementation in eZeeNet and had to rewrite a lot of stuff. Now what if there's a problem in the new stack, how do we find it, and how do we fix it? Repeated emails to their tech support and they refuse to release the code.

Sorry, not taking that chance. Meshnetics really screwed their customers over with this one. I want all the .C files to go with the .H files in the HAL_HWD directory.

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

all that is why I prefer Digi/Maxstream XBee series 1 for ALL non-mesh applications (which is most), where ZigBee isn't needed.

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

We did try go for the XBee option, but the development environment was Freescale Codewarrior and the documentation from Digi (they were called something else before) was totally crap. Actually we bought the ZigBee development kit from Rabbit which comes with three XBee modules and an API for Dynamic C to talk to them.

Anyway the point is this. We'd like to use the ZigBee stack simply to provide a mesh network with wireless UART. The rest is our own code, which we do a lot of in-house stuff.

The eZeeNet option was fine, because it compiles with GCC, so the development environment is free and nice. We also had access to all the source code, except the actual ZigBee stack, which is fine too, because we don't care about that.

But we very really need access to the atmega1281 HAL code, which contains the w1, i2c, uart, etc. code. Which is all available in eZeeNet, now these idiots decide to rip it from BitCloud.

I emailed their support and the guy, point black, flat out said "Sorry we no loner support eZeeNet, please use BitCloud". That's nice, thanks for telling us a few months before that you were phasing out eZeeNet. What are we supposed to do with our codebase now?

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

laichzeit0 wrote:
We did try go for the XBee option, but the development environment was Freescale Codewarrior and the documentation from Digi (they were called something else before) was totally crap. Actually we bought the ZigBee development kit from Rabbit which comes with three XBee modules and an API for Dynamic C to talk to them.

Anyway the point is this. We'd like to use the ZigBee stack simply to provide a mesh network with wireless UART. The rest is our own code, which we do a lot of in-house stuff.

The eZeeNet option was fine, because it compiles with GCC, so the development environment is free and nice. We also had access to all the source code, except the actual ZigBee stack, which is fine too, because we don't care about that.

But we very really need access to the atmega1281 HAL code, which contains the w1, i2c, uart, etc. code. Which is all available in eZeeNet, now these idiots decide to rip it from BitCloud.

I emailed their support and the guy, point black, flat out said "Sorry we no loner support eZeeNet, please use BitCloud". That's nice, thanks for telling us a few months before that you were phasing out eZeeNet. What are we supposed to do with our codebase now?

Most people use a separate small microprocessor to do the application and it communicates via logic-level serial to the XBee using the binary packet API or the Hayes modem like API.

In any vendor's '15.4 module, my approach is to NOT add code to their module's baseline because (1) you may disrupt the MAC timing, (2) the vendor can rightfully say that the product assurance cannot be sustained if you add your own code to their frey and (3) only a very high volume product can justify modifying the module's code base and the high amount of NRE needed to learn that environment and (4) most modules have very little unused memory space.

So the least painful and least NRE way to do this is to NOT use the 802.15.4 API but rather, use a serial port (or some use I2C) API which allows you access to all that's important anyway.

The modules I've used (Xbee, Jennic, SiLabs, ZMD) all have serial port APIs of one kind or another with all the info/status you need for an application. Meshnetics' engineers in Moscow have been slow to follow suit.

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

You may want to check out the TI Z-Stack. They have the HAL and the application layer/profiles as open source. Unfortunately the rest of the layers are closed source, but from what it sounds like, that may be all you need. Not sure which modules use the TI chips tho.

Also, regarding the Digi XBee modules, they have switched from Freescale to Ember. The ember environment is probably better (or at least cheaper) than the CodeWarrior one. Also the XBee modules support mesh networking now.

Akiba

FreakLabs
Open Source Wireless
http://www.freaklabs.org

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

akiba_freaks wrote:
You may want to check out the TI Z-Stack. They have the HAL and the application layer/profiles as open source. Unfortunately the rest of the layers are closed source, but from what it sounds like, that may be all you need. Not sure which modules use the TI chips tho.

Also, regarding the Digi XBee modules, they have switched from Freescale to Ember. The ember environment is probably better (or at least cheaper) than the CodeWarrior one. Also the XBee modules support mesh networking now.

The Digi XBee series one (Freescale) is offered sans ZigBee due to the legal issues arising from TI's acquisition of Figure8 Wireless, author of the early ZigBee stack used by Freescale (TI's competitor). Xbee series 2 uses a 3rd party chip that Ember puts their MAC and Zigbee on. Last time I checked, you cannot run sans-ZigBee with Series 2. So it depends on what you want to do.

My experience with TI's demo kits and their ZigBee was not good. Moreover, what their demo kit does is rather moot if one is trying to begin by using an already FCC certified OEM module. But then, I'm no ZigBee (PRO) fan because it is missing important functionality such as battery powered mesh routing support, leading to many proprietary mesh protocols and no interoperability which was supposed to be ZigBee's charter.

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

Quote:
The Digi XBee series one (Freescale) is offered sans ZigBee due to the legal issues arising from TI's acquisition of Figure8 Wireless, author of the early ZigBee stack used by Freescale (TI's competitor). Xbee series 2 uses a 3rd party chip that Ember puts their MAC and Zigbee on. Last time I checked, you cannot run sans-ZigBee with Series 2. So it depends on what you want to do.

Ember used to use the CC2420 for their chip back in about 2005/2006 time. However they had to switch after Chipcon got bought out by TI. Since then, they acquired the RF unit of Cambridge Consultants and now have their own chips, the EM250/260. The current XBee's allow mesh networking, however it is true that the limitation of Zigbee is that the routers that implement the actual mesh must be MAINS powered or have a huge battery since they are always on.

Quote:
My experience with TI's demo kits and their ZigBee was not good. Moreover, what their demo kit does is rather moot if one is trying to begin by using an already FCC certified OEM module.

I can't say how good TI's demo kits are since I haven't used them. However their stack is from Figure8 Wireless which was the original Zigbee stack. Since then, TI has open sourced some parts of the stack including the HAL and the APP/ZDO layers. Their chips are also the Chipcon chips which were the first ones that supported 802.15.4. They recently opened a forum so you can probably do more research there.

Akiba

FreakLabs
Open Source Wireless
http://www.freaklabs.org

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

I just want to make a slight correction; both eZeeNet and BitCloud has a serial interface called SerialNet http://www.meshnetics.com/wsn-software/at-commands/.

So it is perfectly possible to use the ZigBit modules in a dual chip approach where the module handles the wireless communication.

Another point is that eZeeNet is ZigBee, not ZigBee PRO. And given the changes in the ZigBee PRO standard it is not that difficult to understand that Meshnetics launched a redesign of their FW.

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

The API for the new BitCloud ZigBee PRO stack is actually a lot better. You can see they've learned a lot.

Meshnetics really encourages the development of your own application on the micro. They provide you with a bunch of examples to work from. The simple example of a wireless UART (meshed) compiles with 20% of the 128kb code space available for your own use, as well as 29.5% of the 8kb RAM available (obviously shared with stack) and then you still have some of the 4kb EEProm to use. All in all, that's a lot to work with if you know how to code compactly.

Using a separate micro increases cost, power usage, etc. We really want to go as cheap as possible.

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

Oh regarding SerialNet. In eZeeNet it was somewhat broken. It looks really nice, doesn't remain stable under high throughput, it literally falls over and resets. When contacting Meshnetics about this I was told by their support engineer to "send the data slower". Right. And I was only transmitting once I'd received the \r\nOK\r\n back from the coordinator. That's a ridiculous solution. SerialNet is also very heavy in terms of code/data space usage. Don't expect to add a lot of custom serial extensions to it.

I'm not sure if it even works with the current BitCloud stack as they say, but don't provide, a SerialNet example in the current complete SDK.

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

laichzeit0 wrote:
Oh regarding SerialNet. In eZeeNet it was somewhat broken. It looks really nice, doesn't remain stable under high throughput, it literally falls over and resets. When contacting Meshnetics about this I was told by their support engineer to "send the data slower". Right. And I was only transmitting once I'd received the \r\nOK\r\n back from the coordinator. That's a ridiculous solution. SerialNet is also very heavy in terms of code/data space usage. Don't expect to add a lot of custom serial extensions to it.

I'm not sure if it even works with the current BitCloud stack as they say, but don't provide, a SerialNet example in the current complete SDK.

what do you do for flow control? Usually either RTS/CTS or software XON/XOFF. That's what other '15.4 products use for transparent serial port extension.

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

Hello!
Has bought ZDM-A1281-A2 with version 1.6.2.0.
But it does not work correctly (loses data by transfer).
Tried last insertion from a site, but it does not work.
Whether can somebody send me on e-mail m_t01@mail.ru a working .hex for SerialNet.

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

Hi everybody,
I just realized that there is a new version of OpenMAC at the atmel web page. (December 2008). I am ideally trying to use it in the zigbit module because the OpenMAC from Meshnetics (sourge forge) gave me errors when trying to compile and it seems that it is not updated since 2007. Any comments?

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

hugosg wrote:
OpenMAC from Meshnetics (sourge forge) gave me errors when trying to compile and it seems that it is not updated since 2007. Any comments?

Rumor is that they were in serious financial trouble but some recent funding may help. Not sure if this is more than random rumor.

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

On may Koen asked how to implement the ATMEL openMAC into the Zigit and jean-pierre repply the following:

Hello Koen,
It looks like ZigBit modules have a different SPI link from Atmel modules. It could be like this (this is only based on my investigations) :
Mega1281 AT86RF230
PA7 -> RST
PB0 -> SEL
PB4 -> SLP_TR
PD6 -> CLKM
PE5 -> IRQ
Best regards.
Jean-Pierre

It seems it worked. Where in the code should I do such modification?
Regards and Thanks?
Hugo

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

Hello Hugo,

I just discovered this new release of ATMEL OpenMac and after checking code, it looks like you need to modify "pal_config.h" in order to take into account ZigBit modules.

Best regards.

Jean-Pierre

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

Jean-Pierre. Thank you so much. For the preivous help

All guys:

Another question about implementing OpenMAC on the Zigbit. Which one would it be better to implement considering that in both cases I have to do modifications.
With the ATMEL version I have to dig in the pla_config.h to set up the proper pins.
With the Meshnetics version I have to find what why is it not compiling.
Has people sucedded compiling Meshnetics version?

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

Hello Guys!

Could you please explain how to use BitCloud from Atmel. I'm new with AVR and need explanation what software, directories, examples to use and can I emulate ZigBit device.

BR

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

starch wrote:

Could you please explain how to use BitCloud from Atmel. I'm new with AVR and need explanation what software, directories, examples to use and can I emulate ZigBit device.

1. You can't emulate ZigBit.
2. If you new to AVR are you sure that you want to start with something complex like BitCloud? What task do you have? Just playing around or something more specific?
3. BitCloud also supports Raven and RZUsbStick hardware.
4. Download BitCloud and give it a try.

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