Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Wireless Project

Status
Not open for further replies.
Nigel i just made this code... its for transmitter only... does it look ok?
Code:
/* *****************************************************************************
;                                                                             *
;    Filename:                     				                              *
;    Date:                                         	                          *
;    File Version: 001                                                        *
;                                                                             *
;    Author:   Jason Lopez                                                    *
;    Company:  AtomSoft                                                       *
;                                                                             *
;***************************************************************************** */

#include <p18f2525.h>
#include <delays.h>
#include <string.h>

#pragma config WDT = OFF, LVP = OFF, OSC = HSPLL

/************************************
Prototypes
*************************************/
void main(void);
/*
void SendUART(unsigned char data);
void init_uart(void);
*/
void delay_ms(int count);
void SendByte(unsigned char data);
void SendZero(void);
void SendOne(void);

#define BTN1 PORTBbits.RB1
#define BTN2 PORTBbits.RB2
#define LED  LATCbits.LATC3
#define TX   LATCbits.LATC6
#define ADDRESS  0
#define DATA     1
#define CHECKSUM 2
unsigned char PACKET[3];

void main(void){

	ADCON1 = 0x0F;
	TRISB = 0b00000110;
	TRISC = 0b10000000;
    //init_uart();

	PACKET[ADDRESS] = 0xAA;
	PACKET[CHECKSUM] = 0xAA;
	while(1){
		if(BTN1){
			LED = 1;
			delay_ms((int)500);
			while(BTN1);
			SendByte('J');
			LED = 0;
		}
		if(BTN2){
			LED = 1;
			delay_ms((int)500);
			while(BTN2);
			SendByte('a');
			LED = 0;
		}
	}
}
void SendByte(unsigned char data){
	volatile unsigned char x;
	volatile unsigned char ADDT;
	volatile unsigned char CHKT;

	PACKET[DATA] = data;
	ADDT = PACKET[ADDRESS];
	CHKT = PACKET[CHECKSUM];

	//SEND HEADER
	TX = 0;
	for(x=0;x<20;x++){
		SendOne();
	}
	SendZero();

	//SEND ADDRESS
	for(x=0;x<8;x++){
		if(ADDT & 0x80){
			SendOne();
		} else {
			SendZero();
		}
		ADDT <<= 1;
	}
	SendOne();
	SendZero();

	//SEND DATA
	for(x=0;x<8;x++){
		if(data & 0x80){
			SendOne();
		} else {
			SendZero();
		}
		data <<= 1;
	}
	SendOne();
	SendZero();

	//SEND CHECKSUM
	for(x=0;x<8;x++){
		if(CHKT & 0x80){
			SendOne();
		} else {
			SendZero();
		}
		CHKT <<= 1;
	}
	SendOne();
	SendZero();
}
void SendOne(void){
	TX = 0;
	Delay100TCYx(10);
	Delay10TCYx(4);
	TX = 1;
	Delay100TCYx(10);
	Delay10TCYx(4);
}
void SendZero(void){
	TX = 0;
	Delay100TCYx(10);
	Delay10TCYx(4);
	TX = 1;
	Delay100TCYx(10);
	Delay10TCYx(4);
}
void delay_ms(int count){
	int x;
	for(x=0;x<count;x++){
		Delay100TCYx(99);
	}
}

Each bit should take 208uS to transmit which should make it 4800bps... i have it set to 104uS for between... like when sending a 1... which is a Low to High :

1. Set TX LOW
2. Wait 104uS
3. Set TX HIGH
3. Wait 104uS

Is this ok?
 
Last edited:
wow i cant even wrap my head around the receive code heh... must be the headache i have.. or maybe it gave me a headache.. who knows... :) break time... any thoughts would be nice
 
wow i cant even wrap my head around the receive code heh... must be the headache i have.. or maybe it gave me a headache.. who knows... :) break time... any thoughts would be nice

Transmitting Manchester is trivial - receiving it is VERY difficult - I don't understand it either, I took the routines from the site credited, and incorporated them in the tutorial.
 
He he hee perfect. Now I don't want to do trial and error. I bought my modules from local market months back. I just saw it and bought it. :D Didn't even touch it ever since. :D

Now I can play around with your hard work. He hehe Thanks atom.

**broken link removed**
 
Last edited:
Hey AtomSoft. I just picked up some RFM12 (not the B, but they are basically the same). I'd recommend them, $5 for a transceiver so it can send and receive if you write sensible software. It does encoding too using basic frequency hopping, so theoretically you can run a few different "networks" in similar frequency bands.

Not that I'm trying to put you off looking at the Manchester encoding but it is hard. Microchip have a fantastic document with further details, look for application note TB045. But basically, you need to run a proper state machine on the receiver in order to conduct tasks such as clock recovery. Manchester encoding done properly is not simply encoding each bit to 01 or 10, though of course it is important to remove DC bias.

I really recommend using a chip that does the encoding for you. This frees up time on the PIC and means you can do useful other things than looping forever waiting for the pre-amble.

As a shameless plug, I just designed a breakout for the RFM12 (it uses 2mm pin spacing, not suitable for a breadboard). Let me know if you'd like some, I'm going to order them from BatchPCB soon. Cost price, I'm not looking to profit! There are some 2mm headers available at Farnell that I plan on using so I can prototype using the modules at low cost.

The image below is the best I can get at during the day, can provide a better one from Eagle later.

**broken link removed**
 
Futurlec carry the modules, though they are replicated by a whole bunch of people worldwide. I chose the pin header ones as they are reusable, rather than the SMD parts. Make sure you get the transceiver model!

I think BatchPCB wanted $2.50 for the board (their minimum price). I can send you the files for upload if you want to order direct, that will be cheaper than paying postage from UK to USA. You'll have to pay $10 handling though. Let me know via. PM if you want the files, I trust you :p
 
I might get a couple of these ... (attached image)
 

Attachments

  • nowire.jpg
    nowire.jpg
    204.5 KB · Views: 240
I might get a couple of these ... (attached image)

Pretty sure that's what I bought. I chose the RFM12 not 12B due to the wider operating voltages (2.2v-5v rather than 3.6v). There is tonnes of code out there, once I've got the low level stuff working I plan on writing a simple point-to-point API with simple addressing, packet acknowledge and CRC.
 
I really recommend using a chip that does the encoding for you. This frees up time on the PIC and means you can do useful other things than looping forever waiting for the pre-amble.

The RFM12 does not do any encoding on it's own. You need to move up to the RFM22 if you want encoding done on the module. If you are using the RFM12, you should still be implementing encoding in your data transfers.

2 byte -> 3 byte encoding is much easier than Manchester and there are plenty of examples out there for it. I got my original code from a Radiotronix sample program for the PIC.
**broken link removed**
 
Whilst the RFM does not do data "encoding" the in-build modulation using FSK does a lot of work for you. This is much better and less prone to interference than the simple TX/RX modules. Clocking and other necessary (but less interesting!) tasks are also done for you.

Most of the code implementations I have seen do something sensible like send a few bytes of 0b01010101 before the syncronisation byte, which should ensure a steady state in the receiver.

So yes, the modules which simply interface to UART with a huge buffer and provide encoding/modulation/etc are better. But the RFM12 modules are very suitable too.
 
Whilst the RFM does not do data "encoding" the in-build modulation using FSK does a lot of work for you. This is much better and less prone to interference than the simple TX/RX modules. Clocking and other necessary (but less interesting!) tasks are also done for you.

Most of the code implementations I have seen do something sensible like send a few bytes of 0b01010101 before the syncronisation byte, which should ensure a steady state in the receiver.

So yes, the modules which simply interface to UART with a huge buffer and provide encoding/modulation/etc are better. But the RFM12 modules are very suitable too.

I'm not certain what this response is too. People seem to read much more into my messages than is actually typed. Did you see the first page of this thread? I use RFM12B's and have written a P2P protocol for it.

Your line that I quoted suggests that the RFM12 does encoding, it's doesn't. I'm not saying anything else, nor did I bring up UART->RF modules. If you are writing a P2P protocol, with any decent packet size, use DC balance encoding still, a preamble is not sufficient for a proper/robust protocol for these devices.
 
Last edited:
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top