# Variations in pulses generated and read by a uC

I have a 2 uC's(LPC1778 and a PIC), that perform 2 separate functions. The PIC generates pulses that are coded,where each bit of the code has a pulse duration of 1ms and a complete code is 8 bits long(8ms). The pulses generated by the PIC,travel through a relay(having front and back contacts) and are fed to the LPC1778 as inputs.

At the LPC1778 end,I'm sampling the input pins every 200uS(using a timer interrupt) and capturing the pin state for 32ms(in the timer ISR), before processing whether a valid pulse is available or not. Once a 32ms sample is captured, I take the majority of every 5 samples to determine what the actual bit value of code is. If the code is present in any 8ms duration of the 32ms captured,its fine.

This logic(in my understanding) may work fine as long as the period for each code remains 1ms.

What my doubt is, what are the possibilities that the time period of a pulse can vary? I understand that as long as my software generates 1ms output from a pin(PIC),the input at a pin(LPC1778) also must be 1ms because this is not a wave of high frequency and also the time period of each code is known beforehand.

What else considerations must be kept in mind to ensure that I read the code rightly?

What are the possibilities that this symmetrical pattern turns to an unsymmetrical one?

Update:

Im not using it like UART where data can vary and hence timing is important. I know before hand what data should always be on that pin and hence am merely checking for that 8ms value in a 32ms sample window.I need not always keep checking for it.

void Read_FCBC(void)
{
static U8 bSampleNo1=0;/*1st 200us*/
static U8 bSampleNo2=0;/*2nd 200us*/
static U8 bSampleNo3=0;/*3rd 200us*/
static U8 bAllDone=0;
static U8 bBufferCtrl=1;
static U8 bBufferCtrl1=0;
static U8 bBufferCtrl2=0;

if(bBufferCtrl)
{
dwFC1[bSampleNo1]=dw1Port1;/*200us*/
dwBC1[bSampleNo1]=dw1Port1;
bSampleNo1++;
}

if(bBufferCtrl1)
{
dwFC2[bSampleNo2]=dw2Port1;/*captured after delay of 200us wrt to sample 1*/
dwBC2[bSampleNo2]=dw2Port1;
bSampleNo2++;
}

if(bBufferCtrl2)
{
dwFC3[bSampleNo3]=dw3Port1;/*captured after delay of 400us wrt to sample 1*/
dwBC3[bSampleNo3]=dw3Port1;
bSampleNo3++;
}

bAllDone++;

if(bAllDone == 1)
{
bBufferCtrl1=1;
}

if(bAllDone == 2)
{
bBufferCtrl2=1;
}

if(bSampleNo1==160)
{
bBufferCtrl=0;
}

if(bSampleNo2==160)
{
bBufferCtrl1=0;
}

if(bSampleNo3==160)
{
bBufferCtrl2=0;
}

if((bSampleNo1==160) && (bSampleNo2==160) && (bSampleNo3==160))
{
bMeasureDone=0xFF;
bSampleNo1=0;
bSampleNo2=0;
bSampleNo3=0;
bAllDone=0;
bBufferCtrl=1;
}
}


The sample code for the process in ISR. Note:I have 16 FC's and 16 BC's connected to a port of the uC and hence i have to process in main(). If any 2 buffers agree with each other il use the best of 2oo3 dwFCX and dwBCX

• "each bit of the code has a pulse duration of 1ms and a complete code is 8 bits long(8ms)". How is the data encoded when every bit is a pulse? How do you get 8 1ms pulses to fit in 8ms? Do you mean that eg. '1' is a high level and '0' is low? Or something else? How do you know when the pulse train starts? Can you show us a timing diagram to illustrate your encoding scheme? – Bruce Abbott May 4 '16 at 6:42
• The PIC sends(LSB first)->0x86 indefinitely,01100001 01100001 01100001 01100001(total of 8ms where each bit period is 1ms). Even if i sample the bit stream at any point and from there capture 32ms ,0x86 must be in any 8 samples. Im using something like a pattern recognition. – AlphaGoku May 4 '16 at 7:00
• Im new to coding and so i have this doubt of whether itl work or not,cos the golden rule states "Experience trumps Knowledge". Im concerned if the method by which im sampling the bit stream is correct or not cos to identify a pattern,i should have captured the pattern correctly – AlphaGoku May 4 '16 at 7:11
• For example, Lets say my 32 ms samples are : 1(1st sample)00001 01100001 01100001 01100001 01(last sample)(i.e I missed the 1st 2 bits). Then in my algorithm il check for the code(pattern) 0x86.Value Stored for comparison is 0xA1A1A1A1 First Iteration: 0xA1. Second Iteration:0xD0 . Third iteration:0x68. 4th:0x34. 5th:0x1A. 6th:0x0D. 7th:0x86->All ok :) – AlphaGoku May 4 '16 at 7:45
• Before you go too much further, can the relay even switch at 500Hz? (worst case switching 101010101010) – Sam May 4 '16 at 8:51

I understand that as long as my software generates 1ms output from a pin(PIC),the input at a pin(LPC1778) also must be 1ms

Yes, but the LPC1778 is sampling the level every 200us so there will be an effective jitter of 200us. This is only 20% of the bit time so you should still be able to accurately determine the bit value. However, to do this you need to detect a transition (from '1' to '0' or '0' to '1') in order to determine the start and end of each bit. If you don't then your 5 samples could straddle 2 bits and the result may be indeterminate.

So the full receiving procedure would be:-

1. take samples until a '1' is detected (now you are inside a '1' bit)

2. take samples until a '0' is detected (now you are at the start of a '0' bit)

3. take 5 more samples. The 2nd sample in this group should be '0' (if not then go back to 1.)

4. Continue taking groups of 5 samples, testing the 2nd sample in each group and storing its bit value until you have 32 bits.

In order for this to work properly the receiver must continue to test in the middle of each bit until it is able to synchronize to another 'start' bit (1->0 transition). Bit rate error will accumulate, so the more bits that are received between each 'start' bit, the more accurately the receiver must track the sender's bit rate.

To accurately read each bit the sending and receiving bit times must be within 400us of each other, which is a tolerance of 0.4/32 = 1.25% for 32 bits. This should be OK if both MCUs are clocked by a crystal or ceramic resonator, but may cause trouble if one or both of them uses an r/c oscillator.

Now compare this scheme to the asynchronous signal generated by a UART. The only difference is that it adds a start and stop bit to each byte for synchronization, instead of using the data bits themselves.

• As per the logic i have written in my comment above, even if jitter is introduced in one 8 ms pattern, the code would be detected in the other 3 8ms samples(worst case 2 8ms samples) available right? I dont see the need for a start bit. Plz help. – AlphaGoku May 4 '16 at 9:50
• In Uart,the receiver has no idea when the transmitter is going to send data.Hence a start bit is required. I am completely aware when data arrives – AlphaGoku May 4 '16 at 10:08
• Ur algorithm describes mid point sampling. I tried multi point sampling(200us*5=1ms) where the majority of each 5 samples is the value of a bit. – AlphaGoku May 4 '16 at 10:14
• "I am completely aware when data arrives" - How? – Bruce Abbott May 4 '16 at 10:52
• I know that at pin X, always 0x86868686......arrives. There is no condition as to when the pic starts generating this. PIC always generates this.LPC1778 has to only read if the PIC is generating this correctly/not – AlphaGoku May 4 '16 at 11:03