Ideas for Network of Microcontrollers

[anex]

Hi,

I want to try and develop a network of micro-controllers that can interact
and share data with each other in real time and coordinate together to
perform a function. I want to use a wireless mode of networking and not the
traditional wired CAN network. However I need to convince my supervisor of
the possible applications it may have and its advantages over the wired
version. I am stuck at this point and it seems I dont have any use of the
concept.

Can anyone out of their experience suggest any possible application to such
a network. I have heard about CAN being used in cars to coordinate
different control units, but I wanted something more domestic and looking
for small push to get some ideas rolling in my own head.

thanks


---------------------------------------
Posted through http://www.EmbeddedRelated.com

[upsid...@downunder.com]

On Sun, 08 Jan 2012 04:40:20 -0600, "anex"
<anex.stormrider@n_o_s_p_a_m.gmail.com> wrote:

>I want to try and develop a network of micro-controllers that can interact
>and share data with each other in real time and coordinate together to
>perform a function. I want to use a wireless mode of networking and not the
>traditional wired CAN network. However I need to convince my supervisor of
>the possible applications it may have and its advantages over the wired
>version. I am stuck at this point and it seems I dont have any use of the
>concept.

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.

[Bob]

I'd like a modular lighting panel for creating matrix displays, or other types of smart lighting. Wiring up data connections to all modules is a lot of 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 plugged into. There is a simple way to do this using wired connections, but a wireless 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 control 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 modules had sensors.

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

[1 Lucky Texan]

On Jan 8, 4:40 am, "anex" <anex.stormrider@n_o_s_p_a_m.gmail.com>
wrote:

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;

http://www.youtube.com/watch?v=Fdd6sQ8Cbe0

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?

[David Brown]

On 08/01/2012 11:40, anex wrote:
> Hi,
>
> I want to try and develop a network of micro-controllers that can interact
> and share data with each other in real time and coordinate together to
> perform a function. I want to use a wireless mode of networking and not the
> traditional wired CAN network. However I need to convince my supervisor of
> the possible applications it may have and its advantages over the wired
> version. I am stuck at this point and it seems I dont have any use of the
> concept.
>
> Can anyone out of their experience suggest any possible application to such
> a network. I have heard about CAN being used in cars to coordinate
> different control units, but I wanted something more domestic and looking
> for small push to get some ideas rolling in my own head.
>
> thanks
>

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.

[Sink0]

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

[David Brown]

On 12/01/2012 19:52, Sink0 wrote:
> 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.

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.

> 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.
>

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.

> Any way i think the biggest problem is the auto placing recognition... to
> do that wirelessy in a reliable way is not that easy.

"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.

> 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.
>

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.

[Sink0]

>
>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.
>
>

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.

[David Brown]

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?

[Sink0]

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

[John Mianowski]

On Jan 8, 4:40 am, "anex" <anex.stormrider@n_o_s_p_a_m.gmail.com>
wrote:

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.

[David Brown]

On 13/01/2012 13:37, Sink0 wrote:
>> On 13/01/2012 12:26, Sink0 wrote:
>>
>> 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
>

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.

[upsid...@downunder.com]

On Fri, 13 Jan 2012 10:12:12 +0100, David Brown
<da...@westcontrol.removethisbit.com> wrote:

>On 12/01/2012 19:52, Sink0 wrote:
>> 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.
>
>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.

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).

[Bob]

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.

[upsid...@downunder.com]

On Sat, 14 Jan 2012 14:58:30 -0800 (PST), Bob
<bobcou...@googlemail.com> wrote:

>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.

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.

>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.

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.

[David Brown]

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.

[hamilton]

My take on the OP is NIH.

Not Invented Here.

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

don

[1 Lucky Texan]

On Jan 8, 4:40 am, "anex" <anex.stormrider@n_o_s_p_a_m.gmail.com>
wrote:

bumping to add this;

http://www.youtube.com/watch?v=YQIMGV5vtd4