Logged in as Guest Sun, Oct. 21st, 7:43 AM.
|
|
|
|
|
The NetServices library is used on both the Tungsten C and the WiFi SD card from palmOne to control the 802.11 radio. The new Lifedrive from palmOne also sports an 802.11 radio and when I finally got my hands on one the other day, I was pleased to see that it also supports the NetServices API. However, as I played with it, I discovered a few differences that I will share here.
The first difference is that the NetServicesProfile structure (used to retrieve and store specific settings related to establishing a connection) is now larger than the one that is currently documented. The structure is documented/defined in PalmNetServices.h, however, the size of the structure that is written to by the NetServicesProfileRead function is larger. To illustrate this, the following code doesn't work on the Lifedrive because it corrupts the stack: Example 1:
NetServicesProfile profile;
NetServicesProfileRead(netServicesLib, 0, &profile);
The proper way to use the NetServicesProfile structure is to query its size using NetServicesProfileGetInfo() which will fill a NetServicesProfileInfo structure with general information about profiles on a device. The NetServicesProfileInfo structure then contains the size of the NetServicesProfile structure in the profileEntrySize member. As I write that, I realize it probably is a little unclear, so here is a little sample code to illustrate the proper way to do this:
Example 2:
NetServicesProfile* profile;
NetServicesProfileInfo profileInfo;
NetServicesProfileGetInfo(netServicesLib, &profileInfo);
profile=(NetServicesProfile*)MemPtrNew(profileInfo.profileEntrySize);
NetServicesProfileRead(netServicesLib, 0, profile);
//Use profile here...
MemPtrFree(profile);
In retrospect, this is the way that I should have been using NetServicesProfileRead all along, however, I must say that the very sparse documentation on the NetServices API didn't help my cause. If you know what the new definition of the NetServicesProfile structure is, I'd love to know!
The second major difference that I found relates to the RSSI (receiver signal strength indicator) values that are returned from a WiFi scan. Previously, the RSSI values ranged from 0 to -100 where 0 is the theoretically best RSSI value. On the Lifedrive, however, the returned values ranged from between 250 and 350. Now, these values aren't documented anywhere that I could find and are values that I discovered only through experimentation so your results may vary. Because of these differences, I had to change my WiFi-Where code to normalize the returned RSSI values. For reference, here's my implementation: Example 3:
Int32 NormalizeRSSI(NetBssInfoType* info)
{
Int32 rssi;
BssInfoRssi(info, &rssi);
UInt32 deviceID = 0xFFFFFFFF;
if (errNone != FtrGet(sysFtrCreator,
sysFtrNumOEMDeviceID,
&deviceID))
{
deviceID = 0xFFFFFFFF;
}
if (deviceID == 'TunX')
{
//LifeDrive = 250-350 normalized to 10% - 70%
rssi -= 150;
rssi *= 70;
rssi /= 100;
}
else
{
//Put value into the positive range...
rssi += 100;
}
return rssi;
}
So far, these are the only major differences that I could find. I'm sure that there are others that I simply haven't stumbled upon yet. I will update as I discover more. If you have found other differences in the NetServices implementation, or can fill in the backstory behind these differences, I'd love to hear about it!
-Jon |
|
| Submitted by bosshogg on Wednesday the 31st 1970f December 1969, at 04:00 | |
