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

 

hi Robin,
Check thru these AAC posts.
https://www.allaboutcircuits.com/search?q=hc12

E

 

Also AAC has an article about it
https://www.allaboutcircuits.com/pr...enting-the-hc-12-wireless-transceiver-module/

 

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

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

 

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

 

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

 

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.

 

It's a little more fiddly for my immediate example. For the delays around entering/exiting command mode and putting HC-12 to sleep I need to check each time the current consumption and wait long enough for my ammeter to settle