Si470x sporadically fails to initialize correctly

[mvglasow]

When I start RDS Surveyor with a Si470x source, occasionally I notice that the frequency is reported as 189.8 and the device doesn’t seem to respond to any commands.

Since an Android-based pure Java implementation of the Si470x driver stack that I wrote has the same problem, I started digging a bit deeper:

With a 100 kHz channel raster and 87.5 MHz being the lower boundary of the frequency band, 189.8 MHz corresponds to 0x3FF, which is the channel mask for the READCHAN register and an illegal channel value in any band/channel raster configuration. Looking a bit deeper, I see that all registers (DEVICEID, CHIPID and SYSCONFIG2 at a minimum) seem to report 0xFFFF. No idea why this happens, though, and what triggers it.

[mvglasow]

I suspected the startup sequence which is initially sent to the dongle. I fiddled around with that on my end, making sure it sticks minutiously to the AN230 tech note (set POWERCFG to 0x4001, wait for at least 110 ms (I doubled that time, just to be sure), then do the rest of the initialization)—to no avail.

One thing that I thought of but didn’t try yet—detect when the device reports back a bogus frequency, disable it via the POWERCFG register, then wait a bit (some 500 ms), then go through the init stuff again. If I find out more, I’ll post it here.

[mvglasow]

Today as I was seeking through stations (with my Android port), I noticed that occasionally the tuner would report 189.8, immediately followed by another report with a good frequency (in the range of what I expected, given the previous frequency and the available stations in my area). Seems the Si470x reports all bits high on READCHAN when a seek (or tune?) operation is still in progress.

[mvglasow]

The last comment I made could have been an artifact of a different bug. I have implemented the reset&retry strategy (with the Android driver), just waiting for another occurrence of the all-high bug (Murphy’s law: waiting for a sporadic bug to recur makes it go away for good :-).

[mvglasow]

198.8 has struck again, and my logs tell me that reset&retry was attempted, albeit to no avail. Unplugging and plugging back in fixed it both times, though.

[mvglasow]

To sum it up, I have encountered the issue on both Linux (Ubuntu) and Android, with an ADS Instant FM RDX-155-EF (USB ID 06e1:a155). Christophe tells me he has experienced the same on MacOS (don’t know what model of dongle, though).

Would be interesting to know if this affects Windows as well—in that case the OS is unlikely to be the culprit (unless there is some reference implementation for the USB stack which all major OSes have copied—but that would likely manifest with many different devices and would have been weeded out before).

Also it would be interesting which dongle models are affected—all or only certain types. If only some dongle models are affected but not others, that would indicate a hardware/firmware bug.

Of course, it could also be a bug in RDS Surveyor—though I have no idea where to look.

[ChristopheJacquet]

I can reproduce the same problem on Mac with the same device, 06e1:a155. However after a few attempts I could not reproduce it with SiLab's original USBFMRADIO reference design (10c4:818a).

The symptoms:

• Computer/dongle communication works fine, including USB enumeration with the correct strings, answering the various USB reports with answers of the correct size.
• The scratch report (id 20) returns the correct data. That's data from the μC's flash memory.
• All reports returning Si470x registers return the correct number of bytes, but all bytes have value 0xFF.
• I don't have indication of whether writing Si470x registers works.

So I believe it's a hardware or firmware problem with the affected dongles. Maybe the μC fails to initialize the Si470x, or the communication between the μC and the Si470x is messed up.

We could easily detect this condition (DEVICEID is 0xFFFF) and display an error message instead of pretending it works.