HC-11 and HC-12 transceiver modules

PhilHornby

Senior Member
Sleep mode current not as advertised

The manual says:

AT+SLEEP
After receiving this command, the module will enter sleep mode upon exiting from command mode, with a working current of about 22uA. This mode doesn’t allow serial port data transmission. Upon entering command mode again the module will exit from sleep mode automatically.
This is my code :-

Rich (BB code):
Sleep_HC12:
      low HC12_set                                    ;take set pin low
      Pause FortymS                                   ;wait 40mS
     
      Serout TX_Pin,HC12BaudRate,("AT+SLEEP")         ;night,night ;-)
     
      high HC12_set                                   ;take set pin high, which actions the command
      Pause EightymS                                  ;wait 80mS for any changes to take effect
      return
I'm using FU3, CH64 (458.6MHz) @ 20dBm.

The HC-12 current drain is approx. 15.5mA before the "AT+SLEEP" and it falls to 1.7mA upon its execution. I've used a couple of FTDIs across the HC-12 to verify that the "AT+SLEEP" is accepted, and it is.

1.7mA is quite a long way from 22uA - has anyone else seen this?
 
Last edited:

robert.rozee

New Member
just a guess, but you may need to tristate the RxD and TxD pins connected to the HC-12 once in sleep mode. also, ideally the SET pin should be driven by an open-collector output - it has a 10k pullup within the module.

cheers,
rob :)
 

srnet

Senior Member
That would be my guess too.

Its often the case that to get minimum backup current you need to take account of all connections to the device, its easy for an I\O pin either to supply power to a device or to leak power away.
 

neiltechspec

Senior Member
My measurements are different to that and more closely follow the datasheet.

I suspect your additional circuitry is pulling some current, my 08m2 was pulling 1.1mA after applying a sleep command.

So, as a test, after sending sleep command the 08m2 was put into low power mode.

Measured with a Fluke 77 meter. Powered off a LiPo giving 4.01v.
FU3, CH4 (434.6Mhz) @ 11dbm (not relevant when idle & not transmitting).

Idle current 14.91mA

Sleep current between 20 & 30uA, as accurate as I can measure.

Neil.
 

PhilHornby

Senior Member
Here is the circuit. This is an existing project, that was originally using a HC-05 Bluetooth module:-

Drayton Active Room Node.jpg

I still only have 2 HC-12s in my possession ... but they both behave the same.

When sleeping, if I remove the connection to SET - i.e. let it float - the current increases by about 200uA. Removing the connections to RXD and TXD makes no measurable difference. The current in the GND leg is about 100uA higher than that in the VCC leg.

(AT+VERSION => HC-12_V2.3)
 
Last edited:

PhilHornby

Senior Member
Simplified circuit and code to demonstrate Sleep Current query

Using a Picaxe 08M2, in the following circuit :-

HC-12 Test Circuit.jpg

Using the following code :-

Rich (BB code):
#picaxe 08M2
#Terminal 38400
#No_data


;
; HC-12 458MHz FSK RF module connections
;
Symbol TX_pin              = C.2                ;output to HC-12
Symbol RX_pin              = C.1                ;input from HC-12 
Symbol HC12_SET            = C.4                ;"SET" pin, when low, places module into command mode - no data flow possible
;
; Assorted parameters
;
symbol FortymS          = 40 * 8
symbol EightymS         = 80 * 8
symbol OneSecond        = 1000 * 8
symbol FiveSeconds      = 5000 * 8
;
Symbol HC12BaudRate     = T9600_32              ;HC-12 Baud rate



;
;     START PROGRAM.
;
      setfreq M32                               ;for 9600 baud
;
;     Set o/p ports.
;
      dirsc = %00010101                         ;C.0,C.2 + C.4 are outputs.
      '
      ' Set transmit line idle state correctly, rather than waiting for an initial Serout to do it.
      '
      High TX_Pin                               ;set the line high.
      Pause 16000                               ;wait for serial terminal


      sertxd(cr,lf,"START")
      gosub Wake_HC12
      Pause FiveSeconds                         ;5 secs...
     
      low HC12_set                              ;take set pin low
      Pause FortymS                             ;wait 40mS


      sertxd(cr,lf,"AT+V")                      ;debug HC-12_V2.3
      Serout TX_Pin,HC12BaudRate,("AT+V")
     
      pause OneSecond                                      
     
      sertxd(cr,lf,"AT+DEFAULT")                ;debug
      Serout TX_Pin,HC12BaudRate,("AT+DEFAULT")
     
      pause OneSecond
     
      sertxd(cr,lf,"AT+SLEEP")                  ;debug
      Serout TX_Pin,HC12BaudRate,("AT+SLEEP")   ;night,night ;-)
     
      high HC12_set                             ;take set pin high, which actions the command
      Pause EightymS                            ;wait 80mS for any changes to take effect, before entering pass-thru


      end


Wake_HC12:


      low HC12_set                              ;take set pin low
      Pause FortymS                             ;wait 40mS


      high HC12_set                             ;take set pin high
      Pause EightymS                            ;wait 80mS for for any changes to take effect, before entering pass-thru
      return
      
Using Putty and an FTDI USB-Serial adapter, I logged the following response from the HC-12 :-

HC-12_V2.3
OK+DEFAULT
OK+SLEEP
The initial current was 15.3 mA, dropping to 1.6 mA when the AT+SLEEP was executed.
 
Last edited:

neiltechspec

Senior Member
That's odd.

Very similar to how I have mine connected, except I don't connect TXD as not needing to receive anything.

Try turning your ports C.2 & C.4 back to inputs (high impedance) after putting the HC-12 to sleep, before the "end" command.

Or, if your 08M2 is socketed, try unplugging it when HC-12 is in sleep mode.

Neil.
 

PhilHornby

Senior Member
No change - or at least, not for the better!

I added the following code :-
Rich (BB code):
      input TX_Pin                              ;set pins connected to HC-12
      input RX_Pin                              ;back to being inputs.
     
      input HC12_set                            ;** this causes the current drain to slightly INCREASE! **
Altering either or both C.1 / C.2 makes no difference. Changing C.4 back to an input, has the same effect as disconnecting it (or removing the 08M2 from the breadboard)...the current increases from 1.6 mA to 1.8mA.

When I first got the HC-12s, and was testing using Putty, I couldn't get AT+SLEEP to work properly, but thought it was maybe a timing problem, since I was plugging and unplugging the "SET" pin using a jumper. I do recall a difference between having it floating, and having it connected to +5V. I'm pretty certain that I did achieve 22uA at one point, but I couldn't reproduce it again...
 
Last edited:

PhilHornby

Senior Member
I found the problem...

There needs to be a Pause, between the transmission of "AT+SLEEP" and raising "SET". 40mS works, but may not be the definitive value.

Rich (BB code):
      Serout TX_Pin,HC12BaudRate,("AT+SLEEP")   ;night,night ;-)
      pause FortymS                             ;THIS IS ESSENTIAL
      high HC12_set                             ;take set pin high, which actions the command
      Pause EightymS                            ;wait 80mS for any changes to take effect.
 
Last edited:

neiltechspec

Senior Member
I pause for 100ms at that point & after sending anything else as well (16 bytes messages in my PIR's).

Maybe that's why I never saw the same problem.

Neil.
 

Jeremy Harris

Senior Member
Out of interest, I've been playing with the HC-11 modules to try and see if they would be an easy solution for simple remote controls, where there was no need for any intelligence at the switch end. Unlike the HC-12, the HC-11 has both a unique address (000 to 255) and an additional operating mode, FCxx, where one unit can be programmed as a command transmitter and the other can (allegedly) be programmed as a three channel command receiver. The data sheet gives an example where a transmitter is set up with a frequency and address in the normal way, with AT commands, and is then programmed to transmit the state of the three I/O pins (Tx, Rx and Set) to a receiver that is programmed with the same frequency and address, but set up as a slave receiver.

The indication is that if three switches to 0V are connected between Tx, Rx and Set on the command transmitter, then the slave receiver will mimic these by taking the appropriate pin low or high whenever a switch changes state. I programmed a pair of HC-11s to the same frequency and address, programmed the master using the AT+FCMF and programmed the slave using AT+FCSF. I copied the LED drive given in the HC-11 data sheet, with LEDs from the slave pins to the supply rail, via current limiting resistors, set to give around 8mA, well within the 18mA sink limit that's in the datasheet.

I can report that this mode sort of works. The Tx pin on the slave module reliably follows the level on the Tx pin on the master transmitter, but neither the Set pin nor the Rx pin respond at all. As far as I can tell the master transmitter sends the command when either of the other two pins changes state, as the supply current jumps up for a fraction of a second, indicating the transmitter has operated. No matter what I tried (and I tried three different modules) I couldn't get the slave unit to respond on the Rx or Set pins. Also, the range in this mode is short, so I suspect that the over-the-air baud rate for the command that is transmitted is quite high and independent of the baud rate set using the AT+Bxxxx command (I tried setting a low baud rate and the range stayed exactly the same).

Overall I found this disappointing, as I had hoped that this feature would be useful for making simple remote switches. It's OK if all you want to do is make a remote switch to turn something on or off in the same room, or very close by, and only need a single channel, but otherwise this mode isn't that useful.

I just thought I'd drop this in here to add to the pool of knowledge about the real world performance of these modules.
 

manuka

Senior Member
Thanks Jeremy but sorry your findings have been swampy. Given the very short range it's maybe more of a curiosity than feature...

And talking of knowledge pools -I've just received from Satisfy Electronics the cheap (~US$2) USB-UART adapter pictured. Aside from the near throwaway price it's flying leads caught my eye,as many other such adapters have fixed position pins that often won't match those on the module. I've been caught before with such mismatches on the likes of Dorji's DAC02 & had to rustle up my own adapter.

* Note than the adapter's TXD goes to the HC-12's RXD (& vice versa).

* An extra lead is needed to ground the SET pin when configuring via Rob Rozee's nifty GUI, but that's readily handled with some nifty mini clips etc.


* As many terminal programs (Termite etc) allow 2 way activity,the PC keyboard could perhaps also be used for sending text to the remote receiver.

* When PC monitoring (using a terminal program etc) the adapter's extension cable usefully allows raising of the HC-12 above obstructions into a signal sweet spot too. You could probably extend it many metres with extra USB cables of course.

* I've misplaced my Android OTG (On The Go) cable otherwise I'd also try with a popular Android terminal program. UPDATE - FOUND IT - SEE POST 99 BELOW

* With a Bluetooth module addition the entire HC-12 link could be handled by an Android app. such as Blueterm. In light of a "Waffle" communicator (& also the commercial goTenna ) I ponder this may have appeal for Lora™ modules in fact. Stan.
 

Attachments

Last edited:

PhilHornby

Senior Member
It's only 13 hours from China to the UK...

Have you got some sort of special arrangement with them? :D

"Thanks a lot for your purchase. We have arranged to send out your parcel 2016-06-27. It usually takes 20-40 working days to United Kingdom, if delayed, it will cost 40 working days, please pay more patient for the parcel."

I now have 3 separate consignments of HC-12s outstanding :(

Just for good measure, Paypal used a £->$ exchange rate of 1.31 : 1 ... has something happened ? :p
 

Jeremy Harris

Senior Member
My experience with Satisfy Electronics was great with the first order, around 8 days from order to delivery, which for something from China is remarkably quick. However, it's now nearly three weeks since they received my second order and still no sign, so I suspect there is variability in the postal system to here that causes the variable delay.
 

PhilHornby

Senior Member
Another AT+SLEEP gotcha

As I proceed with the task of converting my existing Bluetooth-based units to HC-12, I've stumbled upon another interesting little issue...

This particular project is 08M2 based, and used to communicate with a HC-05 using "HSerout"; later it was modified to read as well as write, though I used "Serin", rather than "Hserin" for this.

So when my previously developed code failed to put the HC-12 into 'sleep' mode, I assumed it was somehow related to the use of Hserout - but I was wrong...

The code snippet looks something like this :-

Rich (BB code):
Hserout 'of some description, detail unimportant'
Serin [2000,Timeout], RX_Pin, HC12Baudrate, ("REPLY "),#Sensor1,#Sensor2,#Sensor3,#Sensor4,#Sensor5,#Sensor6 ; Get responses

low HC12_set                                    ;take set pin low
Pause FortymS                                   ;wait 40mS
HSerout 0,("AT+SLEEP")                          ;night,night ;-)
Pause FortymS                                   ;ABSOLUTELY ESSENTIAL PAUSE - else sleep mode is 1.6mA, instead of 20uA
high HC12_set                                   ;take set pin high, which actions the command
Pause EightymS                                  ;wait 80mS for any changes to take effect.
Connecting my trusty usb-serial adapters, revealed that on most occasions, the HC-12 was responding "ERROR", to the "AT+SLEEP" command.

It took a while to realise, but I'd also made a slight change to my comms. protocol - in the shape of a few extra bytes on the end of the message (to be used as Sequence no. and CRC, at some future date). Since I've not finished implementing this, I thought it would be ok to simply ignore the extra data for now.

Not so ... when the "SET" pin goes LOW, any data arriving over the air seems to get diverted and acted upon, as though it had been received via the RXD pin - thus it was seeing "AT+SLEEP" intermingled with some extra characters!

For now, simply adding ",#b0,#b0" to the end of the SERIN has fixed it - but it raises some questions for the future. In an ideal world, I'd simply check for either an "ERROR" or "OK+SLEEP" response, but it's probably not going to be particularly easy to do on a Picaxe.

The issue I foresee, is a 'slave' node "talking over" the ongoing conversation between another slave and the central 'master'. When my boat comes in and I finally get my hands on another HC-12, I'll experiment to see if this is a plausible scenario.

As an aside, if I'm right about what is happening, it implies that you might be able to remotely configure a HC-12, if it has its "SET" pin held LOW...
 
Last edited:

PhilHornby

Senior Member
Code to check HC-12 response

In an ideal world, I'd simply check for either an "ERROR" or "OK+SLEEP" response, but it's probably not going to be particularly easy to do on a Picaxe.
It turns out the microcontroller on the HC-12 is slower than the Picaxe @ 32MHz, so this code to put the HC-12 to sleep, checks the result of the "AT+SLEEP" and retries 'till it works :-

Rich (BB code):
_Disable_HC12:
      ;
      ; Clear out storage used to received response.
      ;
      bptr = ByteArray                                ;address of our storage
      for b0 = 0 to 7
            @bptrinc = 0                              ;clear 8 bytes
      next b0
      ;
      ; Put HC-12 into command mode
      ;
      low HC12_set                                    ;take set pin low
      Pause FortymS                                   ;wait 40mS


      bptr= ByteArray
      ;
      ; Send the Sleep command...
      ;
      Serout tx_pin,hc12baudrate,("AT+SLEEP")
      ;
      ; and gather up the response. Should only be "OK+SLEEP" or "ERROR"
      ;
      Serin [2000,noAnswer],RX_Pin,HC12Baudrate,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc ; 8 bytes.
noAnswer:
      ;
      ; debug - print the response
      ;
      bptr = ByteArray
      sertxd(cr,lf,"R:",@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc)
      ;
      ; Ensure response is "OK+SLEEP".
      ;
      bptr = ByteArray
      For b0 = 0 To 7
            lookup b0,("OK+SLEEP"),b1                 ;string to compare with
            b2 = @bptrinc                             ;get Input byte
            If b2 <> b1 Then Goto _Disable_HC12       ;mismatch
      Next b0
      ;
      ; Response from HC-12 looks good,
      ; so take "SET" high to initiate power saving
      ;
      Pause FortymS                                   ;ABSOLUTELY ESSENTIAL PAUSE - else sleep mode is 1.6mA, instead of 20uA
      high HC12_set                                   ;take set pin high, which actions the command
      Pause EightymS                                  ;wait 80mS for any changes to take effect.
     
      return
 
Last edited:

manuka

Senior Member
Well sleuthed there Sherlock! The HC-12's onboard STM8S003F3 micro is indeed just a 16MHz device. The interpretative nature of PICAXE code however may be a factor?

Jeremy & Phil - re your ordering issues. China & NZ have a very beneficial free trade agreement that greatly speeds delivery. However even my deliveries from Rev.Ed are usually EXTREMELY rapid. I recall making a large online order once late on a Sunday (= Saturday UK) which arrived here Friday (NZ) morning.

Stan.
 

Attachments

Last edited:

manuka

Senior Member
Have located my micro USB- female USB OTG ("On The Go" ) cable, & rustled up an Android based HC-12 proof of concept -pictured. This is pretty "paint by number" bare bones, but can be simply LEGO style hacked together as needed to suit walkabout site coverage or data monitoring etc.

Note that no PICAXE is used at this end -"Micro? We don't need no stinking micro! It's effectively a self contained 433MHz send/receive setup that's all smart phone powered. The component items could be quite neatly packaged, especially if right/left angle or new style smaller & cheaper mini OTG adapters are used.

OTG has been around for some years, but not all Androids support it -OTG Helper can assist & verify. The "oldie but a goodie" hand-me-up Samsung Galaxy S3 shown does however. Suitable Android terminal programs abound, but DroidTerm suited here OK. It offers logging to SD etc, but the lack of landscape mode or text resizing may be an ergonomic issue - check many terminal alternatives on Google Play .

Cables may be a hassle, so Bluetooth appeals of course. I'll perhaps look at that next, probably focusing on the more recent BLE.

Extra: Android USB OTG hosting is quite magical but not well known. OTG cables are usually cheap ($) - IF you can find them! Although abounding on line, & even at better coin shops,many computer hardware & phone outlets never seem to have heard of them. If pushed you can organise your own adapter,with the charging "Y" maybe tempting for embedded smartphone setups.

Stan.
 

Attachments

Last edited:

MFB

Senior Member
Another collection of interesting tips from Stan!

However, it does seem a bit fiddly having to use a OTG - USB adaptor and then a separate USB - serial (or Bluetooth) adaptor but there does not seem to be an all-in-one alternative. Which is surprising when you consider how useful a OTG-serial adaptor would be for microcontroller development. A tablet based alternative to keyboard and LCD panel combinations could be more convenient and lower cost.
 

Jeremy Harris

Senior Member
Jeremy & Phil - re your ordering issues. China & NZ have a very beneficial free trade agreement that greatly speeds delivery. However even my deliveries from Rev.Ed are usually EXTREMELY rapid. I recall making a large online order once late on a Sunday (= Saturday UK) which arrived here Friday (NZ) morning.

Stan.
My HC-12s arrived yesterday, a bit over three weeks from the date I ordered (6th June). That's pretty average for deliveries from China, but they can be very variable. My first order of HC-12s from Satisfy Electronics arrived after just 8 days, so much faster than we usually get stuff from there. I have an order outstanding from another Chinese seller since 1st June, and waiting 5 or 6 weeks is not that unusual.

I'm sure that most of the delay is in the postal service, the puzzling thing is the wide variability, why some small packets should arrive in just over a week yet others take well over a month is a mystery.
 

PhilHornby

Senior Member
Chinese postal services...

I'm sure that most of the delay is in the postal service, the puzzling thing is the wide variability, why some small packets should arrive in just over a week yet others take well over a month is a mystery.
I think you're right - I've just received a parcel that was ordered from a Chinese eBayer ... but came by air from Singapore. It had Hong Kong Postal Service stickers on it, so I think it might have been on a ship as well, since it took 2 weeks in total.
 

PhilHornby

Senior Member
Interesting HC-12 / PCB interaction...

I finally received another batch of HC-12s, so popped one into my latest project that has sat there waiting for it for the last 3 weeks. The project worked fine on the breadboard, and also on its PCB. However, the HC-12 was connected by an umbilical cord to a little adapter board and so was dangling outside the box. When I added 5 header pins to one of my new HC-12s, I was somewhat dismayed to find that its comms. were exceedingly unreliable :-(

I found that when I attached it via a similar 'umbilical' cord, it worked fine. Even inserting a stacking header was enough to make it work OK. The new batch of HC-12s are all "Version 2", rather than "V2.3", so I thought that might be the issue. However, I swapped one of my originals in and got the same problems. I couldn't see exactly what was happening, using my debugging setup of Putty and a USB_HC-12, but when I swapped to Realterm all became clear - the top bit of most the bytes at the 'end of the packet', was set to "1". (My code uses Serin ... #var1,#var2,#var3... etc", and it really wasn't happy with that!)

I've fixed it, by replacing the original socket on the PCB, by one that is quite bit taller; that is all that was needed to make it work again! The PCB was made by isolation-milling and so contains an awful lot of copper. I'm new to PCB's (and UHF), so I'm assuming someone knowledgeable will come along and explain the error of my ways to me!

With hindsight, I might have been better off having the helical spring in a vertical position, rather than horizontal.

spacing.pngImagintronixPCB.png
 
Last edited:

Jeremy Harris

Senior Member
Yes, it would be a LOT better with the antenna perpendicular to what is, in effect, a ground plane. Any antenna will be adversely affected by any conductor nearby and parallel to it, and these little helical antennas are even more susceptible than most. This is the reason I fitted the antennas perpendicularly to the boards on my test modules, as I knew that the batteries alongside were going to be a fairly effective ground plane. If the modules are to be fitted so the antenna is vertical and in-line with the circuit board, then they must be away from any conductors. This unit below illustrates what I did:

Prototype pressure alarm - 1.JPG

The board behind the HC-12 has no copper and the ground plane copper on that board is just visible running below the antenna. The black screw is a nylon one, again so as not to affect the antenna too much. The bridge amplifier/A-to-D converter is a bit close, but there wasn't much space available to get it any lower (although I have managed to lower it by about 1/10th of an inch on the final version).

This unit works fine, with a good range, although the opposite end, which is indoors, uses a larger antenna which helps.
 

Jeremy Harris

Senior Member
IIRC, they come set to FU3 mode, 9600 baud and channel 1, so just use a setup like this in the "init" bit of the code, where in this case the Picaxe is running at 4MHz and B.2 and B.3 are the pins used to connect to the HC-12 (change these to suit your own set up, remembering that "Tx_data" has to be a pin capable of being an output):

Code:
;set up 433MHz transceiver port and data format

symbol Rx_data = B.3			;received data (Tx pin on HC-12 module)

symbol Tx_data = B.2			;data to be transmitted (Rx pin on HC-12 module)

symbol baud = T9600_4			;set baud rate for Tx and Rx
To transmit data from one unit to another just use the serout command as normal, like this:

Code:
serout Tx_data, baud, ("data")
where data can be ASCII (as above, the four bytes "d" "a" "t" "a"), or can be variables that hold byte data.


To receive data from one unit to another then just use the serin command as normal, like this:

Code:
serin Rx_data, baud, byte1, byte2, byte3, byte4
where "byte1". "byte2" etc are byte variables to hold the same number of bytes as were transmitted from the other end (i.e. if you transmitted 5 bytes then the receiver needs to be expecting to receive 5 bytes)
 
Last edited:

manuka

Senior Member
Don't forget the 100mW (20dBm) default TX power of HC-12 modules exceeds the 10-25 mW legal limit...
In Canada it may not even be 10mW? For range improvements perhaps go for FU4 & slower data rates.

Aside from USB config. you could tweak things at the PICAXE coding level with embedded AT commands of course, much in the style of PhilHornby's earlier SLEEP trials (snippet below via Phil's ~post #87).

Code:
      .........
      low HC12_set                              ;take set pin low
      Pause FortymS                             ;wait 40mS
      sertxd(cr,lf,"AT+V")                      ;debug HC-12_V2.3
      Serout TX_Pin,HC12BaudRate,([b]"AT+V"[/b])
      pause OneSecond  
      ,,,,,,,,,
To quote the manual -

&#8226; AT+FUx Change the serial port transparent transmission mode of the module. Four modes are available - FU1, FU2, FU3, and FU4.

&#8226; AT+Px Set the transmitting power of the module, with x selectable from 1 to 8. ("6" =25 mW)

&#8226; AT+Bxxxx Change the serial port baud rate. The baud rate can be set to 1200bps, 2400bps,4800bps, 9600bps, 19,200bps, 38,400bps, 57,600bps, or 115,200bps. The default value is 9600bps.

Stan.
 

PhilHornby

Senior Member
Full power

Don't forget the 100mW (20dBm) default TX power of HC-12 modules exceeds the 10-25 mW legal limit...
In Canada it may not even be 10mW?.
In Post #54, I postulated that 100mW on Channel 64 (458.6MHz) was legal in the UK. Given the absence of any significant evidence to the contrary, that's what I've gone with.
 

hippy

Technical Support
Staff member
As some members have pointed out; this thread has rather diverged from the original topic so I will be separating the regulatory and CE comments out to their own thread -

http://www.picaxeforum.co.uk/showthread.php?29079-Regulatory-and-CE-mark-discussions

I might have moved some posts pertinent to the HC-11 and HC-12 with that; please accept my apologies for that, and members are welcome to repeat their points here.
 
Last edited:

neiltechspec

Senior Member
I don't believe this post related to regulatory & CE comments.

1 - Running off 3 Duracell AA's, started off at 4.74v
2 - Running off a 2600maH 18650 LiPo, started off at 4.14v
3 - Running off a 1430maH new & unused iPhone 4s LiPo, started off at 4.14v

1 & 2 have been running for 12 days now.
1 is down to 4.12v from 4.74v.
2 is down to 3.89v from 4.14v.
3 has only been running for a day (following timing changes with code, reduced the post TX delay to 100ms from 250ms on 1 & 2).

No 1 is in the garage, approx 30m away through 2 brick walls.
No 2 is close to 100m away in a neighbours garden.
No 3 is in the house, probably only about 10m away.
An update to my post from a while ago.

No1 (duracells) lasted for approx 33.5 days to 3.5v
No2 (2600mAh LiPo) lasted for approx 35 days to 3.5v

No3 never reached low batt as I re-wrote the 08M2 S/W to include power saving (sleeps).

The PIR modules (BISS0001 based) I was using were left overs from a project from 5 years ago
2 out of the 3 were pulling 3mA when idle - supposed to be < 60uA. Those two have now gone in the bin.

All 3 now running newer code with PIR's drawing < 60uA.

As for the Government mucking up the rules - this is the UK !, where any government body excels at screwing & over complicating things.

Neil
 

manuka

Senior Member
Come in Rev. Ed.

It's some months now since Jeremy started this "alternative to the ERF" HC-11/12 topic. In light of largely positive postings (& Hippy's recent involvement), perhaps Rev.Ed may care to comment on the HC-12's PICAXE potential. I increasingly recommend it to down under educational users,both for PICAXE & nameless other micros, but uptake may go better if the HC-12 was "officially" supported.

Aside from it's verified performance,low supply need & sheer versatility,it's fair to say of course that the HC-12 transceiver's cost effectiveness & small footprint threatens traditional individual TX & RX setups.

Stan.
 
Last edited:

Jeremy Harris

Senior Member
Good reminder, Stan.

The reason I chose to use the ERF modules as the communication units for the Picaxe system that measures the instantaneous power the house is using or generating, was because they were very easy to interface with a Picaxe and already had all the necessary encoding etc built in, so they worked exactly as if the connection was wire, rather than wireless.

The HC-12 modules work in exactly the same way, and are every bit as easy to use (in fact they are a direct swap for an ERF as they arrive, same sort of size, same four connections, same baud rate etc). The only issue is that they are set, by default, to operate at 20dBm, rather than the maximum 10dBm allowed here for 433MHz band LPDs. It would be pretty easy to supply HC-12s pre-set to operate at 8dBm, in much the same way as Rev Ed supplied ERFs are preset to support the break command. Having said that, it's so easy to programme them using the very neat utility that Robert Rozee has written and kindly made available to all, that there's really need to supply them pre-programmed at all.

I now have two projects up and running using these modules and am in the process of making spare units to replace the power measurement and diversion system that I'm running, using HC-12s rather than the obsolete ERF modules, and when I have that done I'll swap them over and then convert the units with ERF modules to HC-12s as spares (I have to do it this way to minimise downtime - part of the function of these units is to provide our domestic hot water).

I'd love to be able to buy these from Rev Ed, even if the price was higher, simply to avoid the long (and very variable) shipping delay from China. I know that if I order from Rev Ed stuff invariably arrives the next day, or at most the day after, and always has done.
 

hippy

Technical Support
Staff member
It's some months now since Jeremy started this "alternative to the ERF" HC-11/12 topic. In light of largely positive postings (& Hippy's recent involvement), perhaps Rev.Ed may care to comment on the HC-12's PICAXE potential.
I believe the main appeal of the ERF to us was that it could be used for over the air PICAXE programming in conjunction with a URF or SRF, and that also provided a means for easy inter-PICAXE and PICAXE to PC comms.

Unfortunately it appears the manufacturer of the ERF has ceased production of that model but XRF and other radio modules can be used to provide inter-PICAXE and PICAXE to PC communications.

I haven't really followed the HC-11/HC-12 discussions so cannot say how they compare but they seem easy enough to use and well documented by its users here. I am not sure what we could add to the discussion or what 'official support' would amount to.

Those who are already using HC-11/HC-12 units could probably produce example code and descriptions of how to configure them, how to use them, easier than anyone at Rev-Ed could.
 

Jeremy Harris

Senior Member
Thinking about it more, what you say makes perfect sense, hippy. This thread probably has most of the information anyone could need, perhaps with the exception of an example project that uses two-way comms. What would be nice would be a UK source for these modules, but if they prove popular then there is a reasonable chance that one of the big Chinese drop-shippers (like Banggood) might decide to stock them in their EU warehouse.

I mentioned somewhere in either this thread, or it's progenitor, that the first application I used these for was a remote switch, where I wanted to have confirmation at the control end that the signal had reached the relays at the remote end. The application didn't need to be particularly secure (it's a remote operated chicken coop door), it just needed to be reasonably reliable.

This is the code for the remote control transmitter, together with the schematic, I'll finish drawing the receiver schematic and post it, together with the code, a little later:

Code:
#Picaxe 08M2

;Remote control code for chicken coop door open and close unit, using HC-12 transceiver modules, 

;The code uses 13 byte random alphanumeric codes for the "ready for command" signal, acknowledgements and commands

;Tested and works at range of up to ~100m, through walls etc

;NOTE: 4 second serin timeouts are mandatory because of the low data rate

;HC-12 transceivers are programmed to run on channel 1 (433.6MHz), 1200 baud, +8dBm, FU4 mode, 8 bit, no parity, 1 stop bit

;Switch is a DPCO, centre off, rocker switch, with one pole used for power switching and the other used for the control line

;Operating method is for the remote control transmitter to send a unique identification code, 13 bytes long, to the receiver as
;a "get ready to receive a command" signal

;The receiver responds by sending an acknowledgement transmission of 13 bytes to the remote control

;The remote control then transmits a 13byte command to open or close the door

;The receiver control unit acknowledges reception of this command, activates the appropriate relay for 10 seconds to allow the
;door motor time to open or close the door and sends a 13 bit acknowledgement back to the remote control that the relay has been activated

;On receipt of the "relay activated" acknowledgment signal the remote control turns on a red LED as confirmation to the user



symbol RFTxdata = c.4
symbol RFRxdata = c.3

symbol LED = c.0



initialise:

	
	pullup %00000110			;Set pullup on ports C.1 and C.2
	
main:

	;Door close command
	
	if pinc.1 = 0 then
	
		;transmit encoded signal ("DpRntcWq7L9S1") from remote control to receiver unit to get ready to receive a command
		
		serout RFTxdata, T1200_4, ("DpRntcWq7L9S1")
		
		;receive encoded acknowledgment from receiver that it is ready to accept a command
		
		serin [4000, main], RFRxdata, T1200_4, b0, b1, b2, b3, b4, b5, b6, b7, b8, b9, b10, b11, b12
		
		;expected encoded signal from receiver is "5Vo3sXiQ8j4aU"
		
		if b0 = "5" and b1 = "V" and b2 = "o" and b3 = "3" and b4 = "s" and b5 = "X" and b6 = "i" and b7 = "Q" and b8 = "8" and b9 = "j" and b10 = "4" and b11 = "a" and b12 = "U" then
			
			pause 600	;this 600ms pause seems to be needed to get unit to work reliably - something to do with the HC-12 timing?
			
			;encoded transmission from remote control to close the door is "0CfIem2qPDz4j"
			
			serout RFTxdata, T1200_4, ("0CfIem2qPDz4j")
			
			;expected encoded return from receiver is "3GwMufp07Cza2" acknowledging that command has been correctly received
			
			serin [4000, main], RFRxdata, T1200_4, b0, b1, b2, b3, b4, b5, b6, b7, b8, b9, b10, b11, b12
			if b0 = "3" and b1 = "G" and b2 = "w" and b3 = "M" and b4 = "u" and b5 = "f" and b6 = "p" and b7 = "0" and b8 = "7" and b9 = "C" and b10 = "z" and b11 = "a" and b12 = "2" then
				high LED	;LED signals to user that the command has been acted upon and is confirmation that the door is closing
				;LED stays on until switch is released powering off the unit but receiver relay will remain activated for 10 seconds
			endif
		endif
	endif
	
	
	;Door open command
	
	if pinc.2 = 0 then		
		
		serout RFTxdata, T1200_4, ("DpRntcWq7L9S1")
		
		serin [4000, main], RFRxdata, T1200_4, b0, b1, b2, b3, b4, b5, b6, b7, b8, b9, b10, b11, b12
		
		if b0 = "5" and b1 = "V" and b2 = "o" and b3 = "3" and b4 = "s" and b5 = "X" and b6 = "i" and b7 = "Q" and b8 = "8" and b9 = "j" and b10 = "4" and b11 = "a" and b12 = "U" then
						
			pause 600
			
			;encoded transmission from remote control to open the door is "8FDX5kW8mOax5"
								
			serout RFTxdata, T1200_4, ("8FDX5kW8mOax5")			
						
			serin [4000, main], RFRxdata, T1200_4, b0, b1, b2, b3, b4, b5, b6, b7, b8, b9, b10, b11, b12
			
			if b0 = "3" and b1 = "G" and b2 = "w" and b3 = "M" and b4 = "u" and b5 = "f" and b6 = "p" and b7 = "0" and b8 = "7" and b9 = "C" and b10 = "z" and b11 = "a" and b12 = "2" then
				high LED
			endif
		endif
	endif	
	
	
END
remote transmitter schematic.JPG
 
Last edited:

Jeremy Harris

Senior Member
This is the code for the receiver and the schematic:

Code:
#Picaxe 08M2

;RF receiver for chicken coop door remote control, using HC-12 transceiver modules, 

;The code uses 13 byte semi-random alphanumeric codes for the "ready for command" signal, acknowledgements and commands
;just to give a modicum of security and resistance to false operation, but these are transmitted as plain text so can be intercepted
;and read, if anyone wished to, so this is not good security for use with something like a lock.  In this application the
;main reason for using 13 bytes of gobbledegook text is to reduce the risk of false operation

;Tested and works at ranges of up to ~100m with "rubber duck" antennas at both ends

;NOTE: 4 second serin timeouts are needed because of the low data rate
;whole sequence takes around 4 seconds before confirmation signal is received by remote

;HC-12 transceivers are programmed to run on channel 1 (433.6MHz), 1200 baud, +8dBm, FU4 mode, 8 bit, no parity, 1 stop bit

;Operating method is for the remote control transmitter to send a unique identification code, 13 bytes long, to the receiver as
;a "get ready to receive a command" signal

;The receiver responds by sending an acknowledgement transmission of 13 bytes to the remote control

;The remote control then transmits a 13byte command to open or close the door

;The receiver control unit acknowledges reception of this command, activates the appropriate relay for 10 seconds to allow the
;door motor time to open or close the door and sends a 13 bit acknowledgement back to the remote control that the relay has been activated

;On receipt of the "relay activated" acknowledgment signal the remote control turns on a red LED as confirmation to the user

;Receiver uses a double 5V relay module, with built in relay driver opto isolator drivers.  The relay drive signals are active LOW


symbol open_door = c.4
symbol close_door = c.2

symbol RFTxdata = c.1
symbol RFRxdata = c.3



initialise:

	;set both relay outputs high at power on, to avoid accidentally oepning or closing the door
	
	HIGH open_door
	HIGH close_door

	
main:
	
	;receive 13 bytes from remote control, time out after 4 seconds and loop back
		
	serin [4000, main], RFRxdata, T1200_4, b0, b1, b2, b3, b4, b5, b6, b7, b8, b9, b10, b11, b12
	
	
	;expected encoded signal from remote unit to signal that fixed unit should await a command is "DpRntcWq7L9S1"
	
	if b0 = "D" and b1 = "p" and b2 = "R" and b3 = "n" and b4 = "t" and b5 = "c" and b6 = "W" and b7 = "q" and b8 = "7" and b9 = "L" and b10 = "9" and b11 = "S" and b12 = "1" then
		
		;transmitted encoded "ready for command" signal to remote unit is "5Vo3sXiQ8j4aU"
		
		serout RFTxdata, T1200_4, ("5Vo3sXiQ8j4aU")
		
		;await encoded command signal from remote unit
		
		serin [4000, main], RFRxdata, T1200_4, b0, b1, b2, b3, b4, b5, b6, b7, b8, b9, b10, b11, b12
		
		
		;expected encoded signal from remote unit for door close command is "0CfIem2qPDz4j"
		
		if b0 = "0" and b1 = "C" and b2 = "f" and b3 = "I" and b4 = "e" and b5 = "m" and b6 = "2" and b7 = "q" and b8 = "P" and b9 = "D" and b10 = "z" and b11 = "4" and b12 = "j" then
			LOW close_door
			serout RFTxdata, T1200_4, ("3GwMufp07Cza2")	;command being actioned acknowledgement to remote unit, "3GwMufp07Cza2"
			pause 10000
			HIGH close_door
		endif
		
		
		;expected encoded signal from remote unit for door open command is "8FDX5kW8mOax5"
		
		if b0 = "8" and b1 = "F" and b2 = "D" and b3 = "X" and b4 = "5" and b5 = "k" and b6 = "W" and b7 = "8" and b8 = "m" and b9 = "O" and b10 = "a" and b11 = "x" and b12 = "5" then
			LOW open_door
			serout RFTxdata, T1200_4, ("3GwMufp07Cza2")	;command being actioned acknowledgement to remote unit, "3GwMufp07Cza2"
			pause 10000
			HIGH open_door
		endif
	endif
	
	
	goto main
	
END
Remote receiver schematic.JPG
 
Last edited:

stevesmythe

Senior Member
It would be pretty easy to supply HC-12s pre-set to operate at 8dBm, in much the same way as Rev Ed supplied ERFs are preset to support the break command. Having said that, it's so easy to programme them using the very neat utility that Robert Rozee has written and kindly made available to all, that there's really need to supply them pre-programmed at all.
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?
 

PhilHornby

Senior Member
Programming

Not easily! I just tried (using one of the USB-HC12 modules at the PC end).

I got "hardware not found on COMx:", during a 'Check Picaxe type connected' operation and "Error: Incorrect hardware connected - UNKNOWN v1.5 (expected PICAXE-08M2)" during programming. (Actually, that implies some sort of connection, since I'd inadvertently used a 14M2 at the far end!)

It might be possible using the techniques developed for downloading via bluetooth, in this thread: http://www.picaxeforum.co.uk/showthread.php?28745-PICAXE-Programming-via-Bluetooth
 
Top