Using Linx RF modules ?

[Sam]

I've searched but haven't found the answer. I have Linx TX and Linx RX modules from Rentron as seen HERE and HERE.

My question (problem) is that I can send to and from a 12F675 through Hyperterminal just fine. But when I connect the output of the PIC to the DATA in on the TX module and I connect the DATA out from the RX module to the serial in line going to Hyperterminal, all I am getting from the receiver is garbled characters, mostly boxes almost non-stop showing in Hyperterminal.

I do notice different characters when the PIC and Linx are actually transmitting and the TX is definitely working as I have a field strength meter next to it. I am using N2400.

So to sum it up, how do I get the receiver to receive the DATA and display in Hyperterminal ?

Thanks for any guidance with this !

Sam

[mackrackit]

Can we see you code so we can tell you where the problem is?
Did you code for the data slicer?

http://www.picbasic.co.uk/forum/showthread.php?t=11589

In the meantime look at the tips and tricks section here.
http://davehouston.net/

[Archangel]

I do notice different characters when the PIC and Linx are actually transmitting and the TX is definitely working as I have a field strength meter next to it. I am using N2400.

Did you try T2400 ?

[Sam]

Can we see you code so we can tell you where the problem is?
Did you code for the data slicer?

http://www.picbasic.co.uk/forum/showthread.php?t=11589

In the meantime look at the tips and tricks section here.
http://davehouston.net/

I will post the code, it's on another laptop I'll fire back up in a little while and post from there. Not much code to it though, just a simple routine to test and be a starting point to learn.

Did I code for the data slicer ? Uh, no, I've made data slicers before from TL 085 op amps before but I don't know about coding for them. I did notice in the data sheet that the RX module has a slicer.

Thanks for the links, not to get OT but I really like your site and bookmarked it ! I packed my last home with X10 stuff, touchscreens controlling TV's and whole house audio through a Smartlinc controller with IR ports, the Smart rocker switches with the vertical row of green LED's, and on and on. I miss that setup, I just have some basic X10 control here now, I still have the controller though.

One more OT thing I thought you might be interested in, I also have the X10 remote pan and tilt modules and the range on the handheld remotes were awful, I added a variable cap in series with a telescoping antenna installed in the remote and the range more than quadrupled and they look factory. They were almost totally useless to me before I added the antennas.

I'll go back to reading your links on this topic though and post back later.THANKS again.

Hi Joe, I think I did try T2400 and still garbled, I'll check it again. BTW: your tachometer program is working great for me, only problem is once you go over ~1000 RPM I have to divide the readout by half but that's not a problem since I don't need to run the machine over 1000 RPM anyway. I checked it with a handheld laser tach.

Man, I keep getting off my own topic here,

Thanks guys, later.

[Sam]

Okay, I did have some success. I had both modules on the same breadboard, I moved the TX module to it's own breadboard and instantly started receiving text properly on the RX module and feeding the data out of the RX into hyperterminal.

This was without an antenna on the RX module, with the antenna I'm getting all sorts of characters which must be "static" of course. So I guess that I need to have a PIC connected to the data out of the RX and programmed to only respond to the string my TX is sending right ?

Such as: Serin DATAIN_pin,N2400,["THIS IS A TEST"] ???

Here's my extremely simple "code" ...

'****************************************************************
'*  Name    : UNTITLED.BAS                                      *
'*  Author  : [select VIEW...EDITOR OPTIONS]                    *
'*  Notice  : Copyright (c) 2009 [select VIEW...EDITOR OPTIONS] *
'*          : All Rights Reserved                               *
'*  Date    : 8/16/2009                                         *
'*  Version : 1.0                                               *
'*  Notes   :                                                   *
'*          :                                                   *
'****************************************************************
'12F675
_CONFIG
@ DEVICE PIC12F675, XT_OSC 
_NOCLKOUT  
_WDT_ON 
_PWRTE_ON
_MCLRE_OFF
_BODEN_ON
DEFINE OSC 4
INCLUDE "modedefs.bas"
TX_Pin VAR GPIO.1    'To DB9 TX pin 3
RX_Pin VAR GPIO.0    'To DB9 RX pin 2

TRISIO.0 = 1         'Set GPIO.0 to input.
TRISIO.1 = 0         'Set GPIO.1 to output     

ANSEL = 0            'disable ADCs
CMCON = 7            'disable comparator


Tx_Pin = 0           'inverted mode idle state


Pause 100            'OSC settle time... 

loop:
    IF GPIO.2=1 THEN
	SerOut tx_pin,N2400,["THIS IS A TEST",13,10]
	Pause 500
	ELSE 
    GOTO LOOP
	ENDIF
    Pause 500
    GoTo loop

[dhouston]

with the antenna I'm getting all sorts of characters which must be "static" of course. So I guess that I need to have a PIC connected to the data out of the RX and programmed to only respond to the string my TX is sending right ?

Here's a picture to illustrate the problem.

The data out line of a receiver (i.e. output of the data-slicer) is shown in the bottom trace - the analog input to the data-slicer is shown in the top trace. All of the RS232 methods (HserIn, HserIn2, SerIn, SerIn2) wait for a start bit and then sample at the midpoint of each bit period. They will interpret the random noise on the left as data bytes - the output will be a series of random bytes.

From the datasheet for your receiver

• The receiver’s output may appear to switch randomly in the absence of a transmitter. This is a result of the receiver sensitivity being below the noise floor of the board. This noise can be handled in software by implementing a noise-tolerant protocol...

What is the data you want to send? How long are the messages?

[dhouston]

I also have the X10 remote pan and tilt modules and the range on the handheld remotes were awful, I added a variable cap in series with a telescoping antenna installed in the remote and the range more than quadrupled and they look factory. They were almost totally useless to me before I added the antennas.

The FCC frowns on that. You should not alter the antenna (or anything else) on a transmitter. You can usually achieve the same result by improving the receiver antenna or by adding a wideband preamp between the antenna and receiver. This will improve range without interfering with any hams in the neighborhood.

[Sam]

What is the data you want to send? How long are the messages?

My first thought was as follows, a PIC and TX module located at a CNC machine,
when the machine moves to specified locations a button closure would activate the PIC/TX to send a short message such as "Change Tool". And other sensors could initiate messages such as "motor stopped" or "coolant flow", ETC.,ETC. and this would be received and the message displayed on an LCD through a PIC on the receiver end.


Or, maybe the better way is to have the PIC/TX send a single character such "a" 5 times or so for one button and another like "b" to the RX/PIC and the RX PIC will generate the appropriate sentence to be displayed on the LCD.

So to answer your question, just short messages or single characters representing different button closures.

[dhouston]

...PIC and TX module located at a CNC machine...

Then, at minimum, you will need error detection. How radio-noisy is the environment? What's the distance between transmitter and receiver? Will this be the only CNC transmitter or are there multiple CNC machines where you might deploy this?

The shorter the message, the better.

I would use something like the NEC protocol for which I have an example on the page mackrackit referenced earlier. I would send each packet 3-5 times with a 10-20mS interval between them, discarding duplicates and any with errors received. This method allows you to handle other tasks within the main loop.

If you want to do it purely with RS232, use $FF,$FF,$FF,$FF,$00,$00,$55 as a preamble and have the receiver's PIC WAIT for the $55. The data (but not the preamble) should be manchester encoded. I would also send these packets 3 or more times with the above interval. With this method you will need to use a timeout if you need to handle other tasks. All in all, I consider it problematic for this application.

If range is not an issue, you might want to consider using the squelch circuit shown in Figure 11 of the Linx datasheet for the receiver. This would eliminate most of the noise (i.e. static) and simplify reception.

However, the best way to do this would be with an FSK transmitter and an FSK receiver with a Carrier Detect output.

Out of curiosity, what type of operation? I spent several years in the machine tool industry and most CNC controls either displayed or had serial outputs for this type of data.

[Sam]

There's allot more to this than I realized and while I love to learn new things, especially PICs and all electronics I think maybe I should go with encoder/decoder chips like THESE and then do the PIC LCD from that.

What do you think about going that route ?

Range only needs to be 50 to 70 feet at most.

And it's your site I bookmarked, sorry about that, very interesting site !

Regarding your question about my CNC setup, it's mostly a hobby setup. I converted a Seig milling machine to CNC and I use Mach3 to control it. I do think there are more outputs from Mach3 I can use but buttons and sensors will suit me fine for now. I do have output functions setup with it to turn the motor and the flood coolant pump on and off per the G-code via an optically isolated relay board I made for it.

Below is a picture of a pendant I made to do the basic functions of the CNC mill so I almost never have to touch the keyboard and a picture of the drivers and power supply in a PC tower case. The perfboard seen is a 12F675 that toggles the power on off via the OEM momentary push button on the front of the case. This picture was taken before I installed the dual optoisolated relay board in the case, also added a second large fan.

Thanks for your help

[dhouston]

...I think maybe I should go with encoder/decoder chips like THESE and then do the PIC LCD from that.

I think the Holtek chips are too limiting. However, Bruce Reynolds has posted some code here for receiving/decoding some Holtek codes.

I'm not familiar with the Mach3 package (and it's been about 25 years since I worked in the industry) but a quick scan of the introduction to its manual indicates it can handle most of what you want. I would study that before choosing a course.

It also seems you want a remote wireless readout so it may be that you will need to add to the built-in functions. The range you need is not a problem with a good antenna unless there are intervening walls. Most range estimates are line-of-sight and you need to figure about 20% of that for indoor use.

My preference is still for FSK transmitter/receiver (with Carrier Detect). Carrier detect with the FM signal along with manchester encoding makes for a very robust system and most FSK TX/RX pairs cost less than the AM modules you've chosen.

I would not do this with a PIC but would use one of the ZBasic chips - probably one of the native versions as it's very easy to create interrupt routines. The ZX328n costs $10, has a free compiler, and includes a serial downloader so you can reprogram it at will. Even if you decide on a PIC, ZBasic is great for developing things quickly which you can then rewrite in PBP.

[Sam]

In what way do you feel the Holtek chips are too limiting ?

Regarding Mach3, I would have to add another parallel port card to get anymore outputs than what I have and are using now and I don't want to go that route at this point even though they are cheap.

Why wouldn't THIS with the companion receiver (just as an example), from Rentron not work for me ?

I mean if this remote can turn LEDs at the receiver on and off why couldn't it activate a PIC programmed with the correct messages and send these corresponding messages to the LCD ?

I'll look into the FSK modules also, I may already have them ???

[dhouston]

I haven't kept up with the hardware so my views may be out of date - Bruce can correct me where necessary The Holtek (and clone) decoder chips have a fixed number of data lines (4 or 8) so you have a limited number of possible codes. These may be adequate for what you want to do - I just prefer more flexibility. Doing your own protocol allows more control. Now, if you want to skip the chips and just use Holtek's encoding scheme, you can have billions of codes.

The device you linked to may well work. I just think utilizing it represents more work than doing it from scratch. Of course, I'm biased as I've done it from scratch many, many times. Once you do it from scratch, you may come to share my bias.

Also, when you wrote CNC, I thought CONTROL which is why I emphasized error detection. But, if you are merely reporting status, error detection may be less of a priority.

[Sam]

Right, status reporting is all I'm wanting to achieve with this. I do prefer to do it from scratch, I just referenced that transmitter as an example. 8 lines will be more than enough for me, 4 will will actually do just fine.

So let's say I have the Linx TX unit and I only want it to report one single button closure on the machine to the receiver 30 feet away through one wall, and I'd like to keep it as simple as possible until I start to get a hold on this as I learn pretty fast once I get one basic thing working and can experiment from there. To keep it simple, lets forget about the LCD and just light an LED for now.

How would you recommend I do this ?

Much thanks.

[dhouston]

I would use the transmitter & receiver code shown in the first two sections at

• http://davehouston.org/PIC-RX-TX.TXT

It uses the same protocol that X-10 has used successfully for 30 years. It can handle up to 256² codes and has built-in error detection.

[Sam]

That looks great, I will study it (more) and give it a try.

Thanks for all your help Dave !

Sam

[Sam]

Dave,

I've loaded your TX code into one 12F675 and connected to the Linx TX and it is transmitting data. ( I changed the interval from 15 seconds to 1.5 seconds)

I then loaded your RX code as seen below into another 12F675 and I'm not getting anything out of GPIO.2. I connected a LED to the data out of the receiver and it does flash in sync with the TX data going out.

I connect GPIO.2 of the RX PIC to Hyperterminal set at 8N1, 9600 and get nothing at all and I connected an LED to GPIO.2 and nothing there either.

Shouldn't I be getting something on the RX PIC ?

'==============================RECEIVER============================	
'-----PIC12F675-----
'USE PIC12F675 if you need to measure linear output (e.g. to tune) 
'Receives 32 bits of NEC protocol RF with initial lead-in of 8.8mS
'outputs received codes via RS232 @ 9600bps on GPIO.2

'12F675
_CONFIG
@ DEVICE PIC12F675
_NOCLKOUT  
_WDT_ON 
_PWRTE_ON
_MCLRE_OFF
_BODEN_ON
DEFINE OSC 4
INCLUDE "modedefs.bas"

DEFINE PULSIN_MAX 968				'>968 RETURNS 0
DEFINE DEBUG_REG GPIO
DEFINE DEBUG_BIT 2 				'GPIO.2
DEFINE DEBUG_MODE 1 				'Inverted
DEFINE DEBUG_BAUD 9600
DEFINE OSCCAL_1K 1

RF      VAR     byte[4]
space   VAR     byte
i       VAR     byte     
bits	VAR	byte  	         	
stx  	VAR     word            		'start of transmission

        CMCON = 7                       	'comparators off

init:	RF[0]=0:RF[1]=0:RF[2]=0:RF[3]=0
	bits=0:i=0
	PulsIn GPIO.1, 1, stx			
	If (stx<792) Then init                   
        While GPIO.1=0:Wend			'wait pulse
        'use SerIn here instead of Repeat loop & $FF tests
        Repeat
          PulsIn GPIO.1, 0, space
          If (space<40) Or (space>175) Then init
          If (space>75) Then
            RF.0(i)=1				'set bit
          EndIf
          i=i+1 
        Until (i>31)
	If RF[0]+RF[1]<>$FF Then init
	If RF[2]+RF[3]<>$FF Then init        
        For i = 0 to 3
  	  Debug (RF[i] REV 8)
        Next           
        GoTo init

        End

[dhouston]

Give me a day or two to finish something else and dig out my PIC hardware and I'll try to run this down.

[dhouston]

I apologize for the delay. I have a spinal cord injury which incapacitates me when it acts up and it's been acting up for several days. What follows is revised slightly from the earlier code. I have not tested this with a terminal program (right now I'm working with Linux and do not have a terminal program handy) but I have looked at the GPIO.2 output with a 'scope and it appears to be a valid RS232 signal. Here's the transmit code:

'-----PIC12F629-----
' Sends 2 bytes + their bitwise complements using the NEC protocol
' repeats every 15 seconds
                     
@ __config _INTRC_OSC_NOCLKOUT & _WDT_OFF & _MCLRE_OFF & _CP_OFF
 
DEFINE OSCCAL_1K 1
 
RF 	VAR	byte[4]
Copies 	VAR	byte			'RF copies 
c	VAR	byte			'loop index (RF copies)
b	VAR	byte			'loop index (RF[b])
i	VAR	byte			'bit index
wb	VAR	byte                    'work byte

        CMCON = 7	
        Copies = 4       
        'Put data in RF[0] & RF[2] & complement in RF[1] & RF[3] 
SendRF:	RF[0]=80:RF[1]=~RF[0]:RF[2]=66:RF[3]=~RF[2]
	Low GPIO.2
	For c=1 To Copies
	  PulsOut GPIO.2, 880           '8.8mS pulse
          PauseUs 4400                  '4.4mS space
	  For b=0 To 3
            wb=RF[b]
	    For i=0 To 7                'LSB first
	      PulsOut GPIO.2, 50        '0.5mS pulse
	      If wb.0=1 Then
	        PauseUs 1500            '1.5mS space 
	      Else
		PauseUs 500             '0.5mS space
	      EndIf 
	      wb=wb>>1
	    Next
	  Next
	  PulsOut GPIO.2, 50            '0.5mS pulse
	  Pause 40:                     '40mS GAP
	Next
	Pause 15000                     '15 SEC DELAY
	GoTo SendRF
	
        End

and here is the receiver code:

'12F629

@ __config _INTRC_OSC_NOCLKOUT & _WDT_OFF & _MCLRE_OFF & _CP_OFF

DEFINE PULSIN_MAX 968				'>968 RETURNS 0
DEFINE DEBUG_REG GPIO
DEFINE DEBUG_BIT 2				'GPIO.2
DEFINE DEBUG_MODE 1 				'Inverted
DEFINE DEBUG_BAUD 9600
DEFINE OSCCAL_1K 1

RF      VAR     byte[4]
space   VAR     byte
i       VAR     byte	         	
stx     VAR     word            	'start of transmission

        CMCON = 7                   'comparators off
        Debug "RF NEC PROTOCOL"
init:   RF[0]=0:RF[1]=0:RF[2]=0:RF[3]=0:i=0
        PulsIn GPIO.1, 1, stx	
        If (stx<792) Then init  		
        'debug #stx                 
        While GPIO.1=0:Wend			'wait pulse
        Repeat
          PulsIn GPIO.1, 0, space
          If ((space<40) Or (space>180)) Then init
          If (space>75) Then
            RF.0(i)=1				'set bit
          EndIf
          i=i+1 
        Until (i>31)
        If (RF[0]+RF[1]<$FF) Then init		'corrupt
        If (RF[2]+RF[3]<$FF) Then init		'corrupt
        RF[1]=RF[0] REV 8
        RF[3]=RF[2] REV 8
        Debug RF[1],32,RF[3]
        GoTo init

        End

[Sam]

Hi Dave,

I'm sorry to hear about your spinal chord injury ! I know a little about that personally also, unfortunately.

Thanks for posting the code re-done, in the meantime I went ahead and ordered some encode/decode chips from Rentron and they work excellent. I am extremely impressed by the range and reliability of this combination of Linx modules and these chips.

I did get a machine "status system" set up with the TX/encoder mounted in a small project box with a real whip antenna mounted on the top of my milling machine. When a section of the machine moves to a specific location, a button is pressed and that activates a 12F675 that turns on the TX and it transmits for .5 sec. then turns off for .3 sec., it does this 15 times with a "for/next" routine then goes to sleep until next time.

The receiver is in a very small project box that resembles a pager with the option of either a beep or flashing an LED. This tells me when the machine is ready for a tool change.

I'll give your new code a try soon, I want to have more status reports for other components of the machine sent to a receiver with an LCD display.

Thanks for the help and hope you're doing well now.

[dhouston]

Sam,

I've added a more generic RF Receiver example to the Code Examples forum.