Arduino Forum

Forum 2005-2010 (read only) => Software => Interfacing => Topic started by: mattt on Sep 28, 2007, 09:38 am

Title: 433mhz wireless problems
Post by: mattt on Sep 28, 2007, 09:38 am
I got a 433mhz transmitter and reciever from Jaycar.
http://www.lostplot.com/pics/TXC1.pdf
http://www.lostplot.com/pics/RXB1%20reciever.pdf

Originally I wanted to send data to the Arduino, part of another project, but had problem with wireless data quality.
I stripped it down and reversed the direction, easier to diagnose I thought.

so I connected them like this...
(http://www.lostplot.com/pics/433mhz.jpg)
The max3223 connects to a serial to usb adaptor on a pc.


on the Arduino...
Code: [Select]

void setup()
{
 Serial.begin(9600);
}

void loop()
{
 Serial.println("1234567890abcdefghijklmnipqrstuvwxyz");
 delay(1);
}



Heres the data captured on the pc...
Code: [Select]
1234567890abcdefghijklmnopqrstuvwxyz
1234567890abcdefghijklmnopqrstuvwxyz
1234567890abcdefghijklmnopqrstuvwxyz
1234567890abcdefghijklmnopqrstuvwxyz
1234567890abcdefghijklmnopqrstuvwxyz
1234567890abcdefghijklmnopqrstuvwxyz
1234567890abcdefghijklmnopqrstuvwxyz
1234567890abcdefghijklmnopqrstuvwxyz
1234567890abcdefghijklmnopqrstuvwxyz
1234567890abcdefghijklmnopqrstuvwxyz
1234567890abcdefghijklmnopqrstuvwxyz


Great.
As I increase the delay, I get the problem again.

delay=20
Code: [Select]
67890abcdefghijklmnopqrstuvwxyz
4567890abcdefghijklmnopqrstuvwxyz
567890abcdefghijklmnopqrstuvwxyz
67890abcdefghijklmnopqrstuvwxyz
0567890abcdefghijklmnopqrstuvwxyz
67890abcdefghijklmnopqrstuvwxyz
1234567890abcdefghijklmnopqrstuvwxyz
67890abcdefghijklmnopqrstuvwxyz
1234567810abcdefghijklmnopqrstuvwxyz
890abcdefghijklmnopqrstuvwxyz
467890abcdefghijklmnopqrstuvwxyz
5&7890abcdefghijklmnopqrstuvwxyz
890abcdefghijklmnopqrstuvwxyz
1234567890abcdefghijklmnopqrstuvwxyz
7890abcdefghijklmnopqrstuvwxyz
7890abcdefghijklmnopqrstuvwxyz
67890abcdefghijklmnopqrstuvwxyz
7890abcdefghijklmnopqrstuvwxyz
7890abcdefghijklmnopqrstuvwxyz
67890abcdefghijklmnopqrstuvwxyz


delay=100

Code: [Select]
@cdefghijklmnopqrstuvwxyz



`cdefghijklmnopqrstuvwxyz


cdefghijklmnopqrstuvwxyz
0À?
    ????¡¥©­±µ¹½ÁÅÉÍÑÕÙÝáåé


                             @`cdefghijklmnopqrstuvwxyz

0abcdefghijklmnopqrstuvwxyz
0abcdefghijklmnopqrstuvwxyz
bcdefghijklmnopqrstuvwxyz



Any ideas why this happens like this ?

I changed the code to tease out some behaviour.

Code: [Select]
void loop()
{
 for(int i=0;i<5;i++) Serial.println("1234567890");
 for(int i=0;i<5;i++) Serial.println("abcdefghijklmnipqrstuvwxyz");
 delay(100);
}



the results...
Code: [Select]
34567890
1234567890
1234567890
1234567890
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
234567890
1234567890
1234567890
1234567890
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
0?? 234567890
1234567890
1234567890
1234567890
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
234567890
1234567890
1234567890
1234567890
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz



Is it to do with initial transmission?
I wonder if the problem is with the pc end, the max3223, that has features which can invoke powersaving.
http://datasheets.maxim-ic.com/en/ds/MAX3221-MAX3243.pdf

I have FORCEON and FORCEOFF, high (vcc) and EN low (GND).

I thought I could elliminate the pc side and loopback to the Arduino's RX, but I'm not sure how I woul know what data I was seeing on the Arduino serial debug console.

Ideas or comments welcomed.
Thanks

Title: Re: 433mhz wireless problems
Post by: kg4wsv on Sep 28, 2007, 01:31 pm
sometimes these TX/RX modules aren't all that robust, especially the cheaper ones.  It appears maybe the receiver needs to receive some data in order to get its data clock/PLL in sync.  With the reduced delay, the clock hasn't had time to drift off yet.  The only problem with this hypothesis is that it doesn't appear to happen when you first begin transmitting.

If this is the case, you may need to put together a simple packet, with a preamble long enough to get the RX clock in sync, and a header and trailer to tell you here the "real" data starts and stops.

Glancing at the data sheet, it looks to me that you have the MAX3223 is set up correctly.

-j
Title: Re: 433mhz wireless problems
Post by: mattt on Sep 28, 2007, 03:38 pm
Quote
sometimes these TX/RX modules aren't all that robust, especially the cheaper ones.  It appears maybe the receiver needs to receive some data in order to get its data clock/PLL in sync.  With the reduced delay, the clock hasn't had time to drift off yet.  The only problem with this hypothesis is that it doesn't appear to happen when you first begin transmitting.

If this is the case, you may need to put together a simple packet, with a preamble long enough to get the RX clock in sync, and a header and trailer to tell you here the "real" data starts and stops.

Glancing at the data sheet, it looks to me that you have the MAX3223 is set up correctly.

-j


ah ok, that's interesting.   Thanks very much.

I spend hours looking thinking it might be the antenna and looking into suitible designs.
Quite interesting if anyone else stumbles across this thread, this might be useful.
http://www.rfm.com/support/apnotes/antenna.pdf


Regarding sorting out a basic packet, do I literally send a bunch of zeros, the a start sequence, then the data, the stop sequence ?
I think I will need to identify a the sender and recipient (might just be 8 bits).
Do I need a checksum too ?

Sound like protocol design to me.
Any resources for this sort of stuff, surely I'm not the first

Matt

Title: Re: 433mhz wireless problems
Post by: Cheater on Sep 29, 2007, 01:26 am
Quote
Regarding sorting out a basic packet, do I literally send a bunch of zeros, the a start sequence, then the data, the stop sequence ?
I think I will need to identify a the sender and recipient (might just be 8 bits).
Do I need a checksum too ?

I'd do something like send '0123456789HDRMydatahereEND'
On the receiving side I'd just sort through the data until I saw HDR (header) and cut when I saw END.

Should do the trick. :)
Title: Re: 433mhz wireless problems
Post by: John_Ryan on Sep 29, 2007, 03:52 am
If you don't mind me asking, what's the LOS distance for this setup?

Also, what are you using on the pc side?

I wasn't aware this setup was possible, I just ordered an Arduino BT - but it looks like this would have done the trick, for what I was wanting.
Title: Re: 433mhz wireless problems
Post by: mattt on Sep 29, 2007, 06:51 am
I only need one way traffic, to send command to an Arduino.
PC->usb->rs232->Max3223->ttl->txc1->433mhz->rxb1->RX->Arduino.
I'll end up using python to send to the com port.

In my tests I have it the other way round.
Arduino->TX->txc1->433mhz->rxb1->Max3223->rs232->usb->Hyperterm

I'm not sure what the LOS distance is, I expect antenna design impacts that greatly.
I have it working from one side of my desk to the other. :)

Title: Re: 433mhz wireless problems
Post by: mattt on Sep 29, 2007, 07:36 am
FWIW, I took the arduino+transmitter to the other end of my house, down 1 floor, 4 single brick walls, and I did see some corruption, just the odd few characters.
I'm just using a 164mm length of wire as antennas.
Title: Re: 433mhz wireless problems
Post by: Cheater on Sep 29, 2007, 08:04 am
Wow nice.

What kind of corruption? The same type as above or 'noise' corruption from the distance?
Title: Re: 433mhz wireless problems
Post by: John_Ryan on Sep 29, 2007, 08:18 am
So - two-way isn't possible?

Anything over 10m is impressive, thanks for the info :)
Title: Re: 433mhz wireless problems
Post by: Cheater on Sep 29, 2007, 08:28 am
Quote
So - two-way isn't possible?

Apparently not with one pair but you could always use two pairs.
Not sure if interference becomes a problem. If you cant change the frequency then you'd need to make a protocol to stop collisions.
Title: Re: 433mhz wireless problems
Post by: John_Ryan on Sep 29, 2007, 02:07 pm
ok, so lucky I've got a BT on the way :)

Thanks for explaining everything, good luck with your project.
Title: Re: 433mhz wireless problems
Post by: mattt on Sep 29, 2007, 04:10 pm
Quote
Quote
So - two-way isn't possible?

Apparently not with one pair but you could always use two pairs.
Not sure if interference becomes a problem. If you cant change the frequency then you'd need to make a protocol to stop collisions.


I have another pair and will try out bi-directional at some point.

Certainly it becomes more complex, but I thought add some control data

Source ID - which device is sending
Destination ID - which device should not ignore the packet
Checksum - something simple.

Maybe add
Packet ID - so destination can acknowledge packet with non-zero ID
Group ID - enables multicast

For Collision detection/avoidance.
This looks interesting. http://en.wikipedia.org/wiki/Truncated_binary_exponential_backoff

Hmm, it's probably all a bit much for me, very interesting though.
While I was googling I found.
http://focus.ti.com/lit/ml/swru130/swru130.pdf
http://www.faqs.org/rfcs/rfc1162.html
http://en.wikipedia.org/wiki/Carrier_sense_multiple_access_with_collision_detection


Title: Re: 433mhz wireless problems
Post by: Cheater on Sep 30, 2007, 01:17 am
Quote
Certainly it becomes more complex, but I thought add some control data

Look up how Wifi/Ethernet works.

Basically if data needs to be sent then it listens for a random amount of time and if its clear it asks "Hey I want to talk."
If that transmits fine (e.g. doesnt collide) then it transmits the data.
Title: Re: 433mhz wireless problems
Post by: PlastBox on Oct 03, 2007, 04:16 pm
Quote
sometimes these TX/RX modules aren't all that robust, especially the cheaper ones.  It appears maybe the receiver needs to receive some data in order to get its data clock/PLL in sync.  With the reduced delay, the clock hasn't had time to drift off yet.  The only problem with this hypothesis is that it doesn't appear to happen when you first begin transmitting.

If this is the case, you may need to put together a simple packet, with a preamble long enough to get the RX clock in sync, and a header and trailer to tell you here the "real" data starts and stops.

Glancing at the data sheet, it looks to me that you have the MAX3223 is set up correctly.

-j


If this is indeed the case, why don't you just continously send "01010101"... through the RF-link, until there is actual data to send at which point you send a preamble of "11111111" or something easily destinguishable from the "01"-placeholder sequence?

I mean, the Arduino sends "010101010101010" constantly until there is data to be sent. Then, it (without delay) sends "11111111", a 2 byte thingie defining the amount of data, then the data itself.

The computer side would read 2 bits at a time and see "01" over and over and ignore it. If it reads 8 "1"'s after eachother, it reads the next 16-bits and converts it into a number representing the length of the data, and then reads that number of bits from the stream.

Example sending "Hey!":
010101010101010101111111111000000000000010001001000011001010111100100100001

...broken down is...

01010101010101010    //reads 2 bits at a time, ignores as long as it is "01"
1111111111    //reads 8 "1"-bits in succession, knows to start reading
0000000000000100    //16 bits telling the computer the length of the data (in this case, 4 bytes (32 bits) )
01001000011001010111100100100001    //the 32 bits to be read
H       e       y       !
   //the computer goes back to looking for 8 "1"-bits


I'm just guessing this would work, and I would suggest adding any extra protocol-stuff (like source/destination/group ID), inside the data-portion of this packet.
Title: Re: 433mhz wireless problems
Post by: kg4wsv on Oct 03, 2007, 08:16 pm
Quote
If this is indeed the case, why don't you just continously send "01010101"... through the RF-link,

That will consume more power.  If you're going to be near 100% duty cycle anyway, or if you have virtual unlimited power (running from an AC supply or large battery pack or the like) then continuous TX may be OK, but if you have limited power or if the TX module is very power hungry, that may lead to really short battery life.

If there is a transmitter in a system, there is a good chance that's the biggest power consumer in the circuit (short of something like a motor or solenoid).

-j
Title: Re: 433mhz wireless problems
Post by: Cheater on Oct 04, 2007, 12:55 am
Also it chews cycles doing that which could otherwise be used to do productive things.
Title: Re: 433mhz wireless problems
Post by: PlastBox on Oct 04, 2007, 09:27 am
Of course both power consumption and data cycles are things one should try to save. So, what if the threadstarter did what I said, except that instead of continously sending "01", he gets the Arduino to send a preamble of.. say.. 4 bytes of "01" before each package? It might still solve the sync-issue, and he would have a fairly robust shell for implementing a higher level protocol with stuff like ID's and such..
Title: Re: 433mhz wireless problems
Post by: mattt on Oct 04, 2007, 02:56 pm

Sending continuous bits will solve the sync issue, but I can't see how this would work for any situation where there's more than one transmitting device.
As it is, my tinkering has shown that sending '1234567890<cr>' before sending payload data, typically results in only seeing between 67890 and 0.  
Sometimes only a few chars of gibberish.
The payload is consistently error free.

I think I will have a crack as designing a simple but usable RF protocol, for multiple units on the same frequency.
I for one have a couple of project I'd like to be able to poke remotely.
http://en.wikipedia.org/wiki/Ethernet#CSMA.2FCD_shared_medium_Ethernet
http://en.wikipedia.org/wiki/Datagram

Title: Re: 433mhz wireless problems
Post by: PlastBox on Oct 04, 2007, 03:13 pm
If you are going to have multiple devices communicating with your computer, you either need some ingenius timing-routine, a system where device 1 transmits to device 2, which appends it's data and transmits to device 3 and so on (not very efficient), or 2-way-communication so the computer can push/poll information to/from the device it wants.

Like I said, sending continous bits was a retarded suggestion on my side. Just send jibberish, followed by an identifier telling the computer that data is starting.

I'm not sure how you plan to link together several devices.. If you need any-to-any communication I'm pretty much lost, but if you need many-to-one type communication, getting a tranciever for your devices is the only good way I can imagine.. The computer says "Hey, unit 3, what is your analog input status?" and device 3 answers.
Title: Re: 433mhz wireless problems
Post by: mattt on Oct 04, 2007, 03:40 pm

I'm thinking I'll give each device an address.
Each devices hears all traffic, much like old Ethernet hubs.

(yes, it will be insecure and vulnerable, but hopefully fun)
Title: Re: 433mhz wireless problems
Post by: John_Ryan on Oct 04, 2007, 03:41 pm
Why not just use different ID sequences for each transmitter, the receiver can decide which unit it's talking to based on the comms start ID string, like "A" for unit 1, "B" for unit 2 .. etc.
Title: Re: 433mhz wireless problems
Post by: John_Ryan on Oct 04, 2007, 03:42 pm
ah, we had a similar thought at the same time  :D
Title: Re: 433mhz wireless problems
Post by: mattt on Oct 04, 2007, 04:02 pm

How might I detect a collision ?

Would a checksum failure be enough to detect a collision ?
So, I'd have to get the sender to listen to it's own data as it's sent ?
Title: Re: 433mhz wireless problems
Post by: diverdale on Oct 18, 2007, 04:29 pm
Which txb1 / rxb1 chip did you use? This looks like it could do just what I'm after....


thanks,
Dale
Title: Re: 433mhz wireless problems
Post by: mattt on Oct 19, 2007, 02:48 am
I used ones from Jaycar.com.au

Something has changed though, my signal is almost 100% junk now, I'm not sure if it something with my setup, or some other interference.
It has made me quite grumpy.
Title: Re: 433mhz wireless problems
Post by: diverdale on Oct 28, 2007, 11:22 pm
I just received my tx/rx from sparkfun http://www.sparkfun.com/commerce/product_info.php?products_id=7815 All I see is garbage on the serial console. Spec says 4800bps I've tried both 2400 and 4800 with no luck.  All I'm seeing is garbage.  Anyone had any luck??

Thanks,
Dale
Title: Re: 433mhz wireless problems
Post by: mikem on Mar 06, 2008, 09:13 am
I have a pair of these tx/rx modules from Jaycar too. The TX is ASK (amplitude shift keying), and when the modulation input is low, it does not transmit (that may be why you are receiving noise) with no signal, the reciver produces noise on its output.

This means that in order to use it successfully, you need to do as another poster said: either transmit a preamble of several characters that gives time for the receiver to sync to the data clock rate, or send a continuous sequence of idle characters until you are ready to send a real data.
Title: Re: 433mhz wireless problems
Post by: mikem on Apr 23, 2008, 01:20 am
I have now posted information about a new library that correctly implements short message transmission with these types of device, without using the UART. It sends a preamble, checksum, using proper DC balance etc.

http://www.open.com.au/mikem/arduino/VirtualWire.pdf

Cheers.
Title: Re: 433mhz wireless problems
Post by: Shubs on Apr 23, 2008, 04:10 pm
I don't know if this might help or not, but we're using a RF frequency transmitter and receiver to send some data too.
We used a filter at our receiving end to prevent picking up random noise from the air. I hope that helps a little bit too.