Re: [bluetooth] question...

["niko vloeberghs" <niko_icu@hotmail.com>]

Hi Alban,

Thank you so much for your swift response !
The problem I saw with the FEC 2/3 decoding is that the FEC 2/3 can not 
detect all errors, so what if the paylenght indicator field has errors ?  
This error would then only be detected at the CRC ?

Or doesn't it matter ?  If the lenght field is wrong, and we decode a wrong 
number of bits, then this will be flagged almost for sure by the CRC, and 
we'll have to retransmit the packet anyway ?

Thanks for your help !

Niko






>From: Alban Villain <Alban.Villain@inventel.fr>
>Reply-To: bluetooth@opencores.org
>To: bluetooth@opencores.org
>Subject: Re: [bluetooth] question...
>Date: Thu, 16 Jan 2003 09:56:59 +0100
>
>Hi Niko,
>
>I cannot see where there is a problem....
>The payload that are FEC2/3 encoded all have a CRC and are at least 3 byte 
>long prior to FEC 2/3 encoding (1 byte for payload header and 2 bytes for 
>CRC).
>That is, you have enough bit to decode the payload length before the end of 
>the packet.
>This was for 1 slot packet, the same applies for 3 and 5-slots packets.
>
>Hope it helps,
>
>Regards,
>
>Alban
>
>At 16:20 15/01/2003 +0100, niko vloeberghs wrote:
>>Hi All,
>>
>>My name is Niko, I am an engineering student currently working on a 
>>Bluetooth project, namely the implementation of the BT baseband layer 
>>using an FPGA board.
>>While trying to write the VHDL for the receiver part, the FEC 3/2 decoder 
>>more in particular, I realised that I couldn't use the payload length 
>>indicator for generating my output valid signal, as it is itself FEC 
>>encoded.  Concerning this, and also in a more general scope I wondered how 
>>in the receiving process, the end of the packet is determined, and at 
>>which stage in the process the payload length is known for sure (I think 
>>it must be after the CRC check).
>>
>>If anyone could give me more insight in this, it would be great !
>>Thanks for reading this mail and hope to read from you.
>>
>>Cheers,
>>
>>Niko
>
>
>Alban Villain
>
>Inventel - http://www.inventel.com
>Paris
>
>**********************************************************************
>This e-mail and its attachments are confidential and intended solely for 
>the
>addressees. If you are not the intended recipient of this message, then
>please delete it and notify the sender. Since the integrity of this message
>cannot be guaranteed on the Internet, Inventel cannot therefore be
>considered responsible for its content.
>**********************************************************************


_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE* 
http://join.msn.com/?page=features/virus

--
To unsubscribe from bluetooth mailing list please visit http://www.opencores.org/mailinglists.shtml