I am creating a game in which a number of devices need to wirelessly communicate with each other using the HM-TRP radio module. Specs for that module can be found here: http://www.hoperf.de/rf/fsk/HM-TRP.htm. For now, I'm working on communication between only two devices.
Just to be on the safe side, I adhered to the default speed of 9600bps and configured both HM-TRP modules to talk to the processor at 9600bps and to talk to the wireless world at 9600bps.
Currently I have one device transmit the correct sequence of characters at a relatively high speed with maybe a 1 microsecond break in-between. The HM-TRP responds correctly with a blinking red light.
This is where it gets interesting...
On the receiver side, when I don't want to transmit, it seems to acknowledge the remote signal via a blinking green light, however when I try to receive data and then one microsecond later after processing the full byte, I try to transmit data, I noticed the HM-TRP only in transmit mode (red light blinks, but green light does not). Once I stopped transmitting, the green light blinks again.
This makes me think I need to invent a better collision avoidance protocol but at the same time I don't want communication speed to be too slow or the game will seriously lag.
My ideas
Do I configure the HM-TRP module?
One idea which I haven't played with is to configure the HM-TRP module itself so its wireless I/O speed is 115kbps and is Uart I/O speed to 9600bps, but I'm not sure if that is going to work, or if the module would have a problem with data management because of two different speed settings within the same module.
Do I increase delays by fixed values?
I could increase delay between time a character is received and the time a character is transmitted. If I follow this option, by how much should I wait minimum? Could I get away with waiting the time it takes for one bit to transfer for the 9600bps speed?
Or go round-robin style?
The rather crude option which I might have to go for is to give each device a unique number and have a timer run so that when the timer hits the same number a device has then that device is allowed to transmit until the timer changes the number.
So what would be the best way out here in terms of speed and being able to successfully transmit/receive characters?
For those who ask about wireless signal factors, all tests were done with the wireless chips located within 6 inches of each other, so odds of interference are like less than 0.01%
EDIT
For clarity, I added a diagram of a typical setup I'll have. Each box (except the actual computer) will have an AT89S52 (DATASHEET:http://www.kynix.com/uploadfiles/pdf/AT89S52-24AC.pdf)as the heart of all processing. The actual computer will connect to the central station to download game data. The data is stored on the central station's extended ram and the data is built up as the individual units send and receive data to and from it hence the green and red lines. Yes I know those lines could be improved but I hope I'm more clear.
explanation
UPDATE
I'm probably going to take a suggestion of going round-robin style but here's the issue. The timing:
9600 8N1 baud
bit delay = 104.17uS
byte delay = 1041.67uS (Start bit + 8 bits + Stop bit)
Seems ok, but In the end I'll be dealing with 40 or 50 players. For simplicity, I'll go with 50. Then for data, I decided to sequence every packet and stamp the sequence number to each nibble to prevent data corruption. Here's an example of a data (converted here to hex) one player wants to send out and assume that player number is 35h and the remote player is 46h:
30h 63h 75h 12h 94h 82h
So the data to the wireless serial line will be:
30h 51h 42h 63h 34h 05h 66h 37h 78h 59h 1Ah 2Bh 9Ch 4Dh 8Eh 2Fh
What I did was take the nibbles (from high to low) of the local then remote player number then do the same with 6 data bytes. I could do checksum but that means more work for the processor and elimination of another byte.
Now if I did some math here, I think the lag time for each player then would be:
byte delay = 1041.67uS times 32 bytes (16 for transmit, 16 for receive)
=33.3mS
Then it can get crazy for the waiting time since each player will always transmit something when its his turn. So the processing time for the remaining 49 players is:
=1631.7mS
Which means I have to wait one second to transmit and receive 32 bytes of data.
Maybe there's a better data protocol I can implement to make total processing time lower.
On a side note, I'm curious. with 9600 baud on an 8051 with 22.1184Mhz crystal, the Keil baud rate calculator suggests I use 0F4h for a timer value. but am I correct to assume it takes 96 clock cycles for that micro and crystal speed for a byte on serial to be processed? or does it actually take 192? If it takes 192 then I can make my baud rate 19.2K without losing characters.
Any other ideas how I can improve this? I don't want players waiting 1 second to send new data.
