Good presentation, nicely done, relieved a lot of concerns of the unknown. Actually very reminiscent of most network topology and protocol studies, concepts not unfamiliar to me, now particularized for this particular application ...
@pauln: slide 15 is good as it stands to show the protocol layers, but to convey the increasing number of "onion layers" as one moves down the chart, it might work even better with the arrows starting close together and getting further apart as you move down the slide, and maybe even color coding to show the portion of the layer above that is wrapped with additional protocol in the next layer below.
@pauln: Any comments as to why the contention-free period follows the contention (CSFM-CA) period when using a beacon? I would think the period immediately following the beacon would provide the greatest confidence about where the contention-free time slots lie.
Actually it's a bit of a mesh, with repeaters as required. We need E2E comm but have little say as to where the radios are positioned, as they have other purposes, although roughly in a line. Don't want to tie you up Paul.
If I were to build a large (many nodes and large distances) I would consider using IP before I invented my own protocol. Designing network protocols (such as IP) is a very complicated business, in the sense that there are a lot of things that go wrong. And, as you learn more about networking technologies, you would probably end up adding more features that are already provided by IP. Or, perhaps not adding them, even though they are needed to meet your requirements.
And, if you have more than a trivial topology, you probably want some sort of automatic routing. There are numerous routing protocols available for use in IP networks. And, desiging a routing protocol is very complicated, in that many problems can be very subtle.
@bbauer - you may be looking at trying to use the intermediate radios as "repeaters" (store and forward) unless you wish to have real-time or connectivity part way along the line. (like at substations)
Zigbee is a suite of protocols. Some protocols may have more problems with the propagation delay of such a network, while other protocols might work OK.
I suspect that the CSMA-CA protocol (if you are really using that on each hop) seems likely to perform poorly. This is analogous to the maximum size of an Ethernet network, which is limited by propagation delay.
The ack mechanism probably works poorly, because of the long delay between a packet transmission and the reception of the ack.
The limitation of having only one outstanding (unacknowledged) frame at a time is a problem with a network this large.
Paul, do you think Zigbee is suitable for real-time applications?
My current project needs a rapid response to an input. We originally tried to apply sub-1G with simple peer-to-peer network. But latter, we have to deal with expanding the wireless coverage. Mesh network such as Zigbee is perfect for our purpose, but I am not sure whether it can provide good real-time performance, say less than 100ms average delay for about 30 nodes. For example, the frequency we are choosing is 2.4GHz and average payload is 40 bytes long.
The sync problem is also present on Cell phones. The difference being that cell phones can tolerate a few bytes being lost without having voice communications suffer. Our ears are amazing at filtering through issues.
Paul - you have lots of vintage radios - any that transmit?
For those of you just joining us, today's questions so far are: 1) What network topologies have you implemented, or are going to implement, in your network? 2) Has anyone implemented a non-beacon, low-power network?
The streaming audio player will appear on this web page when the show starts at 2pm eastern today. Note however that some companies block live audio streams. If when the show starts you don't hear any audio, try refreshing your browser.
In a bid to boost the viability of lithium-based electric car batteries, a team at Lawrence Berkeley National Laboratory has developed a chemistry that could possibly double an EV’s driving range while cutting its battery cost in half.
Using Siemens NX software, a team of engineering students from the University of Michigan built an electric vehicle and raced in the 2013 Bridgestone World Solar Challenge. One of those students blogged for Design News throughout the race.
Robots that walk have come a long way from simple barebones walking machines or pairs of legs without an upper body and head. Much of the research these days focuses on making more humanoid robots. But they are not all created equal.
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.