RF Module Qualifier, CRC?

[tazntex]

Thanks Languer, I have tried everything wired before I went to RF, but, I did not make any changes to the qualifier. I was bored last Friday so reading over my code i realized that obviously the qualifier is not Manchester Encoded so I was thinking if I am sending a preamble of %10101010 preceding the qualifier 254,%11111110,what happens to the data slicer so curiosity got the better of me. I then thought that I could keep the data slicer balance by sending 170, %10101010. Thats when I found that I had a problem. when I changed it to 170 or whatever it became intermittent. By keeping it 254 I could operate this way over a couple of hundred feet with only a rare hiccup, stutter or whatever its called, but that is only when I was going close around my metal shop and vehicle. I've been trying to figure out some of the examples I have found on the CRC though. Instead of cut, copy and pasting them to my code I am trying to understand how each line works before I tailor it to my need.

Again, many thanks

[mackrackit]

This might give you some ideas. Not exactly what you are asking for, but it is very reliable.
http://www.picbasic.co.uk/forum/showthread.php?t=12554

[Bruce]

Have a look at this article. The PIC controls a Linx LR transmitter with data received from the PC serial port. It simulates the Holtek 8-bit encoder, and can control a Linx FCTN-RLY4-xxx receiver/relay, or a Linx KH2 receiver module. Both use the Holtek 8-bit decoder IC.

http://www.myamicus.co.uk/content.ph...Remote-Control

And this thread: http://www.picbasic.co.uk/forum/showthread.php?t=6581 has PBP code for decoding a Holtek 8-bit encoder.

[languer]

Those post from Bruce are very valuable. They show very simple methods to make you comms more robust.

Dhouston also has some very good information on similar subject: http://www.picbasic.co.uk/forum/showthread.php?t=6261

in lamen's terms how I can use CRC?

This is my best attempt to address this in particular (full disclosure - I am no expert). CRC is used in many places when you want to validate the contents of a packet (i.e. detect the packet to be error free). A packet can be anything: wireless data, ethernet data, bootloader data, archive data (read WinZIP). It is a very simple way of coming up with a somewhat unique identifier that tells you the packet you have has not been compromised (i.e. corrupted, changed, etc).

How effective is it? - It depends. There are as many algorithms (polynomials) as days of the year (and then some). It all depends on how "unique" you want to define your packet and how much math (read - computer resources) you want to use to come up with the CRC.

How simple is it? - Again, it depends.

Why use it? - It is pretty standard method of validating packetized data; as long as you have the computing power to do it, and select an algorithm/polynomial and stick with it.

What it does? - It gives you confidence on the validity of your packet (i.e. error detection).

What it does not do? - If your data packet is corrupted, it does not tell you how to correct it (i.e. it does not have error correction).

How you could use it? - On the transmit side, you calculate the CRC of your data packet (after selecting the algorithm you want/need) and send it along with your data packet (usually at the end). On the receive side, you receive the data packet and the CRC. Calculate a new CRC value form the data packet (not including the received CRC) and compare it to the received CRC. If they match you have a higher degree of certainty the packet is free from errors.

Good reads:
http://en.wikipedia.org/wiki/Cyclic_redundancy_check
http://www.hackersdelight.org/crc.pdf
http://www.repairfaq.org/filipg/LINK/F_crc_v3.html

[rmteo]

How effective is it? - It depends. There are as many algorithms (polynomials) as days of the year (and then some). It all depends on how "unique" you want to define your packet and how much math (read - computer resources) you want to use to come up with the CRC.

How simple is it? - Again, it depends.

Why use it? - It is pretty standard method of validating packetized data; as long as you have the computing power to do it, and select an algorithm/polynomial and stick with it.

Many higher-end devices (such as PIC24) implement it in hardware for the reasons you mention.

[Bruce]

Many higher-end devices (such as PIC24) implement it in hardware for the reasons you mention.

Yep. Unfortunately PBP just doesn't support the PIC24, PIC32, or dual-core pentiums..;o) And, for this particular application, that would be like hunting rabbits with a Sherman TANK. Honestly.

You just-do-not-need-to get-that-complex for such simple wireless communications, and it really does NOT require any PIC type beyond what PBP supports.

[rmteo]

I am aware of the limitations and shortcomings of PBP. I was agreeing with languer that implementing CRC in software is resource intensive and may not be the best solution for the OP. That is why it is implemented in hardware - for those that feel they have a need for it. But hey, rabbit hunting with a Sherman tank does sound like fun.