Here’s a quick post for you home automatuers. Screw protocol stacks with their complex encryption, hand-shaking, UID long addresses, IP addresses, MAC addresses, complex Moore state-machines, SYN-ACK-NACK-Crap! What you want is unadulterated, untampered, raw speeds deep into the hundreds, if not thousands of baud!(lawl) Your solution is here at only $5.95! That’s plenty enough !exclamation! for one sitting.
http://www.sparkfun.com/commerce/product_info.php?products_id=8945
This guy accepts TTL level RS232 and ships it out over the air at a blazing 4800 baud. All this board requires is 5v, GND, and TTL signal. No antenna. This board is only the transmitter.
http://www.sparkfun.com/commerce/product_info.php?products_id=8947
Next up, we have the receiver board with the same pin requirements except its signal pin pumps out whatever it finds on the 315Mhz spectrum that remotely resembles UART Asynchronous Serial.
Easy enough, now how do we talk to it? I can think of two ways. One of these ways also has three separate ways. Thatsa lotta ways!
1.) Attach the transmitter to a computer.
1a.) Using the Max232 chip to convert 12v RS232 to TTL RS232 you can talk directly to the transceiver. (Contact me for help)
1b.) Using the FTDI FT2232 chip, open up a USB-Serial bridge via free drivers from FTDI, and the output will be TTL RS232. (Don’t contact me for help)
1c.) Build a simple voltage divider or BJT switcher circuit to drive the 5v output.(Eh.)
2.) Implement your very own stack!
What you’ll need: A PIC (’cause Arduino’s are dumb, JK Joe), ICSP programmer, MPLAB, electronic essentials.
We are going to employ the power of the MCC18 libraries that come with MPLAB C18. Or you could use the HTC libs as I did below./*
This is the transmitter code, 2400 baud, RB3 input
*/
#include <htc.h>
#include <stdio.h>
#include “usart.h”
__CONFIG(INT & WDTDIS & PWRTDIS & BORDIS & LVPEN & UNPROTECT);
void putch(unsigned char byte) //place the function before main so you don’t need function prototypes!
{
while(!TXIF) //check for the TX buffer to be cleared flushed!
continue;
TXREG = byte; //shove the data into the buffer, and the PIC will automatically flush!
}
int main(void)
{
unsigned char TRNSval;
init_comms();
int x=0;
TRISB3=1; //set direction of trigger pinwhile(1)
{ if(RB3==1) //if the trigger is set, fire 100 O’s
{
for(x=0;x<100;x++) //do this 100 times because the fidelity of FM is low.
{putchar(‘O’);} }
if(RB3==0)
{
for(x=0;x<100;x++) //if the trigger is cleared, fire 100 F’s
{putchar(‘F’);} }
}
return 0; //make MPLAB happy!
}
This is the receiver code. because of infidelity of FM signal, a certain value of a particular signal must be received in succession to convince the receiving PIC that the message was fully intended
/*
This is the receiver code, 2400 baud, RB3 output on
50 sequential O’s causes ON condition on … etc.
*/
#include <htc.h>
#include <pic.h>
#include <stdio.h>
#include “usart.h”
__CONFIG(INT & WDTDIS & PWRTDIS & BORDIS & LVPEN & UNPROTECT);
#define Led1 RB3
unsigned char getch() {
/* retrieve one byte */
while(!RCIF) //check that the newest data is in the receive buffer
continue;
return RCREG;
}
void main(void)
{
unsigned char RCVed;
init_comms();
int CountOn=0;
int CountOff=0;
TRISB3=0;
Led1=0;
while(1)
{
RCVed=getch();
if (RCVed==’O')
{CountOn++;
if (CountOn==20) //if count reaches 20, perform the operation
{Led1=1;CountOn=0;CountOff=0;}}
if (RCVed==’F')
{CountOff++;
if (CountOff==20) //if count reaches 20, perform the operation
{Led1=0;CountOff=0;CountOn=0;}}
}
}
So there you have it. Your very own simple wireless switch. It’s very primative, and not to excuse my stack but I became rather bored with these devices and never really finished creating a stack that was more solidly coded. Any questions!? Ask away!
This has been an interest of mine for a while and I have researched and developed a few ways to achieve communication over the air. Here goes…
The MRF24J40 is a chip developed by Microchip that allows for 2.4Ghz communication over the air. The IEEE standard protocol for this device is 802.15.4 which means that the device is not licensed to be compatible with wireless communications using other protocols such as 802.11.x. The device has 4 available channels open for use. These channels associate to transceiver frequencies at which the device can communicate. We have the ability to hop onto these 4 channels via the RFCON0 register in increments of .005Ghz. Knowing this, and knowing the WiFi standard, it IS possible to hop onto a WiFi network with this device as both have common channels at 2.405Ghz, 2.410Ghz … although programming the protocol would be redonkulous.
So how do you use this thing?I’m glad you asked.
So there she is, in all her freaking particular complexity. I’ll tackle the easy part first. Programming.
This chip accepts all of its incoming information from the host controller via the SPI protocol. The SPI protocol is a 2 wire communications type that employs a clock and data line for one-way communications. For two-way communications an extra wire is needed. So, you say, “what the heck do you call CS(not)! That is another wire!” CS(not) is a signal used to herald across the SPI bus which chip is the intended receiving party of the SPI information. SPI is a little strange in that it is a broadcast bus that doesn’t natively allow addressing the receiver. What I mean to say is that, when using the SPI bus, you cannot simply send out the address of the chip you wish to speak with, and then speak, but rather you must signal the chip you which to speak with, and then speak. If you want a true 2-wire serial bus, look to I2C by Phillips. Long story short, tie CS(not) low with a 10k resistor so that you are always permitted to chat with the chip.
Looking at the datasheet, there are a good bunch of registers that need to be set in order to start communicating. This is how.
Now that you can write and read the short registers, we can set up the chip to start yapping at 2.4xxGhz. These are a few registers that need attention: RXMCR,TXNCON,SECCON0,INTCON,BBREG0…Run through the list of short registers and make your selections.
Now,I must back up and mention the few particular nature of RF communications. The chip and specific requirements in order to speak over 2.4xxGhz. I’ll just speak on what I am familiar with in the following schematic.
L5 and L4 are the inductive managers of the incoming and outgoing differential analogue signal. As we know, it is not possible to send digital information over the air because there is little to none differential in binary information. To solve this we employ a SINE wave whose differential is constantly changing. Electrons of porous material respond analogously to a consistent differential. So, L4 and L5 saturate current during the negative and positive cycles of communication. These inductor values must be calculatedly small in order to react quickly enough at 2.4xxGhz. I’m still a little confused about the tank circuit used to trap the resonant frequency but L1, C7, C23, and C38 contribute to a resonant tank circuit that supplies communications of 2.3215Ghz. Capacitors such as C45, C39, C10… are decoupling caps that ensure a consistent operating voltage.
Okay! I know all of this is uber confusing, but hopefully this helps as an introduction to the chip. This next order of business is to select a protocol stack. There are a few options: ZigBee, MiWi, or if you live in your mothers basement and enjoy D&D you could write your own communications protocol. Next post I will briefly describe the differences.
Click for full resolution.
Just wanted to share some pictures I snapped today of the three furnaces in action (all at once!) at different temperatures. This was the first time that all three were active at the same time (drawing ~90-100Amps). Look closely and you can see the wafers inside the furnaces.
N Type Diffusion Furnace @ 825°C
P Type Diffusion Furnace @ 925°C
Silicon Dioxide Growth Furnace @ 1075°C