SparkFun Forums

[riden]

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.

[landon]

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.

[landon]

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.

2. 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.

[riden]

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.

[landon]

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

[landon]

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

[landon]

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.

[landon]

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.

[riden]

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

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.

[Bruce]

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?

[landon]

Hi Bruce. Thanks for your response.

I'll try it and get back to you with the results. I think a number of people would be interested in seeing this work (if for no other reason than we're stumped why it doesn't.) Lets do it

[landon]

Ok, I tied D0-D3 of the encoder to Vcc. I removed the LED from both the encoder Data Out and the Decoder D0 pin. There should be no load whatsoever on either side.

Using my O-scope, I looked at D0-D3 on the decoder side. All were low. This is consistent with my other findings that on the decoder side, the output will go low after an initial transition.

If on the input side D0 went from 0 to +5v, I'd see a quick blip on the decoder side of +4-5v and then back to 0.

In this case, it's like what I saw when I had the opto-interrupter constantly interrupted (high) or an output from an Arduino that stayed high. If it's up long enough (>500ms) on the encode side, the corresponding output on the decoder side drops to 0 and never goes up again - no jitter, either.

[riden]

What are the levels on DATA_IN? Does logic 0 go below .75v?

[landon]

According to my digital multimeter, the decoder DATA IN pin is running 3.25v +/- .05 or so. Same meter reads a 0.00 on all the D0-D3 outputs.

When I look at the wave on the DATA IN side it's square and has an amplitude of almost 5v...guessing maybe 4.9v.

The bottom side of the square wave according to the O-scope goes all the way to my 0 reference point.

[airhead]

wow busy thread,...anyways, I tested them out Using the Lynx encoder/decoders, I built them on the same breadboard, but when I push the button, I have a voltmeter on the output pin on the decoder, and nothing shows up. Before it would jump to .8 volts when the button was pushed, but then would just stick at that, now nothing happens. 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.