Talk:Hauppauge WinTV-Aero-m

When this device worked ...
it worked great ... though that comment comes with a few caveats:

The bulk of my Linux user experience with the device was done while under a kernel 3.4 (will expand upon the possible importance of this point in the section below these bullet pts)

Under Linux - I tried with the built-in antenna for OTA ATSC reception, but did so only under poor testing circumstances, and never was able to detect any ATSC channels ... never got around to testing under good circumstances, nor did I ever get around to attempting such under Windows

Under Linux, using an external antenna for OTA ATSC reception, its tuning sensitivity was great in this regard. Never got around to testing this under Windows (have no reason to believe it would have been any different then the excellent results obtained with the device while running under Linux)

I don't have cable TV any more, so did not get around to testing this feature (under either Linux or Windows)... in any regard, the provider in my area encrypts all but a barker channel or two, and maybe a few radio stations, so it is not really worth my time to bother checking except for being academic about it

Nearest DVB-T source is likely 5,000km away ... would have had to go {insert stereotypical broken english accent here}"back to old country"{/end sterotype} to test this feature

Under Linux, even if you switch to a v3.5 or better kernel, currently there are no userspace tools/apps that would allow for testing ATSC-M/H reception. I never got around to testing this under Windows. In any regard, there are only one or two M/H signals currently being tested with by broadcasters in my region, so it wasn't a pressing matter

Then it all went south
Astute readers will naturally have picked up on the "when this device worked" qualifier of that last section. You can also find similar alarming statements made by others on, amongst other websites, Amazon and Newegg. You see, my device, running under kernel 3.4, was working wonderfully for OTA ATSC (for the less then 2 months that I had had it for) until that stopped working (NOT cool).

Here is my current thought: either it coincidently borked itself just a day after I updated to kernel v3.5, or there is something (programmatically) wrong with the drivers. I will assume that the users on AMZN and the egg (whom also reported that the ATSC section of the device suddenly stopped working) are Windows users and that the problem afflicting me (running under Linux) also exits there too.

Here is what dmesg gives you when its not detecting the LG DT3305 (along with my annotations):

the problem was first encountered, the day after updating to kernel v3.5, after a failed attempt to awaken the system from sleep (S3)

I have seen reports of problems with S3 on kernel v3.5

the first time this happened, I was able to revive the device by doing a fresh installation of it, and the corresponding WinTV software, under Windows, ... not actually sure what step reinitialized the device, as I was actually unable to detect any channels with it under Windows while doing this, but plugging it back into the Linux system revealed a correct working state for the device again

one day later, the device had gone south under Linux again (discovered after a cold boot)

this second time, I was able to revive the device by doing the Windows trick again ... only it required multiple installation/deinstallation/scanning under Windows (and, again, without being able to detect channels while operating under Windows) before plugging it back into Linux revealed a working device

a day or two later, after the second resuscitation, the device suffered a third cardiac arrest under Linux ... multiple attempts with the Windows defibrillator have failed to bring it back

Early Diagnosis
Has my device taken those final few steps towards the shadowy figures in the light? Has its electrons truly passed on through to the other side, and will never return to spark life back upon my screens in this mortal coil?

While it looks grim at the moment, I actually think that there might be hope. Offhand, I'm thinking that problems with the ACPI event (sleep S3) have exposed a fundamental flaw in the programming of registers in the MxL111SF (both under Windows and Linux). Its either coincidental, or noteworthy that the 3.5 kernel added support for the M/H LG2161 demod. Investigation into how this touched upon the MxL111SF is in order, as well as to how its inclusion impacts the LGDT3305 demod, and how a S3 event might have played a part. In a sense, the MxL111SF is the gatekeeper to these two demods. And it is a MxL111SF register gate that I believe is being stuck, and, consequently, making it appear that the device is borked. The real question is who is going to give her the shot? (warning: link not suitable for work or most family situations)

Quick Follow Up
Interesting -- just looking through the old log files. I think my analysis above is on track. Seeing stuff like:

Media_build (now 8 days old) doesn't help at all, as it results in a bunch of symbol related errors. (I don't think they are anything remotely related to the problem, but rather, are related to changes that Antti/Crope has been making to dvb_usb). For posterity sake, they are as follows:

Update 2
Okay, in response to comments I left on the linuxtv IRC channel, Antti/Crope noted that his GSoC project changes only apply to "dvb_usb_v2", and not to the old/original "dvb_usb" (which is what is producing the errors; as seen above) and that they are likely the result of the recent file and directory structure re-organization within the media build. Ahh, good old fashioned re-orgs -- when does one not ever cause a problem? Anyway, one should expect that that will get sorted out soon enough.

On the good news front, Crope mentioned that he too has an Aero-m and that he has it coded up for dvb_usb_v2 (I look forward to testing that when I get a chance). Crope also remarked that he too has seen some of the errors I've mentioned above, though, as I wasn't actually conversing with him at the time, I'm not sure if he meant the problems I noted with the current state of affairs within the media_build repo, or specifically to the Aero-m related errors I've highlighted.

So, getting back on focus -- the Aero-m. I'm pretty confident that the device is not dead but that I just need to reinitialize some of the MaxLinear chip's registers. Hopefully debricking it at this point does not require the use of JTAG (I'm assuming the SoC has a JTAG interface). If that is the case, I simply don't have the time to do that, or experience to do that (or time to learn how to do that) so it will head back on the next train to Long Island so that a HCW engineering monkey may have such pleasure.

In the bigger picture, if my assumption is correct (drivers, both Windows and Linux, are not programming the MxL111SF correctly), everyone of these devices currently is ticking away to brick itself upon encountering certain conditions.