433mhz wireless problems

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

Thanks for explaining everything, good luck with your project.

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. Exponential backoff - Wikipedia

Hmm, it's probably all a bit much for me, very interesting though.
While I was googling I found.

http://www.faqs.org/rfcs/rfc1162.html

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.

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.

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

Also it chews cycles doing that which could otherwise be used to do productive things.

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

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

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.

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)

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.

ah, we had a similar thought at the same time :smiley:

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 ?

Which txb1 / rxb1 chip did you use? This looks like it could do just what I'm after....

thanks,
Dale

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.

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

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.

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.

Cheers.

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.