RS 485 wireless communication

I am using two Texas Inst. SN75176 (RS 485 Transceivers) to communicate between two PIC 18F242s via 2 wire RS 485. The system works fine with the two wires, but does not work when I replace the wires with a Aerocomm CL4490 , 900mhz, RS 485 wireless transceiver.

I have written a simple Serout and Serin program to send a decimal value (1 to 99) from one PIC to the other. The correct decimal value is displayed on a serial LCD on the recieving PIC when wired, but with the radios I always get value of 0 or 252.

Based on the radio diagnosis and factory engineers the radios appear to be set up and connected correct.

Any suggestions

Silly, but have you tried to reverse the wires (a,b) on one side?
Ioannis

I have tried revesing a and b on each radio, and both radios, but do not get any data transfer when switched.

Quote:

---

Originally Posted by Armadus

I have tried revesing a and b on each radio, and both radios, but do not get any data transfer when switched.

---

Can the 4490 be run in UART mode? If so, take the converters out of the equation, and hook the 18Fs directly to the wireless modems.

Did you do the set-up of the units?

As I understand it, you have to use an RS232 to RS485 adapter and connect it to a PC to configure them for "Master/Client" and baud rate.

Master/Client? (What ever happened to the Slaves?). They take the fun out of everything these days.
<br>

I did run the set up utility for the units. I have spoke to the Aerocomm engineers and according to them the set up is correct.

I have also ran the diagnosis and using the PC interface the radios seem to be working properly.

Thanks

RE: Uart mode

I cannot see any method to change the radio to Uart Mode using the Configuration Utility, but I will look into this.

Thanks

I have also ran the diagnosis and using the PC interface the radios seem to be working properly.

If the PC works, then it is your link from the 18Fs to the converters. Now, the PC has a 232 port I assume? How do you connect the PC to the 4490s? I would emulate this with the 18Fs, without the converters. I have worked extensively with 422s, but not 485 converters. I know the parallel resistor across A & B are crucial. If the 4490 system already has one, you may not need another in parallel on your board. Conversely, if it does not, you may need to add one.
You know the link works. The converters work hardwired, if you set up the 18Fs as quasi 232s and establish a link like the PCs (without the converters), all fingers point to the 485 converters. I used Maxims with no problems on my 422 projects FWIW.

Ron

Ron,

Thanks for the insight.

I used a B&B electronics RS 232 to RS 485 converter to connect the 4490 to the PC.

According to Aerocomm there is no need for a terminating resistor, but I have tried a 100 ohm resistor and it made no difference.

At this time I believe that the S75176 converters and the 4490 are just not compatable. I will look into the Max converter that you mentioned.

Thanks
Greg

Can you hook up the PICs directly to the 232 side of the 232 to 485 converters? At least this will prove it is a problem with the TI part. It would bite if you got the Max parts and found out it was something else! I replaced every part on an RF comm board (including connectors!), to find out I mixed up the RTS and CTS lines in my code. That was five hours better spent elsewhere. "The length of time debugging is directly proportional to the stupidity of the error." This I have gleaned from personal experience.
Ron

Ron,

Which of the Maxim RS 422 converters do you use?

-Greg

I used the MAX 487. It is simplex though, but tough as nails. Only one external resistor, and the obligatory .1uF bypass cap.
Any luck with the module? I am using the AC4490 out to a mile with 1/4 wave whip. It is a direct connect to the PICs UART.
Ron

Did you try use a pull up or pull down resistor on the RX pin?

Regards,

I'm curious about the ultimate outcome on this as I'm having the same problem
and although I'm using RS232 right now (at only 1200 baud)....the goal is to use RS485, which is how my hardwired boards are set up.

My hardwired pic to pic is fine but the (LINX) wireless has some problems that at this point, I'm attributing to noise.

I've tried to fix it in software but no luck.

I thought of buying a pair of Maxstream Xcite modules but will hold off? until I see what happens here.

I thought with the Maxstream or Aerocomm products, it may be a simple plug and play.

I think designing a system based on the LINX modules might be more than I bargained for.

Michael, I have personally used the MaxStream 900 Mhz. modules with great success at over 7 miles. I use them to control an Amateur Repeater control functions of a signal to noise voting system. I highly recomend them to any body wanting reliable communications at 19200 baud.

Dave Purola,
N8NTA

I know they make some hi powered units (good for miles) but was looking at the bottom end "Xcite" oem modules for indoors.

Of all the RF stuff out there, I think they look very impressive and very reasonably priced.

I'm wondering if the whole matter of RF data isn't meant for my soldering iron and better left to the experts.

Michael, I have built radios for 50 Mhz. and below but when it comes to frequency's much higher than 440 Mhz. I will let the other guy do the building...

Dave Purola,
N8NTA

Michael:

I currently use the MaxStream 9XCite as well as the 9XStream and 9XTend. These modules work great without any flaws at all. The furthest we have been able to make them work so far is about 2 miles with the 9XTend and about 1500 Feet with the 9XCite. The 9XCite is the cheapest but does not have the build in retry functions for the error correction. This can be done using picbasic code very easily. The way it works is if the data received on the receiving end is corrupt it will be dropped and never sent out of the 9XCite module. By adding a timeout to the transmitting end you can simply resend it again if an acknoledgement is not received within a given amount of time. If you decide to use these modules I would be more then happy to share some example code with you for this. If you decide to use the 9XStream or 9XTend you do not need to worry about this, everything is handled in the module itself. For the 9XCite, choose the 9600 model for it has a much greater distance and I find 9600 to be plenty fast enough.

We have been using these modules for 2 years now and would never change to another one because of how reliable they have been.

[QUOTE=Michael]I'm curious about the ultimate outcome on this as I'm having the same problem
and although I'm using RS232 right now (at only 1200 baud)....the goal is to use RS485, which is how my hardwired boards are set up.QUOTE]


Have you implemented few bytes of preamble and also Manchester encoding to your software?

The first is absolutely necessary to stabilize the data slicer at the receiver end. The second mainly depends on the modules. Does not hurt if you can tolerate speed (you actually send 2 bytes for 1 data).

Ioannis

Don't laugh but I'm not sure about how a data slicer functions.....I do have a squelch circuit that controls an analog switch that I will "assume" is a "data slicer" (pass--no pass?). ??

I have 2 qualifiers in my serin statement and then 2 data bytes that follow.

What seems to be happening is I have a sequence at the very START of the program, that shouldn't function unless a switch is pressed.

It is going through the routine at the rcvr end anyway and the only thing I can figure out is that rather than the data being zero, there is a bit in there that is noise?
SERIN PORTA.4, N1200, [QUALIFIER,QUALIFIER],DATA1,DATA2
IF DATA1 + DATA2 = 0 THEN....

But if I have 2 bytes of qualifier that are working fine everywhere else in the program, why aren't they corrupt as well?

I'm a novice programmer....I'm also out to lunch on "timeout"
and was wondering if I'm missing something there.

Everything works great when it's wired.

I simply have the serout statement in the xmtr pic and the serin on the rcvr
and sometimes (but rarely) they can get out of sequence....I have led's on the xmtr and rcvr that should be in unison.

When they do get out of sequence, it usually just takes a second or so for everything to fall in line...so I never cared.

Am I doing something wrong here? I always wondered about the coordination between the two.

On wire everything is quite clear (hmm, not always, but anyway...).

But radiofrequency is another matter. The receiver has analog circuits that produce a analog replica of the pulses you transmit. If you want a pulse at the output of the receiver, then either you will connect a schmitt trigger or a more clever circuit called data slicer. The first will work only if the signal is at a standard level. The second will adjust the trigger level according to the signal strength. So if you are near the receiver (strong signal) the trigger level will be higher. If you move away from the receiver (weak signal) then the trigger level will fall. But not immediatly. There is a time constant (that's where the preamble is needed-to find the correct level).

There is no need to deal with squeltch or analog outputs of receivers since there are all the circuits included. Just connect your PIC at the data output of the receiver.

Also your bytes should not be a train of 1's or 0's because again in this case data slicer cannot be set correctly. So you need also a manchester encoding scheme. (See: http://www.picbasic.co.uk/forum/show...79&postcount=6 and also: http://www.picbasic.co.uk/forum/show...77&postcount=4 )

All these have been discussed in the forum.

It is a good practice to send a series of 4-5 $55 which is 01010101 in binary as preamble and after this a manchester encoded data bytes.

I would suggest also a CRC at the end if you can, to ensure data integrity.

Ioannis

So manchester encoding is sort of the opposite of compression? More bits to represent the same thing?

I actually have a non inverted schmitt trigger buffer at the LINX rcvr output..(2 sections of a 4093) and using porta.4....the schmitt trigger input.

I'll get it working someday.

Use a scope and see the level of the receiver output. Should be rect pulses of almost 5 volt high. No matter if it is noise pulses or data. If you see this then you are on good road. No schmitt trigger is needed. All necessary electronics are within the receiver module.

Try this:

On the Txer send with serout or serout2 the array $55,$55,$55,$AA,$55

On the Rxer wait with the serin for a $AA and get the next byte. In our case this is $55.

I am sure if you have electrically everything by the book, you will get that byte received OK.

On the example if you check the bytes you will see that there is no continues
train of 1's or 0's. So no DC bias is created internally in the Rxer. That's the idea. Please do a search on the topic, it is cover fully here on this forum and on the mailing list archives of http://list.picbasic.com/cgi-bin/board-search.cgi

Ioannis