Sansa 250c EQ Ignored for Radio (200 Series)

[sqgl]

Whether I use Rockbox or the Original Sansa OS
EQ does not work for the radio.
It only works for MP3's.
Strange that this is not mentioned anywhere.
 
I tried on three units:
A 250c v1 with both Sansa OS and Rockbox 3.6 and
two 250c v2 units with Sansa OS.

Particularly annoying is the fact that the default EQ distorts my bass
when listening to radio on the v1.
It sounds OK on the v2.
I tested it with exactly the same 4 bar audio loop because
I have an FM radio transmitter.

[saratoga]

Radio is analog, so it doesn't pass through the DSP pipeline.  Instead you just get whatever is broadcast, more or less directly. 

[sqgl]

Wow, thanks for the quick reply and simple answer saratoga.

Do you have any thoughts on why the v1 receives the signal differently from the v2? If I compress the bass heavily before transmitting to my v1 Sansa it gets rid of most of the distortion/clipping.

Another way to get rid of it is to tune in with the mono option. Why does this work? Does this suggest that the problem is something other than too much bass? Perhaps the v1 receiver is faulty?

[keyb_gr]

I dug through the wiki, and my suspicion was confirmed: They use rather different radio chips. The c200 v1 employs a Sanyo LV24020LP, while for the v2 it's a SiLabs Si4702.

Looking at the datasheet for the LV24020LP, I see two possible reasons for the distortion:
1. IF bandwidth set too low, or tuning off-center.
2. AFC mistakenly is in fast mode.

Can you reproduce the issue in OF? If not, this would very much smell like a bug.

EDIT:
Now look at that, there are a few bugs reported concerning radio on the e200 (v1 I assume, with the same chip). That would be FS#9420 and FS#10405. The first may be hinting at AFC not being active at all, but not sure whether that's still current. (EDIT^2: Apparently not, tuning was improved afterwards.)

It seems like these ICs use a somewhat convoluted way of setting frequency, since they don't have a frequency synthesizer but only an LC oscillator with a varicap diode tuned by DAC output voltage. (Presumably the whole affair runs at a multiple of LO frequency so that the inductor can be integrated on-chip, with a following frequency divider and filter.) When changing frequency, the change in tuning voltage has to be estimated, the resulting frequency measured, and then the whole procedure may have to be repeated one or more times until the required frequency is established and AFC can be turned on to take care of further drift.

[sqgl]

Great detective work keyb_gr. Must happen to all v1's then. Bummer. v2 has only an unstable rockbox available and v1 has dodgy fm receiver.

1. IF bandwidth set too low, or tuning off-center.
2. AFC mistakenly is in fast mode.
Can you reproduce the issue in OF? If not, this would very much smell like a bug.

1. Bandwidth of the signal? I'm transmiting and have set the signal optimally. Compressing gets rid of much of it. Harder compression (ie all peaks at same maximum level) would probably get rid of all of it but then the music would be almost unrecognisable.

2. I don't understand what "fast mode" means

The issue is reproduced in Original Firmware.

[keyb_gr]

The issue is reproduced in Original Firmware.

Slim chance of Rockbox being able to do better then, I'm afraid.

(Is Rockbox really that "unstable" on the c200 v2 though?)

AFAICS, with standard manufacturer-suggested settings we have about 70 kHz of IF bandwidth in this low-IF design (there is a register to set this), and I've found no hints of any deviation compression (à la TDA7000 family) being applied in this chip.
70 kHz is not a lot. It would actually work reasonably well here in Germany where standard deviation is 40 kHz, but not too well with any large deviations.

The only workaround I can offer is turning down the volume at or before the FM transmitter so that deviation decreases.

Looking at other chips, especially Philips/NXP TEA57xx, it seems the LV24xxx employs an unusually low IF of 110 kHz typical. The TEA5767 is a 225 kHz design with a typical 94 kHz bandwidth, and a TEA5777 gets 110 kHz of bandwidth out of 150 or 133.333 kHz.

Even if we go up to 0.8 for BW/IF here (manufacturer recommended value is .65 for the LV2400x), that would still get us about 90 kHz only, with uncertain consequences in term of selectivity and image rejection.

If you have a reasonably well-populated local FM band and feel up to the task of setting up a build environment for Rockbox (took me about a weekend with some general Linux / *IX knowledge), you could play with the standard value of the IF_BW register in lv24020lp.c and see/hear what happens. One really needs to have a device on hand to test this.