[Dextrose] Modifying 353 (xo-1) to apply the dev.laptop.org/ticket/10195 fix {XO Wifi Issues}

[James Cameron]

On Wed, Dec 01, 2010 at 11:00:36PM -0500, Samuel Greenfeld wrote:
> Pardon me if I missed the clarification, but if one XO unit is
> consistently bad while another physical XO unit always works
> regardless of their locations, this would suggest a hardware issue.

Given no firmware or software differences, yes.

(One such hardware issue is low sensitivity of the receiver; if it
cannot hear distant access points then it is more likely to receive a
nearby access point that would otherwise have had its transmission
trodden on.  This would appear to be beneficial, and would make a
damaged unit always work when a normal unit would be consistently bad.)

> Your truncated "scan-wifi" output suggests that the bad XOs only were 
> working on Channel 1.

A scan is time limited.  The response buffer is length limited.
OpenFirmware only issues one scan request and prints one response
buffer.  Linux may do something entirely different.

Also possible is that there were sufficient beacons heard on channel 1
to fill the response buffer, long before any larger channel number was
attempted by the wireless firmware.

Mikus wrote:
> Note that both the "bad" XO1-s and the "good" XO-1s __will__ connect
> via the (non-adhoc) mesh interface -- to me that says the silicon is
> working -- though I do not know if the AP radio signal in the "bad"
> XO-1s is too attenuated (bad antenna connection?) to be detected.

There are other reasons than attenuation for a report of zero RSSI, or
an access point not being listed.  You need to average out the results,
and only deal with access points that have a non-zero RSSI listed.

-- 
James Cameron
http://quozl.linux.org.au/