RS 485 wireless communication

[SergioRM]

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

Regards,

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

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.

[Dave]

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

[Michael]

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.

[Dave]

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

[PJALM]

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.

[Ioannis]

[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

[Michael]

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.

[Ioannis]

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

[Michael]

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.

[Ioannis]

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