AVR RAVEN Technical Discussion

Go To Last Post
115 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

[NOTE FROM MODERATOR: SORRY TO HIJACK THIS POST BUT I CAN'T SEEM TO PUT MY OWN POST ON TOP HERE]

Since the main RAVEN thread at has been overpowered by many looking-for-free RAVENs posts, I decided to split off a few of the technical posts into this thread.

The split happens around page 11 of the old thread, here

-MMC

[END OF MEAN MODERATORS HIJACKING]

My understanding is that the Raven uses the same transceiver and the RZ200. I haven't actually verified that yet, but it seems that there was something I read to lead me to this conclusion.

Out of curiosity, I started doing some experiments with the RZ200. The RZ200 demonstration kit comes with 5 RF modules and a motherboard/base unit. One of the 5 RF modules plugs into the Base unit and the Base/RF module pair directs the traffic between itself the other 4 modules.

My modest home is a two level structure with a footprint of 30 feet by 50 feed. The base unit was placed in one extreme corner of the house and the other units were places in opposing corners, where at least two of the remote units were as far as possible from the base unit. The RZ200 is pretty functionless as a demonstration kit in that, all that is demonstrated is the transfer of switch closures from the modules. One RF module plugs into the Base unit, one module is set up as a 3 channel LED indicator, and the other three modules transmit the status of a momentary tactile switch status.

I know this prelude was long winded, but I wanted to describe the setup so that you would know what was involved.

The end result of the test was that, communications was "Rock Solid !"t I can find no where within my home where reliable communications can't be established between any RF module and the base unit.

Now, the question that I would have for the Atmel ZigBee team is: Will the RZ200 base and the Raven modules be able to see each other and interact with each other. As all devices have a unique MAC address, the RZ200 and the Raven should be able to take note of the others existence and each should be able to become an extension of the others networking structure.

I could be way off here, but it was one of the first thoughts that came to mind when I was looking at the Raven documentation.

Thanks for bearing with me...

Edit:

My idea is that if possible, I want to place the RZ200 Base module in a central location within my home. As the RZ200 Base unit seems to act as the central hub of the RZ200 network, I wanted to use the RZ200 RF modules for remote switch (such as lighting, TV, Radio, etc.) control, and as the Raven seems to have a higher degree of I/O flexibility, use the Ravens for things that require more complex data, such as transmitting program data to my table-top milling machines.

I don't know if this is possible. But it doesn't seem all that "Far Fetched. "

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

Quote:
My understanding is that the Raven uses the same transceiver and the RZ200. I haven't actually verified that yet, but it seems that there was something I read to lead me to this conclusion.

The radio used is the same, there is a slight change in the MCU connected to that radio chip. RZ200 uses Mega1281, Raven uses Mega1284P. I imagine the switch was to get better performance battery-wise (Pico power).

But assuming you are using Zigbee / 802.15.4... they should all talk to each other. You shouldn't care who made what in theory, anything with that standard SHOULD talk ;-)

I don't see source for the Raven yet, hopefully it just hasn't gone through the release stages yet. There of course is all the code for the Tranceiver Access Toolbox (TAT) / 802.15.4 MAC.

Info on the 1284 used is sparse, so I'm not sure if that stuff would run as-is!

-Colin

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

c_oflynn wrote:

The radio used is the same, there is a slight change in the MCU connected to that radio chip. RZ200 uses Mega1281, Raven uses Mega1284P. I imagine the switch was to get better performance battery-wise (Pico power).

But assuming you are using Zigbee / 802.15.4... they should all talk to each other. You shouldn't care who made what in theory, anything with that standard SHOULD talk ;-)

The 1284P provides PicoPower but it also provides 16K RAM. From experience, more RAM is always welcome for any type of communications protocol.

The software stack that is used is really what determines whether the units will talk to each other. For one, they may not even be on the same channel, and two, they may not even accept each other on their own network.

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

Guillem Planisi wrote:

> I'm missing any information about ATmega1284P.

Well, look into the latest part description XML files...

Essentially, it's an ATmega644P with twice as much ROM and
four times as much RAM. Same footprint, same peripherals
otherwise. I once made my own simple experimental board for
it to test the avr-libc support for the device, using
STK500-style 10-pin headers. Picture attached for the
curious.

Attachment(s): 

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Thanks, Jörg. I will check ATmega644P datasheet. 16KBytes RAM are a really good point. I don't know why I'm always short of RAM.

BTW, nice board.

Guillem.
"Common sense is the least common of the senses" Anonymous.

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

Quote:
For one, they may not even be on the same channel, and two, they may not even accept each other on their own network.

Ah - yes I guess my post as a little generalized! But what I meant of course was that the RAVEN and RZ200 boards should be able to talk to each other, provided you set up the network properly.

BTW - would anyone care if I split these last few technical posts discussing the RAVEN into a new thread? Theres just so many "i want a free one too" posts inbetween the discussion!

-Colin

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

I'm not sure if this is on-topic or off-topic but to me it seems to relate so I'll ask here.

I personally know nothing about RF, and I was curious what issues arise (like relating to Communications authorities...ie: FCC, CRTC, etc.) when using for example the AT86RF230 in a design? Hopefully this isn't a large can of worms I'm opening up...

Any way just curious. I do have a couple of designs which could potentially benefit from using a wireless approach - I especially liked the idea someone mentioned about wireless-ly programming remote boards - this is a pretty cool idea and actually has merit.

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

Re FCC ++

The Ravens and the USB stick has undergone FCC/ETSI testing and holds the corresponding certifications.

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

Forgive me for being a little 'airy' - but like I said I know nothing when it comes to RF.

So if you use these kits (raven/usb transceivers) to iron out the design, then would you still have to seek your own certification to use the design commercially?

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

Does anyone have a feel for how the radios on the Raven might interact/interfere with 802.11 WiFi signals in close proximity? My experience with cordless phones at 2.4 GHz has shown they routinely interfere with WiFi, and I am hoping that won't be the case with 802.15.

I guess I need to get more boned up on the radio technology used in this product.

-Reid-
W0CNN

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

Hi,

I started a thread concernig a WirelessUSART. I will try to implement this on the RAVEN Kit. Anyone with ideas and/or same thought help me / give your comments suggestions https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=60523&highlight=raven

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

@rocketman49:

One of the goals for the IEEE 802.15.4 standard is to have little intereference with WIFI. Different channel layout and spreading technique is used to ensure this. I have done tests with the RF230 close to a WiFI access point, without any problems. Problems might occur if the WiFI unit is set to transmit continously, flooding the air with traffic. The CSMA algorithm in the RF230 will say that the channel is busy and that the data cannot be sent. With normal WiFi traffic in the area where the RF230 operates will not create any problems. You will have to create test intended to get the device to fail!

-fastbakken

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

Is there any information on interference from high power nearby RF sources? I am interested in developing a wireless remote control head for licensed radio transmitters using parts of the spectrum from 29 MHz to 440 MHz at 110 watts, and 900 MHz at 35 watts. The wireless control head would not be directly exposed to the high power antennas, but it would be in near proximity (such as inside a vehicle with a high power antenna on the passenger compartment roof). Shielding helps, the difference in frequencies helps also, but the wireless antenna and receiver characteristics doubtlessly make the largest difference.

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

@Mike

with so much Watts around:
Considering POW (Power over Wireless)?

After all, we're talking Atmel's PicoPower ;)

c is for cookies

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

Mike B wrote:
Is there any information on interference from high power nearby RF sources? I am interested in developing a wireless remote control head for licensed radio transmitters using parts of the spectrum from 29 MHz to 440 MHz at 110 watts, and 900 MHz at 35 watts.

Mike,

I am at the other end of the question. Developing a steerable 6.5 GHz horn antenna for reception and would like to use the Raven "nearish" to it, but concerned about possible interference to the incoming video signal.

Cheers,

Ross McKenzie ValuSoft Melbourne Australia

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

Quote:
Is there any information on interference from high power nearby RF sources? I am interested in developing a wireless remote control head for licensed radio transmitters using parts of the spectrum from 29 MHz to 440 MHz at 110 watts, and 900 MHz at 35 watts.

That's going to be a function of the front-end of the 2.4G RF receiver. How much dynamic range does the first RF stage have before you get gain compression and it starts producing intermod mixing products? That's the key question. Fortunately, for 29/440/900MHz (ham band FM repeaters or remote base?) they are so far away from 2.4 GHz that what the 2.4 antenna manages to respond to you should be able to take out with a front-end filter like a helical resonator. You might even find a 2 or 3 can filter like that in the digikey catalog these days. Or you could do a strip-line filter on the PCB. If you can keep the front-end from collapsing from out-of-band energy you should be fine.
Quote:

I am at the other end of the question. Developing a steerable 6.5 GHz horn antenna for reception and would like to use the Raven "nearish" to it, but concerned about possible interference to the incoming video signal.

"nearish", but not in front of, I bet. Every antenna pattern I've ever seen for a horn in that frequency range is extremely narrow with good side rejection. The RFI won't be coming in through the antenna.

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

BitOfAVR wrote:
with so much Watts around:
Considering POW (Power over Wireless)?
Interesting idea, however these are typically base or mobile transceivers (Rx and Tx) with a limited Tx duty cycle. So, it would limit the control head interface to only operating while the transmitter was active. If a control head function is used to activate the transmitter, then it would be a classic "chicken or the egg first" dilemma :).

The problem isn't powering the control head. One problem is eliminating the bulky cabling that often hinders using good mounting spots in/on the vehicle dash boards. Inside structures, remote operation is another possibility. Even short range remote operation while out of and near the vehicle would be of interest.

dbc, thank you for the input. Adding additional uncompensated filtering would reduce the sensitivity/range, maybe only in inches or maybe more. Of course to some extent, increased Rx sensitivity can be a friend of internal Rx interference. PC board design would also be critical. I hoped someone might have EMI rejection acceptance testing experience with the AT86RF230 chip. Some testing labs can subject a device under test with up to kilowatts of external RF over a wide spectrum range.

The difference between theory and real world interference can be huge. Often the source of the problem(s) can be obscure.

Thanks to everyone for the input.

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

BitOfAVR wrote:
@Mike

with so much Watts around:
Considering POW (Power over Wireless)?

After all, we're talking Atmel's PicoPower ;)

It looks like this has already been done - and here's a kit!
http://www.radiodaze.com/KIT-PICKARD.htm :wink:

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

Yeah, but it's not 802.anything :). The only digital format it did was Morse code, which required a human modem to decode it back in the day. If it was built on an edible sandwich instead of a wooden board, it could power the earphone and the human :wink:.

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

I've looked into the ravens software specs. It seems that as the kit is delievered, it is only 802.15.4 compilant. It seems to be missing the upper layers of the ZigBee stack? Am I correct?

Also, I looked at the MeshNetics RZ200 stack code, and while having more of the ZigBee stack parts in it, there doesn't seem to be anything about supporting the ZigBee standard profiles (home automation in particular). Am I missing something?

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

geek.au wrote:

It looks like this has already been done - and here's a kit!
http://www.radiodaze.com/KIT-PICKARD.htm :wink:

Now, THAT is a great invention :idea:
Thanks for the link.

c is for cookies

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

I found this web page about the difference between 802.15.4 and ZigBee:
http://expertanswercenter.techta...

In addition:

Wikipedia on ZigBee wrote:
The first stack release is now called Zigbee 2004. The second stack release is called Zigbee 2006, and mainly replaces the MSG/KVP (Message/Key Value Pair) structure used in 2004 with a "cluster library". The 2004 stack is now more or less obsolete.
Zigbee 2007, now the current stack release, contains 2 stack profiles, stack profile 1 (simply called ZigBee), for home and light commercial use, and stack profile 2 (called ZigBee Pro). ZigBee Pro offers more features, such as multi-casting, many-to-one routing and high security with Symmetric-Key Key Exchange (SKKE), while ZigBee (stack profile 1) offers a smaller footprint in RAM and flash. Both offer full mesh networking and work with all ZigBee application profiles.
To top it all off, it appears many implementations of ZigBee (profile 1) are often not fully implemented to save on CPU resources (i.e. to use smaller less capable CPUs that cannot support any full ZigBee stack implementation, so some only do a sub-set of a given ZigBee stack profile). In addition the ZigBee Alliance (apparently the creator/guardian of ZigBee) has some hoops to jump through before you can get your hands on any ZigBee specification. Not that you would have much fun implementing a ZigBee stack from scratch :wink:. It appears you have to join the ZigBee Alliance and probably pay dues etc. if you want to do your own ZigBee stack for commercial release.
http://www.zigbee.org/en/index.asp

The IEEE 802.15.4 should be taken care of by the AT86RF230 chip, hardware and interface. The ZigBee stack will be whatever AVR compatible version you can find. Anyway, they are not the same thing even though ZigBee depends on IEEE 802.15.4 for its wireless physical layer and MAC.

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

Quote:
So if you use these kits (raven/usb transceivers) to iron out the design, then would you still have to seek your own certification to use the design commercially?
AFAIK if you use the design wholesale (antenna and all) you may be able to skip the certification of that section. But you may need to still certify your product as a whole.

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

Mike B wrote:
To top it all off, it appears many implementations of ZigBee (profile 1) are often not fully implemented to save on CPU resources (i.e. to use smaller less capable CPUs that cannot support any full ZigBee stack implementation, so some only do a sub-set of a given ZigBee stack profile). In addition the ZigBee Alliance (apparently the creator/guardian of ZigBee) has some hoops to jump through before you can get your hands on any ZigBee specification. Not that you would have much fun implementing a ZigBee stack from scratch :wink:. It appears you have to join the ZigBee Alliance and probably pay dues etc. if you want to do your own ZigBee stack for commercial release.
http://www.zigbee.org/en/index.asp

Actually, you can download the full ZigBee spec here:

http://zigbee.org/en/spec_downlo...

Just fill in a dummy company and provide a real email address and they will email you a link to download the PDF from.

The ZigBee spec covers everything from the physical layer up to the application layer. You as the designer can choose what layers to implement.

Some silicon providers (Freescale and TI) are giving the full stack (up to the Application layer) away for free. I haven't played around much with the Freescale stack, but I have been playing around with the TI stack. Their stack comes with many example applications, one of them being a fully compliant zigbee home automation switch and light controller.

Their example works like this: The coordinator powers up and finds a "free" channel to use. When the routers/end devices power up, they scan the spectrum to find a network to join. Once joined, they will accept/route network traffic as need be. At this point, the devices are liked up via the link layer.

You now have to bind a "switch" endpoint with a "light" endpoint at the application layer. Their example has you push right on the light eval board joystick to "allow a switch to bind". You then push left on the switch eval board joystick to automatically find a light board who is accepting switch bindings. Once this is completed, you can toggle the light (one of the LEDs on the board) with the joystick on the switch board.

TI's switch and light are coded up to meet the ZigBee application layer HA Profile, id: 0x0104. This is where my knowledge tapers off rapidly, though. I can't seem to grasp the intricacies of how this application layer stuff works. I've read the docs, and studied the code, but I'm lost.

I guess my point here was I was hoping I could take a look at the MeshNetics full ZigBee stack, complete with HA profile implemented. Perhaps this doesn't exist at all. If it did, I would hope that studying another solution would provide more insight into how it works.

But when I really boil it down, I don't really need to implement the HA profile. I just thought it would be mondo cool if I did. It's really feeling like it isn't worth all the hassle. But then again, I love a technical challenge.

Another fact going against learning the HA profile: no audio feed back mechanism like "kaw-kaw". :D

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

yzf600 wrote:
Actually, you can download the full ZigBee spec here:
It is linked off of their main page, but reading the agreement "hoops" it appears to me that you may not divulge the specification contents to anyone else and you may not develop commercial ZigBee code from it (I didn't read it in depth). It's not a problem for hobby/research projects, but I have no idea if you could ever distribute any ZigBee stack code you write, even for free.

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

You will find a ZigBee NWK layer in the RZRAVEN kit. This NWK layer provides you with star and tree network support.

-Fastbakken

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

-

The Zigbee Alliance as such has a different opinion on the state of things from its members -
http://www.zigbee.org/en/join/me...

This is a toned down version of what they were saying a while back, where they were suggesting that everyone - almost but not quite including the householder who pressed a zigbee lightswitch - would have to (pay to be) a member of the Zigbee Alliance.

The Zigbee Alliance offers several levels of membership $40,000 a year buys you top level membership, and a seat on the board; $9,500 a year buys you full membership with - wow! - a right to vote!; the bottom level of membership - just grunts like us - which allows us to use "their" intellectual property - costs $3,500.

Yup, according to the Zigbee Alliance, we would have to pay them $3,500 every year to be allowed to use "their" product, even if we're using a module from a member company. Or, come to that, a free stack provided by Meshnetics/Atmel.

Manufacturer members - such as Atmel - seem to have a somewhat different view on this subject.

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

I read and wrote some of the 'toned up' stuff and I don't come to the same 'toned up' conclusion as you did. The FAQ does not say what the difference is between ZigBee code developed by a member with full access to the specification and ZigBee code developed under the no disclosure allowed 'free' specification access. Manufacturer members - such as ATMEL - have their own ZigBee license that might allow giving away the code? Anyone not privileged to the ATMEL license details would not have any clue about this.

One of my questions is if anyone is giving away ZigBee commented source code or just linkable object files in a library?

My previous question, not suggestion, involves if releasing source code for free under total 'no disclosure use' would violate the disclosure or not. Like I can't talk to you about or give you copy of the specification, but here is commented source code to reverse engineer if you want. I just realized that if you restricted source code distribution only to other 'free' ZigBee specification holders or full members then there would not be any problem. It still could not be used for profit until after joining.

This situation means that any non-member academic research or hobby development can only enrich ZigBee Alliance members. If you are a non-member and do not want to do unpaid work for their commercial enrichment, assert your rights and enforce your rights as real not for profit use only or offer to sell a license :).

The FAQ does make it clear that you may not make any ZigBee product or product with any ZigBee in it for profit without joining. 'ZigBee.org', what a joke :evil:. I wonder if they could be charged with tax evasion under the guise of a non-profit or with misrepresentation?

I vote for a GNU open source alternative that will eventually leave ZigBee in the dust.

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

Quote:

The FAQ does make it clear that you may not make any ZigBee product or product with any ZigBee in it for profit without joining. 'ZigBee.org', what a joke Evil or Very Mad.

If so, IMO as an outside observer, that will be the death knell. It is one thing to pay an extra $1 per module for dev costs and ZigBee dues. But if I might be on the hook for a lawsuit somewhere down the road for embedding, say, an Atmel piece such as the Raven into a product with Atmel-provided libraries/source code, then no thanks.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

For a factory that knows they will produce more then 3,500 ZigBee units a year, its a bargain. The more you make, the cheaper it gets per unit. If you make 35,000 units, it drops to 10 cents a unit. I really do not see how the ZigBee Alliance could actually enforce any membership requirement for development (i.e. what they don't know...), but the final ZigBee design would have to be produced by a member.

If I read the FAQ literally (just like a software developer is likely to do), if I manufactured and sold my own custom home automation product line that included a few complete ZigBee modules interfaced to a non-ZigBee bridge on my end, manufactured by a ZigBee Alliance member (purchased as complete hardware/software units), then I would also have to join the ZigBee Alliance to sell my product line. Oh darn, it appears there is no Emoticon for :stupid:. I lost a good Emoticon opportunity there :).

To tone things down, my literal reading must be wrong as that appears to be just too stupid/greedy to be real.

I'm reminded of the Firewire/USB wars. It seems USB 1.0 was inferior, but it didn't carry extra costs per unit. Well, now you can find Firewire on some motherboards, but try and find any motherboard without USB!

The Raven IEEE 802.15.4 is totally separate from any protocol like ZigBee (ZigBee was just written to take advantage of 802.15.4, they do not own any of it), so Raven development can use any suitable protocol other than ZigBee. This is where I believe a strong GNU open source effort could all but kill ZigBee off. I mean, don't some people still have 8 track music tapes and players in their basements? Make room for ZigBee in that old tape box :).

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

rocketman49 wrote:

> So if you use these kits (raven/usb transceivers) to iron out the
> design, then would you still have to seek your own certification to
> use the design commercially?

That depends on the legislation you want to operate these in. For
FCC, you *always* have to get your own certification, for the final
device that's going to be sold. That's because it is a device that
intentionally emits radio waves. (Devices that are not intended to
emit can optionally be self-declared as conforming to FCC
regulations.)

For the EU area, you have to declare that your device conforms to all
applicable regulations, and the end-user visible sign for that is that
you apply that CE label. Upon request, you have to produce a
statement of conformity to anyone asking for it. *Which* regulations
apply to your product is within your own responsibility, and it's also
your own responsibility *how* you found out that you are compliant.
However, you've got to be pretty sure you are, and in case of anyone
seriously doubting it, you'd better provide some kind of proof about
how you ensured your device is compliant. This could be a measuring
protocol from a recognized test lab, but it's not strictly required.
In theory, if you are using one of the reference designs 1:1, with the
very exact layout, components etc., and you're reasonably sure you
didn't change anything that would make the emitted RF different than
it has been in the reference design, this might be sufficient to
deduce that your own design is also CE compliant. (There's more than
the Raven available as a reference design, see the AT86RF230
application notes.) Either way, if your product is going to become a
high-volume one (where the costs of recertification will amortize
quickly), you'd better at least do *some* measurements. If it's going
to be low-volume, it's probably also below the radar of your
competition (which you might have to fear much more than any kind of
authorities gratituously starting to make their own measurements on
it).

If you're out for an FCC certification anyway, better run CE and FCC
measurements within a single session, as most of them can be shared
within the test lab (often, there are only slightly different limits
that apply, or things like measuring in a different distance which the
certification lab can recalculate from a single distance based on
their own experience).

For other areas than North America and the EU, there's often extra
certification needed. Some of them might require you to show a proof
of prior certification, like the Japanese who want to see an FCC
approval before they even start.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Mike B wrote:

I vote for a GNU open source alternative that will eventually leave ZigBee in the dust.

As GNU voting is free of charge: count me in.

And since Odin's spear is called Gungnir, which never misses its target, I propose this new stack developed for the Raven Kit to be called:

Gnugnir :P

c is for cookies

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

Quote:
This is where I believe a strong GNU open source effort could all but kill ZigBee off.

If your goal is Total World Domination for your protocol, the GPL is not the most effective choice. The BSD license is the tool of choice for that goal.

GPL is for when you want to retain some control over distribution, and retain the possibility of renumeration for commercial use under an alternative license. BSD is for carpet bombing the world with your invention in order to influence the course of human history.

And before anybody thinks I'm trying to start a license flame war -- I have exactly the opposite intent. All licenses have their purposes. Choose your license the way you choose a screwdriver, not the way you choose a religion.

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

Gnugnir :-) Excellent name.

There is nothing in the Raven source code that prevents it from being used as a seed into such an open-source project (From Atmel's stand-point). It is more or less the best way that this code can adapt and continue to evolve. The source code will support GCC and IAR at launch.

-Fastbakken

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

Quote:
There is nothing in the Raven source code that prevents it from being used as a seed into such an open-source project (From Atmel's stand-point).

So... Atmel has changed it's license for this one? The most open license I have ever seen from Atmel says you can use the source code for any purpose as longs as the result is a binary that runs on an Atmel processor. Or at least the way I read it that is what it says. Unfortunately, that is not compatible with the GPL, as it is a restriction over and above what the GPL places on code. Nor would that be compatible with the BSD license. Or MIT license. or the Mozilla license. Or most other licenses I can think of. So, either a) Atmel used a new license for Raven code, or b) I'm mis-interpreting the license.

As I said, I haven't read the license that comes with the Raven code -- so I'll go do that now. But most licenses I've seen from Atmel are almost-open-but-still-useless licenses.

EDIT
So I did go check the 802.15.4 MAC zip file, and although there isn't a specific license file that I found, all the source files I spot checked looked like a "BSD" license. So that's good news, it can be incorporated into most anything.

The Zigbee code is packaged in a self-extracting .exe, so there is no way I could look at it until my 8 year old daughter lets me reboot her machine into Windows -- which is unlikely as she has the Linux side up because she left it in the middle of a PCB design that has about 25 rats left.

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

dbc wrote:

The Zigbee code is packaged in a self-extracting .exe, so there is no way I could look at it until my 8 year old daughter lets me reboot her machine into Windows -- which is unlikely as she has the Linux side up because she left it in the middle of a PCB design that has about 25 rats left.

I installed the MeshNetics Zigbee software on my box. The license is pretty restrictive. You can modify the code, but only distribute the changes in binary format. You can't even re-distribute the Documentation or code unmodified.

At any rate, I've been mulling over this ZigBee application layer stuff for a while. Now I'm no software engineer (ASIC designer by trade) but it seems overly complicated for what it really does. Maybe it got this way because ZigBee was trying to address the needs of every member.

The reason I say this is I've seen all the cool projects here and all over the internets and they all do some pretty advanced stuff with some simple code. The Ardunio is a good example of this.

On the other hand, I'm terrible at reading specs/standards. I never feel like I can get a good handle on something after reading the spec. I need to experiment and get feedback to learn something.

So all that to say that I'll develop my own application layer to sit atop the ZigBee NWK layer fastbakken referred to. I think that would be the easiest and most robust solution for what I need: light control, home monitoring and security.

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

Quote:
So all that to say that I'll develop my own application layer to sit atop the 802.15.4 MAC layer.

Yup. 802.15.4 is designed for exactly that, anyway. I always used to see ZigBee talked about in the context of warehouse automation, so I think a lot of the decisions for the ZigBee layer were based around the needs of that environment.

As for layers on top of 802.15.4, the 6loPan protocol looks pretty interesting. Haven't studied it much, though.

Thanks for checking the license on the ZigBee stuff, BTW.

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

yzf600 wrote:
dbc wrote:

The Zigbee code is packaged in a self-extracting .exe, so there is no way I could look at it until my 8 year old daughter lets me reboot her machine into Windows -- which is unlikely as she has the Linux side up because she left it in the middle of a PCB design that has about 25 rats left.

Now That's cool! Very cool!!! :wink:

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

Bonus points to the daughter! :mrgreen:

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

> Now That's cool! Very cool!

My thoughts, too, Dave. ;-)

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Quote:
Now That's cool! Very cool!!!

Thanks, guys. I have to admit that I did the placement and analog routes before giving her the board and I'm coaching her on strategy. It's only 48mm x 128mm, medium density. This is her third board. She saw me designing boards and begged me to give her one, so the first one was a simple switch/resistor/LED circuit. I had it fabbed and helped her solder it up. When she showed it off at the local robot club, a couple of the guys had just come back from exhibiting at CES and they were so impressed they gave her a remote control toy robot they had picked up as trade show schwag. So now she is convinced that every time she designs a PCB, somebody will give her a prize.

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

Really really cool!!

Guillem.
"Common sense is the least common of the senses" Anonymous.

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

Quote:
So now she is convinced that every time she designs a PCB, somebody will give her a prize.

It works the same way here for a board or firmware--it is called a "paycheck" as a prize.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

What is the range of RZ200 or RAVEN?
In side room and in open air?

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

> What is the range of RZ200 or RAVEN?

We once tested the RZ201 open-air and reached close to 1000 m.
Note that the RZ201 has a directional antenna (the Raven uses the
same antenna), so this measurement was taken within the main
antenna direction, of course.

The little USB dongle in the Raven kit uses a much smaller almost
omnidirectional antenna, which has much less antenna gain, so the
achievable distance with that antenna is for sure shorter.

If you leave open air paths, things get difficult. Most of the time,
it's not the signal strength then that determines the quality of the
link, but interferences from multi-path propagation (echos, so to
say). Also, the building itself can account for "shading" certain
areas, so it's often a matter of just moving half a meter further in
order to re-establish the connection.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

Last Edited: Fri. Mar 28, 2008 - 03:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dbc wrote:
The Zigbee code is packaged in a self-extracting .exe, so there is no way I could look at it until my 8 year old daughter lets me reboot her machine into Windows -- which is unlikely as she has the Linux side up because she left it in the middle of a PCB design that has about 25 rats left.

If she can make VCRs stop blinking too, she ought to put out her consultant's shingle! :D

You probably have a better option than waiting for that PCB design to finish, though. Just hibernate that machine, and reboot into windows ... do your thing ... then reboot back into Linux. On the rare occasions I need Windows, that's what I do.

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

Quote:
We once tested the RZ201 open-air and reached close to 1000 m.

I have no experience with RF, but have worked with AVRs.

If one has to install a network of sensors at an Industrial unit, and these sensors will transmit the data using AT86RF230 + ATmega128: Any experiences can any one share about the industrial "noise" causing disturbance for RF links

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

Industrial noise is probably not that much of an issue, unless your
noise sources are emitting 2,4 GHz noise directly. However, a WiFi
access point close to an IEEE 802.15.4 device can indeed seriously
degrade the performance. Both use different modulation schemes, but
if the WiFi interferer makes your 802.15.4 node hear nothing but WiFi,
you won't have much fun with the link.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

dbc wrote:

As for layers on top of 802.15.4, the 6loPan protocol looks pretty interesting. Haven't studied it much, though.

As I wouldn't like to rule out the possibility for my coffee machine to have an IP number in the near future, i'd place my bets on 6LoWPAN ( IPv6 over IEEE 802.15.4) see RFC4944

There is an (GPL) implementation from Sensinode here: NanoStack(tm)

Which requires: FreeRTOS

c is for cookies

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

With GPL being probably about close to the worst license one could
chose for a piece of software intended for an embedded device. Who's
going to hand out all the source code for their embedded devices?
(Why's that that microcontrollers ship with lock fuses at all?)

But it's great there's at least one opensource implementation around.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

dbc wrote:
The Zigbee code is packaged in a self-extracting .exe, so there is no way I could look at it until my 8 year old daughter lets me reboot her machine into Windows -- which is unlikely as she has the Linux side up because she left it in the middle of a PCB design that has about 25 rats left.

I best be getting started with my daughters. At 1.5 and 3.5 years old I should have time to get them up and coding within 4 years each ;)

I wrote my first GWBASIC programs back when I was 8, but PCB design? Wow.

Would it be possible to use the necessary software on a different Atmel processor - say, an atmega32 - and connect it with the Atmel RF chip and have a working piece of communications hardware? I'm thinking of a small PCB, a small SMD atmega processor, a dash of flash and a radio node that is small enough to fit inside a ping pong ball, with a small 3V lithium battery. No THAT would be cool. And useful.

-Sale

ps. Sensinode is operating at the University of Oulu, where I'm also studying mechanical engineering, as well as working for the dept. of electronics and information engineering..small world ;)

Sauli Särkkä
Oulunsalo, Finland

Pages