HC-11 and HC-12 transceiver modules

Jeremy Harris

Senior Member
I'm still not clear, from reading this thread, whether you can use Robert Rozee's software to configure an HC-12 pair (one of which is connected via USB) to allow wireless programming of a Picaxe chip. Hence, it would be an alternative to the discontinued ERF/URF pair.

Is this possible?
I've not tried, and it would depend on whether or not the serial interface allows the "break" capability or not (which is just holding the Tx line at a logical 0 for longer than a single frame, on command). My understanding is that the only difference between ERF modules purchased from Rev Ed and those purchased from elsewhere, is that the Rev Ed versions were especially programmed to add the "break" capability. Its unlikely that the HC-12 modules support this, as it seems few RF serial modules do. The Rev Ed version of the ERF was the only 0.1" pin spacing module that I'm aware of that has a "break" capability.
 
Last edited:

hippy

Technical Support
Staff member
My understanding is that the only difference between ERF modules purchased from Rev Ed and those purchased from elsewhere, is that the Rev Ed versions were especially programmed to add the "break" capability. Its unlikely that the HC-12 modules support this, as it seems few RF serial modules do.
That would also be my guess. The two differences in the ERF compared to the XRF are that signal polarities are inverted ( idle low to match RS232 polarities rather than the idle high of UART polarity ), and the ability to carry the out of band break signal is added.

Signal polarity can be changed using hardware but passing the break over is usually the obstacle to over the air programming. That usually requires a change to the firmware which runs on the RF chip itself, or additional micros have to be put between sender and RF module and between RF module and target PICAXE to make it work.

In that respect I would say the HC-11/HC-12 were more XRF alternatives than ERF replacements.
 

manuka

Senior Member
One could become confused with Nottingham based Ciseco's/Wirelessthings ever changing product range... Many of their RF offerings are 800-900 MHz, and 433 MHz seems only available as an option. Their UHF module,as befell the ERF, seems now also discontinued.

However their "extremely popular" XRF,although approx. 4-5 times the HC-12 delivered price, pleasingly remains available. Check details here - note pinouts are 2mm pitch & thus are NOT breadboard friendly...

EXTRA: The XRF's TI "ChipCon" CC1110 RF IC seems not as sensitive as the HC-12's SiLab equivalent.

Stan.
 

stevesmythe

Senior Member
However their "extremely popular" XRF,although approx. 4-5 times the HC-12 delivered price, pleasingly remains available. Check details here - note pinouts are 2mm pitch & thus are NOT breadboard friendly...
Might be useful to note that RevEd produces a "proto shield" (intended for use with its AXE401 Shield Base, but also Arduino Uno-compatible). The proto shield has a section designed for mounting an XBee (or, in this case, an XRF module).
 

manuka

Senior Member
Just to hand from fellow Kiwi Robert Rozee
I've created repositories on github for the HC-11, HC-12, and reformatted HC-12 user manual. These should be there long term, as long as github remains free. See:
https://github.com/robert-rozee?tab=repositories
It may well be worth Rev.Ed working in with Rob. on the HC-12, especially given the recent announcement that Wirelessthings/Ciseco are sadly "turning off the big switch" on ALL their once popular A/S/E/U/XRF modules ...
 

cachomachine

Senior Member
A while ago, I ordered a set of HC-12 just to play with and was able to transfer bytes back and forth for at least 500 meters using 14M2 at both end.
A couple of weeks ago, I tried them again but was unable to get any communication between both. (Both have the factory settings)
Thinking that I could have blown them, I ordered a new set but still no communication.

Here is the transmitter code:
#picaxe 14M2
#No_data
Setfreq M8
dirsb=%00000010
dirsc=%00000000

main: For b0=0 To 255
Serout b.1,T9600_8,(b0)
Debug
Pause 3000
Next b0

And the receiver code:
#picaxe 14M2
#No_data
Setfreq M8
dirsb=%00000000
dirsc=%00000000

Main: Serin b.2,T9600_8,b0
Debug
Goto main

And the wiring diagram:Diagram.jpg

Am I overlooking something?
 

hippy

Technical Support
Staff member
There is no obvious reason why they stopped working and won't work now. Have you reprogrammed the two 14M2 in case the program has been overwritten or somehow become corrupted ? Have you tried other 14M2 chips ?

When using a Txxxx baud rate you should have a HIGH B.1 at the start of your transmitter program and perhaps a PAUSE after that, but not having those would only corrupt the first byte of data sent.

The dirsB= and dirsC= are unnecessary and can be removed from both transmitter and receiver.

One thing to try is to connect the TXD ( serial into HC12 ) pin on your receiver module to V+ or to V+ via 1K. Some modules may see noise on their receiver pins, keep sending that, and that can jam-up comms entirely.
 
Last edited:

hippy

Technical Support
Staff member
I am not familiar with HC-12 but probably worth checking which of TXD/RXD are in and out just in case those are miswired.

Other than that I cannot see why it's not working.
 

hippy

Technical Support
Staff member
Thanks.

3 RxD - Input (weak pullup) - UART data input, TTL level. 1k resistor connected in series inside the module

4 TxD - Output - UART data output, TTL level. 1k resistor connected in series inside the module

5 SET - Input (10k pullup) - Parameter setting control pin, active low level. 1k resistor connected in series inside the module
The TXD/RXD seem opposite to how you have things in your diagram in post #127.
 

AllyCat

Senior Member
Hi,

was unable to get any communication between both. (Both have the factory settings


Perhaps one of your neighbours has bought a pair and is (also) continuously blasting out data at an (illegal) power level, using the "factory settings". :rolleyes:

Cheers, Alan.
 

techElder

Well-known member
Has anyone attempted a multiple transceiver "network" (sort of like the chicken coop door system) with the HC-12? I envision an alarm system with multiple sensors, but only one receiver. Or multiple chicken coop doors to close and open! :D
 

Pongo

Senior Member
Has anyone attempted a multiple transceiver "network" (sort of like the chicken coop door system) with the HC-12? I envision an alarm system with multiple sensors, but only one receiver. Or multiple chicken coop doors to close and open! :D
I could use something like that too. I was thinking of using an 08M2 with each TX sending a different code, and at different repetition frequency to minimize collisions. I need up to 100 meters range in open country.
 

PhilHornby

Senior Member
No chickens involved :) ... but I have such a multi-master setup.

Six temperature logging/heater controlling nodes report into a central 'command unit'. They report either every five minutes, when there's been a 'significant' change in temperature, or when someone presses the "Sync" button. The 'command unit' acknowledges their data, and updates them with the latest thermostat 'setpoint'.

This was originally implemented using Bluetooth HC-05's, and the multiple collisions that occurred during the required 'linking' operation made it an absolute nightmare. I had all kinds of Random-'backoff' algorithms, but none of them worked very well. The knock-on effect, was to make battery operation impractical.

With the HC-12, I get almost zero collisions - presumably because the connection is state-less, and over in a flash. I also get fantastic range (as in, I cannot make them fail in my application), and ~100% data integrity.

Note: I read on some web site or other, that the SI4463 that the HC-12 uses, has some kind of 'listen-before-talk' functionality. I can't find that in the datasheet though.
 

inglewoodpete

Senior Member
the HC-12, I get almost zero collisions - presumably because the connection is state-less, and over in a flash. I also get fantastic range (as in, I cannot make them fail in my application), and ~100% data integrity.
Tell us more about the settings you have configured (Power, mode, channel number or freq., baud rate and typical packet size). Also, what sort of antenna?

I'm currently on a steep learning curve, in the development stage, so possibly have my two units too close together. Using the lowest power setting, I'm getting about 85% round trip success rate with 8-byte packets @ 9600baud.
 

PhilHornby

Senior Member
All HC-12 are initialised at Power-On, with "AT+P8" ... and "AT+C064". (100mW @ 458.06MHz). I came to conclusion that this combination is probably OK for the UK...
...all other settings are left as default.

Data-wise, a remote node sends the following: <lf>*U*U* ... pause 80mS ... <data>

Because the Receiver was designed around an interrupt condition of the STATE pin of an HC-05 going high, I reworked it to generate an interrupt when the Receive data line goes low instead. The <lf> is just for formatting on my debug receiver (when present) and the "*U*U* " was a bit of 'conditioning' that I thought might help. In practice, the <linefeed> is enough to wake the other end up by itself. The 80mS gives the receiver time to enter the ISR and post a 'serin' for the rest of the data. It waits for a prefix of "START ", and has a timeout label configured.

Typical data looks like this: START 3,984,0,300,1,P,180,45<cr> (There's a node number, a temperature, voltage, sequence number, node-type etc). The 'serout & serin' make use of the "#" processing, to perform the ASCII to binary conversions.

When the read completes, there is at least a 10mS delay, before it posts back its response. (i.e. there's some processing, then a 'pause 10mS').
The reply is in a similar vein, but there is no need to wake the other end up - by now, it's sat on a 'serin', with a qualifier of "REPLY "...

<lf>REPLY 1088,1072,1072,1072,1072,1088,180,45<cr> (These are my six thermostat 'Setpoints', and something to identify who the message was intended for)

I've just used the 'spring' on the HC-12, accepting that it may well be sized for 433MHz, rather than 458MHz. I've not had any issues with the units being too close together ... there are currently three sat on my workbench about 35cm apart. Even at 100mW, they seem perfectly happy.

I did have an issue with a poorly designed PCB though: see my post on Page 11 of this thread.

Just to add:

I have one of the 'USB' HC-12 modules plugged into a PC, and find it really useful for monitoring the data-flow. (Using Putty/Realterm etc).
 
Last edited:

Pongo

Senior Member
Good stuff, thanks for posting that :)

All HC-12 are initialised at Power-On, with "AT+P8" ... and "AT+C064". (100mW @ 458.06MHz). I came to conclusion that this combination is probably OK for the UK...
To clarify, the connected picaxes are sending "AT+P8" ... and "AT+C064" at Power-On - is that correct?
 

techElder

Well-known member
With the HC-12, I get almost zero collisions - presumably because the connection is state-less, and over in a flash. I also get fantastic range (as in, I cannot make them fail in my application), and ~100% data integrity. Note: I read on some web site or other, that the SI4463 that the HC-12 uses, has some kind of 'listen-before-talk' functionality. I can't find that in the datasheet though.
Phil and Allycat, fantastic information that you are posting. "listen-before-talk" is what I was worried about creating in an application/network similar to yours. Thanks!
 

techElder

Well-known member
Data-wise, a remote node sends the following:
Phil, after some thought, it occurs to me to ask this question. Perhaps due to a collision (or other reason), what do your transmitters do if they don't receive a response from the central receiver?

<lf>REPLY 1088,1072,1072,1072,1072,1088,180,45<cr> (These are my six thermostat 'Setpoints', and something to identify who the message was intended for)
 

PhilHornby

Senior Member
Comms Error Handling

Perhaps due to a collision (or other reason), what do your transmitters do if they don't receive a response from the central receiver?
They just retry, after a random 'NAP'. The number of times they retry is influenced by the current battery voltage. The thought behind the 'random' element was to try and prevent multiple nodes getting into some sort of synchronised shouting match, where none of them would back down. :)

This code was already in place from the original Bluetooth design, where the problem was getting the link established. The original room nodes were purely sensors/loggers and didn't receive anything back (they knew their data had been received, because Bluetooth has the concept of a 'connection' ... i.e. STATE pin HIGH meant that a one-to-one link was established). To counter the Bluetooth connection unreliability, I'd introduced the concept of an 'active' room node, that controlled the heating as well as just logging the temperature. This meant that I already had a two-way protocol in place before swapping to the HC-12s. The new 'active' nodes don't retry as often as the original 'passive' ones; if they don't receive an updated thermostat Setpoint, they can just keeping using the previous one (stored in EEPROM).
 

manuka

Senior Member
Months later -2017 ! Down under summer holiday tinkering (and a looming academic year) mean wireless e-project thoughts may be in order.

Although the venerable 433 MHz Dorji ASK modules remain popular, it may increasingly be worth focusing on the HC-12.

Refer a features summary attached. This was first organised mid 2016, but diverse experiences & alternatives may since have developed. Any thoughts ? Stan.
 

Attachments

techElder

Well-known member
Stan, you state that you used a single LI... battery. Do you have any thoughts on life before changing in your application / testing?
 

PhilHornby

Senior Member
Bit of an update of my experiences...


  • I managed to snap the 'spring' off one module and it took part of the PCB with it - so no hope of re-attaching it. Range without it, is still 4+ Metres @ 100mW :p (though the module at the other end is still complete)

  • Another of my HC-12s, in a remote Heater Controller stopped reporting back to base. Inspecting my code, I could see a possibility of an endless loop, if it should have decided to stop responding to the "AT+SLEEP" command. (Previously, a test module had got into a state where it responded with "f", instead of "OK+SLEEP" and the code was an attempt to fix it - by simply repeating the "OK+SLEEP", until it did work...).
On arriving at the remote location a.k.a holiday home and investigating, I ascertained that it was a distinct possibility - so rather than power-cycling the whole unit, I removed and re-plugged the HC-12. The result was heat, flat batteries and a whiff of 'magic smoke' :(. That particular HC-12 is now completely dead and the small capacitor next to the VCC pin is looking rather worse for wear!

I'm somewhat worried about the possibility of a similar meltdown occurring without my intervention!
 

manuka

Senior Member
Texasclodhopper: "Changing" ? LiFePO4 cells are of course rechargeable, & additionally they hold an extremely steady 3.2-3.3 V until almost totally discharged. Furthermore the supply voltage doesn't sag significantly under heavy load (perhaps such as an HC-12 drawing 100mA when transmitting).

LiFePO4 are mega reliable too - I've had them up in single LiFePO4 AA powered outdoor solar security lamps that are now into their 4th year. Although we are only a stones throw from the sea, and can have significant rain, wind & blistering UV, not one of 7 over assorted sites has missed a beat in that time. Earlier 1.2V NiMH powered equivalents almost all died within a year, often due to corrosion at the multiple cell contacts...

Naturally 3.2V is low side marginal for powering an HC-12 of course, but such a single rechargeable LiFePO4 cell supply may have niche appeal for solar charged applications,especially when the HC-12 receiver spends significant time SLEEPing.


PhilHornby: Yikes - alarming indeed- best you tell us more of this ! Pictures etc ?

Stan.
 

PhilHornby

Senior Member
IMG_0063.jpg

I've been trying to think of an error on my part that might have caused this - perhaps I re-inserted it 'one pin over' ? I seem to recall that HC-05's didn't like that treatment :eek:

(Inserting it the wrong way round isn't possible - there isn't room in the case).
 
Last edited:

PhilHornby

Senior Member
Regards hardware reliability - 100% up to now. (With the previously mentioned exception during testing, when one of them decided to ignore the AT+SLEEP command - don't know if it was this one or not)


One thing I have noticed, is that - unlike Bluetooth - data integrity is not guaranteed. The error rate is very, very low - but it does happen. When it does, it almost always seems to take the form of a bit being SET, that shouldn't be (occasionally more than one bit). Since my Heater Controllers receive "Set Point" information from a central controller, I've just embarked on adding a CRC to the message.


Something struck me about the board you pictured ... it's not the same as the one I'm looking at!


Could there be such a thing as a Fake HC-12 :confused:

(The forum software seems to be acting strange - and won't let me upload the picture - so I've put it here: https://www.dropbox.com/s/w747fqmbiytosml/IMG_0066.png?dl=0)

UPDATE

I've just noticed that mine is the same as the one in your previous picture - there's obviously more than one version.
 
Last edited:

srnet

Senior Member
I would imagine that the actual over air packets are themselves CRC checked, in which case any apparent bit errors would be down to firmware issues between the RF IC and the serial interface.

And if the over air packets are not CRC checked, then it would be manadatory for any application using them to implments their own CRC checking, UHF comms are just not reliable enough to operate without error checking.
 

inglewoodpete

Senior Member
I would imagine that the actual over air packets are themselves CRC checked, in which case any apparent bit errors would be down to firmware issues between the RF IC and the serial interface.
I have come to the conclusion that the HC-12 does no CRC checking of over-the-air data packets. I get quite a few character drops occurring, so I have had to incorporate my own basic CRC checking and handshaking so that data transfer in guaranteed.
 

manuka

Senior Member
Re "fakes" - perhaps early prototypes or 2nd sourced? Mine are sourced from satisfyelectronics ebay store, & all look like the corrected image below. Yes -indeed corrected, as somewhat alarmingly their web site shows this mirror imaged !

HC-12 prices have pleasingly eased somewhat in recent months,although most outlets (Alice etc) still offer them globally freight free.

Re CRC: Check the micromite friendly Back Shed's forum about CRC & the HC-12's presumed lack of. Stan.
 

Attachments

srnet

Senior Member
I have come to the conclusion that the HC-12 does no CRC checking of over-the-air data packets. I get quite a few character drops occurring, so I have had to incorporate my own basic CRC checking and handshaking so that data transfer in guaranteed.
Well, I would not be wanting to run any UHF comms without error checking.

And implementing you own seems to be a significant extra complication.
 

techElder

Well-known member
Longitudinal Redundancy Check (LRC)

Here's a snippet that I've used to generate a longitudinal redundancy check (LRC). I've not used it with my HC-12 setup yet, but I have used it on an RS-485 setup with success.

Code:
[color=Navy]#macro [/color][color=Black]LRC_RAM[/color][color=Blue]([/color][color=Black]LRC,LRCRAM_BEG,LRCRAM_END[/color][color=Blue])
   [/color][color=Green]' Procedure to generate longitudinal redundancy check (LRC) 8-bit field
   ' Uses bptr, LRC (byte variables)
   ' Uses LRCRAM_BEG, LRCRAM_END as constants pointing to start RAM and end RAM
   ' bptr is set to the beginning RAM location of bytes to be added
   ' All bytes important including LRCRAM_BEG to LRCRAM_END
   ' LRC poked into 1 byte after LRCRAM_END
   [/color][color=Black]LRC [/color][color=DarkCyan]= [/color][color=Navy]0                                   [/color][color=Green]; clear sum
   [/color][color=Purple]bptr [/color][color=DarkCyan]= [/color][color=Black]LRCRAM_BEG                         [/color][color=Green]; start here in RAM
   [/color][color=Blue]do
      [/color][color=Black]LRC [/color][color=DarkCyan]= [/color][color=Black]LRC [/color][color=DarkCyan]+ [/color][color=Purple]@bptrinc                   [/color][color=Green]; Add in 8-bit variable (carries discarded)
   [/color][color=Blue]loop until [/color][color=Purple]bptr [/color][color=DarkCyan]> [/color][color=Black]LRCRAM_END
   LRC [/color][color=DarkCyan]= [/color][color=Navy]$FF [/color][color=DarkCyan]- [/color][color=Black]LRC                           [/color][color=Green]; Subtract from 0xFF to produce a ones-complement
   [/color][color=Black]LRC [/color][color=DarkCyan]= [/color][color=Black]LRC [/color][color=DarkCyan]+ [/color][color=Navy]1                             [/color][color=Green]; Add 1 to produce the twos-complement
   [/color][color=Blue]poke [/color][color=Purple]bptr[/color][color=Black], LRC                            [/color][color=Green]; Poke LRC into 1 byte after LRCRAM_END[/color]
[color=Navy]#endm[/color]
 

PhilHornby

Senior Member
Error checking - but what flavour?

I can't decide whether to go for a simple checksum, an LRC or a CRC ... and if the latter, which polynomial ?

In the absence of any other reason, I thought I'd go for the one used by the Imagintronix Sensors that I decoded - simply because I have the code already written to do it. (I created it using this tool: https://pycrc.org/ - but annoyingly, its output is 'C', rather than Picaxe Basic :rolleyes:)

A bigger problem up to now, was finding the Program Space for it. I've addressed that in my 14M2 Room Controllers, by expanding into #Slot 1. The 20X2-based Central Control Unit has things I can trade (amusingly, it already implements a checksum of the data it sends to its companion 08M2 (Web Server) - because everyone knows, Serial Data is unreliable - especially when travelling down a comms. line 3cm long @ 9600bps ;))

It is worth re-iterating ... the number of errors I have seen is minute - apart from my previously documented hardware faux-pas (Post #104).
 

techElder

Well-known member
It is worth re-iterating ... the number of errors I have seen is minute
Then that is why I use the LRC. It is fast and provides some minimum checking. I've forced 1-bit errors to show up, but haven't done any documented testing.
 
Top