manchester decode

[temtronic]

hmm, I think you've mislabelled your diagram ?
you've got sync-header-data

Mr. T's code has the sequence as
header --> sync--> data
'state' starts off at 0 (header)
then 'state' turns to '1' when 'delta' is > syncpulse
then 'state turns to '2' when beginning of 'data'

header is the group of 7
sync is the high for 4.8ms
data is the group of 56 bits.

that's how I read his code....

[bulut_01]

Yes, there seems to be something wrong with the code.
mr. ttelmah answers

[temtronic]

I have to think Mr. T's code is correct,he's almost a 'dino' like me BUT he's based his timing on your numbers.
You may have to adjust his numbers.
1st, you're using the internal clock and it may not be exactly 16.000000 MHz
2nd, you readings of 2.5ms and 4.8ms might not be accurate

With all serial communications 'timing' IS everything.

Try adding a 'marker' blip ,sends a 0-1-0 at the end of the 'header' ,and another one at the end of 'sync'... have it displayed on the logic analyzer and post the picture.

[Ttelmah]

Three things.
First, as Jay says I based this on the figures.
Second though is that it may well give the wrong sequence. The actual
edge counts and switching, I tested on the first 8 bits of the data, but no
further. It needs you to generate an SCL file of the data, with the correct
timings for the whole sequence, and then check that the clock inversion
does happen correctly. I didn't/don't have the time to do that.
Third, you do realise that this requires the data to be arriving on pin A0?.

[bulut_01]

There seems to be a problem with the sync header data order. Please specify above. How can I fix this? The order is wrong.

[bulut_01]

I edited the input as pin_a1 in the code

[Ttelmah]

There is no data order. The sync search just loops through the input bits,
till it sees one that is longer than SYNCPULSE.

[bulut_01]

syncpulse 4800 is the number here 4800 us? So why doesn't the code work? Is it because of the error margin of the times? TE time is 640 us. There is no setting for this in the code. I think if I could just run this code, I would relax

[temtronic]

just saw this.....
#use rs232(baud = 1600, parity = N, xmit = PIN_a0, rcv = PIN_a1, bits = 8, STREAM = UART1, stop = 1, errors) //uart setup


..... Actually saw 1600 baud ,which is a really odd baudrate but then notices the pins used for xmt and rcv....


and I really hate grn on wht.

fosc/4 then timer setup /4 = 1us

16MHz/4 = 4MHz to timer, then prescaler is /4 , gives 1us interrupts.

[bulut_01]

mr.temtronic
uart is off.your still think there will be a problem
disable_interrupts(int_rda);
disable_interrupts(INT_TBE);

[temtronic]

I don't know as I have never used that PIC but it 'might'.
One observation is that A0,A1 are also used for programming the PIC, so are they still connected to the programmer ?
I dedicate the ICSP pins exclusively to ICSP operations only.
You have the option of using RA3, 4 or 5 for 'signal in.....'
As well you could 'move' the UART to RC4 and RC5.

[bulut_01]

[temtronic]

No, though I probably have samples here.
99.44% of all my projects are PIC18F46K22 based. It became my 'Swiss Army Knife' PIC several years ago. With lots of memory, 2 UARTS, 40 pins, 3 or 5V operation,and a lot of other features(most I've never used), it's always worked for me. One project used all but ONE I/O pin.
Using this PIC has saved me 1000s of hours of 'learning a new PIC', and I have a 'library' full of functions that I KNOW work.

yes, 'smaller' PICs could work for most applications but the upfront cost savings maybe ($1) is offset in far reduced R&D time . Once a product is past 'Proof of Concept', someone else has to 'do the math' and see IF using a smaller ,less expensive PIC IS worth the effort.

[bulut_01]

You are right, I live in Turkey, pic mcu is expensive here, it is cheaper in America.

[PrinceNai]

You always say: the code doesn't work. Maybe I didn't read all the posts carefully enough, but I don't see exactly WHAT doesn't work. I'm sure the code I posted "works". I know it because what I send from one PIC shows in the buffer of the other PIC. I'm also quite sure the other code from Mr. T works. So, what doesn't work? How do you know it doesn't? If you are relying on your logic analyzer to compare the results, you'll never ever going to see the same thing. Look at the pictures you sent. Where the analyzer "sees" the data? On one of the pictures it ignores at least one byte at the end. If you have an extra PIC, do yourself a favor. Build a transmitter that will send known data every time. Than you can compare sent with received and see if there is a difference and where. Once again, I'm 99,99999% sure the first data bit starts one TE after the 4.800us preamble. I concluded that from the shape of the signals on your pictures. There are 113 bits sent out. Count them from the last one back on the picture that has a logic 1 as the last bit. Also from the shape of the signal. If you start with the first zero after the preamble, you have 0,0,1,1,0,0,1,1. That is NOT Manchester coded data. Your analyzer takes the falling edge of the preamble as the first bit. But to cut it short. What doesn't work?