Help needed with multiple Tx to single Rx 433Mhz

[Buzby]

Hi All,

I have built two handheld battery operated transmitter units, each with a PICaxe 20M, a 433MHz Tx module, and four switches. I have also built a receiver, again with PICaxe 20M, and eight relay outputs driven by a 2803. The purpose of the system is to operate each relay from a specific switch, i.e. the 4 switches on one Tx operate 4 relays, and the other Tx operates the other 4 relays. The required operating range of the system is less than 20 metres.

My code, ( which I can't post here yet, because I left my pendrive at home ! ), does something like this:

Each Tx runs a loop, checking the switch states and building a nibble from them. Each time round the loop if the nibble value is different that last time then a switch must have changed, so a serout is triggered. The serout looks something like this :

serout 1,T1200,(“xxxxxxxxABC”),nibble,"A"

The "xxxxxxxx" is to give the Rx something to sync on. ( I don't know if this is essential. )
The "ABC" is the qualifier that the Rx serin will react to.
The nibble is the switch states. ( Actually its a byte, but only four bits are used.)
The "A" character is to identify which Tx the is, "A" in one Tx and "B" in the other.

The receiver is just a serin like this :

serin 1,T1200,(“ABC”),b1,b2

The code sits waiting on the serin for the "ABC" qualifier, then gets the nibble into b1 and the Tx ident into b2. A bit of decoding then operates the relays.

It all seems to work fine, but I want to iron out a glitch that I can't fully envisage how to solve. If a switch on each Tx changes state within a small time window, both Tx's send at the same time, and the receiver gets a mishmash of both radio signals. The serin doesn't trigger, and no relays change state.

My obvious first task is to reduce the critical time window to its shortest possible value. ( I'm thinking of pushing the baudrate up to reduce the time the radio is busy. Whats likely to be the reliable baud limit ?. Does anyone have any other ideas ?. )
This will not solve the problem totally, but will reduce the occurence.

My next idea is to transmit each message more than once, but I think that this might just shift the time frame, so that two switches at the same time will work, but will not work if they are at slight different times.

I'm sure there must be some algorithm for solving this type of issue, but I don't know where to start looking, so I've asked the Fount Of All Knowledge !.

Cheers,

Buzby

 

[Andrew Cowan]

Higer baud = more easily affected by noise. I usually use 300 or 600 baud, as noise very rarely has an impact. Try 2400 baud, and see if that still works as well.

A

 

[Buzby]

Hi Andrew,

Is there someway I could get numbers about the noise ?. If I put a scope on the Rx output what would I expect to be seeing ?. ( I can't do that just yet, my scope is broke !. - but I can fix it.)

 

[Andrew Cowan]

You could just try sending a sting of numbers (eg 12345678) from the transmitter.

Then connect the receiver to the PC and use sertxd to display what it gets in. If the receiver is receiving the ocassional hash sign, random number or letter etc, it indicated the baud rate is too high. To solve that, use a checkbit (eg the last number is the sum of all the previous numbers) to detect faulty packets. Alternativly lower the baud rate.

Note that the further the transmitter is from the receiver, the noisier the signal will be.

A

 

[retepsnikrep]

Couple of things

1) Watch out for the Sein/Serout brackets trap

2) Peple have found a pause is reqd between pre-amble to sync txd and rxd and the data, so my code which works with some 433mhz AM modules looks like this.

TXD

serout DriveInhibit,N2400, (0x55, 0x55, 0x55, 0x55, 0x55) 		;Txd 5 byte preamble to sync & clear Rxd
pause 5				;Pause for 5ms to allow serial rxd to clear 
serout Txd,N2400, ("bms",b0,b1,b2,b3,b4,b5,b6,b7,b8)	;Txd data (2400 baud)

RXD

serin Rxd,N2400,("bms"),b0,b1,b2,b3,b4,b5,b6,b7,b8	;Receive data via 433mhz link

Adjust the number of preamble bytes up down until you get reliable comms. You can try a lower baud rate as well by all means.


Sorry jst re-read your post and see the comms is not the issue, it's the clash of comms that is. Sorry.

Sounds like you need a data window.

So when you press a button on one unit it transmits straight away then pauses for (250ms) and repeats until button is releassed. On the other unit make the delay (500ms)

Your actual data probably only takes a 100ms or so to transmit so there is plenty of room for the data to sort it self out. Adjust the pauses up and down with both unit transmitting until it starts to clash.

 

[Buzby]

Hi Retepsnikrep,

Your sync/pause/data is useful to know about anyway, even if not to fix the comms clash.

Thanks,

Buzby

 

[hippy]

The only way you will fix the comms clash is to only have one TX sending at a time. It may probably be necessary to have all other TX powered off at that time.

While good enough for proof of concept and testing, you will probably want to add packet formatting and checksum to what you send and ensure correctness when received, especially if two TX could corrupt each other, but normal radio interference could also do that.

 

[moxhamj]

In addition to the above (checksums etc), I've set transmitters up so they sense at regular intervals and send their status. So even if one message gets corrupted a new one will go through eventually. Another trick is to use the random number generator to generate random delays between sending, so transmitters can't end up synchronised with each other. And a third system which I was soldering up today is to have one board transmit, and at the other end a sensor board senses that a relay closed, and then sends this information back to the original board. So you flick a switch and after a few seconds a light should come on to say the remote board actually got the message.

 

[Buzby]

Hi All,

I've not actally monitored the output of the Rx unit with a scope yet, but I have put a sertxd immediatley after the serin. What I see when two simultaneous Tx's happen is usually nothing at all, or very rarely some garbled data. Because I decode the 4 bits in the data nibble, and also the 8 bits for the Tx ident have to match exactly, I've never seen garbled data that decoded 'correctly', but it could theoretically happen. However, thats not the main issue. The fact that 99% of the time the 'two switch scenario' results in no action at all is the main challenge.

The idea from retepsnikrep, to have multiple repetitions of each message, with TxA having 500mS gaps and TxB having 300mS gaps means that there will always be some time when only one Tx is active, no matter when the Tx cycles start, sound good. The times of 500 & 300 are way to high, but if I turn up the 20M clock to 8MHz I'll process the Rx quicker, and if I increase the baudrate I'll shorten the message. I'm also goint to reduce the number of characters in the message, with less preamble and a shorted qualifier.

What effect will the disconnect command, ( which stops the PICaxe polling for a download ), have on execution time ?

I can try all these tonight. My scope is broke, but I have got an antique Tektronix/Sony logic analyser somewhere that should be able to give me timing charts.

I'll let you know how I get on.

Thanks,

Buzby.

 

[Buzby]

Hi Dr Acula,

Our posts crossed, so I'll reply to yours now.

The third option, feedback confirmation, needs Rx at the end with the switches.

The first option, cyclic status, I tried. But when the Tx's got 'in sync' it took them many minutes to un-sync.

The second idea, cyclic with random intervals, sounds good.

As I mentioned before, I'll try these ideas tonight. But first I need to get some timings showing just how long the Tx is busy for. I'll calculate one set timings from the baudrate, and measure another set by putting a pin high/low either side of the serout command and measuring it with something. ( Seeing as my scope is broke I could use pulsin on another PICaxe to do the timing ! )

 

[hippy]

The idea from retepsnikrep, to have multiple repetitions of each message, with TxA having 500mS gaps and TxB having 300mS gaps means that there will always be some time when only one Tx is active, no matter when the Tx cycles start, sound good.

Only if you have one TX powered at a time. Otherwise both TX will be transmitting 'zero'. At least that's what I found, or something like it.

What effect will the disconnect command, ( which stops the PICaxe polling for a download ), have on execution time ?

None.

 

[Buzby]

Only if you have one TX powered at a time. Otherwise both TX will be transmitting 'zero'. At least that's what I found, or something like it.

Oops, that's not what I thought these 433 AM transmitters did !.

I thought they just transmitted a wave when the input went to 1. Are you saying they are transmitting all the time, just at different levels ?

I did have problems originally when I used N1200, each would work alone, but not neither worked when both were on. I changed to T1200 and it works OK. I put this down to when I used N1200 the output was idling at 1, but T1200 idles at 0. Or have I got this the wrong way round ?.

 

[tomleijen]

I have recently done some work with the 433MHZ tx rx units and I didn't notice them transmitting anything when the tx was not active.
The rx units only pick up data when a signal of a particular rate of bps (look at data sheet) is sent from the tx unit, a signal which is too slow or too fast won't be picked up, therefore the rx units should not pick up anything when the tx data pin is held low (or high) for a longer amount of time.

Wifi networks use a technique called 'collision detection', this is when the unit transmitting the data checks if any other units are in the process of transmitting data (i.e. to check if the 'air is clear') before transmitting data, this significantly reduces the chance of collisions occurring. If a collision somehow still occurs (the receiver checks this using a checksum), the unit receiving the data will broadcast (to all transmitters) a request for retransmission, the transmitting units will then attempt to retransmit the data after a randomly selected period of time.
This solution may not be as elegant space and budget wise, and I don't really know how you could check if the air is clear (maybe using pulsin?) but this is how it's done in computer networking so it must have some merit in terms of reliability!

 

[hippy]

@ Buzby : It may be I used N1200 rather than T1200, it was a long time ago.

Best thing is to start with a slow system for testing ...

TX1:
Do
Pause 3000
SerOut ... ( "UUUUUUUUUUUU" )
Pause 50
SerOut ... ( "ABC", "TX1" )
Loop

TX2:
Do
Pause 5000
SerOut ... ( "UUUUUUUUUUUU" )
Pause 50
SerOut ... ( "ABC", "tx2" )
Loop

RX:
Do
SerIn ... ( "ABC" ), b1, b2, b3
SerTxd ( b1,b2,b3, "-" )
Loop

You should then see "TX1-tx2-TX1-tx2-TX1-" and so on. That will prove the setup is working. There will probably be some corruption along the way if there is a clash and both transmit at the same time