HC-11 and HC-12 transceiver modules

PhilHornby

Senior Member
Do the units work as simplex or have they got to be used half duplex?
They're definitely duplex, rather than simplex - but whether they're full or half duplex I don't know ... I haven't had need to pass data simultaneously in both directions.

(Definitions: http://www.iec-usa.com/Browse05/DTHFDUP.html)


him as well said:
Don't suppose its possible to simulate any of this?, can two picaxe communicate serially hardwired, the info seems to imply that the HC-12 just replaces a serial link?
Yes you can do that. The only real difference is that the HC-12 parcels-up the data into packets - so the gaps between the characters will be different. Also the HC-12 presumably has a finite buffer size (and there's no flow-control), so there would come a point where you have to stop sending data, and wait for the HC-12 to deal with it. (I seem to recall that this varies with the mode the HC-12 is in).
 

JPB33

Senior Member
I'm hoping someone reading this thread who uses the HC-12 can point me in the right direction.

I've configured my recently arrived HC-12 to 5dBm and 2400bps using the Robert Rozee utility and got the correct confirmation response of the changes. My serout from picaxe is N2400. I have successfully used the earlier MX-05v wireless modules to transmit data between picaxes. Substituting the HC-12 produces no results and I'm fast getting lost!

Can the HC-12 work as a direct substitute for the earlier wireless simplex modules, does the HC-12 need to be used as a transceiver or do I need to change some other settings on the HC-12 to achieve communication?

Thanks Peter
 

JPB33

Senior Member
Changed mine to N and now working fine---many thanks---great thread--thanks for posting all that encouraging info!
 

PhilHornby

Senior Member
My serout from picaxe is N2400. I have successfully used the earlier MX-05v wireless modules to transmit data between picaxes...
...Can the HC-12 work as a direct substitute for the earlier wireless simplex modules, does the HC-12 need to be used as a transceiver or do I need to change some other settings on the HC-12 to achieve communication?
As per Jeremy - mine all use "T" - though I've used T9600 (the default) throughout. Since you're communicating with the UART on the HC-12 module's µController , you have to match whatever that uses - and there's no means to change it. In the case of the MX-FS-03V (MX-05V is the receiver), you're simply switching a transistor ON & OFF.

(MX-05V/MX-FS-03V schematics here: http://forum.hobbycomponents.com/viewtopic.php?f=25&t=1324)

Re: not using it as a Transceiver - I see the ability to perform a handshake and know your data got to its destination, as being one of the great features of the HC-12.
 

inglewoodpete

Senior Member
The following configuration is what I used on a 28X2, utilising the background transmit/receive option.
Rich (BB code):
      'Initialise serial uplink
      hSerSetup B9600_8, %00001  '9600 baud @ 8MHz, Background, no invertion (receive or transmit)
      '                  %abcde where, for X2 chips:
      '              Bit a (bit 4): disable hserin       a=0*enable;     a=1 disable
      '              Bit b (bit 3): disable hserout      b=0*enable;     b=1 disable
      '              Bit c (bit 2): Receive  mode -      c=0*No invert;  c=1 Invert receive
      '              Bit d (bit 1): Transmit mode -      d=0*No invert;  d=1 Invert transmit
      '              Bit e (bit 0): Foregrd/Backgrd mode e=0 foreground; e=1*background
      '
 
Last edited:

JPB33

Senior Member
I can see lots of advantages in using it as a transceiver with the confirmation of a handshake but as coding is not my first language everything must be learned. But least its working--dead chuffed with that.

I only want to remote switch and read displays at present, do you have a simple example of a handshake for this, also what's the best command to use to send a pin high on the remote picaxe using serout? Think I'm making my code more complex than it needs to be as can be seen in my receive example. Thanks

input C.4,C.2
output C.0,C.1

do
pause 100
serin c.4, T2400, b0
b1 = 200
pause 100
if b0 >= b1 then
high C.1
else if b0 <= b1 then
low C.1
endif
loop
 

PhilHornby

Senior Member
Handshake example (Part 1)

I can see lots of advantages in using it as a transceiver with the confirmation of a handshake but as coding is not my first language everything must be learned. But least its working--dead chuffed with that.
Point taken :eek:

I did a bit of speed-programming ... these are (untested) examples of a transmitter and receiver pair. I assumed Picaxe 08M2. They demonstrate the use of 'qualifiers' and 'timeout' on Serin. The receiver sits and wait for the string "MODE:", which the transmitter will start its message with. The transmitter then sits and waits for the string "REPLY" (which the receiver starts its response with).

Transmitter code here. Receiver in next post (forum limits again :sigh: )
Rich (BB code):
#picaxe 08m2

; Transmitter

symbol BAUD = T2400                                   ;baud rate to use

symbol OUTPin = C.4                                   ;Pin connected to HC-12 RX
symbol INPin = C.3                                    ;Pin connected to HC-12 TX

symbol MODE_OFF = 0                                   ;command to request "OFF" at remote end
symbol MODE_ON = 1                                    ;command to request "ON" at remote end

symbol TIMEOUT = 500                                  ;no. of mS to allow for other end to respond

symbol ACK=1                                          ;Other end did as we asked
symbol NAK=2                                          ;Other end didn't do as we asked (for whatever reason!)
symbol NO_REPLY = 0                                   ;no response from other end

symbol RESPONSE = b0                                  ;somewhere to receive remote reply

;
; START PROGRAM
;
      RESPONSE = NO_REPLY                             ;Initialise the response from the receiver
      High OUTPin                                     ;Do this or the first serout will send rubbish
do
      ;
      ; Send "ON"
      ;
      serout OUTPin,BAUD,("MODE:",MODE_ON)            ;Request "ON"
      serin [TIMEOUT,NOREPLY],INPin,BAUD,("REPLY"),RESPONSE ; Get response - or timeout in 500mS
      gosub Check_Response                            ;what was the reply?
      ;
      ; wait a while
      ;
      pause 5000                                      ;wait 5 secs.
      ;
      ; Send "OFF"
      ;
      serout OUTPin,BAUD,("MODE:",MODE_OFF)           ;Request "OFF"
      serin [TIMEOUT,NOREPLY],INPin,BAUD,("REPLY"),RESPONSE ; Get response - or timeout in 500mS
      gosub Check_Response                            ;what was the reply?
      ;
      ; wait a while
      ;
      pause 5000                                      ;wait 5 secs.
      goto loop_end                                   ;repeat the loop
;
; Timeout handler - we come here if no reply in 500mS
;
NOREPLY:
      sertxd(cr,lf,"No reply")

loop_end:   
loop


Check_Response:
      ;
      ; We received *something*
      ;
      select Case RESPONSE
            Case ACK
                  sertxd (cr,lf,"It worked!")
            Case NAK
                  sertxd (cr,lf,"It failed :-(")
            else
                  sertxd (cr,lf,"Unexpected response")     
      end select
      RESPONSE = NO_REPLY                             ;Re-Initialise the response from the receiver
      return                                          ;return to caller
 
Last edited:

PhilHornby

Senior Member
Handshake example (Part 2)

Rich (BB code):
#picaxe 08m2

; Receiver

symbol BAUD = T2400                                   ;baud rate to use

symbol OUTPin = C.4                                   ;Pin connected to HC-12 RX
symbol INPin = C.3                                    ;Pin connected to HC-12 TX
symbol RELAYPin = C.2                                 ;Pin to turn ON or OFF on command from transmitter

symbol MODE_OFF = 0                                   ;command to request "OFF" from transmitter
symbol MODE_ON = 1                                    ;command to request "ON" from transmitter

symbol TIMEOUT = 500                                  ;no. of mS to allow for other end to respond

symbol ACK=1                                          ;Tell transmitter, we did as asked
symbol NAK=2                                          ;Tell transmitter we failed to do as asked

symbol COMMAND = b0                                   ;somewhere to receive command from Transmitter
symbol RESPONSE = b1                                  ;variable to hold the response we send.

;
; START PROGRAM
;
      output RelayPin                                 ;Configure our 'Relay' connection
      High OUTPin                                     ;Do this or the first serout will send rubbish
do
      ;
      ; Wait for command from transmitter (forever)
      ;
      serin INPin,BAUD,("MODE:"),COMMAND              ;wait for command from Transmitter
     
      ;pause 10                                       ;give transmitter a chance to post 'Serin',
                                                      ;before we reply.
                                                      ;It's not needed in this example, because it will
                                                      ;be a while before we send a response anyway.
                                                      ;(Though we need to reply in 500mS, or other end will
                                                      ;assume we didn't get the command)
     
      ;
      ; We received a command - what was it?
      ;
      select Case COMMAND
           
            Case MODE_ON
                  sertxd (cr,lf,"Pin ON")
                  High RelayPin                       ;Turn Relay ON
                  RESPONSE = ACK                      ;Say it worked
                 
            Case MODE_OFF
                  sertxd (cr,lf,"Pin OFF")
                  low RelayPin                        ;Turn Relay OFF
                  RESPONSE = ACK                      ;Say it worked
            else
                  sertxd (cr,lf,"Unknown command!")  
                  RESPONSE = NAK                      ;say it failed
      end select
      ;
      ; Send reply to transmitter
      ;
      serout OUTPin,BAUD,("REPLY",RESPONSE)           ;send the handshake
loop
 
Last edited:

JPB33

Senior Member
Apologies for the slow reply. Thanks Phil for the example of a handshake with the followable explanations, viewed it via sertxd and it worked perfectly first time! I'm pleasantly surprised at the range of the HC-12, even with the power turned well down and on the rubbish aerials it easily goes through brick walls so will do what I want.

Never used select case before, read the manual but confused about the rules for using it, also confused about what can be sent as as a variable over serial? In my mind variable are b1 etc as read on the code explorer!
 

PhilHornby

Senior Member
... it worked perfectly first time!
That's quite amusing. Because you hadn't replied, I assumed there must be a problem with the code; I was in the process of testing it, when you wrote your message.

It doesn't work for me :D ... reason unknown at the moment! (Turned out to be a crossed over RX/TX on one end:eek:)

Him as well said:
also confused about what can be sent as as a variable over serial? In my mind variable are b1 etc as read on the code explorer!
You could think of the variable names b0,b1,b2 etc as being pre-defined locations for storing data. It's usual in programming languages to define 'variables' (with meaningful names) to hold your data - but when you define them, you don't normally tell the processor where you want them storing 'physically' - the compiler does the job for you.

That's where Picaxe Basic differs. Not only do you declare the 'variable' (such as "RESPONSE" in my program), but you also have to say which location to use. So for example, in my code: "Symbol RESPONSE=b0". From then on, you can refer to a variable called RESPONSE, rather having to remember that location b0, is where the incoming reply from the other Picaxe is stored.

Once you've successfully invoked the "ABC - Check Syntax" function, the Code Explorer will show you both versions.
 
Last edited:

Goeytex

Senior Member
The HC-12 is a half-duplex device. Since it has a single antenna and an RF switch to switch the antenna between TX and RX sections it cannot possibly send and receive at the same time. Furthermore the RFIC (Si4463) cannot be in TX mode and RX mode at the same time.

I have not seen any full duplex RF modules. However I think one could be made using 2 inexpensive RFICs operating on different channels with one dedicated to receive and another dedicated to transmit. A microcontroller with 2 MSSP modules and 2 USARTS could do the Serial stuff.
 

JPB33

Senior Member
Good to hear you've got yours going, nice easy none damaging mistake! Thanks for the explanation on the variables, making more sense now and keen to try it out. Theres not a great deal of code but it contains quite a lot of "unknowns" at least to me because I've not thought of using them or perhaps needed them.

Can simulator be used with a code containing serin? It always stops wanting a value but Iv'e not managed to work round that yet. Sorry if I've missed the obvious!
 

Goeytex

Senior Member
The sim stops at "serin" and will only continue after you enter the correct number of bytes. For example. If it stops at "serin C.1, N2400_8, B1,b2,b3" Then you need to enter three numbers separated by commas. Example: 48,126,118. The sim will then assign B1 a value of 48, B2 a value of 126 and soon. It will then use these values as if they were received by serin.
 

ZOR

Senior Member
How can I find what channels are allowed in the UK for the HC12? I want to operate two transmission setups but one gets frozen if the other is on. Presumeably changing to different channels for each TX?RX might change that?? Thanks
 

neiltechspec

Senior Member
As far as I am aware

Ch1 433.4Mhz
Ch2 433.8Mhz
Ch3 434.2Mhz
Ch4 434.6Mhz

All at 10mW (I use 11dbM / 12mW which is close enough for me, as there isn't a 10mW option)

Neil
 

ZOR

Senior Member
Many thanks both, I had missed that. good informative reading.

A bit worrying to get the mozzila message this is an unsafe site to log into? Thats all new!
 

PhilHornby

Senior Member
A second failure...

Another of my HC-12s, in a remote Heater Controller stopped reporting back to base.
I've had another occurrence of this. It was in a recently deployed unit (6 weeks?), with a new HC-12.

The HC-12 had stopped both sending and transmitting. It was also not responding to "AT+SLEEP" commands.

Rebooting the Picaxe did not clear the problem, but power-cycling the whole unit did. At this point, it seemingly went back to working perfectly again...

I can't think of anything which could have caused the HC-12 to lock up in this manner and I could tell that the controlling Picaxe 14M2 was working normally. As a precaution, I've swapped the HC-12, with one that had previously been on long-term deployment.
 

techElder

Well-known member
Reminding you that error messages can be sent from the HC-12, and there might be a looping/waiting condition locking up the program.
 

PhilHornby

Senior Member
The last time this happened, I managed to destroy the HC-12 (somehow!). This time it's intact, so I'll make a test rig for it and give it a stress test.
 

The bear

Senior Member
@ Phil Hornby,
Re; post #221 I've managed to kill two HC-12's in the past, probably through mishandling, e.g. plugging into its socket incorrectly.
However, today,( I've got an HC-12 monitoring a readADC transmission, volts set at 4v6). When it was powered up, the bench power supply showed a short circuit.
Quick switch-off, smell test, the Hc-12 was the culprit. The 3v3 on-board was short circuit.(Info to follow). Did a transplant from one of the duff HC-12's
and its working OK now.
Did you see where a diode in series with a 5v0 supply to the HC-12 was recommended?

Info; https://www.scribd.com/document/236605655/XC6206P332MR-662K-SMD-Voltage-Regulator

XC6206P332MR-'662K' SMD Voltage Regulator

Regards, bear..
 

PhilHornby

Senior Member
Did you see where a diode in series with a 5v0 supply to the HC-12 was recommended?
Yeah ... but it's only a suggestion ... so I ignored it ;-)

Being serious, it says this applies "if the module is working in the transmitting state for an extended time". None of the modules in this 'system' transmit for an extended time - they spend the vast majority of their time asleep. There is a HC-12 in my "Central Control Unit" that never sleeps; it's been continuously powered (from 5V) since June 2016 - seemingly without issue.

The HC-12 that has just suffered from this problem - whatever it is - isn't dead ... it was just in a non-responsive state. It took a power-cycle to make it come back to life - a Picaxe-only RESET didn't help, even though this would have gone through my HC-12 initialisation/setup routine.

I've brought the errant HC-12 back to base and put it in another project. Only time will tell if it will 'fail' again.
 

PhilHornby

Senior Member
Another locked-up HC-12

I have had another of these lock-up incidents.

This time, it was on my battery-powered "reference/test unit" which had been running undisturbed for several months. For all those months, the Picaxe had checked the room temperature every 30 seconds and had sent a message via the HC-12 if there was a significant change (or five minutes had elapsed, since the last report).

Once again, resetting the Picaxe - or even reloading its program did not resolve the problem. I experimented with holding the "SET" pin low for an extended period and also watched for signs of data coming OUT of the HC-12 (it should acknowledge "AT+SLEEP"). The HC-12 appeared as dead as a Dodo - until I popped the battery connector off and re-attached it. I am 100% certain this is not a Picaxe problem!

Here is the circuit and a photo of this particular PCB. The only thing I can think of, that might - possibly - explain this issue, is the fact that I have omitted the recommended electrolytic across the HC-12 supply...

IMG_20180417_163900.jpg Room Controller V2.jpg
 
Last edited:

manuka

Senior Member
Phil: I've rarely used electrolytics across battery supplies when current drains are modest. Hence I suspect some innate HC-12 (or clone) issue is the culprit ? Time for a fresh topic on "HC-12 issues" ? Stan.
 

Jeremy Harris

Senior Member
I have had four HC-12s running 24/7 now for well over a year. These are all modules that I bought in 2016, in two batches, from the same ebay supplier. None have every glitched at all, let alone locked up, although some were accidentally turned off maybe three or four times during power cuts so have been randomly reset (although one is running on a battery backed up supply so has never been off).

I don't have any special decoupling on any of mine, but they are all connected physically pretty close to the Picaxe that they are communicating with, with track lengths of maybe 20mm at most between the HC-12 supply and the Picaxe supply pins, that are decoupled. All have an electrolytic on the supply, adjacent to the 5V regulator. I've made no attempt to reduce the idle power consumption with any of mine, as the permanently on ones are all mains powered.

I'd be interested in finding out exactly what the cause of these lock-ups is, if it can be tracked down.

Edited to add:

I've just checked all the HC-12s I have and all seem to have the "T300" marked crystal.
 
Last edited:

techElder

Well-known member
The original HC-12s that I bought in 2017 are marked "T300", but a recent batch bought in 2018 are all marked "30.000 MHz". I haven't had time to test this new batch for compatibility, but will soon.
 

Grogster

Senior Member
The ones with the oscillator marked T300 are genuine. The ones marked with 30.000MHz are fakes. They are also off-frequency by about 37kHz, which might make them illegal depending on your chosen frequency of operation. See this thread.

I have also been trying to work out what is going on here but it would seem that there are indeed fake HC12's on the market now.

I would not trust them. Being clones, they could have all sorts of issues - if they work at all. Lockups of the module could just be another example of that. The fakes are hard to spot. The easiest way to tell is by using a scanner radio to check the chosen frequency is indeed where you asked it to be, and not 37kHz further up the band.
 

techElder

Well-known member
Grogster, I have HC-12s that have both of the different labels on the crystals, but have none of the differences that you identify in your posts. In other words, except for the crystal labels, they are physically identical.

I'm struggling with how to determine if the frequencies are different in a definitive way. I don't have time to devote to comparing channels or frequencies or pair compatibility, but I will do that.

Perhaps, the "FAKE" label is strong at the moment? It wouldn't be the first time that eBay facilitated the marketing of rejected production. :D
 

Grogster

Senior Member
Perhaps.

I have tested six HC12's so far, all with the "30.000MHZ" crystal marking, and all of them are off frequency by the same amount, so we are not just talking one dud one here, but probably heaps of them. I have not tested the other seven I found in my stock, but I probably will just to see what they do.

If you use two or more of the suspected clones, they work fine with each other. They won't, however, talk with the genuine ones with the T300 crystal osciallator markings.

I guess it depends what you plan to use them for, and so long as you don't mix and match them, they should still work OK. I, however, am convinced of clones entering the market, so I am trying to work out how to order direct from the manufacturer, but their website is only in Chinese - no English version, which makes that kinda hard. ;)
 

techElder

Well-known member
Also, there are plenty of recent examples of HC-12s listed on eBay now with photos (mixed sometimes) of crystals that are black in color, so I'm presuming a "plastic" crystal instead of a "metal can" crystal.

Perhaps there's a method of identifying the true frequency of these HC-12s without sending them to a lab for certification?
 

Grogster

Senior Member
Sure is. Just use a UHF scanner radio, or if you have one, a spectrum analyser. I have both and a frequency counter. The counter and the scanner both confirm that if you set channel 1(433.4MHz), you are actually transmitting on 433.437MHz. The genuine ones are smack on 433.400MHz as they should be for the same channel selection. :)
 

PhilHornby

Senior Member
HC-12 lockup - same module as 3 days ago

This same physical HC-12 has 'locked up' for a second time, in the space of a few days. Previous occurrences have been different modules and many months apart.

I am now wondering if this is power supply related?

The battery pack (pictured) is currently down to 3.77V - which according to the manual is within spec.

I might trying stress testing it, using my Bench PSU ...
 

Grogster

Senior Member
Hey Phil. :)

Are these modules the clones or genuine ones? I seem to recall reading that the ones that lock up are suspected clones, but I just want to be sure I am thinking the right thing. I have had issues running HC12's before at 3v3, but 3v7 should be within spec, yes. Can you try running the HC12's at 5v for the purposes of testing? I run all mine at 5v and never have any issues.(with the genuine ones!)

EDIT: I just took a look at your photos, and see you ARE running from 5v. Do the modules lock up when on battery power only, or do they also lock up if you leave the 5v power on the circuit?
 
Last edited:

PhilHornby

Senior Member
Are these modules the clones or genuine ones? ... I have had issues running HC12's before at 3v3, but 3v7 should be within spec, yes. Can you try running the HC12's at 5v for the purposes of testing? I run all mine at 5v and never have any issues.(with the genuine ones!)
I don't think I have any clones, though I can't easily confirm that.

The supply voltage appears to be a red herring ... I left my test unit running a diagnostic program all night with a 3.2V supply. The Picaxe woke the HC-12, then put it to sleep again 288mS (nap 4) later. After a one second delay, the operation was repeated.

Looking at the HC-12 output, it returned "OK+SLEEP" 23000 times and "ERROR" 120 times. It never stopped responding completely during this test.
 
Top