correlation receiver on 8515

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using two 433 MHz transceivers to send 14 databit's between two AT90s8515's, too synchronize the reciever and transmitter I am trying too program a correlatin reciever in the 8515 on the recieving end. My problem is this: Although a high datarate is not necesary, I was hoping to use a baudrate of about 9600 Baud, but with 4 samples/bit the code generated by CVAVR (attachment) is far too slow (the routine takes about 640 microseconds) and 6900*4 gives a sample period of about 25 microseconds. Does anyone have an idea of how i can make more effective code.

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is a tough problem. I doubt that your AVR will be fast enough.

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Ohm,

sorry, all what I can see, are tons of macro definitions and some code fragments totally without any comments.
This was equal bad readable than pure binary code.
So anybody was unable to find out, what happens.

Please give us any short C code, which described better, what you want to do.
Or describe in words, how your routine should work.

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have now included the C file with comments, hope this will clarify things.

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Ohm,

to understand, what you want:

1.
the function synkroniser() was now free running, but in real it must be called in constant time intervals ?

2.
you want to recognize the bit pattern 01100101

3.
with 4 sample points:
any 3, 4 or 5 zeros in series should be read as 0
any 7, 8 or 9 zeros in series should be read as two 0
...
any 3, 4 or 5 ones in series should be read as 1
any 7, 8 or 9 ones in series should be read as two 1
and so on

Right ?

Also is it possible that disturbance occur (pulses below 3 scans)
and if yes, how should it be handled (e.g. ignored) ?

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Ohm,

it seems, you are no longer interest on this item ?

I found some mistakes in your code, so it can never work.
E.g. the result of the shift operation was not used. I assume, you are a beginner on C language:
You need the "=" sign to store the result of an operation, e.g.:
x = y >> z; works, but y >> z; have no effect.

Also its unwise to use 16 bit on an 8 bit machine, if you only count up to 32 (only wasting time and memory).

Please answer, if you still interest for more,

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello Peter,

The reason I didn't answer you before is thet the 17th of may is a national holiday in Norway, and beeing a student I took the 16th off as well ;-)

Some answers:

1) As the receivers only task is to receive the bits and display them on an LCD display, the synkroniser() function will run constantly until a full set of bits have been received (the function is not complete yet) then i will run a function that convert the bits into an integer and displays them on the LCD before I return to the synkroniser() routine.

2)Correct

3)Right!, The "sum" variable is the number of "correct" samples currently detected, this will be lowered to account for false values.

Noise should not be a major problem, the transmitters are quite close to each other. The most important aspect is the syncronization of the transmitter ad receiver.
I'll have another look at the code and then come back too you.

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've changed the shift operation, what data type should I use instead of int for the "sum" variable? char is 8 bits long, can I use this in the same way as an int

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Ohm,

1)
The synkroniser() function without any time stamp should not work, since than the next scan only determined by its execution time, which was unknown and not constant.
So e.g. the timer overflow should be used to get defined and equal scan intervals.

3)
Only if you use the same crystal for receiver and transmitter you get always 4 samples per bit.
Otherwiese its some times possible to get 3 or 5 samples instead of 4.

Yes, on an 8-bit CPU prefer char, whenever it was possible.

Also to get more speed, try to avoid long.
E.g. divide your task in smaller (also faster) steps:
- sample 4 times
- detect a bit
- collect 8 bits to a byte
- compare the byte

See the attachment. I have no AVR-C, so its written for the 8051.
But changing to AVR must be easy.

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

if you really use a radio link it is recommended that the number of zero-bits is approximately equal to the number of one-bits. if it is possible that the relation of 1 to 0 is unbalanced you have to accept degraded quality.

there are some ways to guarantee an approximately balanced datastream. the most important ones are the following:

- send after each byte the same byte but inverted
advantage: the 0 to 1 ratio is exactly 1
it is very easy to implement
disadvantage: you can use only half of the bandwidth

- use all 256 combinations of an 8-bit value and eliminate those where the number of 0 (or 1) is unequal to 3,4 or 5. there should be 172 combinations left. eliminate 44 combinations you don't like (too much 0 or 1 in a row). you can map a 7-bit value to one of these 128 8-bit values and transmit them.
advantage: the 0 to 1 ratio is in worst case 3:5 (usually it is much better)
it needs only medium skill to implement it
disadvantage: you will need 2 tables with a size of 256 entries in rom (256 words of flash in total) for encoding and decoding in addition to your program-code.

- use modified frequency modulation (mfm) - encoding
advantage: the 0 to 1 ratio is in worst case 1:2 (usually it is much better)
you can use the full bandwidth for your transmission
disadvantage: it is not so easy to implement as the first proposal

if you are not satisfied with the quality of your radio-link you can improve the sender. if you have a cheap sender with an analog input it is better to use an analog output at the controller (take e.g. 4 pins of the port and some resistors and build your own d/a-converter). if you do so don't switch from 0 to 1 but use some immediate steps. using the waveform of the squared cosine is a good choice (a small table with some precalculated values) because it produces less harmonic frequencies.

the last part you can improve is to use soft-decoding at the receivers side. this means that you don't use a threshold to decide between 0 and 1 with a comparator instantly. instead you sample analog values (your d/a-converter from the sender in conjunction with the analog comparator will do a great job) and additionally to the possibility of deciding between 0 and 1 you know something about the quality of the transmitted bit. send your data in blocks of 8 bit plus an extra parity bit. if you detect an error (only single bit errors can be detected with this strategy) on the receiver side you correct (=invert) the bit with least quality thus improves the quality of your communication line further.

if you need more information about this stuff feel free to send me a mail. :)

greetings
tom

admin's test signature