3
\$\begingroup\$

I am using these RF link modules for a project since I need a cheap, small, and simple wireless link between two microcontrollers. The data being sent is a single integer and can be spam sent to prevent any mistakes in the data over the air.

http://www.seeedstudio.com/depot/433mhz-rf-link-kit-p-127.html?cPath=139_140

However, I want to be able to use multiple of these one-way wireless connections in the same area and in order to prevent them from jamming each other out, they have to be different frequencies. The RF link's I can find are always either 315 or 434 mhz and dont come in any more frequencies. I was wondering if there was a way to alter these to change the frequency (im looking for about 5 different frequencies) so that they dont all interfere with each other.

I could use a transceiver module, however for the simplicity of the communication, these are generally overkill. In addition, they are almost twice the cost of these links when you buy one for each of the microcontroller.

Can anyone help me understand how to change the frequency of these, or if there are any websites where you can buy these RF links in more than two different frequencies?

Thanks Din

\$\endgroup\$
  • \$\begingroup\$ we can use Xbee for single receiver and multiple emitters.... \$\endgroup\$ – user34383 Dec 19 '13 at 11:22
3
\$\begingroup\$

In the 433 MHz band, there are 69 channels and the list of them and their exact frequencies can be found here.

As far as these modules are concerned, I can't see any mention of channels or exact frequency in the documentation. I know that some (for example this one) modules do mention their frequency, but so far I've been unable to actually find any modules whose frequency channel can be programmed. They do exist, though, since I've seen them in some products.

Some manufacturers (can't find the link at the moment) mention that modules with channels other than default are available for order, but the downside of that is the fact that manufacturers usually do not want to talk to small buyers.

\$\endgroup\$
1
\$\begingroup\$

I won't provide you with a professional answer since I'm not in the RF field, but... spam sending an integer over and over? Jamming? That's no way of doing communication. You should send data along with meta-information.

Let's assume you have 4 devices sending information. That means you need 2 bits of information about the device. So the first two bytes will contain information about which device sent it. 00 - first device, 01 - second, 10 - third, 11 - fourth.

You shouldn't stream data all the time, too. Your hardware should be protected against noise to a certain extent, so you don't need a hundred thousand redundant bytes sent through the RF link. A single byte sent through UART<->RF should take you a couple tens of microseconds. If you don't need high speeds, you can afford to attempt sending this data a few times. The transfer of data should go thusly:

  1. Device #1 sends a byte of data to device #2
  2. Noise prevents the byte from being successfully sent, device #2 is just standing there oblivious to the fact.
  3. Device #1 waits a bit for a response from device #2. If timeout is exceeded, another attempt is made.
  4. Let's say device #2 received a byte, but the checksum doesn't add up. It now sends a predefined error byte.
  5. Device #1 received an error signal, so it sends the same byte again.
  6. Device #2 received the correct byte, so it sends and Acknowledged control byte.
  7. The noise disrupts transfer yet again! So device #1 sends the byte yet another time. Perhaps it should include an ID? This way device #2 won't interpret this as a completely new byte.

This is a very chaotic description of what I imagine should happen in a very rudimentary communication system that is prone to errors. In order to create a reliable system from scratch, you should create your own protocol. Redundancy is only one of the ways of achieving this.

If you intend to send a large chunk of data, and the transfer takes a few milliseconds, there might be a chance another device will attempt to start its own transfer. However, that device should also be capable of checking whether the 'ether' is free. If it detects transmission, it should wait until it's finished.

This is such a fascinating topic that someone, somewhere has probably created a very well thought out protocol. There is probably a library on avrfreaks that will fit this application. Maybe there are industrial solutions you could mimic. What is certain is that this is not a simple matter.

\$\endgroup\$
  • \$\begingroup\$ How exactly does Device #1 "wait for a response" or "check whether the ether is free" when it only has a transmitter, not a receiver? \$\endgroup\$ – davidcary Sep 26 '12 at 3:04
  • \$\begingroup\$ yea my project is mainly a one way transmission between two mC's... since there is no return communication, the spamming just ensures that the message got across with reliability. I want to add multiple of these one directional links in the same area and dont want them to interfere with each other, which is why i wanted to simply change the frequency \$\endgroup\$ – din Sep 26 '12 at 6:06
1
\$\begingroup\$

I'm interested in developing something similar, but basically I envision one receiver and multiple emitters on the same frequency. In order to prevent collisions I want to have the devices send information at random times, with pauses in between. The same information will be send repeatedly several times to make sure that it gets to the receiver and it doesn't matter if some packets are lost on the way - because they will be. Actually just with on emitter-receiver pair there is a significant amount of information lost (from my experiments). The data sent from each emitter will have an ID and a checksum so the receiver will know where the message is coming from and if it's a correct message.

I use Arduino with the VirtualWire library which also takes care of checksumming and a specific modulation that has better chances of being received undisturbed.

\$\endgroup\$
  • \$\begingroup\$ You're not the first to come up with this idea. It's a good one, and you can read some of the mathematical justification for it in this Circuit Cellar article from 1999 by Carl Huben. \$\endgroup\$ – Dave Tweed Oct 16 '12 at 4:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.