Best protocol for multi-device wireless communication in limited-resource micros

[mik3ca]

I'm working on a setup in where multiple devices (about 25) each running on 8051 based micros connect to each other via wireless UARTS (specifically the HM-TRP radio modules).

At this moment, my packet format is as follows:

Byte 1: Recipient
Byte 2: Sender
Bytes 3 - 28: Data
Byte 29: Checksum

I ran my entire code through a simulator (uCsim) and all results are perfect. I run it on real hardware and use LED's for debugging and the checksum never passes.

When I was using the wireless modules in the past, I did notice a loss of random bytes at times, so maybe I could blame the wireless settings?

For clarification, I configured the module as follows:

- Air and UART rate: 56Kbps
- Deviation Frequency: 58Khz
- Bandwidth: 175Khz (58Khz times 2 + baud) (I'm trying to follow carsons rule?)
- Maximum transmit power

All other values in the module are at defaults.


I'm curious. Could I get much better luck if I send and receive only 4 bytes at a time wirelessly?

I'm talking about this packet format:

Byte 1: Recipient
Byte 2: Sender
Byte 3: Data
Byte 4: Checksum

Or maybe 3 bytes and have the checksum as last packet and have packets as follows:

Packet 1-n:

Byte 1: Recipient
Byte 2: Sender
Byte 3: Data

Last packet:

Byte 1: Recipient
Byte 2: Sender
Byte 3: Checksum for last n packets

Which would be best in the wireless world? I want to be able to send lots of data but I don't want data missing in the air in the process.

 

[Beau Schwabe]

Does your scheme work in a direct point to point connection without any wireless? ... Get that going first. You may need to implement handshaking from the receiver sending back to the transmitter that data was received properly and if not have the transmitter send the data again.

I usually add an additional random seed or incremental rollover seed in my data packet that is also calculated into the checksum so that even when you repeatably send the same data it still varies slightly.

 

[Nigel Goodwin]

I'm assuming this is the on-going saga of trying to build a 'laser quest' type system?, by totally ignoring the way it's done commercially and trying to use radio links and out dated processors.

 

[mik3ca]

Ok, I'll do just that. I have the random seed field set.
One thing that keeps slipping my mind is that I need to add a delay between when the radio received data to when the radio sends data. I think it's called a ramp-up time or something.

Just because something is "outdated" in comparison to today's standards does not mean it has zero use for my project.

 

[Beau Schwabe]

The data packet I typically use follows something like this ...

[Attention BYTE][Command BYTE][Seed BYTE][Data BYTE1][DataBYTE2][CRC BYTE]

The "Attention BYTE" can be anything that has an ODD ASCII value .... ! ... or ....?... The reason for this is because I like to implement auto baud detection and the START bit combined with an ODD ASCII value being sent will generate a predictable START bit that can be timed and used to determine the proper bit width for the remainder of the 6-BYTE data packet.

The "Command BYTE" prepares the receiver of what needs to happen and how the remaining BYTES are processed.

The "Seed BYTE" can be a random BYTE or simply a BYTE that increments and rolls over every time a Data packet is sent. Adds slight robustness to transmitted data.

The "Data BYTE1" and "Data BYTE2" is the actual information sent.

The "CRC BYTE" a simple XOR of the first 5 data BYTES in the packet. Nothing fancy for most applications, but adds a layer of robustness to the transmitted data as well.


Most important.... get your code working without the wireless connection FIRST. Then worry about going wireless.