next topic »

[on:]

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...

The max3223 connects to a serial to usb adaptor on a pc.


on the Arduino...

Code:

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

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

Heres the data captured on the pc...

Code:

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:

67890abcdefghijklmnopqrstuvwxyz
4567890abcdefghijklmnopqrstuvwxyz
567890abcdefghijklmnopqrstuvwxyz
67890abcdefghijklmnopqrstuvwxyz
0567890abcdefghijklmnopqrstuvwxyz
67890abcdefghijklmnopqrstuvwxyz
1234567890abcdefghijklmnopqrstuvwxyz
67890abcdefghijklmnopqrstuvwxyz
1234567810abcdefghijklmnopqrstuvwxyz
890abcdefghijklmnopqrstuvwxyz
467890abcdefghijklmnopqrstuvwxyz
5&7890abcdefghijklmnopqrstuvwxyz
890abcdefghijklmnopqrstuvwxyz
1234567890abcdefghijklmnopqrstuvwxyz
7890abcdefghijklmnopqrstuvwxyz
7890abcdefghijklmnopqrstuvwxyz
67890abcdefghijklmnopqrstuvwxyz
7890abcdefghijklmnopqrstuvwxyz
7890abcdefghijklmnopqrstuvwxyz
67890abcdefghijklmnopqrstuvwxyz

delay=100

Code:

@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:

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:

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

[Reply #1 on:]

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

[Reply #2 on:]

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

[Reply #3 on:]

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.

[Reply #4 on:]

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.

[Reply #5 on:]

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.

[Reply #6 on:]

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.

[Reply #7 on:]

Wow nice.

What kind of corruption? The same type as above or 'noise' corruption from the distance?

[Reply #8 on:]

So - two-way isn't possible?

Anything over 10m is impressive, thanks for the info

[Reply #9 on:]

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.

[Reply #10 on:]

ok, so lucky I've got a BT on the way

Thanks for explaining everything, good luck with your project.

[Reply #11 on:]

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

[Reply #12 on:]

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.

[Reply #13 on:]

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.

[Reply #14 on:]

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