Page 1 of 1

TB387 20dBm High_Power 2.4GHz Serial Module (HCMODU0089)

Posted: Mon Jul 06, 2015 2:48 pm
by admin
Image

Order yours here

Image

The TB387 high powered module (HCMODU0089) provides a means of transmitting serial data over much greater ranges than standard RF modules such as Bluetooth. Simply connect a TTL serial interface to a transmitter and receiver module and the modules will transparently transmit your data over a 2.4GHz signal at a range of up to 400 meters. In practice we have successfully transmitted single byte data in free air in excess of this. The module can also be placed into a configuration (AT) mode and using simple ASCII 'AT' commands sent via its serial port its default parameters can be changed. This includes changing its frequency to one of 80 channels or its two byte ID which allows a theoretical 65536 modules to communicate with each other. To try and reduce errors caused by poor reception an automatic retry system is enabled (defaults to 100 retries) which will repeatedly resend a data packet a fixed number of times.



Image

Model number: HCMODU0089
Working voltage: 3.3V-5.5V;
Frequency range: 2402~2482MHz
Transmit power: 20dBm;
Receiver sensitivity: -87dBm;
Operating temperature: -40~+85 ° c;
Transparent transmission mode baud rate:
2400, 4800, 9600(Default), 14400, 19200, 38400, 57600, 115200, 12800, 25600
AT mode configured baud rate fix to: 9600;
Transmission current: 120mA peak
Receive current: 30mA
Module dimensions: 32mm (l) x 12.8mm (w) x 11.3 (h including header)
Antenna length: 106mm (inc ufl connector)



Image

Image

1....VDD: 3.3V or 5V power supply
2....GND: Ground
3....TXD: serial port output, Arduino or USB to serial port RXD
4....RXD: serial port input, Arduino or USB to serial port TXD
5....CMD: Enter PIN AT mode, active low level;


Image



AT Command Mode:

To enter AT mode you must pull the CMD pin low *AFTER* the module has been powered up. AT mode can be entered and left at any point by toggling this pin. To exit AT mode either pull the pin high or leave it floating.

Once in AT mode default BAUD rate is 9600 irrespective of what the BAUD rate is set to.

When sending AT commands a line feed (LF) or carriage return (CR) is not required.




AT Commands:

Change baud rate for communication mode:

AT+BAUD=<BAUD>

Where <BAUD> is one of the following values:
0 = 2400
1 = 4800
2 = 9600
3 = 1440
4 = 19200
5 = 38400
6 = 57600
7 = 115200
8 = 128000
9 = 256000

Note that lower BAUD rates will result in lower transmission errors. Also, be aware that the module has a 32 byte serial buffer. If the receiving module has a lower BAUD rate you should allow time for the receiver to transfer the data.


Change frequency (channel):

AT+FREQ=<FREQ>

Where <FREQ> is the frequency in MHz in addition to the modules base frequency of 2402MHz. E.g.

AT+FREQ=8

Will change the module channel to 2410MHz (2.410GHz). Maximum frequency setting is 2480MHz.


Change the modules ID:

AT+ID=<ID>

Where ID is a two byte identifier giving a theoretical 65536 different identifiers. Modules must have the same ID value to communicate with one another.


Change the number of automatic resends:

AT+RETRY=<VALUE>

Where <VALUE> is the number of retries.


Query the current BAUD rate:

AT+BAUD?

Example response:

BAUD = 2


Query the current frequency:

AT+FREQ?

Example response:

FREQ = 0x27


Query the current ID:

AT+ID?

Example response:

ID = 0x1234


Query the current number of retries:

AT+RETRY?

Example response:

RETRY = 0x64


Query the current software version:

AT+INF

Response:

Thank You For Choosing TB387
Version:2.00


Restore to factory settings:

AT+RESET



Basic Arduino Sketch To Remotely Blink An LED:

Code: Select all

/* FILE:    TB387_Transmit_Example.ino
   DATE:    24/06/15
   VERSION: 0.1
   AUTHOR:  Andrew Davies

06/07/15 version 0.1: Original version

PINOUT:

Module......Arduino
VDD.........5V
GND.........GND
TXD.........Rx
RXD.........Tx

   
You may copy, alter and reuse this code in any way you like, but please leave
reference to HobbyComponents.com in your comments if you redistribute this code.
This software may not be used directly for the purpose of selling products that
directly compete with Hobby Components Ltd's own range of products.

THIS SOFTWARE IS PROVIDED "AS IS". HOBBY COMPONENTS MAKES NO WARRANTIES, WHETHER
EXPRESS, IMPLIED OR STATUTORY, INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ACCURACY OR LACK OF NEGLIGENCE.
HOBBY COMPONENTS SHALL NOT, IN ANY CIRCUMSTANCES, BE LIABLE FOR ANY DAMAGES,
INCLUDING, BUT NOT LIMITED TO, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES FOR ANY
REASON WHATSOEVER.
*/


void setup() 
{
  Serial.begin(9600);
}

void loop() 
{
  /* Send out a 'H' to set the remote LED pin high */
  Serial.print("H");
  delay(1000);
  /* Send out a 'L' to set the remote LED pin low */
  Serial.print("L");
  delay(1000);
}

Code: Select all

/* FILE:    TB387_Receive_Example.ino
   DATE:    24/06/15
   VERSION: 0.1
   AUTHOR:  Andrew Davies

06/07/15 version 0.1: Original version

PINOUT:

Module......Arduino
VDD.........5V
GND.........GND
TXD.........Rx
RXD.........Tx

   
You may copy, alter and reuse this code in any way you like, but please leave
reference to HobbyComponents.com in your comments if you redistribute this code.
This software may not be used directly for the purpose of selling products that
directly compete with Hobby Components Ltd's own range of products.

THIS SOFTWARE IS PROVIDED "AS IS". HOBBY COMPONENTS MAKES NO WARRANTIES, WHETHER
EXPRESS, IMPLIED OR STATUTORY, INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ACCURACY OR LACK OF NEGLIGENCE.
HOBBY COMPONENTS SHALL NOT, IN ANY CIRCUMSTANCES, BE LIABLE FOR ANY DAMAGES,
INCLUDING, BUT NOT LIMITED TO, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES FOR ANY
REASON WHATSOEVER.
*/

#define LEDPIN 13

void setup() 
{
  Serial.begin(9600);
  /* Set the pin that will control the LED to an output. */
  pinMode(LEDPIN, OUTPUT);
}

void loop() 
{
  char Data;

  /* Has a byte of data been recived? */
  if (Serial.available() > 0) 
  {
    /* If so then get the data */
    Data = Serial.read();

    /* If the received byte is a 'H' then set the LED pin high */
    if (Data == 'H')
      digitalWrite(LEDPIN, HIGH);

    /* If the received byte is a 'L' then set the LED pin low */
    if (Data == 'L')
      digitalWrite(LEDPIN, LOW); 
  }
}




FAQ:

What is the range of these modules?

The manufacturer specs the maximum range in open air to be 400 meters. In our own range test we have seen successful transmissions at around 615 meters using single byte data and good weather conditions (see best practices below).

Can I transmit to more than one receiver?

Yes, so long as the receivers are on the same channel and have the same ID then it is theoretically possible to transmit to up to 65534 receivers.



Best practices for getting maximum range

To achieve the best possible range there are several things you can take into consideration:

Lowering the transmission rate (BUAD) of your data - lowering the data rate will reduce the likelihood of packet corruption.

Keep the antenna of the receiver in the same orientation as the transmitter - this will have a significant effect on range.

Keep the antenna away from solid objects, especially metal - RF signals do not like to transmit though solid objects. Nearby metal objects will also de-tune your antenna and reduce its range.

Use a smooth power supply - When transmitting, the module can easily draw 120mA. This can cause momentary dips in your power supply (especially if powering from an Arduino) and in turn can cause the module to be temporally kicked off frequency. If you are having transmission problems even at small distances this could be the cause. Try placing a relatively small capacitor across the modules power supply (e.g. 10uF).

Change the channel - The modules operate on the 2.4GHz frequency spectrum. This frequency range is shared by a lot of modern devices such as WiFi, Bluetooth, wireless cameras etc. The channel you are on may be very busy so try changing the modules channel to a different frequency.

Move the receiver - 2.4GHz signals like to bounce off solid objects. These reflected (multi-path) signals then recombine and can cancel out or multiply with each other to create dead zones and hot spots. Simply moving the receiver slightly may move it out of a possible dead zone.



Disclaimer: Libraries, example code, and diagrams are provided as an additional free service by Hobby Components and are not sold as part of this product. We do not provide any guarantees or warranties as to their accuracy or fitness for purpose.

Descriptions and diagrams on this page are copyright Hobby Components Ltd and may not be reproduced without permission.

Re: TB387 20dBm High_Power 2.4GHz Serial Module (HCMODU0089)

Posted: Tue Mar 10, 2020 4:15 pm
by MarkE
This is a very good module, but it has some gotcha's that seemed worth documenting for those who follow on, as I haven't seen them elsewhere. I originally had a setup with two Arduino Megas, each with a TB387, and each end could act as both sender and receiver. Each message was a single byte sent at 9600 baud using the default module settings. The protocol was that the sender sent a message, the receiver acted on it and then sent an acknowlegement back, so the sender knew it was in step. Later, I re-purposed one end so it controlled two receivers (they had no buttons to press), using the same underlying protocol. The intention was that depending on the message, one or other receiver would act and respond, and the other would ignore the message. Along the way I found the following:
- The TB387s have to be physically separated by at least a couple of metres, maybe more, before communication worked. In real life operation this doesn't matter much, but it's a pain when trying stuff out as you can't sit the two ends next to one another.
- Although probably obvious, it's a pain programming and debugging on a Uno or Nano, as you can't upload the code via the USB if the TB387 is plugged in. The programmer simply hangs. Fortunately I'd started with a Mega, and that's got another couple of serial ports.
- I couldn't make multiple receivers configured identically work reliably together. If I turned off one receiver, the other would accept its commands and ignore the rest as designed, but with both receivers turned on, each often required the same message multiple times before acting and acknowleging. I tried separating the receivers by 10m or so, but this didn't help. My suspicion is that the underlying TB387 handshaking (which you can't really control) gets messed up. Note that the protocol I'm using does not involve both actively transmitting an acknowlegement - only one acts on a given message and replies.
- To overcome this I gave the two receivers different IDs (using the AT command), and the sender selected the appropriate TB387 ID before sending and then awaiting its response. It took quite a bit of effort to get AT to work: First, I found it was necessary to put a delay (I used 200mS) between setting the Command pin to 0 and sending the request; Second, the documentation on the format of the number to send is unclear - you need to send the right number of digits appropriate to the request, as a hex value, but without the 0x; Third, it doesn't seem to be documented, but you get a Y<cr><lf> back if the update is recognised, and a N<cr><lf> if it isn't. If you don't know this then your first real data read will get gibberish.

The most irritating aspect is not being able to use multiple receivers configured the same way, even though the documentation suggests you can. If anyone reading this has had better luck and made it work, it would be good to hear about.

Re: TB387 20dBm High_Power 2.4GHz Serial Module (HCMODU0089)

Posted: Wed Mar 11, 2020 10:03 am
by andrew
The TB387s have to be physically separated by at least a couple of metres, maybe more, before communication worked. In real life operation this doesn't matter much, but it's a pain when trying stuff out as you can't sit the two ends next to one another.
Unfortunately this is a side effect of them being high power modules. As you mention you will indeed need to make sure they separated from one another. When they are close together it's like someone shouting in your ear with a megaphone. The receiver chain simply gets swamped out with signal. If you've not already, removing the antennas will help a lot.


Although probably obvious, it's a pain programming and debugging on a Uno or Nano, as you can't upload the code via the USB if the TB387 is plugged in. The programmer simply hangs. Fortunately I'd started with a Mega, and that's got another couple of serial ports.

Yeah the serial port on the Uno/Nano is shared by the USB interface IC so this is a common issue with these Arduinos when using their serial port. If you really need to use a 328 based Arduino have you considered using the software serial library?


I couldn't make multiple receivers configured identically work reliably together. If I turned off one receiver, the other would accept its commands and ignore the rest as designed, but with both receivers turned on, each often required the same message multiple times before acting and acknowleging.
First, I found it was necessary to put a delay (I used 200mS) between setting the Command pin to 0 and sending the request;
The most irritating aspect is not being able to use multiple receivers configured the same way, even though the documentation suggests you can.

You should defiantly be able to send the same message to two receivers with the same ID at the same time. This may not be causing your issue but a couple of suggestions...

Firstly most RF transmitters are very sensitive to power supply noise. The problem is they require very brief but relatively high amounts of power when transmitting and some power supply's simply cant react to this fast enough. The 5V supply on Arduino boards defiantly have this issue. This causes a momentary dip in the power supply upsetting the modules VCO which in turn causes the transmitter to momentarily be kicked off frequency. The result is quite often this causes the first part of what your transmitting to get lost.

If you have any spare capacitors laying around between about 10uF-100uF it is worth putting one across the transmitting modules power supply to see if that improves reliability.

The second issue is a possible gotcha when switching serial paths. The Arduino print function is non-blocking. This means the Arduino will move on to the next instruction after the print statement whilst it is still transmitting serial data in the background. So for example if your next instruction was to switch the module into AT mode you could inadvertently chop off the serial data.

Re: TB387 20dBm High_Power 2.4GHz Serial Module (HCMODU0089)

Posted: Tue Apr 21, 2020 5:28 pm
by MarkE
Hi! Thankyou for the comprehensive reply, it contained much useful stuff. However, I am still concerned about the multiple receivers problem, and I implemented some cut-down code to illustrate the problem. I put 100uF caps across the power for all the wireless modules, and removed the aerials for closer working. I've attached the code in case anyone can identify something I'm doing stupidly, or else can replicate the problem.

There are two pairs of applications, Receiver/Transmitter and 'Simple' versions of each. The non-simple ones are still very basic and mimic the wireless exchange or my real application, sending a 1-byte message from Transmitter to Receiver, and then, depending on the message, back to the Transmitter again. Activity is diplayed on the LED on pin 13. In the Transmitter directory is a trace file which was used when I had the serial output for debugging illustrating the breakdown in responses: I subsequently disabled that so there was no chance of it interfering as described in your reply. The Simple version simply sends a 'beat' every half second to one box (running the non-Simple code!) turning the LED succcessively on and off, and it replies with the same instruction to the Transmitter. When running normally, the two should flash their LEDs regularly, in tandem. This happens until I turn on the other box, running the SimpleReceiver code... at this point the regularity of the LEDs gets lost, and they either stay on or off for multiple beats. Turning the SimpleReceiver off restores regularity. SimpleReceiver does absolutely nothing in its code, once setup.

To me, the fact that turning on another wireless module with code that does nothing can interfere with the communication between the other two does suggest a real problem. If someone had the time at some point to take a look that would be great, because my workaround of switching ids is a real pain and doesn't work well in many scenarios and if it turns out to be unnecessary that would be brilliant.