# HC-12 Undocumented limitations

#### Robin66

Joined Jan 5, 2016
266
I've been experimenting with one of these modules for a while now but I waste a lot of time getting caught out by undocumented limitations. I was hoping people would share their observations and any tips that may save some time.

As an example, it's documented to allow a delay of 40ms to enter command mode, and 80ms to exit command mode. But it isn't documented that any delay needs to be provided between receiving "OK+SLEEP" and setting HSET=1. However if I don't leave a ~10ms delay the module doesn't properly go to sleep, evident from the ~1mA consumption, cf. ~22uA when asleep.

Also, the 40ms and 80ms are not a function of the mode according to the datasheet. But these are very long delays which significantly increase the power consumption in my use case. Does anyone know if you can safely trim these times in FU1 mode?

This is the best version of the datasheet I've seen
http://statics3.seeedstudio.com/assets/file/bazaar/product/HC-12_english_datasheets.pdf

#### Robin66

Joined Jan 5, 2016
266
I have taken the time to read that article but unfortunately I'm already far ahead of it's technical detail. The example in the article circumvents any undocumented issues by liberally adding long delays. In the example below a 500ms delay is added after the HC12.print() command. I'm trying to understand why an undocumented 10ms delay is required after the command has been echoed from HC12. The below doesn't know if it's been echoed or not

Code:
delay(100);                              //
digitalWrite(HC12SetPin, LOW);            // Enter command mode
delay(100);                              // Allow chip time to enter command mode
Serial.print(SerialReadBuffer);          // Echo command to serial
HC12.print(SerialReadBuffer);            // Send command to local HC12
delay(500);                              // Wait 0.5s for a response
digitalWrite(HC12SetPin, HIGH);          // Exit command / enter transparent mode
delay(100);                              // Delay before proceeding

#### ericgibbs

Joined Jan 29, 2010
11,925
Hi Robin.
In my VB programs I don't add any delays for Status checking or changing.
Once the HC12 cmd mode is set, I send AT+RX<crlf> and get an instant response and display of the Status.
E

#### Robin66

Joined Jan 5, 2016
266
Hi Robin.
In my VB programs I don't add any delays for Status checking or changing.
Once the HC12 cmd mode is set, I send AT+RX<crlf> and get an instant response and display of the Status.
E
Good to know. I suspect the documented delays as the worst-case scenario for FU2 because they can't be bothered to doc the same for the faster modes. If these are in the region of 10us you may get away with it. I'll do some testing in FU1 mode trimming the delays one at a time, starting with the 80ms delay.

I am doing this for a practical reason. In my app the module is sleeping for ~1minute and then waking up to do a heartbeat and going back to sleep. Whether the heartbeat takes 50ms or 200ms has a big impact on the battery life

Last edited:

#### ericgibbs

Joined Jan 29, 2010
11,925
It should be easy to set up a bench test, using one HC12 in TX master mode and a second HC12 in RX [ACK] mode, using a scope to check the timing.