Page 2 of 2 FirstFirst 12
Results 21 to 29 of 29
  1.    #21  
    Quote Originally Posted by gazment View Post
    well aside from getting a little dizzy my phone did burn up an extra 5% of battery in that 1.5 hours I had it set to turbo, with nothing else running aside from a couple text messages
    Typically once a LED controller has been programmed, it does not take any software cycles to manage it, and the current draw on a single LED is usually very minimal. We did some informal testing on the 700wx and determined that the impact was negligible, but I haven't done any testing on the 800w.

    You said extra 5%, does that mean you tested with it and without?
  2. #22  
    More of an informal test I did using my best judgement. I knew LED's use up a very tiny bit of power but I didn't think it was so low that it wouldn't be noticable.
  3.    #23  
    Quote Originally Posted by hannip View Post
    zbop, I think there might be an issue. It hung once when turning off a orange-fast blink. Actually it didn't hang the phone, but it didn't seem to exit after it turned off the blink. I'll let you know if it happens again.
    I ran a few different tests overnight and couldn't reproduce it. If I run multiple instances concurrently, sometimes one of them will hang temporarily until the other is finished, but it is only for a second. By any chance were you rapidly trying different combos when this happened?

    In the case of the 800w, my code is really simple and don't think the bug is there, but it's possible that the driver has a problem with threading/serialization. Currently I allow more than one instance of TreoLED to run at the same time which might be causing the driver grief. If we see this again, I'll change that and see if it makes a difference.
  4.    #24  
    Quote Originally Posted by gazment View Post
    More of an informal test I did using my best judgement. I knew LED's use up a very tiny bit of power but I didn't think it was so low that it wouldn't be noticable.
    With the 800w battery, I can see how you'd be concerned, but it really should be minimal. If in doubt, use the standard blink rates and stay away from the turbo modes.
  5. #25  
    LED's use such a tiny amount of power it's not even really worth being concerned about.

    Much brighter LED's than that can run hundreds of hours off a much smaller (watch sized) battery.
  6. #26  
    zbop or anyone,
    I've been trying to write some code to get LEDs working on the Treo Pro. As you may know, the WM NLed API only works for the vibration and I can't perfectly manage the LEDs. I wrote the portion of code below that makes the red and green LEDs blink but as soon as I call these functions, the normal LED behavior is lost (e.g. the red light no longer turns on while i'm charging and I have to soft-reset the Treo Pro).
    You probably faced this same issue with TreoLED and I'm wondering if you could help me figure it out.

    Code:
    typedef enum tLEDS{LED_RED, LED_GREEN, LED_BLUE, LED_L_GREEN, LED_AMBER}eLED;
    
    unsigned long out[32] = {0};
    unsigned long read = 0;
    unsigned long inBuffer[5] = {0, 0, LED_RED, 1, 0};
    
    HANDLE hLED = CreateFile(L"LED1:", GENERIC_WRITE | GENERIC_READ, 0, NULL, OPEN_EXISTING, 0, NULL);
    DeviceIoControl(hLED, 0x80020008, inBuffer, 0x14, out, sizeof(out), &read, NULL);
    CloseHandle(hLED);
    Thanks !
  7.    #27  
    Quote Originally Posted by Skaber View Post
    zbop or anyone,
    I've been trying to write some code to get LEDs working on the Treo Pro. As you may know, the WM NLed API only works for the vibration and I can't perfectly manage the LEDs. I wrote the portion of code below that makes the red and green LEDs blink but as soon as I call these functions, the normal LED behavior is lost (e.g. the red light no longer turns on while i'm charging and I have to soft-reset the Treo Pro).
    You probably faced this same issue with TreoLED and I'm wondering if you could help me figure it out.

    Code:
    typedef enum tLEDS{LED_RED, LED_GREEN, LED_BLUE, LED_L_GREEN, LED_AMBER}eLED;
     
    unsigned long out[32] = {0};
    unsigned long read = 0;
    unsigned long inBuffer[5] = {0, 0, LED_RED, 1, 0};
     
    HANDLE hLED = CreateFile(L"LED1:", GENERIC_WRITE | GENERIC_READ, 0, NULL, OPEN_EXISTING, 0, NULL);
    DeviceIoControl(hLED, 0x80020008, inBuffer, 0x14, out, sizeof(out), &read, NULL);
    CloseHandle(hLED);
    Thanks !
    Skaber, you'll need to intercept power state changes to handle this.

    I didn't include this in TreoLED (it simply sets the state) but Hannip implemented it in TreoAlert.

    You'll need to do one of the following:
    A) Register for a notification on power state change (search for PBT_POWERSTATUSCHANGE)
    B) Request notification on registry change, i.e. on the 800w it is HKEY_LOCAL_MACHINE\System\State\Battery\ACConnected, and use RegistryNotifyCallback() or RegistryNotifyWindow()

    Avoid the use of NOTIFICATION_EVENT_ON_AC_POWER, it is notoriously unreliable.

    BTW, if you have LED control on the Treo Pro and you've implemented command line parameters, please contact Hannip so that he can incorporate this into TreoAlert (assuming you don't mind giving him the code or binary).
  8. #28  
    Is TreoAlert/TreoLED source code public ? If so, where can I find it ? I could have a look and make proper changes to support the Treo Pro.

    Registering on events and managing the LEDs won't fix my issue. As soon as I will leave my application, the LEDs won't work anymore.

    How do you light up a LED right now ? Are you using the nled api ? My code can only make the leds blink, I can't get a LED permanently on.

    Thanks
  9.    #29  
    Quote Originally Posted by Skaber View Post
    Is TreoAlert/TreoLED source code public ? If so, where can I find it ? I could have a look and make proper changes to support the Treo Pro.
    The source is not public for either, and unfortunately it wouldn't help you. The method and parameters used are very device-specific. For example, I've added support for 3 different Treo models and in each case I had to start from scratch, the previous code did not help. Palm maintains no consistency in their LED implementation, HTC is better in this regard; the code you posted is consistent with other HTC models.

    Registering on events and managing the LEDs won't fix my issue. As soon as I will leave my application, the LEDs won't work anymore.
    Your first post implied that you could make the LEDs blink, but when you plug in a charging cable it did not light up. I responded with a suggestion to deal with that...

    I'm having trouble parsing what you wrote; Are you saying that you have to toggle the LEDs on/off to make it blink and when your app quits, it stops? Or are you saying that once your code runs, something is hosed and the LEDs will never light up again (even if you rerun your code)? Or something completely different?

    How do you light up a LED right now ? Are you using the nled api ?
    As I mentioned, device-specific:
    Treo 750 - driver ioctls
    Treo 800w - NLED API
    Treo 700wx method 1 - System calls
    Treo 700wx method 2 - Poking I/O mapped control registers
Page 2 of 2 FirstFirst 12

Posting Permissions