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.
Engineers at Fuel Cell Energy have found a way to take advantage of a side reaction, unique to their carbonate fuel cell that has nothing to do with energy production, as a potential, cost-effective solution to capturing carbon from fossil fuel power plants.
To get to a trillion sensors in the IoT that we all look forward to, there are many challenges to commercialization that still remain, including interoperability, the lack of standards, and the issue of security, to name a few.
This is part one of an article discussing the University of Washington’s nationally ranked FSAE electric car (eCar) and combustible car (cCar). Stay tuned for part two, tomorrow, which will discuss the four unique PCBs used in both the eCar and cCars.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.