Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

HT12D and HT12E encoder/decoder issues

Status
Not open for further replies.
I found my issue
I had the config set at 20. After setting to 8 it works or so it seems to.
Will do more research as I want to know exactly why.
 
...Will do more research as I want to know exactly why...


Exactly why? Because you had the clock frequency set wrong. Geez. I explained this in my last two posts. What more research is needed?

All timing functions are based on the clock frequency specified. Baud can also be called bits per second. Sounds like it's time related don't you think?

I don't explain this stuff for my benefit, and apparently not yours either. All the pieces have been explained to you numerous times. Your research should be in trying to understand what people have explained to you! I can't post in crayon, so I don't know how to make things any clearer to you.
 
LOl You don't have any crayons or what? LOL. This is beginning to look like life here you can make hard or easy. Learn one part learn it well go to the next.

The compiler handles the time part based on what you tell it and that's it... The chip uses a fixed clock or the one made in it and there agin it only uses the one you tell it.
I really don't see why you make this hard on yourself it really don't have to be if you can't remember what you did the last time you set the clock make a note to remind you.
It's that easy. Good luck here.
 
The problem was I had the wrong clock frequency. I went from 20 down to 8 and it works.UI was using the same external clock settings etc but had to go with internal osc since thats what the device will be using in the finished prototype
Now on the the unexpected results of running the RIDE sequence which draws the most current.
Its 10:52pm. Using a fresh 9volt duracell alkline battery the led segments finally went dim. been running since 3pm today. Accounting for the fact that the flash rate was about half due to the required delays in the code and the battery has an average rating of 230mah I figure the estimated run time using https://easycalculation.com/physics/classical-physics/battery-life.php to be 4 hours
using the ADC module and a voltage divider. I was surprised it ran as long as it did. Should be no problem using say a 1200mah battery.
 
Doing some house cleaning by eliminating unnecessary code,and boy are there lots of junk in this train wreck. checking schematic against code and adding LOTS of annotations.
Adding in CASE SELECT for battery condition/LED indication. Will call this my battery fuel gauge.
I found out that exactly at 4.7v the LED segments go dim so CASE SELECT can be configured.
Lessons learned - pay better attention to my osc settings and check code against schematic AS I compose code, not later. Found one addition and one mistake on port numeration. EEweb suggested to correct errors when found immediately, not later as they could be overlooked.
 
As I said before, "battery fuel gauge" has a very specific meaning, and what you're (attempting) to do ain't it.

You are simply monitoring battery condition based on cell voltage. Yes, this works to a limited extent, and is fine for this application.

A battery fuel gauge measures current flow. It literally counts the electronics going into the battery during charging and the electrons going out of the battery during use. Here's a good description: Maxim Battery Gas Gauge Ap Note

Words matter. When somebody is (futilely) trying to follow what you're trying to do, terminology is everything.

Alas, you'll ignore this too.....
 
If you want to verify for yourself that measuring battery voltage is not a "fuel gauge" do the following simple test.

1. Measure battery voltage and log. Say 6 volts.

2. Apply load and measure the time to reach some lower voltage, say 5 volts.

3. Remove load. Marvel as voltage returns to nearly the original voltage.

4. Apply load and measure the time to reach the the lower voltage.

5. Repeat.

Notice the battery voltage will return to nearly the original voltage even when almost dead. Notice the time interval to reach the lower voltage gets shorter every time you repeat the process. Battery voltage under load is an indication of the state of charge, but isn't a foolproof measurement.

A battery fuel gauge won't be fooled by a test like this, since it's actually measuring electrons into and out of the battery. It will give an extremely accurate indication of battery charge but it's very much overkill for this application.

Why does it matter if you call your simple test a battery fuel gauge? Imagine the poor SOB who is searching for info on battery fuel gauges and comes across this topic. He'll waste an inordinate amount of time going through what, 25 pages and counting, only to find there's nothing of the sort here.
 
Well I see your point about terminology.
BATTERY MONITOR INDICATOR sounds ok but no real panache-lol
On the test you mentioned, Yes I measured the battery voltage last night after I removed the Pickit2 etc.
Battery was up to 7.2v. Connected up the board again and I waited to see at whaty point the battery voltage dropped to the point when the segments go dim again. Lets say I wanted to verify my voltage readings before writing code to indicate battery condition under load.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top