Lost in determining best way to implement RF side of project

[RV4Flier]

I currently have the project developed on an Atmel SamR21 Explained board and have all the on board (non RF) functions completed - I'm moving on to the RF part which is new to me.  I have a RZUSBSTICK immediately available to use at the PC but could switch to a different device if recommended. 

Using the RF connectivity a need to coordinate data on multiple nodes with a small array of data using a PC as the data source/coordinator.  I'd like to send array  values and version number and receive a reply from each node that it has the latest array.  Imagine 20 field devices randomly scattered through an area and a user with a cell phone or PC connected 802.15.4 device updating the nodes with a new array of info about once a month or even every other month.  Very low updating cycle.

My thought is to try LWMesh but...I don't know if I should be spending time working toward (learning) bitcloud, zigbee, etc.  I've also had issues finding documentation for the RZUSBSTICK associated with LWMesh.

Any pointers?

[ataradov]

You will spend 10 times more time doing anything with ZigBee than learning LwMesh.

There is no direct support of the RzRaven, but it would not be too hard to add RF support, both radio and MCU are supported, it is just a matter of combining them. But it would be harder to support USB. You will probably have to figure out how to use LUFA stack.

For simplicity, I would stick with R21 Xpro  for PC as well. It has a UART connectivity to PC via EDBG chip. And it is much easier to get native USB working as well.

[julianhigginson]

first ask a few questions about what you need from the rf solution. here's some I can think of right now, you might have other/more questions for your project:

1) what frameworks/libraries did you use in making the existing code? (ASF?) and what RF link options do these easily support with existing drivers/examples?

2) what kind of energy capacity do you have to support the radio aspect of the project?

3) how much development budget do you have to do the project?

4) how much cost can the radio add to the devices?

From that you identify what your requirements are, and from there you can pick what's most suitable for your project.

[jnz]

You will spend 10 times more time doing anything with ZigBee than learning LwMesh.

I didn't know anything about it, so I just looked up LwMesh. You're right, seems simple. Esp the AT86RF212B standalone wireless device they have. All RF protocol and timing separated away with a pretty large FIFO and SPI. Seems pretty reasonable.

[RV4Flier]

first ask a few questions about what you need from the rf solution. here's some I can think of right now, you might have other/more questions for your project:

1) what frameworks/libraries did you use in making the existing code? (ASF?) and what RF link options do these easily support with existing drivers/examples?

      ASF, Atmel Studio 7.  I believe that support for LWMesh is already there

2) what kind of energy capacity do you have to support the radio aspect of the project?

    I need to save every electron I can.  I will be supplementing battery power with a small solar charger system, this is already implemented in the design and working.  I accounted for the current cost of the radio and assumed mostly sleep time.  Since my updates are infrequent it's cost effective for me to have the user wait for even a half hour while nodes wake and update.  Updates should be very quick since data payload is tiny.

3) how much development budget do you have to do the project?

  Haha...the budget always less than it will take.  I'd like to keep the rough start up of the radio end under 80 hrs of developer time (me).  I already have about 24 hrs into basic research on that end but that's not direct to the project - falls under the education and training budget.

4) how much cost can the radio add to the devices?

   It's a critical component.  The devices will not be accessible for about 9 months of time but the control data array will need to be modified as frequently as two weeks or as infrequent as three months.  That said, the radio can be the bulk cost.

From that you identify what your requirements are, and from there you can pick what's most suitable for your project.
[/quote]

[RV4Flier]

Thank you all for the info.  I didn't think about using the R21 as the PC device; I have the RZUSBSTICK and thought it would be handy since it's already the right form factor to give a user.  Using the R21 would be easy too...mental block was preventing me from seeing that.

Sounds like LWMesh fits the application I'm looking at.  Let me know if the above answers to  julianhigginson give way to another option.

Pat

[ataradov]

In an interest of full disclosure - I'm the author of LwMesh, so I may be biased.

I personally prefer the standalone version and manual integration into a project, but if can make ASF version work for you, then go for it.

If you don't need mesh, then just take PHY layer from LwMesh, and you will same even more energy on route discovery. It has very simple API - just 3 functions - Request, Confirmation of the request and Indication of a new frame.

[RV4Flier]

Alex, thanks for clearing that up...cheer for your code!

I'm reading the PHY layer now.  I just loaded a new project and added LWMesh to review what I'm dealing with.  While doing that I noticed RF4Control.  What is the application for that?

[ataradov]

While doing that I noticed RF4Control.  What is the application for that?

That's ZigBee RF4CE - a branch of the ZigBee spec for TV remote controls. It is even more pointless than a real ZigBee.

[jnz]

While doing that I noticed RF4Control.  What is the application for that?

That's ZigBee RF4CE - a branch of the ZigBee spec for TV remote controls. It is even more pointless than a real ZigBee.

Since you're in the know... How do you think the Zigbee vs Ant vs Thread vs Mesh types vs BLE vs ?? will come out? It seems to me that BLE is making big strides but I'm working on a BLE project and maybe just want that to be the case

[ataradov]

Since you're in the know... How do you think the Zigbee vs Ant vs Thread vs Mesh types vs BLE vs ?? will come out? It seems to me that BLE is making big strides but I'm working on a BLE project and maybe just want that to be the case

  None of them will go anywhere unless manufacturers of the stuff with those protocols agree to play with each other. And this is not going to happen ever, so the whole IoT thing will stay dead and fragmented. This is for home use.

Right now all this stuff is just a way to get your data out to the Internet and then charge you $10/mo.

None of them are good for industrial use either, but it is less sensitive to interoperability issues.

[julianhigginson]

IoT is happening already all around us - but not so successfully in our homes. Yeah - at the radio link end, there's lots of different options that don't work together (and in many cases could NEVER work together because they do totally different things) but hey this is why people make gateways! Also there's a lot of movement at the API end for connecting together "Silo" products... not that I think that's the best way forward, but it's something.

anyway... rf options for IoT things...

wifi - really good option for stuff to go on a home area network. it's a solid and reliable and well supported transport, and everyone pretty much has it already. And when you use it, you can use any LAN or internet resource you want.... its weakness is power usage but SOCs that can get on, do their thing and get back off very quickly can still run for years off a coin cell if needed... they keep adding stuff to the spec (like wifi-direct which would have been a really nice thing to see people take up - allows BT style advertising of what is available on a network before joining) but people seem happy with the basics, and stuff like this hasn't ever caught on. Also connecting a wifi IoT device to a home network can be a pain, current best practice seems to be the direct login and configure dance, which requires the person using it at home to know the wifi router setup, etc. Needs a special phone app, needs to spend at least a few minutes per device...

zigbee - was an old attempt to make a network that's good for home automation, but in practice it's pretty crappy, and quite a pain in the bum to setup and maintain. They totally missed the idea of a simple auto configuring/minimal config network when they made this, because it was designed by geeks for geeks. If you're a geek and want to build yourself a simple collection of non-moving sensors and devices around your house, I think zigbee is an OK choice... you want to build a product to sell? nope.

Thread - looks like what you'd do if you wanted to make a better version of zigbee.. even uses the same 802.15.4 standard for the PHY - unfortunately the licensing costs they bunged onto thread will mean the community of developers they need for thread to become a serious consideration will not happen. Which is a real shame, because I get the feeling if it could make headway and get used by lots of developers it could become the simple low power HAN where multiple manufacturers devices could work with a single gateway.

6lowpan - seemed like a nice idea, but it also seems that nobody ever cared to use it for anything...

All other 802.15.4 protocol options - I'm sure they all have a purpose and relative strengths/weaknesses but really they all just seem too similar yet different. if you make a standalone system of things that can use one of them, then go ahead, but your system will always need its own gateway if you want to get out of the local network.

bluetooth - has only ever really been about connecting stuff to phones and computers, even though it theoretically can do a lot more, nobody really uses those aspects for anything, and therefore those aspects of it are really not supported in practice. BT5 looks promising, and I heard rumours about what 6 will have that sound really interesting - but basically they're trying to extend towards and compete with wifi... I expect people will not use this much because wifi already works for what they use it for, dual BT/wifi chips already exist, and BT will stay a personal area network solution..

ANT - made some headway in sports stuff, but seems to be at a bit of a dead end. Not sure why you wouldn't just use BTLE.

LoRaWAN.. I can see that getting very big, if the LoRa alliance get their current project to implement position determination in the base stations working (sooooooooon apparently)

Sigfox... I see a lot of investment in infrastructure here in Australia, and it seems to be rolling out over a lot of the world, but people are rightfully wary about investing into a tech where only one company owns the data transport forever... I dunno. Wouldn't buy shares in this, personally...

NB-IOT (LTE variant) - a serious competitor to LoRaWAN and likely a sigfox killer if the standard can get written well and fast and implemented in silicon and supported by cell tower manufacturers in time..

3G, LTE - works for plenty of use cases (some cars nowdays have multiple cellular modems in them for telemetry purposes already) though costs a lot to power and maintain subscription don't work for a lot of things people want to do.


I think the big problems with "IoT" as a buzzword are:
1) the fact that everyone seems to think it's just one singular thing that you can roll out over the world in every use case.
2) the utter lack of imagination and poor understanding of user requirements that many IoT things have had so far (and the really greedy subscription models that business people these days want to pursue)

[ataradov]

Thread is a marketing name for 6LoWPAN + attempt at some sort of standardization of the application layer. Both are utter crap from design point of view. Also, neither has licensing fees of some sort. No one wants that garbage even free of charge.

"IoT is happening" is a really broad term, and can be applied to things that were happening for the past 50 years, depends on how optimistic you want to be.

[julianhigginson]

What do you mean thread and 6LoWpan are "utter crap"? talk about broad statements! Surely like every other low power device comms approach, there's situations where thread can work great, others where it wouldn't?

that "attempt at some standardisation" looks like a fair bit of work that should make customer network commissioning/config a lot easier. essentially providing something that other home network solutions don't have.  Setup/commissioning on a common network is the first stumbling block for any interoperability you might want different products from different manufacturers to manage! so at least thread is starting to look at that.

I just had another look at what I need to work with thread... thanks for the heads up - I was confusing thread group membership with licensing fees... looks like I don't actually need to be in the thread group to play about with it, as long as I don't need all the detailed spec and test help...

[ataradov]

What do you mean thread and 6LoWpan are "utter crap"? talk about broad statements! Surely like every other low power device comms approach, there's situations where thread can work great, others where it wouldn't?

It is not salable past a couple dozen of devices. In adopting that highly layered approach, people working with high layers forgot that underlying layer has very little bandwidth and wireless in nature, so a singe sent frame prevents every other device in the range for communicating. 6LoWAN is very chatty to the point where service traffic takes over the actual application traffic.

It is also not designed for good inter-network communication, the whole thing is built so that a number of devices cold talk to a single gateway (or very few gateways).

a fair bit of work that should make customer network commissioning/config a lot easier.

  Yes, that's exactly the indication of a problem. A protocol that does not think of this in a first place is garbage in my book. This is the most fundamental thing that has to be there from the beginning, not bolted on later on in the process by a third-party.

Development of this technology is a very politically-charged process. Some good features were consciously not included because they affected someone's interests.