Here is a list of potential UW2453 code problems I pointed out to
ZyDAS/Atheros in private mails. No response yet (after 2 months).
Firstly, as someone without a huge amount of knowledge about RF stuff,
I'd be interested to know why this RF has 12 different per-channel
configuration tables. Do the other RF's automatically tweak themselves
to lock on the correct value, or is this one just more advanced in that
it can resolve onto 'finer signals'?
1. For calibration, these values are written:
HW_Set_IF_Synthesizer(pObj, 0x307602); //5d01
The first 2 lines are clearly tuning the synthesizer to channel 1. I
haven't investigated the next line. The final line is setting the VCO
I tried to match lines 1, 2 and 4 to a specific entry in the
UW2453RF_dongle table. I didn't find any match. The value 0x346063 is
only used for channels 3 and 4 in table 6.
I realise that this may be intentional or a non-issue, as I don't really
have a full understanding of this calibration process. However, I
thought it was worth pointing out.
3. All of the VCO config (register 3) writes set the upper 4 bits (bits
[0:3] in the specs) to 0x4. However, the specs state that bits [0:4] are
Maybe the specs I have are out of date, again just something I thought I
would point out.
4. I noticed that the final write to register 0 in
HW_Set_UW2453_RF_Chips() when we are initializing (as opposed to
changing channels) sets it into CAL_FIL mode. The specs say that after
coming out of CAL_FIL mode, the device goes into SLEEP mode. This makes
sense, by description it sounds like it is the lowest power mode, and
after all we don't know that the user actually wants to use the radio
any time soon.
However, when turning the radio off, HW_RadioOnOff() puts the device
into IDLE mode, which still has some radio circuits powered up.
Shouldn't this be putting it into SLEEP?
5. Actually, in number 4 I assumed that your driver would be turning the
radio ON during "ifconfig wlan0 up" and OFF during "ifconfig wlan0
down". However, with some printk debugging I discovered that the radio
is NOT turned off when the interface is brought down. Is this
intentional or a bug? zd1211rw definitely does execute the radio off
code when the interface is brought down by the user.
6. Final comment: we've seen the UW2453 RF present in both ZD1211 and
ZD1211B devices. This is interesting to me, because so far we haven't
seen the same RF appearing in both chipsets unless the driver-level RF
programming is substantially different.
I just noticed another strange thing in your UW2453 code. It seems so
clear that perhaps it was intentional, but it seems really strange at
the same time. Perhaps you could clarify?
You have this big table of configurations, UW2453RF_dongle.
During RF initialization, you go over these configurations one-by-one
until you get a PLL lock. At this point, you record the index of the
*NEXT* configuration table (value i+1) into UW2453RFTableIndex, and
Later on when you come to use UW2453RFTableIndex it is used as an array
index in unmodified form. So, if you got a PLL lock after programming
the configuration found in table 3 (UW2453RF_dongle), you later on
use the next table exclusively, in this case table 4
(UW2453RF_dongle), and never use table 3 again.
This appears like it may have been intentional because you never try to
get a PLL lock on table 11, but at the same time it seems really odd.
Any chance I could have a brief explanation here?
Another observation, I seem to be getting many more TX retry failed
interrupts with this RF than my other hardware. Have you made any
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
Zd1211-devs mailing list - http://zd1211.ath.cx/