1
\$\begingroup\$

I attempted to ask this question on the network engineering forum but the mods there think superuser.com is a better place for it, but when I posted there, they think here is the best place for this type of question. so here goes:

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

\$\endgroup\$
  • 1
    \$\begingroup\$ "9600 baud" and "a 1 microsecond break" don't belong in the same sentence. Each character will take on the order of 1040 microseconds. But don't just change the baud rate - the radio probably has assorted delays and turnaround latencies given in its data sheet. \$\endgroup\$ – Chris Stratton Oct 14 '17 at 6:19
  • \$\begingroup\$ I'm sorry I don't have time to write a proper answer, but actually your round-robin style is not crude at all. It is called TDMA Time Division Multiple Access and this is exactly how GSM works. Provided every unit has data to send during every one of its slots then this is the most efficient way to do it! If however, each unit only has data to send occasionally and at random times, then something like CSMA/CD could work, but every transmission would have to have a corresponding acknowledgement, and potential retransmissions, and this can cause intermittent speed variations \$\endgroup\$ – Mark Ch Oct 14 '17 at 6:19
  • \$\begingroup\$ I may go for TDMA. I also updated my question to illustrate the issue I have with it at this time. \$\endgroup\$ – user152879 Oct 14 '17 at 15:52
1
\$\begingroup\$

It sounds like the transceiver is half duplex and you want to use it for full duplex communications. So the answer that suggests itself to me is use two modules. One for dedicated receiving, and the other for dedicated transmission. Then design your packet protocol to include station identification so you can toss out any packets originating from localhost.

Or use a board designed for full duplex operation.

\$\endgroup\$
  • \$\begingroup\$ I think its half-duplex too and of course I'll use a radio module for everything that's meant to connect to the network. I already am planning on making one device for mostly transmission and the remaining devices as slaves, but I'm more interested on the best way to do efficient timing so people that play the game won't experience lag because of wireless transmission/reception. \$\endgroup\$ – user152879 Oct 14 '17 at 3:07
  • \$\begingroup\$ If the game is running on a PC, I would use wireless network cards to be honest. Writing WINSOCK code isn't that difficult. \$\endgroup\$ – Anthony Bachler Oct 14 '17 at 3:16
  • \$\begingroup\$ Not quite. Only one of the wireless devices is connected to the PC. The heart of the remaining wireless devices are running off 8051 microcontrollers. Windows/linux sockets will not really help here since I'm pushing the 8051 to the limits. The actual chip I'm using to directly interface with the HM-TRP is AT89C4051 with a 22.1184Mhz xtal. \$\endgroup\$ – user152879 Oct 14 '17 at 4:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy