Ideas for Network of Microcontrollers

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

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.

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.

On Jan 8, 4:40=A0am, "anex" <anex.stormrider@n_o_s_p_a_m.gmail.com>
wrote:
> Hi,
>
> I want to try and develop a network of micro-controllers that can interac=
t
> 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 t=
he
> traditional wired CAN network. However I need to convince my supervisor o=
f
> 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 su=
ch
> 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 throughhttp://www.EmbeddedRelated.com

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=3DFdd6sQ8Cbe0

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?

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.

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 http://www.EmbeddedRelated.com

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.

> 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 http://www.EmbeddedRelated.com

>
>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.	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

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

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?

>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	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com