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