How to select marker for data transmission?.

[xtcx]

Hi friends!, I'm doing a master project in SDR. I have employed few modulation and demod techniques in FPGA however while transmitting data stream @ 2MHz from Tx to Rx, due to broadcast nature of the Tx unit, the reciever unit fails to sync with the Tx without a proper sync pulse\data. So If I transmit audio from codec in Tx, I'm recieving all MSB-LSB bits in mingled order. I need to use marker to achieve a good starting and locking.
My data stream is @ 2MHz
My modulation is FSK @ 4MHz&6MHz(f1,f2)
Data width is 32 bits.
codec idle time after conv is 48µs(which i use to send my data+marker)
Since the data from codec for L.CH and R.CH are 16+16 bits, at certain case, using a marker of 32-bit width even can't give proper sync because the marker values are mimiced by data bits many times. so sync seems impossible. Is there anyway to define marker in a more efficient way or any special value available for this?..Please help me...Thanks for you time!

 

[FvM]

I don't understand from your post what's your of audio data sample rate respectively how many idle bits you have left for synchronisation. This is essential to decide which synchronisation methods can be used.

However, the problem is common to serial communication. As an efficient sync method, 8B/10B encoding is used e.g. in ethernet or PCI express serial communication, but it is somewhat resource expensive. For a similar problem, I divided a 32 bit packet into 8 bit symbols, sending each with an insert 9th '0' bit. The start symbol (or character) was an unique 9 bit all '1'. There may be more simple techniques thinkable.

Regards,
Frank

 

[xtcx]

Thanks! My audio sample rate is <15KHz only, but my codec has been configured to give 32 bits with 0.5µs time period or at 2MHz bit clock. Two successive frame sync occurs at 8µs interval for ch1(16bits) and another 8µs for ch2(16bits). followed by this I have an idle time of 48µs. So a total time is approx 64µs\15KHz.
Now I gotta use this 48µs time to collect,add header,marker,etc and send it out. I guess you got it this time....I can ofcourse get uniform bits from codec, but since there are some post-processing,this idle time is necessary. ok, You concept of bit insertion seems so interesting and helpful... Thanks a lot. Let me give it a try. Altogethor I got to know about another idea. This is followed in HDLC level encoding. As you know the "bit-stuffing", the starter sync bits are selected as "01111110". Six '1's followed by two 0s at front and back. This value has been chosen since it is a less redundant code after all in data. Now if a data comes in this same pattern, for instance, then all you need to do at the coding level is to add a zero at the 6th position as like this ----> "01111-0-10". Then your data follows.so in receiver unit when it detects a zero after '1' in 5th position, then it simply discards the '0' at 6th bit and retrieves the data. So in this way i guess we can sync our data at 8-bit level without more overhead.if it slips or gains at the receiver unit....Also could you telll me that by implementing a CRC in this model might help for synhronization apart from error detection?....Any suggestion?

 

[FvM]

Hello,

HDLC encoding would be another option. I don't see exactly if has advantages for this application, or how resource usage would be. Regarding CRC, I think it is meaningful with wireless transmission anyway. But it can't be used exactly as unique start mark, with a certain prohability, you get false starts.

Reagrds,
Frank

 

[xtcx]

Yeah! you are correct. I prefer bit-stuffing for now...CRC level critical operations aren't necessary in my 1st prototype model...Thanks