SparkFun Forums

[landon]

Which radios did you use?

[airhead]

Well..I did specify at the beginning of this post but....
http://www.sparkfun.com/commerce/produc ... cts_id=872
and
http://www.rentron.com/remote_control/Holtek.htm
LINX TECHNOLOGIES LICAL-DEC-LS001 8-PIN DECODER IC
LINX TECHNOLOGIES LICAL-ENC-LS001 8-PIN ENCODER IC

[landon]

The reason I asked was that your results are quite different from mine despite using the same parts. Mine's really close to working, but seems like nothing we try helps get it over the hump.

Sorry to piggy back on your thread but I kind of took off where it left off (encoding devices.)

[maf]

I'm using a 9volt battery connected to a 5 volt voltage regulator, so 5 volts is powering everything, maby it isnt enough power? But there right next to each other, maby 2 inches space, and no signal at all.

Separate the transmitter and receiver by a 3 or 4 feet. I have two pairs of the A434 modules where the receiver will miss bits if they are any closer without loading down the transmitter. I don't remember having this problem with the 315MHz modules...

As a first step try feeding the transmitter with a square wave and observe the output on the receiver with your scope. If you don't have a signal generator the 5V TTL square wave calibration output from the scope should work.

--
mark

[airhead]

I mistyped there, I cant measure the signal, but it doesn't seem like theres any communication.
Also, I wanted to make sure the encoder/decoder chips aren't fried, so Is it possible to just connect the output of the encoder to the input of the decoder, to see if they can actually detect a button press?, and does there need to be a load on the output pin or can just directly connecting a volt meter work fine?

[landon]

If you look back through the thread that's exactly one of the tests I did. Output of encoder into input of decoder. So, yes, that's a good test to do.

For me, that test worked perfectly and is the definitive one that pointed to the RF being the variable that was causing the system to not work.

[airhead]

hmmm, mine didnt work, so either the breadboard is faulty, or the chip is, and I think its the chip, I hope there good with replacements

[riden]

I needed an extra TX/RX pair for a project, so I thought I would order a LICAL-ENC/DEC set to test as well. I am observing the identical situation that Landon is experiencing (transmit as long as a signal line is high, but only get a brief activation on the RX side). I'm using the TX/RX set supplied by Reynolds as well as a LaiPac set and a Radiotronix set. I'm going to drop an email off to Rentron and see if they can shed any light on this situation.

[saipan59]

Hey folks: In case this hasn't already been covered:
I noticed that the output of the Laipac 434 rcvr won't stay 'high' for more than 1/4 second or so, in the presence of a continuous RF signal.
That is:
- Xmtr powered off - rcvr outputs random stuff.
- Xmtr powered on with Data line high - rcvr output is high for about 1/4 second, then goes low and stays low.
- Xmtr Data line toggling at least a few hz - rcvr output follows xmtr Data input.

So, perhaps this behavior is a problem for the encoder/decoder chips?

Pete
Colo. Springs.

[Philba]

is the transmit pin capacitively coupled - that would explain the results.

[saipan59]

is the transmit pin capacitively coupled - that would explain the results.

I don't think so - I verified (with a scope) that the xmtr's output is whenever the Data input is high - no exceptions.

Rather, the rcvr seems to have a "one-shot" type of behavior on it's output. And it's not that the rcvr loses the signal somehow, because the rcvr output stays steady-low as long as the carrier is on. When the xmtr goes off, the rcvr *then* goes back to random output.

Pete

[riden]

Hey folks: In case this hasn't already been covered:
I noticed that the output of the Laipac 434 rcvr won't stay 'high' for more than 1/4 second or so, in the presence of a continuous RF signal.
That is:
- Xmtr powered off - rcvr outputs random stuff.
- Xmtr powered on with Data line high - rcvr output is high for about 1/4 second, then goes low and stays low.
- Xmtr Data line toggling at least a few hz - rcvr output follows xmtr Data input.

So, perhaps this behavior is a problem for the encoder/decoder chips?

Pete
Colo. Springs.

Thanks for the info, Pete. When I say that the transmitter is continously on, I mean to say that data is being continously applied to the transmitter (so the transmitter is being cycled on and off by the data at 2400 baud). I will examine the output of the receiver anyway just to be sure. I'm also going to try adding a comparator to the analog output to quiet the random noise between bits. It seems that I can get a successful decode once, but after that, I need to start all over.

[saipan59]

Just FYI, I should mention that I've never tried one of the decoder chips.

My setup is UART-to-UART, and it has worked well for me so far.
More specifically, I do this at the moment:

- 18F4620's TX line driving the Data line on the xmtr at 4800 baud, 434 Mhz. The same TX signal also drives the trigger input on a 555 configured as a 1-shot with a duration of about 0.1 seconds. The 555's output supplies the Vcc to the xmtr. So, when the UART sends a byte, the xmtr is powered up by the 555. If additional bytes are sent within 0.1 seconds, the xmtr stays on. Shortly after the last byte is sent, the xmtr is powered down automatically.
- The code in the 4620 starts every transmission with a preamble of "<space>+++". The space gets the xmtr turned on, and the +++ is for the rcvr to lock onto the signal.
- The rcvr is connected to the RX input on a 16F917.
- The rcvr code watches for 3 consecutive '+' chars, then assumes that it will be followed by the real data. The rcvr stops listening when it sees a <cr>. This means that each 'packet' is assumed to be a single line of ASCII text.

Pete

[riden]

Just FYI, I should mention that I've never tried one of the decoder chips...My setup is UART-to-UART, and it has worked well for me as so far.

USART to USART is also the approach that I take, as I have the necessary tools to build and program the chips. This thread started to a explore a simpler approach (i.e. no microcontroller needed) using encoder and decoder chips, and the chip approach seemed like a good idea at the time. Actually, many people successfully use the HOLTEK chipsets, and I'm sure we're close to getting to the root of the issue with the Linx chips.

[landon]

Got a very informative note from Bruce at Reynolds. I asked and he agreed to look at my parts, breadboard it see if he could figure why the Linx encoder/decoder doesn't work with the RWS radios.

Turns out the latest radios that are being manufactured have a "sloppy" response time which throws the encoder/decoder out of tolerance. Sounds like Reynolds has a good alternative for the Linx solution. I'll try it out and let people know how it works.

Thanks to all who have put their brains against this - especially riden and bruce.

[quote]
Hi Landon,

Yes we have received & tested the parts you sent in. The problem is a combination of things, but primarily down to a sloppy response time of the receiver. We found the same problem with the new versions of the RWS-434 we have.

The old version RWS-434 works perfect with the Linx encoder/decoder pair. The newer versions however appear to have the same problem as the receiver module you sent us. I’m guessing the manufacturer has changed something on this receiver.

We spent most of the Thanksgiving weekend testing the Linx encoder/decoder pair with various RF transmitter/receiver combinations. They work fine with everything except some of the latest version receivers.

Most of the new version receivers have very sloppy response times compared to the older versions of the same receiver; all from the same source. The manufacturer has changed something on the latest version of these receivers.

With latching type encoder & decoder ICs they all work 100%. With the Linx LS momentary series they don’t. The Linx decoder is less tolerant of the sloppy response time of these receivers. The majority of the newer receivers “doâ€