AVR Freaks

my first thought,

leaving it float or low vs high - low.... that will indicate there is a weak pull-up inside, so when you leave the line float it will be defined high else it is defined low. This way they ensured that if you do not connect the pin it will always be defaulted.

It might be as Doc said that the chip only read the address line during power up, it then configures its internal stuff to be that specific setting, and after that the pin is a don't care. Note that they might not tell that explicitely in the datasheet, but it a lot of the times is there in the small letters or some mysterious diagram that tells one what has to be done before what to get good operation.

you could smply take one unit lift the power pin and put a switch in series, then after you changed the address you power cycle the chip and see what happens.

Cool.  But...

I think your test shows that the Tx will allow dynamically changing the address.

It reads the Addr data and the Data data and sends out the data burst, (three times, or whatever).

I'm not sure that test shows that the Rx can dynamically change its Addr data, on the fly.

In "normal" operation, for a garage door opener, or an RC vehicle, etc., the Rx Addr might well be settable by the user, through a banked DIP Switch, (old school), or through a smart phone interface, (new school), but once you set it you generally leave it alone.

In any event, it sounds like you have the hardware necessary to test this, i.e. your working Tx & Rx pair of devices, (unless they aren't configurable).

The test would be to set your working pair to Addr 00h, turn them on, and confirm that you can Transmit a data packet and correctly receive it.

Then, without turning off the power to the receiver, change it to Addr 01h.

Change the transmitter's Addr to 01 h also, with or without cycling its power, (or both ways...), and again see if the Rx acknowledged the Addr change, and captured the new data transmission on the new address.

That will confirm that you can change the Rx's Addr on the fly.

Some more trouble shooting thoughts...  As I wake up this morning, (so bear with me as I think out loud).

Even if the Rx won't allow one to change the Addr on the fly, that doesn't kill the project.

It just means one has to add a high side switch, (an NFet driving a PFet), to turn the HT chip on and off, as you test addresses.

This would slow the scanner down a bit, as each new test needs to await the HT's start up time before one can validly "listen" for an input signal.

That time, BTW, is probably very short, but it has to be long enough for the HT's internal oscillator to power up and stabilize.

If that spec isn't in the data sheet, then it isn't a hard one to measure, and we can work that out down the road.

Next, it always seems to me that Projects beget sub-projects...

By that I meant that the HT has very weak Data Output Drivers, ~ 1.5 mA per pin.

So, unless you are using very low powered LEDs it is tough to easily watch the output in real time as your test the setup, AND you still need a data latch for the VT pulse...

So I'd likely power up another Nano with 5 inputs, one for the VT signal, and 4 for the data bus, and use that to capture the VT pulse and the Data Bus data, and let it light up four LEDs for the data, and another one (with a software pulse stretcher), for the VT signal.

The code would only be a couple of lines, and nothing fancy.

No Pin change interrupt for the VT needed...

Just a loop watching the VT pin to see it change state, then read the data bus and display it.

Then have a short, 2 Sec), or whatever delay, and then turn the LEDs off and watch the VT signal again.

Easy to test it with your known good working pair of devices.

Then hook it up to your test bed device, so you can easily, at a glance, see the output signal.

Do add the by-pass cap, it is an expected part of the design, even if the data sheet doesn't say so.

Put one on both the Tx and the Rx chips.

How many of the HT Rx'ers do you have?

Generally, when a new chip isn't working, it is our understanding of exactly what it is suppose to do that is in error, not the device itself.

That said, at some point it is nice to verify that you don't have a dead chip...

What is the actual hardware lash-up for your working Tx & Rx pair?

Can you simply replicate the working Rx'er setup with your other chip, as a starting point?

JC

Absolutely keep me posted.

I wish to see you successfully resolve your problem.

Do keep the by-pass caps on the Tx and Rx chips, they should be there, and their presence is not why things are not working as expected.

I don't have the HT Rx data sheet in front of me at the moment, so bear with me if I tell you something incorrectly.

You appear to be monitoring one data bit.

Does the light go out if you change the data being transmitted, and send the new data?

i.e. Is the receiver displaying the last valid data until it gets new valid data?

I like to Keep It Simple at the start, and then expand on the project, both hardware and software wise.

As you have a Tiny monitoring the data bit, you really don't (yet) need the transistor if your "light" is simply an LED.

The Tiny can drive an LED if it has a resistor in series with it, day 330 ohms, 470 ohms, 510 ohms, etc., (non-critical value, but critical that it is there to limit the current).

Is your "light" a small tungsten filament bulb?

If it is an LED then you need a resistor in series with it.

The HT Receiver pulses the VT line when it detects valid data.

That was why I suggested the micro monitor the VT line, so when it sees a pulse it can turn on a "VT Pulse / Valid Data" received LED, at least briefly, and then turn it back off.

Part two of that is to read and display the data lines when the valid data VT pulse comes along.

Is this your PCB or breadboard?

The 7805 power supply would usually have a Cinput and a Coutput cap, and the Coutput is often a 0.33 uF and a 0.1 uF cap in parallel, or the 0.33uF cap can be larger.

The "exact" values vary from 7805 manufacturer to manufacturer, some are more particular in spec'ing Cout than others.

That's not likely the issue, but as you do more and more hardware tinkering you will want to optimize your designs.

As you tinker and play, make sure your batteries are good!

It is very frustrating when your batteries are marginally good, and the circuit fails as an LED turns on...

(Don't ask me how I learned that.)

JC

As an aside, Google should uncover a software implementation of the ht12 protocol. This would simplify the hardware.

Glad to hear it works!

Good luck with the rest of the project!

JC