HT12D and HT12E encoder/decoder issues

[JonSea]

I can't really say I understand your logic in displaying battery condition after the device is turned off, but no big deal.

You need to test the battery condition under load...I.e., when you have the LEDs illuminated or when you're running the transmitter. After the load is removed, the battery voltage will rise, leading to erroneous results.

What I would do is set up a flag, a Boolean variable called BatteryDead. Check the state of battery each time through the program loop, just as I did in the code I posted. If the HVLD indicates the battery is low, set BatteryDead to true. Then, at whatever time you want to illuminate the low battery LED, test if BatteryDead is true.

Set BatteryDead to false only when the program initializers (I.e., before the main program loop) so that any low measurement results in a low indication.

 

[MrDEB]

Setup = user puts the device on their helmet then goes riding.
User returns, checks battery condition to see if it needs charging. RED = needs charging, GREEN = good to go.
I want to eliminate, if possible over charging or causing battery memory, especially if using Ni cads. I need 2.4v for the transmitter to work. If I set the HLVD to 3v for RED LED and anything over 3.5v a GREEN LED.
I need to calculate/test how long the transmitter can run before getting down to 3v on the batteries.
So testing the batteries is not needed until the device is removed from helmet.
Hope I got this right. Trying to look at all options and possible user usage. Looking at a way to turn off device but its a delayed power off, long enough to check battery condition. This may be getting to involved but ?
looking at slide switches that are spring loaded. My GPS has similar that's where I got the idea to begin with. If I can't configure then just a push-button that the user uses to check battery condition.

 

[JonSea]

Ok, you know what you want to do....even if it's not going to work. I've outlined something that will work and how to do it. You're on your own from here.

You have so many fragments of marginally thought out ideas that making a whole of them will require nothing short of a miracle. Good luck. Hope you find a new saint to help.

 

[MrDEB]

Why do you say it won't work--just curious
Your outline sounds viable but testing the batteries IN - USE is not what a user is going to want to do.

 

[JonSea]

1. Testing an unloaded battery is garbage. It can be nearly dead and still read an acceptable voltage when unloaded.

2. As far as battery life is concerned, the voltage you want has nothing to do with it. The battery curve shows the necessary cutoff.


Why not test the batteries in-use when it's a meaningful test? It takes few program cycles and consumes at most 45 micro (not milli) amps.

But you've made up your mind on an ill-conceived idea. Don't let me change it. Besides, you've stated on numerous occasions that I don't know what I'm talking about, so I'm done.

 

[be80be]

Hey if help's to prove a point I'll give you the battery I took out of the smoke alarm it shows almost 9 volts till you plug it in then it reads 6 volts LOL

You can't tell how much charge is in on if it's not being used. You have to load it up Mrdeb

 

[MrDEB]

Well technically when it is tested as I described it is under a "load" if you want to consider .34ma a load. The max load is 15ma while transmitting.
Out of curiosity, I measured the current draw of a Direct TV remote while pushing various buttons = 12ma - 15ma max while a WII controller had 48ma while turning on (4leds) but while pushing various buttons, 12 ma. My conclusion, a AA battery will last a long time in my application but plan more testing.
As far as testing under a load, I could, as Jon suggested (a viable idea) just cycle several transmissions(max load) and run the HLVD routine.
Should be no problem with this setup.

 

[JonSea]

Why not test the batteries in-use when it's a meaningful test? It takes few program cycles and consumes at most 45 micro (not milli) amps.

*shrug*

So instead of testing during operation, add extra unnecessary battery drain to test. Good thinking chief.

If I were you, I'd just measure until the voltage reaches zero and then turn on the LED the appropriate amount of time before that happens. To keep the bogon flux high, you should use an LM317 configured as a constant current source to drive the low battery LED, otherwise the temperature coefficient of the series resistor will result in a varying load with temperature. Alternatively, an I2C LED driver chip will simplify the circuit and add fragility to the code. I2C is definitely preferred over SPI in this application.

 

[MrDEB]

Was thinking about this and think I have a plan that will test how long the battery pack will last (provide enough power to transmit) and how many 15ma cycles when it reaches the unable to transmit point.
setup the usart to count how many viable transmissions per minute (set up transmitter to transmit 12 pulses per minute) and note battery voltage at that point (should be 2.4v).
This will give a real time vrs voltage test under ACTUAL load conditions. Just need to get some rechargeable AAA batteries. All I have are 400mah battery packs out of a cordless phone. Would work but not a accurate as using AAA batteries.
Test using actual load conditions then adjust the HLVD to proper voltage.

 

[JonSea]

Another brilliant idea chief. Assuming all AAA batteries follow the same discharge curve (even different lots of the same brand don't) and that testing at some arbitrary number of pulses per minute approximates "real life."

All this to avoid checking the battery voltage during routine operation which has about zero cost in terms of degrading operating time or in complexity. It's absolutely amazing the lengths you will go to to have a Mickey Mouse solution (no offense Mr. Disney).

 

[JonSea]

Just to reiterate, the HLVD circuit draws a maximum of 45 micro-amps when it's turned one. For the math challenged, that's 0.045 mA, and it can be turned off between measurements.

 

[be80be]

Here a event driven sample it turns a red led on telling you the battery is low.

Device = 18f2520 
Clock = 8 
Config osc = INTIO67 
Include "utils.bas" 
Include "HiLowVolts" 
Event OnVoltChange() 
    If PIR2.bits(2) = 1 Then                          
            PORTC.7 = 1 
            PIR2.bits(2) = 0          
        Else 
            PORTC.7 = 0 
    End If 
End Event 
Dim LedRed As PORTC.7 
Dim LedGreen As PORTC.6 
OSCCON=$72 
SetAllDigital 
  
Output(LedGreen) 
Output(LedRed) 
  
LedRed = 0 
LedGreen = 0 

HLVDCON =%00011011      
While true 
    HiLowVolts.Initialize (OnVoltChange) 
    Toggle (LedGreen) 
    DelayMS(1000) 
Wend

And the module

Module HiLowVolts 

// event handler type... 
Type TEvent = Event() 

// local and public variables... 
Dim LowVolts As TEvent 

// ISR routine... 
Interrupt OnVoltChange() 
    LowVolts() 
End Interrupt 

// initialize... 
Public Sub Initialize(pOnvoltEvent As TEvent) 
   LowVolts = pOnVoltEvent 
   PIR2.bits(2) = 0        //clear HLVD flag 
   PIE2.bits(2) = 1       //enables HLVD interupt 
   intcon.7 = 1     //enables HLVD interupt 
   Enable(OnVoltChange) 
End Sub

The way i see it this is about the only way to work this using interrupt's Jerry looked at it and said he don't see a easy fix the red led stays on till you change the battery's but I think that would be what you would want.

 

[Pigskin Tony]

Well, at least ol DEB seems to have tried Jon's code before he started FIXING it this time!

But he sure got himself in a pickle now!

 

[MrDEB]

Don't think so.
I have explained what I want to do but maybe I didn't explain it right or people just don't get it.
I have complied a code that I hope does what I want it to do.
press a button and it enables the transmitter thus putting the batteries under maximum load, then enable the HLVD module, then indicate a green led for batteries are still good to go / Red led batteries need to be recharged. Hopefully avoid overcharging of batteries if I use rechargeable s which is perhaps the better route.
The post about using an LM317, Ic2, spi is not going the KISS method. I really got a laugh over that post.
NO I didn't fix Jons code, I changed it to fit my needs.
As for an ISR, The only time I think I need to use it is when the pic is asleep. After I get my newly written code to work I will let you know.

 

[be80be]

Jon code doesn't work as you are thinking it's polled The code I posted will work when the chip is in sleep mode it will wake up the chip.

 

[JonSea]

I'm not sure why on earth you would wake the micro from a low-power condition to check the batteries. As explained before, this would be an extremely non-representative test and it would waste battery power. Burt is exactly right.... The routine I wrote is polled, expected to be run (only) during normal program execution to get a realistic view of battery condition.

But rational thinking, explanations and so forth obviously have no place in this discussion, so never mind.

 

[be80be]

Jon I'm with you on this there no reason to test batteries when your not using the dang thing and I still say Mrdeb is wanting to drain them way past the point of no return. And like you said the drop off point happens real fast.

Battery capacity ratings are meaningless when used to compare different types of batteries or to compare the capacity of batteries powering different types of devices.


This means that you may not be able to predict how long your electronic device will run just by looking at the capacity rating of a battery. For example AA alkaline batteries typically have a capacity rating of over 2,500 mAh and AA NiMH batteries have rated capacities of only 1,200 to 1,900 mAh. But when it comes to actually powering an electronic device like a digital camera, the NiMH batteries will often run the device for three or four times a long.

 

[MrDEB]

You both don't understand my planned setup.
Going to test with the batteries under load.
User removes the device from helmet, then presses a button which enables the TX_PWR thus putting the maximum drain on the batteries (was even thinking of adding an extra 20ma load so total load would be 14ma + 20ma = 34ma but not on one pin)
Upon pressing the button that enables the TX_PWR it also enables the HLDV routine. Add a delay of 3000-5000 for good measure.
I got sidetracked but need to re read Burts posted code.
As far as Sleep, the pic goes to sleep between switch closures of s1 and s2, not the battery test button.
need to research the polled condition more.

 

[JonSea]

Just so I can understand your logic, exactly what is wrong with testing the batteries during normal operation as I have explained? As I said, you can set up a Boolean flag and set if if the batteries read low at any point. You don't have to act on it right away since you for some reason think that's a bad idea; you can display a low battery condition as part of the shut-down sequence.

press button to transmit

transmit data

test battery and set flag if low

To Shut Down

press off switch

if dead battery flag is true, flash LED

sleep



I truly don't understand your reluctance to do this, unless the words Boolean and flag scare you. As part of the normal program loop, the HLVD test requires just a few lines of code (the same lines that would have to be used elsewhere), no time to execute and adds at most 45 MICRO-amps of current draw.

Please enlighten us.

 

[MrDEB]

You got what I want to do but slight change, you press button which enables the transmit AND enables the HLVD routine to test batteries. No need to enable the HLVD routine unless maybe an audible alarm (simple beep) while the unit is in use to alert the user that the batteries are getting low(I just though of this while typing and your post inspired this idea (THANKS)
The LED would flash before shutting unit off then no need for a delayed power off to make things simple.
You have sleep after the device is off?
If I include an audible alarm while in use sounds like a good idea. Remember this device is behind the users head so LED indicators while in use won't work, only when removing to recharge.