One Wire One Way Custom Comm. Protocol

[FFT]

Hi All,

I wanna make an one wire one way protocol for my system.

My system can be explained as following;

1 pic -> opto ->|
1 pic -> opto ->|
1 pic -> opto ->|
1 pic -> opto ->|->1 PIC (X)
1 pic -> opto ->|
1 pic -> opto ->|
1 pic -> opto ->|
12f675 ___________18f4520

The PIC named X receives the datas on a pin and all the other pics send their datas over the opto couplers.

Conditions;
1 - All PICs use INT_OSC configuration and their signal lengths may change by temperature...

2 - X PIC can switch off/on all of the other PICs VCC remotely. When X switches on the VCC, all the other PICs have VCC.

3 - X PIC switches on VCC of other PICs and gets datas each of them, then switches off the VCC till the next repeat.

4 - All PICs have unique IDs

5 - The data of 1 PIC is ~20bits

I want to collect some ideas for the best communication protocol for such kind of system.

It should be faster and secure.

All PICs must send their datas separately by a kind of queue (the others must wait the PIC which send its data to avoid synchronization issues)

How can be defined the optimum time interval for waitings?

Should X PIC measure the pulse widths of signals to avoid changing of pulse widths because of the internal oscillator?

As result; How to make the best protocol for such system and how to receive the datas?

Not: Optos are TLP181GR
Not2: Output and inputs pins of PICs are NOT interrupt featured.

Lets think a bit
Sincerely.

[temtronic]

quick ideas...
If you're saying that the Master PIC controls the individual remote PICs power(VCC), then 99% of the communication details are easy,real easy.
Have the Master powerup a remote, get the data, then power down that remote.Do the same proceedure for the next remote, then the 3rd, etc....
Speed is dependent upon the optocoupler setup,cable length as well as any data error checking you have in mind.No remote IDs are necessary as the MASTER knows who it's talking to.
Consider sending data in 8 bit packets( 3 bytes) to make it simple using the builtin use rs232(..) functions, getc,putc,etc.

[ckielstra]

Just some design ideas:
- A one-way communication system is only a design option when it is acceptable to lose data once in a while. When lives depend on the data it is not an option.
- A standard hardware UART can not be used because it requires a 3% stable clock for sender and receiver combined. INT_OSC for most PICs does not match this (consider temperature influence as well).
- Study the Manchester encoding (used in Ethernet). It is an encoding where the clock signal is included in the data transmission. Drawback is that transmission time is doubled.
- You will have to add some kind of data integrity check. For example the CRC8 code as used in the Dallas one-wire protocol. 8 bits of CRC is overkill for a 20-bit data message, but I do like the efficient algorithm. Get things working first, only then start to optimize.
- The CRC-check ensures you will only accept valid data, but in case of corrupted data what to do? Consider sending the same data multiple times (this is what television remote controls do). Or use the power switch off/on to start the whole procedure again.
- Instead of the CRC-check it might be more useful to use an Forward Error Correcting (FEC) code. FEC is great for one-way communication because it allows the receiver to detect and correct a limited number of errors occurring anywhere in the message without the need to ask the sender for additional data.

If you can not switch on/off each PIC individually, then synchronization of the data transmission between the PICs becomes more difficult. As the time for each transmission is known, you could use the PIC id's to create a stand-off time:
- PIC1 starts transmission on power-up,
- PIC2 waits 1*(transmission time + safety margin),
- PIC3 waits 2*(transmission time + safety margin),
- etc.

Another wild idea is to use the power-line to the PICs as a trigger mechanism by removing the power for real short times and using a data input on the PIC for sensing the power drop. This would require a relative large capacitor and diode on the power line for each PIC. Hey, improving this a bit more would give you a two-way communication mechanism.

[Wayne_]

is this a homework project?

As the opto's are one way (a slave has no way of knowing if another slave is transmitting) and you turn ALL slaves on and off at the same time then there is only one way to do it.

As stated by ckielstra
"As the time for each transmission is known, you could use the PIC id's to create a stand-off time:
- PIC1 starts transmission on power-up,
- PIC2 waits 1*(transmission time + safety margin),
- PIC3 waits 2*(transmission time + safety margin),
- etc.
"

[aruna1]

I would be using sony IR protocol for such communication, its pretty easy to implement and decode

[FFT]

Thanks ckielstra and the others for your replays.

FEC is good idea. I also think for huffman code.

As CRC I think to count the ones in the data and send it together, then check it on the master PIC.

The MOST Important:

[Ttelmah]

3bits repeated, gives 3* the transmission length, and only requires one error, to leave you unable to tell which is the right copy...
Sending them 'adjacent', means that if the error source is EE noise, it is quite likely that adjacent bits get damaged at the same time. Burst errors. Duplication is 'wasteful', compared to encoding methods like Hamming encoding.
Look at the encoding used on CD's.

Safety margin, will depend on the accuracy of original clock sync, interval between sync's, and the clock accuracies of the chips.

Best Wishes