IR network for PIC-processors

Hi, I have built timer/controllers for 10 kodak dias caroussels with a pic18f2550 microcontroller, and I want them to communicate to each other. Therefore I put a IR-LED and a IR-receiver on the pic's serial port and want to build some kind of ir protocol to broadcast settings over the network. All caroussels can not "see" all the other ones, so each caroussel has to retransmit received packages.

For now I have build my own protocol based on MACAW, but it would be nice to use some kind of standard protocol. Do you have any suggestions for implementing a IR-based point-to-multipoint protocol for this project?

I know about I2C, CAN, etc, but they are all point-to-point and what abaout collision/media access? How should that be implemented with IR?

- kristoffer ek

Reply to
Kristoffer Ek
Loading thread data ...

Sound like the ideal config for a hub. The central controller should have 10 sets of TX/RX and be powerful enough to route the traffic.

Reply to
linnix

The required data rate is very low, so I would prefer simpler hardware (one LED and one LED-receiver) i each caroussel. I would prefer decetralized topology becouse the dias caroussels can be put up without knowing anything about network configuration.

- kristoffer ek

Reply to
Kristoffer Ek

Peer to peer would complicate software significantly. Hub and spoke would be simpler.

Same thing. The host can just deactivate the non-responsive node.

Reply to
linnix

I know, but the software I build now actually do the works, but I was looking for something more standard-like.

Actually some of the nodes acts as hubs when they can "see" more than one node.

My protocol works like this:

when receive packet: to me: send ack

not to me: resend packet

plus collision detection on every sent packet.

- stoffer

Reply to
Kristoffer Ek

Perhaps applicable to your application, HP had developed a low cost IR (2400 baud) interface for use in some of their computers, printers and calculators. It was known as 'HP-SIR".

Other manufacturers had used it, but IRDA had then taken over.

The article "An Infrared Link for Low-Cost Calculators and Printers", in the the October 1987 issue of the HP Journal has details.

TomC

Reply to
tomcee

t

node.

How far apart are the nodes? IR only have narrow angle of view as well.

Reply to
linnix

node.

most of them can se each other. My question is about how to design the protocol :-)

- kristoffer ek

Reply to
Kristoffer Ek

one node.

You might want to take a look at the zigbee stack. Just change RF to IR.

Reply to
linnix

Thanx, thats a good suggestion, according to what I read about zigbee it looks pretty much as my stack is a beacon-less version of zigbee - wonder if there are any zigbee software stacks?

- kristoffer ek

Reply to
Kristoffer Ek

Microchip has zigbee stack for PIC18 and PIC24, but you would probably need 64K to 128K flash.

Reply to
linnix

to

The ZigBee sample router is around 64K for PIC18 and 96K for PIC24. So, you probably need 128K PIC18 or 256K PIC24 to do anything useful.

Reply to
linnix

You probably do not need to implement a full ZigBee, in which case you need less than 128 kB.

The RF4CE stack on top of an 802.15.4 radio will do just fine. Atmel has a qualified stack for this that runs on top of the ATmega128RFA1.

--
Best Regards
Ulf Samuelsson
These are my own personal opinions, which may
or may not be shared by my employer Atmel Nordic AB
Reply to
Ulf Samuelsson

t

Yes, but it's not going to work on 32K PIC18f2550. If the OP wants full Peer-to-Peer, he will need bigger chips. However, he can have 3 to 4 routers and the rest in devices only. Devices might fit in 32K, but not routers.

Reply to
linnix

They can "se" each other at up to 10 meters...

--
- stoffer
Reply to
stoffer

Yes, I think its overdoing it with zigbee

--
- stoffer
Reply to
stoffer

A lot of the code is dealing with routings, with ZigBee or IR. If you want Peer to Peer, you have to deal with routings. If you want simpler protocols, use star (master to slave) configuration.

Reply to
linnix

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.