Ideas for Network of Microcontrollers

The CAN network (when implemented properly) is very predictable.

However, any wireless network is highly unpredictable.

Sometimes it might work very well, sometimes not at all, depending of the phase of the moon, the air temperature, the location and a myriad of other factors.

Unless you actually need (mobile, rotating) systems, I would try to avoid using an RF system, if we are talking about 2-4 nines (99 % -

99.99%) of reliability.

I'd like a modular lighting panel for creating matrix displays, or other ty= pes of smart lighting. Wiring up data connections to all modules is a lot o= f wire and bandwidth is also an issue. I would also like each module to be = generic and determine its address (x,y,z coordinates) from where it is plug= ged into. There is a simple way to do this using wired connections, but a w= ireless module would need some other way to "know" where it is - by sensing= its location somehow, either in relation to its neighbours or a central co= ntrol point.

Each panel could be controlled individually, or by picking its own data out= of a broadcast, or modules could be peer controlled, if some of the module= s had sensors.

Obviously each panel/module would probably still need a wired power connect= ion, but it is relatively easy to wire bus or star power connections.

t

he

f

ch

Although the Kiva system is centrally directed, I suppose the system might be made in such a way that info is passed along between the individual robots;

Zigbee, Bluetooth, infrred, near-field and other types of communication would have to be very robust I think to compete with wires. An application that required movement of the 'node' or, which need to be repositioned frequently, is where a wireless network excels. And domotics like X-10 can often help in retrofitting situations where running wiring is inconvenient.

But just consider the wireless devices in your life now. How robust are those connections? Ever have cellphone drop-outs? Have to reinitialize your wireless inkjet printer? Are your bluetooth headphones reliable?

Let me get this straight... You have a problem that can be handled using wired networks. Your boss wants to use wired networks. /You/ know how to solve the problem using wired networks. You don't know anything about wireless networking, you don't know how to solve the problem, or even if the problem /can/ be solved with wireless networks. But you want help and advice on how to convince your boss that wireless networking would be a good idea?

The only thing I can think of is that you believe wireless will be more fun. While I am all in favour of people getting to enjoy their work (it even makes good business sense, as they do a better job), in this case I think CAN is more fun than wireless.

Use CAN, and do the job right. CAN is quite easy - it is /much/ easier than wireless, and usually cheaper (unless the wiring costs dominate), and far easier to get working reliably and predictably.

As far as i could understand, OP just need a isochronous network. For sure he does not need a lot of reliability on the data delivered, but just a strict timing. The same as any video cast... I can't see a reason why he cannot go to wireless. Actually that is pretty much market dependent, and maybe his customers hate wires more than anything.

Any way i think the biggest problem is the auto placing recognition... to do that wirelessy in a reliable way is not that easy. On the other hand if you follow a placement pattern on a wired network, that might be fairly easy. A bus network will not help you much on that point. You could try to go for a ring/line based network. I have nothing in mind right now. Just EtherCAT but would be very expensinve (10 EUR for a chip) for your application.

As you probably wont need a high throughput thinking that you do not have THAT many light points, you could create a module with no problem i think, but that would be customized... Another option is firewire, but i have no idea of the ASICs price today...

Cya

--------------------------------------- Posted through

Wireless does not give you any reliability about data delivering /or/ timing. You must build your wireless system with the assumption that it often won't work at all, and certainly that telegrams will get delayed, lost, re-transmitted, corrupted, etc.

Marketing departments love wirelss - it's a current fad. Development departments love wires, because they are far more predictable, and generally easier to work with. Installation departments sometimes like wireless, because it's fewer wires to attach - unless there is some other setup or positioning needed, in which case they prefer wires. And service and support staff love wires, because they always work - wireless systems work in some places, and for some of the time.

So if you are an engineer or developer, push for wires every time. A developer trying to persuade his boss that wireless would be better (in a case like this where CAN would definitely work) is about as sane as asking the boss to half the time budget just to make the project more challenging.

"Not that easy" being a euphemism for "almost impossible". You can't measure distance accurately with radio waves unless you want to invent your own GPS system - and I doubt that's in the budget. Some people think you can use "signal strength" as an indication of distance - they are wrong.

It is possible to use known limited-range wireless, like near-field communication, to get an indication of position - but for automatic positioning that would mean several readers on each card, at great expense.

So the way to do your "auto positioning" is to have a push-button on the board, and manually synchronise pressing the button with a setup program.

Or you simply add an extra wire or two in your connections. These are synchronisation wires - they don't need high speed or anything fancy. One card sets it's line high and broadcasts a "who is next to me" message. Other cards read their line - the one that reads a high signal is the neighbour. Easy.

I agree with all your opinions, but you can for sure get a very good timing on wireless video transmiting if you give up data integrity, and that is the whole point of working with isochronous transmission. You just dont check the data as in general the user wont be able to notice a wrong bit or even a whole dead frame if we are talking abou a 60hz refresh rate. That would work as a digital tv or any other digital video broadcast. Actually even working on wires, checking data integrity on your video can kill you whole application as you can not assure any timing. Thats why it is always isochronous transmission.

Finally i dont know why you guys are talking about CAN... CAN is not meant to transmit any sort of video.. considering a 60Hz rate, with 3 bits collors and 2000 "pixels" (20x100) we gor 360kbps, and that is pretty close to CAN limit considering overhead.

--------------------------------------- Posted through

We are talking about CAN, and not video, because the OP asked about real-time networking and data sharing between microcontrollers using wireless networking instead of CAN.

I am not sure why you brought video into the discussion.

Maybe there has been some mix-up of threads somewhere. I see that both you and the OP posted through a website rather than using the comp.arch.embedded newsgroup directly - maybe you've mixed something up with other discussions elsewhere on that website?

I guess i got confused here. I thought that the third message was sent by OP. The one talking about modular matrix displays. But i am wrong. Sorry my mistake.

Cya

--------------------------------------- Posted through

t

he

f

ch

This approach is what's called, "A solution in search of a problem". It almost never ends any way other than ugly, expensive, unreliable, expensive, or an utter failure, not to mention expensive. Did I mention "expensive"? Good luck becoming a rare exception!

Key points:

"..I need to convince my supervisor of the possible applications..." - In other words, there are no defined needs. "...I dont have any use of the concept..." - Nor do your customer(s), who are expected to actually pay for the product.

Start with your (customers') needs & requirements. Work from there. Search for the simplest & most robust solutions that solve the actual problems. It may very well turn out that wireless is the best solution. It also may not. It's not a very sexy process, but it improves your odds of ending up with a viable product.

Starting with a solution, & trying to shoehorn problems into it, is what I call "Painting yourself into a corner". Once you've made a particular choice (i.e. to paint the floor next to the door first, etc.) it can become very difficult to adapt when the REAL problems that actually do need solving pop up.

Well, when people use meaningless pseudonyms and silly names, it's easy to get mixed up. There are occasional good reasons for anonymity in Usenet groups or other discussion forums (I know some manufacturers and tool developers haunt this group under pseudonyms, for example - if they were open about their names and employers then it could hinder free discussions). But mostly such names just means no one knows who is talking to whom.

Except for really trivial communication cases, you either get reliable but not realtime transfers or alternatively realtime but unreliable communication, but you can not get both reliable and realtime at the same time. This applies to both wired as wireless environments.

In a broadcast (one way) system (e.g. GPS downlink), the timing is quite exact, only slightly varying due to the varying speed of light in a medium (troposphere and ionosphere).

Sure, the easy path is to give up, but that doesn't help develop anything new. If the OP wants to go wireless, why not let him try.

Apparently, "engineers" have developed some quite successful wireless technologies. I guess if John Logie Baird had been on the internet, some people would tell him he was crazy, and should stick to wires.

Perhaps having spent time working on mobile phones, DECT etc, I am not quite so scared of wireless as you are. As you say, there is a market for wireless devices, maybe some engineers will be smart enough to work out the solutions.

The problem is the great influx of people with only digital logic background trying to do wireless things.

Unfortunately, the learning curve may be too steep for real world non-trivial wired digital communication (which essentially deals with analog phenomenons) not to mention any non-line-of sight wireless communication systems.

technologies. I guess if John Logie Baird had been on the internet, some people would tell him he was crazy, and should stick to wires.

Different wireless users groups have quite different expectations for the reliability of communication.

For instance, some amateur radio operators are satisfied if they can utilize some special propagation phenomenon that might work 1 % of the time (or even once in a lifetime).

A person marketing some wireless gadgets are usually satisfied with

30-70 % reliability, so that in a marketing situation, the system would appear to work (and if it fails to work in some are marketing situation, it is still easy to find some excuses :-).

Any serious wireless communication system is expected to work 99 % or even 99.99 % of the time. Unfortunately. the system cost tend to go up by one decade, for each nine added to the reliability requirement.

If wireless the best choice for the problem at hand, then use wireless. But as the OP described the situation, they could deal with it using wired connections, and that's what the boss wanted (presumably the boss knows more than the OP, or has taken advice from people who do). So wired networking is good engineering - it solves the problem reliably in a way that satisfies the customer. Using wireless networking may or may not be an alternative - good engineering practice is to consider it, but only to use it if there are clear advantages.

I think you are mixing up "inventions" and "engineering". When you know a good way to achieve the required results, then it is simply unprofessional to waste time and money on something unknown unless you have good reason to believe it will be much better in the end.

My take on the OP is NIH.

Not Invented Here.

He wants his ideas to be the "profitable" idea.

don

t

he

f

ch

bumping to add this;