LINX RF module and PIC

I have a pair of 16c65B, one as a xmtr using serout and the other as a rcvr using serin.

When I hardwire the output pin to input, everything works great. I normally have an optoisolator in there and it works fine either way...with or without.

I bought a LINX ES 916mhz xmtr and rcvr module and was hoping that it would be a simple plug and play but so far, no luck.

I have a scope connected to the data output on the rcvr module....the data is there and looks fine but when I connect to the rcvr pic (or the opto), I lose the waveform and get nothing.

I tried some series resistance, which gets the waveform back but still no action on my rcvr.

Could someone tell me what I'm doing wrong?

It has to be something simple.

I even inverted the data for the heck of it but obviously this is an interface problem as I'm losing signal completely.

--thanks

I did now just notice one thing that may play a part.

I'm using A4 as my input pin for SERIN on the rcvr and I know it's a schmitt trigger input (didn't know that before I did the pc board).

But like I say....if I hardwire....everything is fine.

I'll try another input and see but I don't think that's it.

?

actually, come to think of it, I made porta.4 serin BECAUSE of the schmitt trigger.

works wired...just not with the linx.

On most PICs RA4 schmitt trigger inputs require a minimum input level of around 0.8 * Vdd to be recognized as a logic 1. Assuming you're running right at 5V, this would be around 4V.

The Linx ES series receiver data output level for a logic 1 is around Vcc - 1.1 min, Vcc - 1 typical, or Vcc - 0.9 max. You only have around 3.9V min to ~4.1V max. Best case is around .1V above the minimum level required by RA4, so this could be a problem.

A TTL input would have been nice, but you can always use an FET or transistor.

Both my linx rcvr and the pic are powered by 5v supplies (seperate) so I sort of ruled out a threshold problem but I thought of just using a transistor buffer last night to see if that solves it.

I thought the linx out and the pic input would be compaible as most schematics
I've seen show a direct connection.

It's like when I connect the linx, it just shorts out the signal completely.

I'm gonna goof with it later....I'm sure it will be something stupid.

Well....I tried a buffer into the pic (inverted and not)...plenty of data on the SERIN pin and still nothing.

I don't get it....it works perfectly with a wire pair but nothing with the Linx.

How important is a squelch circuit?

I'm not using one.

The difference in a hard wired connection & wireless is like the difference in night & day.

Are you saying you "are" seeing serial data at the PIC input, but your program isn't responding as expected? Or are you still losing the signal altogether when making the connection?

Got it working Bruce with a non-inverting buffer.

One thing is for sure...the Linx ES rcvr is not compatible going straight to the Pic (PortA4 anyway).

Now, I'm having a bit of a problem with data out of sequence between xmtr and rcvr but just a "timing" thing.

I may be able to live with it but I'd like to solve that as well....without rewriting the PIC software.

Using SERIN and SEROUT at just 1200 baud with 2 qualifier bytes and the data byte.

Are sequence problems just part of the "RF deal"?

Where is your software listing. I suspect your serin command may be locking up on noise without the use of the squelch circuit from the data sheet. Also are you aware that the es series transmitters have a maximum recommended operating voltage of 4 volts. There are some typos in both manuals which make this unclear.

I use the ES for voice and data and I find the range is limited to around 75 feet max with 1/4 wave whip antennas.


Your software, if you post it, could also provide some insight into whats going on.


Mike

Yeah, I'm sure you're right. I'm going to try a squelch circuit first and then get out my windowed chips for some software changes.

A learning process for me and really I'm sure when you're doing code for wireless
it would be a good idea to test the connection first and take other things into consideration.....like "settling down" times etc.

Maybe even some sequence "markers" along the way or something.

At least they are talking to each other.

If I showed you my code....you'd make fun. I'm sure I write a page for a good programmers paragraph.

Actually....thinking about it....I wonder if a longer pause at the start of the code may help a bit? (doubtful).

My program really gets going quickly with a serial feed from the transmitter.