Help me with a simple alarm with the 2400bps 434MHz RF Link

Wireless & IoT
21

Well, I finally brought out the big guns and dusted off my old Hitachi O-scope (20MHz) that I bought out of college in 1984 :slight_smile: and took some screen shots of what I saw on the scope. Very interesting.

First, I checked the TX data in line to see if I could see the Linx encoding wave. Sure enough. I got a completely continuous (locked) encoding pattern. See this picture of the O-scope image: http://flash.360vl.com/~lcox/breadboard … ataOut.jpg The scope is showing about 5 volts per major graduation so this looks very TTL-ish as I would expect. Again, this reading was taken on the Data Out side of the encoder that goes to the TX data line.

Secondly, I checked the digital data port on the RX side to see if I could see a corresponding wave. It’s also obvious that the encoding is making it through the RF, albeit, by the time it goes into the Linx Decoder, the wave form amplitudes are not pure TTL any more. Here’s a screen of the O-scope on the Data output of the Receiver (Data input to the decoder.): http://flash.360vl.com/~lcox/breadboard … ata-In.jpg. Notice the TX and RX patterns correspond but the RX side is not at 0-5V like the TX side is…it looks more like 2.5-5v transitions.

Anyway, I’m not sure what to do about this at this point. It’s clear the encoding is making it across the RF link but is different enough that it’s not like the TX encoder output is connected to the RX decoder input - that worked, but going across the RF doesn’t and it’s obviously due to the difference in the wave form.

I don’t know if it’s due to the level changing that occurs coming out of the RX or some other factor. It seems like the wave is somewhat slower as I can see the edges on the RX side but on the TX side, I could only see the levels and not the edges. Don’t know if that’s meaningful, but just an observation based on these pictures.

Any ideas to try next?

22

One more thing to refine the above results - I calibrated the scope some more and see 0-4v square waves on the TX side coming out of the encoder’s data out. On the RX side, I see 0-3.7/3.8v (not quite 4v) going from the rx radio digital data pin.

I’ve double checked that the receiver radio is seeing +5v on its +5 pin, so I don’t think it’s running low.

Again, if I run that 0-4v signal directly into the rx linx decoder I see a solid D0 out. I’m now wondering if I’m going to need to pull up the RF digital data out to true it up to 4-5v. I’ll experiment with that to see if that would help.

23

According to the datasheet, the minimum input HIGH for DATA_IN is 0.8 * VCC (4v for a 5v input). I think the problem is that the amplitude of the input signal from the receiver is a bit low. Why that is, I can’t say at the moment. Why don’t you try putting a diode from VCC (anode) to pin 1 (cathode) of the decoder chip. This will reduce the supply voltage to the decoder by .6 - .7v which makes the input high threshold 3.44-3.6v. I think this will get things decoding for you, and then you can investigate why the output of the receiver is lower than expected.

Another idea is to take a 10k or so resistor and use it to pull up the DATA_IN line to +5v. I’d try the diode approach first to confirm it is an input level issue, which is almost certainly is seeing the oscillocope waveforms you provided.

24

I’m not sure I follow the TX side picture but that transmitter, I believe, is for ASK. when the input is low, the transmitter is off and when it is high, the transmitter is on. As such, the transmitter takes some amount of time to ramp up so your pulses will be shorter than the direct connection. You might want to decrease the length of the low periods to see what happens.

I don’t think the voltage level thing is an issue.

by the way, does your scope have some alignment problems or is the waveform really decreasing in amplitude in both pictures?

25

Thanks for the responses.

riden said:

This will reduce the supply voltage to the decoder by .6 - .7v which makes the input high threshold 3.44-3.6v. I think this will get things decoding for you, and then you can investigate why the output of the receiver is lower than expected.

Interesting. I will definitely give that a try and/or the resistor as well depending upon the results of the diode test. This sounds promising.

Philba said:

I’m not sure I follow the TX side picture but that transmitter, I believe, is for ASK. when the input is low, the transmitter is off and when it is high, the transmitter is on. As such, the transmitter takes some amount of time to ramp up so your pulses will be shorter than the direct connection. You might want to decrease the length of the low periods to see what happens. I don’t think the voltage level thing is an issue.

The reason I went with the Linx encoder/decoder was so that all the timing would be taken care of for me in hardware. I don’t have a microcontroller bit banging the pulses. The Linx encoder is doing everything. So, there isn’t anything I can do to change the timing of the pulses.

I want to mention that I ran the experiment on both baud settings of the Linx (adjusted the baud on both ends) and got the same results on the faster baud rate even though the 434 should not be able to handle the faster baud rate. I wanted to see if there were any clues from that. None that I could pick up.

by the way, does your scope have some alignment problems or is the waveform really decreasing in amplitude in both pictures?

Yes, it’s alignment is off (as I said, vintage 1984). To tell you the truth I’m not sure how to get it aligned - I went through the dusty old manual and don’t see anything related to getting it aligned. In any case, it did what I needed it to do - told me what wave forms I was getting and their relative amplitudes, so for that I’m glad.

26

Ah found the ol’ scope’s alignment internal adjustment. Got her squared up. Nothing like something out of alignment to drive an engineer nuts.

Will get back to you guys on the diode/voltage level experiment.

27

landon:
Yes, it’s alignment is off (as I said, vintage 1984). To tell you the truth I’m not sure how to get it aligned - I went through the dusty old manual and don’t see anything related to getting it aligned. In any case, it did what I needed it to do - told me what wave forms I was getting and their relative amplitudes, so for that I’m glad.

I looks like the yoke, the coils on the CRT that control the positioning of the beam, needs to be adjusted. Please be careful since there is high voltage on the CRT (a few KV) and up to several hundred volts flowing through the yoke.

If the LICAL decoder specs say minimum input HIGH is .8 * VCC (4v with a 5v VCC) and you’re not seeing that from the receiver, that would be a problem. I think the waveforms look pretty good, and I’m pretty confident that the receiver will be able to process the data as that is what it was designed to do.

28

landon:
Ah found the ol’ scope’s alignment internal adjustment. Got her squared up. Nothing like something out of alignment to drive an engineer nuts.

An internal electrical adjustment, now that being having the move the yoke anytime!

29

Ok, I’m getting scary good at taking o-scope screen shots.

But first, if you want to see an overview of the breadboard: http://flash.360vl.com/~lcox/breadboard … oardRF.jpg. The Arduino mini-stamp in the upper part is separate. The only thing it’s doing for me at the moment is giving me +5v from the USB connection. I plan to hook it up eventually to this experiment, but right now, the focus is on the middle (TX) and bottom right (RX). Notice my transmitter antenna strapped to the BBoard on the left. That’s the 434 antenna I was referring to earlier that I got from Renton.

I did several of the suggested experiments. Here are the results.

I put a diode between VCC and pin one of the decoder to pull down the supply voltage as suggested by riden. Unfortunately it didn’t help - in fact, instead of getting a consistent blip on the RX LED, sometimes it wouldn’t light…it was a lot more inconsistent/ hit and miss.

I measured the voltage at pin one and got 4.75v so it didn’t drop quite as much as might be expected. The Vin without the diode is about 5.05-5.10v, so didn’t get the .6v-.7v voltage drop with the diode experiment and the results were unstable.

So, I replaced the diode with a straight jumper to vcc. Then found a 10k resistor and went from vcc to the data in pin of the decoder to try to pull that up. First, I did an o-scope shot of the data-in pin without the pull-up and got a nice wave on this shot: http://flash.360vl.com/~lcox/breadboard … Pullup.jpg The bottom of the wave is my 0v reference point just so you know. So, it’s amplitude looks like it’s around 3.75v.

With the 10k pullup, here’s the o-scope shot: http://flash.360vl.com/~lcox/breadboard … Pullup.jpg You can see the pull-up did its job. The top amplitude of the wave is about 4.5v so should be right in the sweet spot, I think.

The results are maddeningly consistent. I just get a quick blip on the output side of the decoder with the pull-up.

I then tried running with both the diode on pin one of the decoder and the pullup on data in. Same results, though interestingly, it seemed a little more spurious. With the photointerrupter constantly blocked (high), occasionally I’d get some flicker out of the RX LED that seemed like noise except that without the diode and pullup, I never saw any flicker…half wondering if it was thinking about working, but wasn’t quite there.

I appreciate all the ideas to check out. It’s got to be close, but I don’t know what’s missing. Any other ideas to try?

30

One final thing before I bag it for the night. I have a second Tx/Rx radio. I substituted the Rx radio and got the same results, same voltages out of the data pin of the radio. So, either I have two bad parts, or they are working as designed (~3.6-3.75v on data out pin of the radio.)

31

I’ll bet you were using a germanium or Shockley diode whose drops are around .2 volt. But, I’m glad the pull-up brought the level up to the proper level. The pull-up is a better approach anyway. I really thought that getting the input levels where they’re supposed to be would fix this.

I noticed that pins 5, 6, and 7 are connected in your receiver photo, but they aren’t connected in your view of the entire breadboard. If you don’t have +5 on 5, and GND on 6 and 7, you should hook them up.

Other than that, I can’t see why this isn’t working. Perhaps an email to Rentron describing the problem might help. Be sure to reference your oscilloscope measurements or this message thread. On their site, they show essentially the same setup as yours using the same parts.

32

I’ve tried the RX radio with all the +5v and GND wires, and also with just one +5 and one GND. It didn’t change the behavior so didn’t get any clues. So, what you saw in the overview of the breadboard was the state without all +5’s and all GNDs.

In any case, I will reconnect them to be correct. I’ll contact Renton to see if they have any ideas for why this doesn’t work. I saw on their site somewhere that they were in Canon City, CO, so if worst comes to worst, maybe I can drive it down and show them if they’re interested in figuring this out. In any case, the Linx encoder/decoder solution just doesn’t seem to work with these 434 radios. Would be nice to know why and given Rentron is saying they should work, then I would think they would be interested in this problem also.

33

FYI - I sent a note off to Rentron tech support and received this reply:

Hi Landon,

I have a couple questions;

  1. What baud rate are you using? I.E. what logic level do you have the LS encoder & decoder baud select pins at?

If you have the baud select pins at Vcc, then you’re way over the max data-rate of the RF modules you’re using, and that would cause similar results.

  1. Have you tried triggering the encoder without the photo interrupter? I.E. simply connect the encoder data input directly to Vcc? Does that work?

If it does, it may be that the device you’re triggering the encoder with fluctuates, and isn’t holding the data input pin at Vcc.

Something to remember with “any” momentary type encoder/decoder chipset is that you’ll need a very stable “uninterrupted” data transmission/reception between encoder and decoder. Even a slight interuption in the flow of data will cause jitter on the decoder

outputs.

You also need RF modules that are relatively stable. I haven’t used the ones you have now with the Linx LS series, but I have quite a few others, and they work as advertised assuming a solid, unobstructed flow of data from encoder to decoder.

Regards,

-Bruce

tech@rentron.com

Reynolds Electronics

I responded to him with summaries of everything we’ve tried here and asked him to look at the scope images. They don’t look jittery to me at all, but then again, this is the first time I’ve seen the output of one of these, so maybe there’s something in the image I don’t see.

One of the things I’m planning to try tonight is to put some different data inputs into the encoder (D0-D4 = +5,0,+5,0 and so on to see if I can find an encoding pattern that works across this particular RF link.

The next thing is going to be to try some different RF modules - this one apparently is cantakerous enough to stump us all as we all try to outfox it.

Anyway, wanted to share Rentron’s response so far.

34

It looks like Bruce is going down the same paths as this thread has. This really looks like a RF link issue. I think that the modules you are using are the LaiPac modules, which are fairly common, but I’d check on the manufacturer of the boards Rentron uses.

35

Mine are the Laipac modules. Rentron is selling TWS?

I’m planning to pick up the 4800bps version of the 434 http://www.sparkfun.com/commerce/produc … ts_id=7815 late this afternoon but may not get a chance to try them out tonight.

I’m wondering if the slower 2400bps RF is just on the edge for this encoder/decoder.

One thing I noticed was Rentron’s transmit RWS-434 was the “A” model: RWS-434A. I see Sparkfun’s 4800bps that I’m getting today is KLPA vs the KLP (the 2400bps I’ve been using.) So, just wondering if anyone’s actually validated this solution at under 4800bps - only 4800bps and up. Just thinking out loud.

As soon as a I get a chance to try out the new radio as well as experiment with the D0-D3 inputs to see if I can find an encoding pattern it likes with the old radios, I’ll post my results.

Thanks for all your suggestions - I’ll keep you aprised.

Landon

36

Just got a nice followup note from Bruce/Reynolds Elect:

Hi Landon,

I just saw the pictures you posted. My guess would be you’re over-loading

the receivers front-end with the transmitter located just a few inches from

your receiver.

Try building both circuits on separate breadboards, be sure to install at least

a 6.5" antenna wire on both TX & RX, separate them by around 30’, remove

the LED from your encoder data output, and test them with a simple push-button

switch on the transmitter.

If you can, use batteries for initial testing, or try to filter your power supply down

to <20mV peak-to-peak noise or hash on the rails. This is especially critical in

the receiving circuit.

It may even work by simply removing the antenna from your receiver so it’s not

being over-loaded with the transmitter so close, but I would still go for the separate

boards and power supplies with at least 30’ separation distance.

Regards,

-Bruce

Reynolds Electronics

I’ll separate the TX and RX as he suggested.

Fortunately, I have a bunch of new stuff to try so will keep you all updated on what I find.

Thanks again for the suggestions.

Landon

37

Sorry I didn’t post earlier, but it seemed like the Sparkfun site was down.

Anyway, I have new information after some new experiments, but no success with the 434 RF.

First, I replaced the 2400bps 434RF modules from Sparkfun with a 4800bps from Sparkfun. Same manufacturer as far as I can tell - pin-for-pin substitution.

I got the identical behavior as before whether the Linx encoder/decoder were set to 2400bps or 4800bps. I was thinking with the better radio (4800bps) and Linx feeding it slow (2400bps), that it would potentially work, but it didn’t and 4800bps sel state for Linx didn’t either.

One interesting thing from this experiment is that the 4800bps radio receiver does put out a nearly 5volt data output unlike the 2400bps - which was more in the 3.75 neighborhood. So, I didn’t need to do any pull-up resistor on the data in side of the decoder.

The wave forms looked good coming out of the radio - not glitchy, very solid, square wave shapes, but then again, that was very similar to what I saw from the 2400bps. They were locked on and not glitchy either.

I did put a .1uF cap on the rails of the protoboards in case power noise was an issue.

The 2nd thing I tried was separating the Rx and Tx onto two different proto boards and then space them quite a ways apart from one another. I tried different distances - 4-5 ft, and then probably 20 ft. Once again, this had no affect on the problem.

The 3rd thing I tried was to replace the opto-interrupter with a simple repeating pulse that I generated from the Arduino Mini/stamp. The pulse would always make it across the RF, but once again, on the output side of the decoder, it would be a brief high and then go out until the next pulse.

It’s getting harder for me not to conclude that the Linux encoder/decoder solution will not work with the 434 radios from Sparkfun. I think about my only choice now is to order some 434 radios from Reynolds - the ones they sell in a combo with the Linx encoders.

I got a 2nd Arduino mini and was considering trying to do a UART tx/rx connection between them. If you believe the sparkfun descriptions of these 434 radios, this is what they were made for, but unfortunately, I don’t have a lot of confidence in the radios any more.

Does anyone have any other experiments to try? This is so simple, it’s maddening that it doesn’t work as advertised.

38

Just to test the radios a little more, I hooked up a GPS on the TX side and a TTL serial to USB adapter on the RX side. I went straight from the TTL tx on the GPS into the Data port on the transmitter.

On the RX side, I went from the digital data port to a the RX of a serial->USB to Hyperterm on a PC.

I can see NMEA data on hyperterm just fine (albeit maybe every 10th line has some scramble in it, but the majority of the data going over the air is just fine.) That was at 4800bps.

The Transmitter was about 2.5 ft from the receiver, so it’s obviously possible to get decent data across this RF link even at short distances, so I don’t think this transmitter was ever oversaturating the receiver.

It just seems to me like this Linx encoder/decoder’s tolerance is too high and if it’s not perfect (Data out hardwired to data in), it doesn’t work. Seems like it should be harder to get a UART to UART over RF working than a simple switch/encoder, but in this case, it’s easier.

Anyway, I’m open to suggestions on other things to try to make this wireless switch work. Obviously I could put a micro on each end, but I was trying to avoid the expense and size of that in this solution.

39

I’m running out of ideas, and I really can’t figure out why this doesn’t work. :frowning:

What is the logic 0 level on the DATA_IN pin? The spec for the LICAL-DEC says it can’t be any higher than .75v. Maybe the receiver isn’t delivering a good logic 0 level and a simple emitter follower will make things right.

If the level looks too high, take a general purpose NPN transistor, connect the collector to +5 volts, the emitter to GND via a 1k resistor, and the base via a 1k resistor to the receiver output. Connect the DATA_IN pin to the emitter of the transistor.

40

Try wiring encoder data inputs D0-D3 directly to Vcc. Remove all loads

from your decoder outputs, and use a logic probe or meter to test each

output.

What happens?