RF Data transmission protocol

F

Thread Starter

Fred Chwalek

I am using RF modems to transmit data from a number of elevated tanks and remote pumping stations. The method of collecting the data is report by exception when a parameter change is relevant from each remote site to the host, and polling by the host when it hasn't heard from a remote site for a certain amount of time. Although it seems to be working I am not comfortable with the setup for these reasons:

1. Remote sites may try to transmit at the same time.
2. Transmission may not be successful and a transmission retry may be necessary.

I think I can handle the radios trying to transmit at the same time by monitoring the receive buffers. If there is something in the
receive buffer then another radio is transmitting, so I wait for the buffer to be empty. The real problem seems to be when the
transmission is not successful and a retry is attempted. Should I try scheme where the sending device sends a message and waits for an OK from the receiving device that it got the message? If there is no OK, retry sending the message? Or should I just send the message and hope it got through? Or, should I send the message two or three times, every time and hope it got through? Is there some kind of standard way that, say, Motorola handles this type of situation?
I will appreciate any suggestions.

FRED CHWALEK
[email protected]
 
A

Al Pawlowski, PE

You can shorten the time between no action polls, but obviously, the most secure way is to transmit (but with a definite limit to tries) until the Central replys with an acknowledgement. However, if there is a too much traffic for your response needs, you need to increase bandwidth
availability with more channels/frequencies or possibly just higher bit rate to shorten transmission time.

Looking at the receive buffer at an RTU is not very useful because the RTU's ususally use directional antennas pointed towards the Central and results in your RTU missing other RTU transmissions. Noise often shows up in the buffer too.
 
R
> 1. Remote sites may try to transmit at the same time.

Normal solution to this is Carrier Detection, but that does not exclude.....

>
> 2. Transmission may not be successful and a transmission retry may be necessary.

Which requires non destructive arbitration. If you are using OOK modulation, you could use CAN interfaces, with higher quality FSK or FFSK modulation some sort of token passing or scheduling may be approapriate.

I have recently developed a simple protocol that satifies your requirements, and is also designed to be easy to implement of the serial port of a non RTOS system (i.e. connecting remote modules to a PC).

I wrote this because I could not find any protocol that satisfied my requirements, and intend to publish it, but it needs more meat and documentation yet. If you are prepared to wait.............
 
N
> Hi Fred

1. Normally the origionating station would only transmit if the channel was clear i.e. the mute was not open. This usually prevents most collisions.

2. Every transmission should be acked (acknowledged) by the recipient. The ck can be
just that, a simple short string, or a status of the I/O or a repeat of the transmission. The origionating station must receive the correct ack to prevent retries.

3. All transmissions should have a CRC appended for error checking.

4. If the origionating station does not receive an ack in a certain time frame, it retries, BUT every station has different or random delays between retries. This ensures that if two stations DO transmit simultaneously the first transmission will be wiped out, hopefully one of the retires will get through. Channel busy monitoring will separate subsequent retries and both stations will be successful.

5. A number of retries should be programmed. I usually use 3-5, depending on path reliability

6. If transmission is not successful, a local alarm or coms fail O/P is exerted.

regards
neil jepsen
new zealand.
 
F

Fred Chwalek

Just to update what I have been doing and what I have learned from responses.

Looking at the receive buffer seems to be working for me. It does tend to get noise in it, but I can determine noise from data and filter it out. The antennas are pointed at the repeater, and are not receiving messages from other RTUs'.

Every transmission is acked, and CRC checked.
If an OK is not received, there is a random generated delay before the station retries. This is to try and avoid two stations transmitting at
once. The number of retries is programmable, and the RF signal is good so three retries seems to work. Local alarms are set if messages are not ack'd properly.

I have two questions. What is non destructive arbitration, and how does carrier detect work.

I am using Kenwood radios with a data port connected to EF Johnson RF modems that convert ASCII to FSK data, and the controller is from Opto22.

I am working on getting all the controllers to recognize when there is data in the receive buffer, analyze it to see if it is noise or identifiable data, assume that another station may be transmitting and waiting for an ACK
from the central controller, and then wait an random amount of time before transmitting ( at least long enough to accomodate the maximum number of retries another controller might need to get its message through ). I could even program to detect when the ACK was received and determine if it was ok to transmit.

Anyway, I'll get back to work now

Fred Chwalek
 
In the situation that you describe, you need to have equipment that will support an "RF Carrier Sense" to avoid collisions plus, if a collision
occurs, have a "random" retry period so everyone can get their messages out. contact [email protected] (or nbtinc.com) for this type of equipment.
 
R
Normal solution to this is Carrier Detection, but that does not exclude.....

> 2. Transmission may not be successful and a transmission retry may be necessary.
>

Which requires non destructive arbitration. If you are using OOK modulation, you could use CAN interfaces, with higher quality FSK or FFSK modulation some sort of token passing or scheduling may be approapriate.

I have recently developed a simple protocol that satifies your requirements, and is also designed to be easy to implement of the serial port of a non RTOS system (i.e. connecting remote modules to a PC).

I wrote this because I could not find any protocol that satisfied my requirements, and intend to publish it, but it needs more meat and documentation yet. If you are prepared to wait.............
 
R

Robert Phillips

At 03:26 PM 4/27/00 -0400, you wrote:
>You can shorten the time between no action polls, but obviously, the
>most secure way is to transmit (but with a definite limit to tries)
>until the Central replys with an acknowledgement. However, if there is a
>too much traffic for your response needs, you need to increase bandwidth
>availability with more channels/frequencies or possibly just higher bit
>rate to shorten transmission time.
>
>Looking at the receive buffer at an RTU is not very useful because the
>RTU's ususally use directional antennas pointed towards the Central and
>results in your RTU missing other RTU transmissions. Noise often shows
>up in the buffer too.

On the Zetron RTU's we use, each has setting for:
a. Channel use limit
1. number of exceptions per X minutes
2. Y minutes to disable exceptions if 1. exceeded
Host can still poll as according to poll rate.

Robert Phillips
City of Wichita Falls, Tx
Cypress Water Purification
 
F

Fred Chwalek

Via programming I only have access to RTS and CTS, and the status of the receive buffer. I don't think I can (or don't know how to) use Carrier Detection in this scenario. The program is turning into "spaghetti" as I try to take all possibilities into consideration. I know that this system will work great if I were just using polling as the method of gathering data, but the customer doesn't want regular polling because they are using the same repeater/duplex system for other purposes and too much radio traffic may adversely affect the other system. I am not sure your protocol is what I am looking for but it sounds good and I am not prepared to wait .......
So.....
 
D

Dave Gunderson

I'm going to toss my hat into the ring... I have not been placing too close of attention to this thread and may cover some territory that may have
already been covered - but will make some comments anyway...

I am making the assumption that you are going Bell 202 at 1200 baud and piggybacking on a standard [non telemetry radio] . I also assume that the 'end' radios are run squelched [closed].

Your client wants the telemetry system to be passive [non polling] on the shared comm system through a hilltop repeater - data to be passed on a 'report by exception' basis from the field units.

I maintained a system like this eight years ago - abandoned & upgraded same system four years ago.

You were wondering how to do it...

How many signals are supported on the RS-232 ? Is it dumb [3 wire] -or- do you have DSR/DTR support? If it is dumb [3 wire] , you will have to use an interface to develop the RTS signal for you [this will control keying the local transmitter for outbound data] . B&B Electronics makes them for $120 a pop. Goes between the RTU and the MODEM. If you have DSR/DTR support at BOTH ends of the link - it makes the job a lot easier.

In a nutshell:

1.What I did was to build a working mock-up in the shop to workout the details. The initial interface between units was -

RTU>-----<bell 202 Modem>---4 wire interface---<bell 202 Modem>---<PC

Test the protocol , send messages , etc to see if it works WITHOUT THE Signaling Lines.

2. Once the Software and MODEMS are checked - add the signaling Lines. DSR/DTR will simulate the E & M signaling that you have with Comm circuits.
Start at the RS-232 level - It can get tricky as some vendor's equipment may use a '*non standard' signal [like CD - to activate the port].

PC MODEM MODEM
RTU
----------------------------------------------------------------------------
1<-----*CD-------<8<carrier det<
2>-----TxD-------->3>-------------------------->2>-------------->RxD
3<-----RxD--------<2<--------------------------<3<--------------<TxD
4>-----DTR-------->20>key Tx >>>>carrier det>8>-------------->DSR
5>-----GND-------<7>
<7>--------------<GND
6<-----*DCE------<8<carrier det<<<<<key Tx<20<-------------->DTR
7>-\
8<-/
9-nc

3. Once you have found the correct handshaking for your system - re run your data tests using Radios on a SIMPLEX Frequency bypassing the Repeater [and the potential problems there]. See that the Radio keys up on TX , and the Carrier Detect Signal CD becomes ACTIVE when the RECEIVE RADIO becomes un-squelched.

4. Assuming that the Audio signals are matched for impedance and levels between the MODEM and the Radio, Data testing can begin . At this time you find out if you need to use pre-emphasis/de-emphasis network-OR- flat audio for your MODEMs to operate. The Audio used by the MODEMS shifts at 1200 to 2200 Hz . The audio 'gain' on most radios is non-linear for these frequencies.
Depends on the Radio -- some work just fine [I've had good luck with Motorola but so-so results with EF Johnson].

5. Once you get the details 'worked out' on a simplex frequency test and the Radios pass Data -- try it out on the Repeater... Chances are that you will have to do some tweaking on the audio levels here too. Second consideration is how the 'squelch tail' will process as your Data terminates.

6. Problems with repeaters. Timing considerations can be a problem too. Another 'workaround' is the use of PL Tones to Key and un-key the repeater.

7. Problems with the Radios. You MUST provide a Transmitter Timeout circuit in the event of a 'stuck mike' . One problem unit causes the entire net to go down .

Considerations:

How long will this co-op system be in existence? Does the customer know about long term supportability in a system like this? For the time and effort supporting a shared analog radio system , your client will not save a great deal of money in the long run. Why? Assuming that the MODEM is the only equipment outlay -- Let's say $200 per modem . Radio conversion should take about 3 hours each . Repeater adjustments -- about 4 hours . A hybrid system like this requires a maintenance man or shop support that is capable of troubleshooting Data problems . In simple terms -- Bob from the local radio shop may not be able to fix your problems .

Now, on to Software --

I believe that in an earlier message you stated that you lacked a method of making sure that your input buffer contained 'fresh' information ?

If this is the case and you have software access to modify the contents of the input buffer, you can flush out the buffer after you have read data from it. The procedure --

1. Read the buffer.
2. Write a 'flag' word to the buffer. Make the flag word a value that you will NEVER see as actual data [9999999.00] .
3. create a Loop condition that reads the input buffer. New Data is a value not equal to the flag.
4. Upon detection of valid data -- save the data and go back to step 2.

This procedure should work if the radio's open squelch does not generate random trash in the input buffer.

Regards from the Desert Southwest --
Dave Gunderson
Hoover Dam Comm & Control Group
Website: http://www.futureone
 
A

Al Pawlowski, PE

Excellent post Dave. Best short explanation of typical telemetry radio problems/working I think I have ever seen. Could you follow up with a
little more detail on the repeater timing and squelch/data tailoff aspects?
 
D

Dave Gunderson

Thanks for the kind words Al,

When I wrote the original post I forgot to mention that passing data through an RF Link had subtle differences as compared with a hard wired -or- typical MODEM setup. The RTU should have some designation for how its Com port is to be configured. If the Firmware on the RTU is in-flexible in this regard - talking to a radio is difficult [unless the B&B Electronics solution is
used]

What's the rub here? Timing and Synchronization

Hardware wise - serial communications begins and ends through a UART. On a direct wire connection - there is no delay problem . After the Receive UART gets the Start Bit -- it has recovered enough information to sync with the other end .

Going MODEM to MODEM is a little more complex as another layer is added. More overhead is needed to sync the end to end connections.

Going RF is worse . The timing here is --
1. Key Transmitter . Wait a short time to allow the Transmitter and Receiver to settle .
What Happens:
TX: A Bell 202 MODEM should send out a 1200 Hz tone when RTS is raised. The Transmitter Keys. RX: On the other end -- The Radio un-squelches , the MODEM synchronises , CD then becomes Active on the MODEM . The CD signal is used to wake-up the local Com Port.

2. Send Data .
What Happens:
Tones on TX end shift between 1200 Hz to 2200 Hz . Since the 1200 Hz tone synchronized the RX end MODEM earlier -- no data is lost in the transmission.

3.Un-Key Transmitter .

Here is where it can become nasty....Repeaters usually remained Keyed for several seconds (to retain communications continuity for PEOPLE) . If the transmission has any 'white noise' in it , the MODEM accepts it as 'garbage data' . In addition , the local Radio goes from un-squelch to squelch . The transition can also add more garbage .

Enter -- PL Tones.

To eliminate the 'delay time' by the repeater and the squelch tail , a PL Tone is used. For those of you who know something about Radio Communications and Repeaters , PL [Private Line] Tones are 'sub audible' that can be piggybacked with the normal audio. The Tone is generated at the Transmitter -- Decoded at the Receiver end . In normal practice, it is a means of keeping unauthorized users off the repeater. In our usage -- dropping the PL Tone is used to mark the END of the transmission . When the Transmitter stops , the data transmission also stops - if the PL Tone is used is used at the receiving Radio .

In closing . I wanted to impress upon this engineer , that marrying a Telemetry System to a working repeater system can be done , but is not the best solution today , in my eyes .

Regards from the Desert Southwest --
Dave Gunderson Hoover Dam Comm & Control Group
Website: http://www.futureone.com/~davegun
 
F
Dave,
Thank you so much for the detailed explanation. I started this discussion because I wanted to see if what I have been doing is standard procedure, or something I have just made up and nobody else would ever do it this way.

I have a system running, going on four years now, with 25 RTU's and RF modems, repeater, and a main RTU polling the remote sites on a regular basis. This was a new install, dedicated to this purpose. Through much trial and error and endless hours of onsite testing, I have discovered
all of the timing and synchronization issues you have mentioned. I just didn't know how to explain them in any kind of technical terms since I am not a radio man. I made the system work, but if someone asked me why I did it this way or that, all I could say was " because that is how it
works."

Now I have been asked to replace an existing system in stages with a new RTU system. The customer and his radio man asked if I could make this work, and I said yes, but I have had my misgivings about the project. I agree it is not the best solution today, but I guess sometimes you have to work with what is there.

Again, thanks very much for your detailed explanations. It has been very difficult if not impossible to find someone who understands all the
intricacies of this type of radio system, and can help me explain them to the radio man and customer.

Have a good day.
Fred Chwalek Inotek Technologies Corp.
 
E

Eduardo F. Cardoso

Hi, I am a student of engineer and a trainee, i am needing your help. If you know or if you know who can teach me how is the IEC 870-5-101 protocol with RTU. thank you. Bye, Eduardo.
 
Top