SparkFun Forums

[reklipz]

Hey everyone, I've come to ask a few questions, and hopefully gain some insight to this whole wireless business.

First off, as the title says, I'm looking to create some sort of keyless entry system for my car. As I've never done any wireless before, I thought it a good idea to ask a few question before I started.

Secondly, after looking at a few modules, I've decided that either the simple RF Link modules, or the Long Range Modem modules will work fine.

My questions:

1. Was I correct in the module choice?
   I'm fairly certain that the simple RF Link is the correct choice.
2. Is there any benefit of xxx frequency over xxx frequency, and ultimately, why?
   Yep, this is about the only question I've left. Amazing what wonders the search feature can do .
3. What sort of data rates will I be needing, and how do I go about calculating this (this would have to include all of the data that needs to be sent for the protocol and the DC balancing stuff and whatever else I still need to learn)?
   Not so much an issue, I'll just be sure to go with the 4800bps, I think they're the same price too.
4. What is DC balancing, and what are some other things that I may need to consider in order to get the link working?
   After some reading, I think I've got this one covered. http://www.piclist.com/techref/microchi ... ansync.htm and http://www.ottawarobotics.org/articles/rf/rf.html were very helpful.
5. How do I go about corrupt data and such (I believe that the Long Range Modem modules eliminate the last two questions, no?)?
   Those two articles pretty much covered this, and I doubt I'll need to implement CRC or anything that cumbersome as I can always use my actual keys to open the door if need be.
6. Do I need to worry about securing the link at all, or is the fact that it will be a custom design be enough, and if not, any suggestions?
   KeeLoq is the solution!

This will more than likely be a PIC base solution.

Thanks for your time and for reading my post!

-Nathan

[stevech]

They way I did this many years ago was to buy a kit intended for this. Just installed it. No doubt, you want to roll-your-own though?

The hardest part for me was to work out the interface to the car's locks. Likely easy if you work in the after-market upgrade industry, but I didn't, and I didn't have any shop manual. I dismantled the door switches in my car and luckily, I was able to reassemble it. The circuitry is pretty exotic.

The key fob choice is a big issue. There are many on the market. Most are 433MHz or 318MHz (in No. America). These send a simple code (insecure) or a rolling code (more secure).

Since your car is somewhat at risk, I'd suggest you not do a totally home-brew project for this - but rather, buy a purposeful add-on kit from someone like JC Whitney.

[reklipz]

Well, I'm fairly hellbent on doing this project, although I appreciate your concern. My car is a '95 Buick Regal, got it for like $1000, so I won't really miss it if I do happen to lose it, but the whole point is to make the system secure, so that doesn't happen. I've been reading about the microchip KeeLoq code hopping techniques, which are used in the real keyless entry modules from real manufactures, but the only down fall of that route is the expense of using two RF links, or the one transceiver module (the two RF link modules are still cheaper, but the transceiver has the added bonus of longer range, and the error detection/ handling, basically a direct drop in for a serial cable.)

EDIT---------
After a quick re read of the keeloq datasheets, i've realized that I still only need a unidirectional RF Link, so long as I can get the encoder "learned" into the decoder.

Also, I've got a schematic of my car's electrical system, and have power locks / windows (wouldn't that be a cool feature, lol ) so that shouldn't be an issue.

Thanks for the reply!

[reklipz]

Well, the KeeLoq system seems like a really good choice, but there is only one issue with it. The way I wish to use it, I will need to find a way to PWM the code I get over the RF Link into it. The reason for this is that it needs the RF Link to be connected to it. The encoder on the other hand, allows you to clock the code out to a µC to send over a different RF Link, instead of having the RF link connected right to it.

Now, one might ask why I don't just use the built in "button" system that it puts into its codes (certain version do this). The reason is just that it would be too easy, and I'm then limited to 4 buttons (15 if I do some fancy dioding of signals). Although, this is a really cool system, if anyone is looking at doing simple security devices, this should definitely be on the top of your list.

Still hoping for answers to those other questions!
Thanks!
-Nate

[reklipz]

OK, I've got the wireless link up and running, using 6.8" λ/4 monopoles, and in case I haven't said so yet, I'm using the 433.92MHz version of the modules. (Should be a tad shorter because of the insulation, but no biggie.)

This brings me to my final question; What kind of antenna should I put in the transmitter, which will hopefully be a small fob like all of the regular ones use. Is there anything better than a magnetic loop? Is the spiral better than the coil? Do I need to worry about matching the two, using LC networks, and if so, how?

I've seen what look like wire whip antennas with a coil in the middle, would that be better than just a λ/4 or λ/2 monopole for the receiver? Would a dipole be better in this situation? Maybe add a reflector to the receiver? (the reflector would probably not be good, as I would then only be able to use the remote on one side of the car, no?)

I've also read that using the full wavelength antenna for both the receiver and transmitter is not a good idea, referring back to something about matching the two. Is it matching the impedance?

What are other people using for antennas, and how well do they work?

Thanks much!

[reklipz]

Should anyone care, heres some CRC-16-CITT that I scrounged together for MCC18:

Code: Select all

unsigned int CRC16CCITT(const unsigned char *data, const unsigned char size);

unsigned int
CRC16CCITT(const unsigned char *data, const unsigned char size) {
	unsigned char CRCPolyLo = 0x21,
					  CRCPolyHi = 0x10,
					  CRCLo = 0xFF,
					  CRCHi = 0xFF,
					  CRCHiSave,
					  CRCData,
					  CRCCount,
					  i;
	
	for( i = 0; i < size; i++ ) {
		CRCData = data[i];
		CRCCount = 8;
		
		_asm
		_loop:   movf    CRCHi,0,1			// Save the high byte of the CRC
			      movwf   CRCHiSave,1
			      bcf     STATUS,0,0			// Rotate the CRC left 1 bit
			      rlcf    CRCLo,1,1
			      rlcf    CRCHi,1,1
			      movf    CRCData,0,1		// XOR the data with the saved high byte
			      xorwf   CRCHiSave,1,1
			      btfss   CRCHiSave,7,1		// If the 7th bit is set, apply the mask
			      bra     _notset				// Otherwise skip it
			      movf    CRCPolyLo,0,1		// XOR the polynomial with the CRC
			      xorwf   CRCLo,1,1
			      movf    CRCPolyHi,0,1
			      xorwf   CRCHi,1,1
		_notset: bcf     STATUS,0,0		// Rotate the data so we can calculate the next bit
			      rlcf    CRCData,1,1
			      decfsz  CRCCount,1,1			// Decrement CRCCount and finish if 0
			      bra     _loop					// Otherwise, continue the calculation
		_endasm
	}
	
	return (unsigned int)CRCHi << 8 | CRCLo;
}

[saipan59]

Antennas:
For the fob transmitter, I'd use a tuned loop, like in the Microchip app note. Their example, which can be tuned for either 434 or 315 Mhz, is a PC trace in the shape of a rectangle about 3/4" X 1.5".

The rcvr antenna will probably not be very 'picky'. A 1/4 wave vertical would be fine (17.3cm at 434 Mhz).
A dipole (1/2 wave) is probably overkill. If you use a dipole, note that if it's horizontal it will be directional (it works 'broadside' to the orientation of the antenna).

In reality, I suspect that you'll find that the link works from a considerable distance (which may be a bad thing - you don't want the fob in your pocket to accidentally unlock your car when you're sitting down in a restaurant).

Pete