FPGA Central

I’m working on an FPGA implementation of an ITU J.83 Annex A
modulator; I know this is kind of re-inventing the wheel . . . but I
wanted to see if I could do it. Well I’ve finished the modulator and
it’s working great with our demodulator for 16QAM, 32QAM, and 128QAM.
What I can’t figure out is that for 64QAM and 256QAM I can’t get our
demodulator (based on Broadcom’s BCM3510 chip) to achieve FEC lock. I
can get QAM lock and an MER above 40dB, but that’s it.

So finally to my question . . . I’m wondering if any of you remember
any special cases surrounding 64QAM or 256QAM in the modulation
process. The ITU J.83 and the DVB-C spec don’t seem to mention any,
but maybe I missed something? I’m feeding the modulator with MPEG
null packets, so one thing I’m suspecting is that the BCM3510
demodulator won’t work on 64QAM and 256QAM with MPEG null packets, but
I’m having a hard time believing it since it’s happy with them for 16,
32, and 128QAM. I’ve also double checked my constellation mapping
with the specs and they match what the spec says, I’m hoping the specs
don’t have a typo :-).

Any help or guidance you can give me would be greatly appreciated.

Thanks
Brett

Well I figured it out. Apparently the BCM3510 won't lock onto an
Annex A 64QAM or 256QAM if it is stuffed with MPEG null packets. I
modified my mpeg block to send a 0x47 sync byte, followed by 187 bytes
of PRBS15 sequence and now the BCM3510 demodulator is locked and
happy.

To me this seems like a bug in the demodulator, why should it care
what is inside the mpeg packets? The next step in the modulator is a
randomizer, so there was already plenty of randomization in the bit
stream being fed into the interleaver - byte to symbol mapper -
etc. . . Plus the BCM3510 was happy locking onto Annex A 16QAM,
32QAM, and 128QAM with MPEG null packets.

Anybody ever hear of anything like this?

Thanks
Brett

BrettE wrote:
> Well I figured it out. Apparently the BCM3510 won't lock onto an
> Annex A 64QAM or 256QAM if it is stuffed with MPEG null packets. I
> modified my mpeg block to send a 0x47 sync byte, followed by 187 bytes
> of PRBS15 sequence and now the BCM3510 demodulator is locked and
> happy.
>
> To me this seems like a bug in the demodulator, why should it care
> what is inside the mpeg packets? The next step in the modulator is a
> randomizer, so there was already plenty of randomization in the bit
> stream being fed into the interleaver - byte to symbol mapper -
> etc. . . Plus the BCM3510 was happy locking onto Annex A 16QAM,
> 32QAM, and 128QAM with MPEG null packets.
>
> Anybody ever hear of anything like this?

Before it finds the beginning of the packet, it doesn't know what's
inside and what's start/end overhead. If it could know to ignore the
packet's payload, it would have already synced.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

On 11/25/2009 2:52 PM, Jerry Avins wrote:
> BrettE wrote:
>> Well I figured it out. Apparently the BCM3510 won't lock onto an
>> Annex A 64QAM or 256QAM if it is stuffed with MPEG null packets. I
>> modified my mpeg block to send a 0x47 sync byte, followed by 187 bytes
>> of PRBS15 sequence and now the BCM3510 demodulator is locked and
>> happy.
>>
>> To me this seems like a bug in the demodulator, why should it care
>> what is inside the mpeg packets? The next step in the modulator is a
>> randomizer, so there was already plenty of randomization in the bit
>> stream being fed into the interleaver - byte to symbol mapper -
>> etc. . . Plus the BCM3510 was happy locking onto Annex A 16QAM,
>> 32QAM, and 128QAM with MPEG null packets.
>>
>> Anybody ever hear of anything like this?
>
> Before it finds the beginning of the packet, it doesn't know what's
> inside and what's start/end overhead. If it could know to ignore the
> packet's payload, it would have already synced.
>
> Jerry

Null packets are a valid payload, so it does seem to me that it's a
problem if the demod can't transport them. Are you sure that the
scrambler (randomizer) is turned on? I could see the system losing
synch on null packets if the scrambler weren't enabled, and it'd
certainly synch on a PRBS sequence under the same condition.

--
Eric Jacobsen
Minister of Algorithms
Abineau Communications
http://www.abineau.com