HC-11 and HC-12 transceiver modules

Jeremy Harris

Senior Member
Some may recall this thread: http://www.picaxeforum.co.uk/showthread.php?28761-Alternative-to-ERF where I started off looking for a replacement for the now-discontinued ERF transceiver modules and the conversation drifted into a discussion about the cheap Chinese HC-11 and HC-12 modules that abound on a certain auction site. In that thread I found that the range performance of the HC-11 modules at 9600 baud was disappointing, even when fitted with a decent 1/4 wave antenna, rather than the small helical antenna that is supplied with the module.

Following on from that, and from advice given by Stan on a supplier here: http://www.picaxeforum.co.uk/showthread.php?28761-Alternative-to-ERF&p=297481&viewfull=1#post297481 I ordered some HC-12 modules, and I have to say they arrived very quickly, just over a week, which is pretty good for a Chinese supplier to the UK. Interestingly, the HC-12 modules I ordered a week earlier from another supplier haven't yet turned up.

I intend to carry out some proper, side-by-side range comparisons between the HC-11 and HC-12 later, as soon as I've built some test boxes, but my immediate requirement was to set up a remote switch in my garage (at the end of the garden) so that I could turn something on or off from anywhere in the house or garden with a hand held remote, and have confirmation on that remote that the switch had actually activated.

Both ends use 08M2s, running at the standard 4MHz. After my experience with the HC-11s, I decided to programme the HC-12s using an FTDI on a USB cable, and the software Stan linked to in this post: http://www.picaxeforum.co.uk/showthread.php?28761-Alternative-to-ERF&p=297250&viewfull=1#post297250 which can be downloaded from this link he gave to the Back Shed Forum: http://www.thebackshed.com/forum/forum_posts.asp?TID=8246&PN=1 . This software makes programming these cheap little transceivers really easy, it takes just seconds to do, provided you have plugs and sockets handy. My next test set up will use plug and socket strip connections, so that I can easily unplug the transceivers, re-programme them and see how the performance changes.

Right now I thought I'd report on what I have working and how it performs, as a starter, with luck I'll get more testing done in the next week or so.

The first thing to say is that these modules, either the HC-11 or the HC-12, are extremely easy to use with a Picaxe. They happily work at Picaxe-type voltages (I'm running the fixed switch in the garage from a 5V supply and the hand held unit from 3 off AA cells, so around 4.5V). They are fussy about baud rate, as they seem to use pretty exact baud rate timing, whereas (as previously reported) Picaxe software serial port baud rate timing can have some significant errors at some internal clock speeds (for example, if you want to use 9600 baud you pretty much have to setfreq to M16 or M32 to get the baud rate within the acceptable range for a lot of hardware serial devices).

Anyway, back to the remote switch. The basic scheme I used was to send a 13 bytes code from the hand-held unit as a "wake up" call, with the remote switch sending a different 13 byte code back to say that it was ready for a command. The handheld unit then sent another 13 byte code as a command to the remote switch, one code for "switch on" another code for "switch off". The remote unit switched the appropriate relay and when it had done that it transmitted back another 13 byte code as an acknowledgement. This last received code turned on an LED on the hand-held unit so that I had confirmation that the relay at the remote end had really operated.

This isn't really a super-secure requirement, although sending sequences of 13 byte random-looking characters back and forth, with the appropriate handshakes, means it is really pretty secure in practice, it would take a persistent bit of listening and reverse engineering to figure out what was going on. It could be made more secure by using all available bytes on the 08M2 (so 28 byte coded messages instead of 13 bytes), and even more secure by implementing some form of rolling code algorithm, but for my needs out in the country for a low security switch I deemed this system secure enough.

After my experience with the poor range of the HC-11, I opted to programme the HC-12s in their "long range" mode, FU4 (a claimed 1800m), that works at a supposed 1200 baud. I kept within the UK licence exempt band with the set frequency (I used channel 4, which is 434.6MHz), but did break the rules with power, and left the units at the default +20dBm (100mW) and with hindsight I could have easily used +10dBm (10mW), and I may well unsolder the modules and re-programme them one day.

I fitted the hand-held unit into a small plastic box that would just take 3 off AA cells plus the circuit board, two push buttons and the LED, and used the supplied small helical antenna. I fitted the remote unit into another plastic box, screwed to the inside of the garage wall and powered from a small 1W mains power supply. Because I had some space there, I used a 1/4 wave (approx) antenna, a bit of stainless steel wire cut to the right length. I didn't do any antenna optimisation at all, the garage unit is vertically polarised, the hand held unit is vertically polarised if held vertically, but will most often be at some angle, so there will be a fair bit of polarisation loss in the path.

The test today was to see if the unit would work, with me being able to operate the remote switch from anywhere inside the house, even the very farthest corner, where the signal has to pass through 4 internal walls plus an external wall that is extremely effective RF screen (it's over 400mm thick, has a foil-type membrane in it and the triple glazed windows are metal sputtered to reduce long wavelength IR loss, so are also good RF screens). The good news is that it works very reliably from anywhere inside the house, even with the hand-held unit horizontal. The down side is that the signal transmission time seems way too long for 1200 baud, it takes 5 seconds from pressing the button on the hand-held unit to receiving the confirmation LED. I originally had 2 second timeouts on the serin commands both ends, but found that to get the system to work reliably I had to increase these to 4 seconds.

Having got the unit working. I decided to see how far it would work, so I went for a walk around the village. I can confirm that it still works fine at over 400m (as far as I went - lunch was calling!). That was through other houses and gardens and over the top of a small rise, so not really line-of-site. I have no doubt that the claimed 1800m range line of sight is genuine, or that I could run at a much lower power and still have a reliable link for my purpose.

It'd be nice to know what's going on inside these units, though, as the transmission time is puzzling. Each 13 byte transmission should take a bit over 1/10th second (I think) and there are a total of five transmissions, with an inherent 1.5s delay in the software, so that means it should take around 2 seconds from button press to receipt of the LED confirmation, not 5 seconds. I'm guessing that the modules aren't actually transmitting over-the-air at 1200 baud, but may have buffering within the microcontroller that's on the board.

Anyway, I thought this update on performance was worth posting. Based on my findings I'd not bother with the HC-11 modules at all, unless you only need a very short range and are happy with a low baud rate (my guess is that the HC-11s will work better with a lower baud rate when I get around to doing some proper testing). If you want cheap and reliable long range links, then the HC-12 is hard to beat. They are cheap (less than £3.20 each including the antenna and shipping) they don't give out any spurious data (so they don't upset the serin command) and they seem easy to use.

More will follow when I've had some time to make some test units up for proper range testing.
 

PhilHornby

Senior Member
Based on the original thread, I ordered a pair of HC-12's for testing. I've not completed my investigations yet, but can confirm that stunning performance.

I quickly ran out of 'property' to walk around - this being the UK - so I gave them the most severe work-out I could think of. Test #1 was with one end of the link inside the Freezer, and Test #2 was with one end in the car, parked on the drive. From my vantage point here in the test centre, I was able to bounce characters around the link with no errors at all that I noticed.

This was with the units left on their default FU3, 20mW setting, each fitted with the supplied 'spring' aerial. These are so much better than HC-05 Bluetooth modules that I've previously employed.

One thing I have noticed, is that the "AT+SLEEP" command doesn't always make the unit enter low-current mode ... but this is with me making and breaking the connection to the SET pin with a breadboard jumper wire, so I'm sure it will resolve itself.
 

manuka

Senior Member
Jeremy (& Phil) : Glad the HC-12 has also shaped up well for you both! That button press confirmation issue is probably related to the FU4 mode selected, as this has a 1 sec (1000 ms) delay. Try instead the factory default full speed FU3 mode which has delay of just 4-80 ms.

FU3 range is less,as the RX has "only" -117dBm sensitivity at FU3 5000 bps air rate (versus FU4's superb ~-122dBm at this mode's mere 500 bps air rate), but it'll probably still be more that enough for your Blighty wall punching needs. (NZ homes are typically timber & virtually UHF transparent). Consider the edited manual extract below for insights. Apologies for showing as CODE,although this may allow grabbing for PICAXE coding.

Rather than unsolder for reconfig, consider sending thru' AT commands embedded in the driving code. First take the SET pin low to enter command mode of course. AT+FUx (where x = 1 to 4) handles the mode change.

While you're about it -ahem- perhaps play the game old sports & LOWER the TX power to UK legal levels too. Use AT+Px (where x = 1 to 8) & set to 5 for 12 mW (still admittedly a whisker over the UK 10mW limit!). Phil - that default FU3 setting has TX power 100mW (20dBm), which is far above even our NZ/Aust. more generous 25 mW (~14 dBm).

I'm wary that these HC-12 may be banned if folks blindly use them at full power. Of course the answer is to take your ham radio ticket & then be legally allowed WATTS over a wider "70cm" spectrum.

Stan. ("Manuka") Ham ZL2APS
Code:
[b]Mode                  FU1         FU2        FU3        FU4         Remarks[/b]

Idle current          3.6mA       80uA       16mA       16mA        Average value
Transmission delay    5-25ms      500ms     4-80ms      1000mS      Sending 1 byte
Loopback test delay   31ms        31ms       31ms       31ms        Serial 9600,1-10 bytes 
LoS range -100mW TX   100m        100m      1000m/2.4k  1800m/1.2k 
Air baud rate         250k bps    250k bps  >5000 bps   500 bps     Default FU3 9600 bps 
(at serial bps)       1.2-115.2k  1.2-4.8k  1.2-115.2k  1.2k only   air data rate =15k bps
 
Last edited:

srnet

Senior Member
I'm wary that these HC-12 may be banned if folks blindly use them at full power. Of course the answer is to take your ham radio ticket & then be legally allowed WATTS over a wider "70cm" spectrum.
I would agree, get an Amateur radio license, and with a few restrictions, you can quite legally carry out such tests.

Also not a good idea to be advertising on a public forum that you are ignoring the legal requirements of ISM device use.



And whilst the HC modules might seem to be a bargain @ £3.20, for a mere £4.30 you can get a Dorji LoRa module. For sure the software to use them is more complex, but the range they are capable of is just so much greater, well worth the effort.
 

manuka

Senior Member
srnet: Having "walked the talk" on LoRa™ I certainly agree on it's stunning benefits!

Best however that we caution those tender souls unaware of the £4.30 module you've mentioned (assumed an SPI addressed HopeRF RFM98 or Dorji DRF1278F),that faint hearted & less skilled folks may be near overwhelmed. Check HopeRF's RFM95/96/97/98(W) 121 pages of data for insights!

There's an emerging IoT place for LoRa ™, but also of course a need for easy-to-get-working serial addressed ASK/FSK wireless devices. Stan.
 

Attachments

Last edited:

Jeremy Harris

Senior Member
I'm pleased others have found similar range performance, I'll admit to being astounded yesterday with the range I managed to get with my crude testing.

I think it is very wise to only use these at +10dBm, and stay legal, as there really seems no need at all to use any more power, in fact arguably even less power might be sensible for the majority of short range links.

I've started looked at making two simple range-testing boxes, with socket strip so that I can plug in either HC-11 or HC12 modules and do some direct comparison testing, although given the low price of the HC-12 it hardly seem worth the bother.

Thanks for confirming the cause of the delay, Stan, it wasn't mentioned in the short data sheet I found on the HC-12, but the 1 second delay and the lower over-the-air baud then perfectly accounts for the delay I am seeing. For my purporse the delay isn't significant, it just means holding the button down on the remote until the LED comes on to confirm that the relay has operated at the opposite end of the link.

I take the point about the LoRa modules, and did seriously consider them for a time, but they are significantly more complex to use with a Picaxe, and originally I was looking for something that was a more-or-less direct replacement for the now-defunct ERF module, to fit in the same space and have the same 5V UART interface. The HC modules have this distinct advantage for me, but for more demanding applications the LoRa modules could easily be a better bet, even though they need a bit more code to drive them.

I think that for my next project, a linked network of power switch modules around the house to replace 5 time switches, I'll stick with the HC-12 units, with the power turned down. This next project is intended to avoid the biennial round of resetting the time on 5 time switches whenever the clocks change for GMT/BST. The time switches are a great boon for controlling things like heated towel rails, the immersion heater boost and the boiling water tap in the kitchen, as a power saving aid, but I do not enjoy setting the clocks on them all twice a year, especially as one is outside in the water plant shed and controls the backwashing filter on our borehole water supply. The idea is to have a central timer (using a Picaxe with a display, a RTC and an MSF time code receiver) that sends out coded on and off messages to each switch unit. That way the whole lot will need no attention, as the time will change automatically, plus I'll have the benefit of a central display showing an accurate time and the on or off state of each remote switch module. It should make for an interesting Picaxe project too.
 

manuka

Senior Member
For those that missed this in the earlier thread, a significant factor in the HC-12's wonderful performance seems due to the very sensitive receiver part of it's SiLabs Si4463 RF IC.
 

Jeremy Harris

Senior Member
I'm currently etching some small circuit boards (AA battery size) that will have a Picaxe 08M2, plus a 5 way socket strip to plug in either an HC-11 or an HC-12. The idea is that these will just fit into an unused battery space in a 4 cell AA battery box, with three cells to power the unit in the other spaces. at the moment I'm looking at just doing a simple test to replicate the sort of intermittent data transmission that a typical Picaxe remote project might need (and I don't think it's sensible or polite to do anything other than data burst transmissions on this licence exempt band, anyway). The two boxes will be identical, except for the code, and both will have the small helical antenna that comes with the module soldered perpendicular to the module, so the circuit board and batteries will form a bit of a ground plane.

To make the test fairly tough, I'm planning to transmit 28 bytes, then have the remote end retransmit the same 28 bytes back, and repeat this every 10 seconds. If the 28 bytes are correctly received back, then an LED will light for a second, if they aren't, it won't. Both modules will have LEDs, on the remote, or slave, module it will just indicate that the one-way 28 byte data burst has been correctly received, on the master it will indicate that the round trip has been successful with no errors.

I should be able to use this set up to do some cheap and simple range testing, out in an open space where I can measure range reasonable easily. I have a small GPS tracker, and may use that to record positions for the longer ranges I'm expecting in some modes. I'll try and test as many modes and rates as practical, but will probably settle on just doing the worst case (9600 baud, standard mode) and the best case (FU4 mode for both, at 1200 baud). I also plan to do some ad hoc tests from inside the house to outside with both modules, to see how they fare when the signal is going going through structures. This will be a tough test, as our new house is like a Faraday cage, that attenuates mobile phone and FM radio signals significantly, and renders DAB radio unusable without and externally mounted antenna.

If I get time I'll try and do some different combinations. Rather than make the text boxes more complex with options to select operating mode and baud rate, I've opted to just load the easy programming utilities onto an old Windows netbook, and make up a simple FTDI lead with a socket that will just plug directly on to a module to programme it. This way I can just unplug a pair of modules, reprogramme them and plug them back in again in a few minutes and keep everything portable and easy to use out in an open space.
 
Last edited:

PhilHornby

Senior Member
off topic...

This next project is intended to avoid the biennial round of resetting the time on 5 time switches whenever the clocks change for GMT/BST.
My RTC of choice is the ESP8266, running an NTP client - accurate time, with automated daylight saving changeover. Currently have to output the time via Serial pin, but I'm sure someone will get I²C Slave mode working soon, so it can emulate a DS1307. However Wifi coverage could be an issue in the case of your shed.
 

Jeremy Harris

Senior Member
Yes, I can't get a decent wifi signal outside at the moment, the new house is just too good at screening out RF. I had originally planned on using a net of ESP8266 modules, and even bought a bag of them, until I realised the problem with extending the net outside the house.

The house is a new build, and currently (not including the time switch replacement project) it has 6 Picaxes controlling or data logging various things, from diverting excess PV power generation to the hot water storage through data logging the internal and external environment to running two electric car charge points! By the time I've finished I reckon I'll probably have over a dozen Picaxes in the house doing various jobs..........................
 

srnet

Senior Member
For those that are interested in testing and comparing these modules or antenna performance, you can easily do so if you have some means of measuring signal strength down to circa -100dBm.

I originally built a signal strength meter using a RFM22B, PICAXE and LCD display. You set the frequency of the RFM22B to match the modules you are using, then as the RFM22B is relatively narrow band device its not that affected by interference. All you need then is an open field.

There are some details of how to use these simple tools to measure transmitters and antennas in a document called 'Testing and Comparing' here;

https://goo.gl/IeEiC1

I was using a LoRa module and Pro Mini in those tests, but a RFM22B or PICAXE will do the same job.
 

manuka

Senior Member
Thanks Stuart- very comprehensive as per your usual diligent style!

In mid 2015 fellow Kiwi Andrew rustled up a PICAXE driven "staircase" approach for range checking Dorji's DRF1278DM LoRa™ modules - see pix below (grabbed from my LoRa Instructable).

It'd be significantly easier to "AT+Px" this for the HC-12 of course. See attached table snippet. Stan.
 

Attachments

Jeremy Harris

Senior Member
I've knocked up some small PCBs that will fit into an AA battery size space and hold an 08M2 and either an HC-11 or HC-12 to use for range testing. Nothing as sophisticated as suggested above, as I want to re-use these boards later as the control boards for my time switch replacement project (the LED will just be replaced with leads to an opto-isolated solid state relay). This is what the test boards look like (minus the 08M2 at the moment, I still need to finish the short bit of code and programme them):

Range test board.JPG

And this is all the parts, an FTDI board plugged to a USB lead, with a simple wiring harness with a socket that plugs on to the plug strip I've fitted to the HC-11s and HC-12s. The HC-11s are fitted to the circuit boards, and are green, the HC-12s are loose or plugged in to the FTDI and are blue:

Range test boards and FTDI programming lead.JPG

I just need to finish writing the code, then go out and get some AA cells, as I've just realised I've run out (I buy boxes of 24 of these at a time, Duracells, and something in this house just eats them, I'm sure............).

With luck I should get some testing done soon. All tests will initially be done at +10dBm (10mW) and I've decided I will try the very low power mode in one test series, as I'm curious as to how well either module performs in this mode, as it could be pretty useful for battery powered projects. I have in mind making a remote PIR switch to fit outside to trigger the record function on our security camera DVR, as the built in motion sensing often false triggers from rain or small insects flying by the camera. A very low current PIR sensor, coupled with a low power data link, run from a small rechargeable battery and solar panel sounds like a reasonable option, if the low power mode of these units works OK.

It may take me a few days to get the testing completed, but I'll try and post details of each test series as I complete it. If anyone wants a particular mode, power or baud rate tested, then let me know and I will try and do some extra tests. The basic test will be to send and receive 28 bytes every 10 seconds, as I think that is probably fairly representative of a typical Picaxe remote application.
 

manuka

Senior Member
Can we see PCB track side please !? I appreciate that this is just a prototype, but perhaps consider 90 degree header pins/sockets for a neater space saving fit under the HC-12? Stan.
 

Attachments

Jeremy Harris

Senior Member
Sorry, the boards are hot glued in now, but I'll try and take a photo later of the reverse of the undrilled spare boards.

I agree that the 90 deg headers are neater and mechanically better, but they wouldn't have allowed this small board to fit into an AA size space in a battery box.

I've just bought some new Duracell AAs and done two sets of tests. Here are the line of sight, open air, test results, with the helical antennas vertical and at the same relative height (+/- 1m):

HC-11, set to mode FU3, power +10dBm (10mW), channel 001 (433.4MHz), Address 000, 9600 baud - range = 24m

HC-12, set to mode FU3, power +8dBM (6.3mW), channel 001 (433.4MHz, 9600 baud - range = 47m

Note that the HC-12 doesn't have a +10dBm power setting, hence the use of +8dBm

This initial testing at 9600 baud seems to bear out the view that the receiver in the HC-12 is very significantly better than that in the HC-11. In each case I measured the range at the point where I was getting a rock-solid response to the 28 byte transmitted and echoed transmission, but the edge of reliable operation for the HC-11 was pretty sharp, 1m further away and it started to play up, 2m further away and it stopped altogether. The edge of reliable operation for the HC-12 was broader, it started to get unreliable at around 48 to 49m range, but didn't totally stop until over 53m range.

I may get some more tests in this afternoon, if the weather holds (it's threatening rain again at the moment).

Edited to add:

I've just managed to do another set of tests with both modules, the last for today I'm afraid.

The results were:

HC-11, set to mode FU3, power +10dBm (10mW), channel 001 (433.4MHz), Address 000, 2400 baud - range = 57m

HC-12, set to mode FU3, power +8dBM (6.3mW), channel 001 (433.4MHz, 2400 baud - range = 98m

Very roughly, it looks like the HC-12 at +8dBm has close to double the range of the HC-11 at +10dBm for the FU3 mode, with range extending with baud rate reduction, as expected.

I've just managed to squeeze in one more test with the HC-11 modules, set to FU2 mode, which is the very low current (80uA) mode. I did the test at 2400 baud and got quite a surprising result, the range was a solid line-of-sight 108m, which seem odd, given the poor performance of these modules when compared to the HC-12s. It bodes well for anyone looking for a low power mode, though. I only need a range of around 30m, through the walls and into the house, and the HC-11 in mode FU2 at 2400 baud seems to do that comfortably (I've just tried it). It'll be interesting to see how well the HC-12 modules do in this mode.
 
Last edited:

neiltechspec

Senior Member
Remote wireless PIR's is what I have bought 5 HC-12's for.

Running off single LiPo Cells.

Planning on waking up the HC-12 on detection of activity or tamper, also sending
a periodic 'I'm alive' signal every 60 seconds with PIR identity & battery level.

Similar to a commercial product, I have extensive experience with, by a company called
Luminite who make the Genesis range of PIR products. Horrendously priced for the home
enthusiast and really big ugly PIR's.
But they do work very well indeed.

Neil.
 

Jeremy Harris

Senior Member
As promised, here is a photo of the reverse of the small test PCBs that Stan asked for:

Rear view of two undrilled or cut boards.JPG

And here is a view of the test transponders that I've been using. The Master unit transmits a 28 byte sequence at the selected baud rate, which is then received by the Slave unit, compared with the 28 byte sequence it expects to receive, and if it is correct it transmits it back. If the master unit receives the 28 byte sequence back without any errors it flashes an LED.

Master and slave transponders.JPG

In practice this works well, as you can walk along watching the flashing LED and wait until it stops flashing and goes to error mode (three rapid flashes). One thing very noticeable is that the link is quite motion sensitive, particularly the last test I did with the HC-11 in the FU2 80µA mode. I had to stop for a few seconds and hold the unit still for it to acquire the signal and get the link to lock up, where it would once again be solid until it moved. A walking pace was quite enough to give it problems, not something I noticed with the other tests. I'm guessing this is down to the low over-the-air data rate that the FU2 mode probably uses, together with possible doppler effects. It's hard to be sure, but the effect was quite pronounced.

It shouldn't be a problem if this mode is used as a low current link between two fixed points, bearing in mind the relatively long initial latency period of 380mS.

I did all these tests in the open air along a straight length of narrow lane, with the Slave unit resting on to of a fence post and the Master unit in my hand. I did attract a few curious glances from some of my neighbours...................
 

manuka

Senior Member
I did attract a few curious glances from some of my neighbours...................
Jeremy: Tease them & say you're polling the local Brexit mood ?!

Good work on the testing, which is consistent with similar findings here in NZ. Your results confirm the superior sensitivity of the HC-12's Si4463 SiLab "EZRadioPRO" transceiver.

As earlier mentioned, the HC-11 uses a TI CC1101 "Chipcon" RF IC which is indeed some 6dB deafer in comparision. As you've neatly found,each 6dB system gain should double range (CP =Ceteris Paribus = "other things being equal").

Perhaps also check current drains with each module too ? Stan.
 

srnet

Senior Member
It might be worth trying different antennas. The figure I had in mind for an open field test @ 10mW would be around 1km on simple 1/4waves.

This was testing at 1000bps on the RFM22B (a -121dBm FSK data receiver) and figures I recall are 100M @ 0.1mW and 300M @ 1mw. So 2400bps ought to be similar.

You cannot directly compare modules using their quoted sensitivity as this is an ideal figure in a noise free environment. In reality a receiver such as this will see around -100dB of background noise, and since FSK receivers need to see a signal that is stronger than the noise (so -90dBm or so) it has no chance of receiving signals at -121dBm.
 

Jeremy Harris

Senior Member
If I get time I'll try and stick a couple of stiff copper wire 1/4 waves on, but my feeling (based on the earlier testing I did comparing these with the small helical antennae) will be that I will just get a result that is, again, close to theory (the helical antenna is probably around 2dB or so down on a 1/4 wave, I think).

One odd thing I noticed yesterday, but found again this morning, is that the HC-11 range in mode FU2 is massively greater than the range of the HC-12 in the same low power mode (BTW, I did check the supply current and they are broadly inline with the data sheet on standby, I've not checked during transmit yet). The HC-12 data seems to show that in the low current, FU2 mode, it has an over-the-air baud rate of 250,000baud, which would explain the very poor performance. I'm consistently getting a range of around 24m in this mode with the HC-12, versus over 100m in the same mode with the HC-11. The Picaxe configuration for these tests is the same for both, 2400 baud, and all I'm doing is swapping over pre-programmed transceiver modules.

I can't find any reference to the over-the-air baud rate for the HC-11 in FU2 mode, but from the difference in performance I think it must be massively lower than the 250,000 baud that the HC-12 apparently uses in this mode. It's a complete guess, but I wonder if the HC-12 very high over-the-air baud rate in this low current mode is a way of reducing the overall power used. At 250k baud the transmitter on time would be very much shorter than if the data was transmitted at its native 2400 baud, resulting in a significant power saving for lower power devices, as long as the large reduction in range is acceptable.

Edited to add:

I've just done some very "rough and ready" power consumption testing, and that would seem to bear out the theory above, that the HC-11 uses a much slower over-the-air baud rate when in FU2 mode than the HC-12. Measuring the transceiver current shows that the 30mA or so burst from the HC-12 is extremely short, barely enough to register on the meter (in fact it probably wasn't properly registering). On the other hand the burst from the HC-11 on transmit (around 40mA) was significantly longer. This indicates to me that it probably does use a much lower over-the-air baud rate in FU2 mode, probably the native rate at a guess (in this case, 2400 baud).

For me this creates an interesting point, in that for my battery powered PIR alarm application, where I only expect a transmission whenever there is an alarm event, the power used during transmission isn't significant, it is the standby power that takes most of the power budget. This makes the HC-11 a better fit for that application.

For a shorter range battery powered application, with more regular data bursts, an HC-12 may well be a better bet.

I think I'll some further tests today at 2400 baud, in different modes and, perhaps, with different antennae, to see how they compare, but the base data above is probably enough to make a selection of a device on. In most cases the HC-12 is the better bet, as despite not being able to operate at the highest power allowed (in the UK) of +10dBm (it can only be set to +8dBm to stay legal) it has significantly better performance that the HC-11, except in the FU2 low power mode.
 
Last edited:

PhilHornby

Senior Member
Low power mode

For me this creates an interesting point, in that for my battery powered PIR alarm application, where I only expect a transmission whenever there is an alarm event, the power used during transmission isn't significant, it is the standby power that takes most of the power budget. This makes the HC-11 a better fit for that application.

For a shorter range battery powered application, with more regular data bursts, an HC-12 may well be a better bet.
This is the reason I started investigating the HC-12's "AT+SLEEP" command - which lowers standby current to 20µA or so.

The sequence is "SET->LOW, send "AT+SLEEP", it responds "OK+SLEEP", then SET->HIGH". Taking "SET" low then high restores normal operation. It wasn't working reliably when I was plugging and unplugging a lead on my breadboard - 'contact' bounce maybe? It's on my list of things to follow up...
 

srnet

Senior Member
Good job on doing the flat field tests, its a very good way of testing and comparing radio modules. The test should be reproducible by anyone the world over.

Do try some 1\4 wave wires, the difference in distance (of reception) will tell you the dB difference in the antenna types.

Also be aware that the UK power limits are ERP (effective radiated power), I cant recall exactly what the reference point is, but if you measure the difference in dB performance between the helical coils and say a 1/4 wave its permissible to increase the transmit power to compensate for a poor antenna. The downside of this is that its not permissible to put a gain antenna on a transmitter running 10mW, as the gain would break the ERP limit.
 

Jeremy Harris

Senior Member
One infuriating thing with these modules is the lack of comprehensive and reliable data sheets. Those we have seem to be compiled from more than one Chinese source and are often strangely translated. If we had one good Chinese-speaker plus the person that designed these boards (and I'm reasonably sure that they've both been designed by the same person or company) then I'm sure we could remove many of the ambiguous comments and put together a useful pair of data sheets.

There are glaring gaps in the HC-11 data, in particular, so we don't know, for example, what the over-the-air baud rate is in Mode FU2. Similarly, there a gotcha's in the AT commands, in that there has to be a fairly significant delay (at least 15mS) after sending an AT command before you do anything else, particularly with the HC-11.

For me, the HC-11 programming utility from here: http://www.thebackshed.com/forum/uploads/robertrozee/2016-01-15_155359_HC-11_config.zip always chucks an error message after sending each command (so a handful of error messages every time you programme one unit) yet despite these error messages the check config option shows that the module has been programmed correctly. Reading the thread on the Backshed forum it sounds as if the author of these very useful utilities, Robert Rozee (see here: http://www.thebackshed.com/forum/forum_posts.asp?TID=8246&PN=8) may be more used to working with the HC-12 and so may not have fully tested the utility with the HC-11. That's just a guess, but even with the glitches his utility is a LOT quicker to use to programme modules than a terminal programme and typing in AT commands.

It may be that there are other critical issues around the timing of taking the set pin low and high, in relation to going into AT mode, that aren't documented. My usual tactic with things like this is to add massive delays to see if it works that way, then if it dose reduce the delays until it stops working, then double that delay time just to be safe!
 

manuka

Senior Member
I'm glad the (Australian) Back Shed link has been mentioned. Although microMite slanted their active Forum has many PICAXEable HC-12 postings,most recently SLEEP related.

Poster Robert Rozee (a fellow Kiwi) & I have been in touch - he admirably "translated" the original Chinglish data sheets, but a total revamp is increasingly justified. Yes- I've put my hand up for the task,& (as you can probably guess) am steadily collating the collective wisdom.

Extra: At 2.4GHz WiFi freqs you can't go past ESP8266 devices these days, but just to hand is this comprehensive Hackaday "Bird house" account,which uses tweaked Nordic nRF24L01 (2.4GHz) modules for 100s of metres of wireless data (& image!) coverage thru' EU woodland vegetation. Impressive !

Stan.
 

neiltechspec

Senior Member
I've been playing about with these and I have a quick question.

If module is set to 2400 baud, on bringing 'SET' low, does AT (e.g. AT+SLEEP) command need to be at 2400 or 9600 baud.
Data sheet is not clear about this, only for power up with 'SET' low, when it's 9600.

I want to leave one running off a single LiPo (1400mAH) sending battery voltage every 10 seconds @ 11dBm, just to see how long it lasts.

Neil.

edit:
After playing about further, I think I may have answered my own question.
It needs to be at 9600 for AT commands regardless of what the module comms baud rate is set to.
Found out using a USB2Serial & Putty.

Neil
 
Last edited:

Ga-Retired

New Member
Just got my HC-12's today an have been following this thread from Jeremy and others and was wondering which serial interface to use for programming the units.I looked at the Rev-Ed setup for their ERF modeles using the AXE027 serial cable and the "Back Shed" HC-12 setup utility (Neat), is this the best way to program these modules? My link won't be over 20-30 Meters or so at a planned 1200 to 2400 Baud rate sending Temp data.Hoping the helical spring Ant. will do the trick with a reliable link going thru one external wall.Thanks all for your help,very interesting thread for sure. Jeff
 

Jeremy Harris

Senior Member
Neil, you're right, programming in AT mode is 9600 baud

Jeff, I've found the FTDI USB to serial board to be very reliable and easy to use for programming these boards, either using a serial terminal programme of the very useful utility programmes written by Robert Rozee and linked to above. I've not tried using an AXE027 cable, but I do have an older USB to serial adapter that I took apart years ago and fitted into a small box, with a variety of serial interface cables, so I could connect to serial devices using USB, so I may get time tomorrow to test this and see if it works OK. It uses the old Prolific PL2303 USB to serial chip and I can't see any reason why it shouldn't programme these boards OK. Unlike the Picaxe, there is no special serial port requirement, I've managed to connect them to a real serial port (genuine RS232), using some level changing to get the signals down to 0 to 5V (rather than the -12V to +12V of RS232) and that worked OK.

As an aside, I find that programming Picaxe chips using a real serial port is a heck of a lot faster than using an AXE027. I recently acquired a Mini ITX 64 bit dual atom PC that was used as an industrial controller, and it has hardware serial and LPT ports. Makes me grateful for being a hoarder and keeping the +10 year old Picaxe serial programming lead I bought when I first started playing with them!
 

neiltechspec

Senior Member
Came across another issue this evening, am sending at 2400 baud and seemed to be clipping the last few characters.

Turned out I wasn't leaving time to allow for sending to complete before putting the module into sleep mode.

I am using an FTDI USB2Serial for programming and receiving test messages from HC-12's without issues. A 08M2 is doing the sending.

Neil.
 

lbenson

Senior Member
... the "Back Shed" HC-12 setup utility (Neat), is this the best way to program these modules?
I think you should be ok with any working ttl level usb/serial dongle and the Back Shed HC-12 setup utility. Be sure to cross over RX & TX. This worked for me.
 

Jeremy Harris

Senior Member
Came across another issue this evening, am sending at 2400 baud and seemed to be clipping the last few characters.

Turned out I wasn't leaving time to allow for sending to complete before putting the module into sleep mode.

I am using an FTDI USB2Serial for programming and receiving test messages from HC-12's without issues. A 08M2 is doing the sending.

Neil.

I'm finding out similar quirks with timing. There is a disparity between the baud rate at the module and the baud rate over the air, plus some sort of "housekeeping" going on in the front end processor, so the serial link in some modes isn't as completely transparent as it could be. There are also some odd quirks, like the very high over-the-air baud rate in some modes, especially the HC-12 in the low power mode, and this means that it's very difficult to predict range variation from input baud rate.

Only really minor problems, and they wouldn't be problems at all if we had decent data sheets, that were clear as to how each mode worked internally.
 

manuka

Senior Member
Can I strongly encourage folks to experiment with alternative antenna, especially since the "spring" helical that comes with the HC-12 modules seems no great performer. All manner of simple & cheap DIY designs exist of course! The loaded coil (pix below) may even show promise-wind turns on a small screwdriver blade perhaps.

Don't forget that at UHF height can be everything - grassroot setups may struggle to cover a fraction of the distance of even modestly elevated systems.

Although the HC-12 is compact,versatile & very cheap, it's fair to say that in urban regions only "a 100 metres or so " could be expected at even slow data rates, although LoS could reach to several km. Ranges however greatly exceed classical ASK 433 MHz setups, which additionally need seperate RX & TX modules (rather than a single combo transceiver module) and antenna.

Field work: A recent stroll around my village confirmed that classic ~165mm ¼ wave verticals are superior to the bare HC-12 helicals,with reliable ranges approx doubled. Dead spots tended to relate to metal garages, tennis court mesh fences & ferro-cement buildings (halls, & schools etc).The 25mW TX was placed several metres high on a wooden support, while the RX was handheld. The slowest FU4 mode was used,as it's stated as giving the best coverage. This suits "occasional data" IoT applications of course - we're not streaming video!

Findings were consistent with many other 433 MHz GFSK transceiver modules (often larger & far more costly) that I've worked with in recent years.

Footnote: I used much the same code & setup previously organised for LoRa™ modules (see =>http://www.instructables.com/id/Introducing-LoRa-/ ). That 2014 workout revealed a blanket coverage of the village out to several km, with LoRa™ signals only stopped by rocky headlands. LoS coverage at sea level was maintained right across the harbour (~10km). Yes - LoRa™ ranges tend an order of magnitude better for the same power, antenna & setup conditions - as Stuart will readily confirm !

Stan.
 

Attachments

Last edited:

Jeremy Harris

Senior Member
I'd second that view. My first application using these modules is using 1/4 wave monopoles, made from stainless wire, and, as I mentioned here: http://www.picaxeforum.co.uk/showthread.php?28761-Alternative-to-ERF&p=297037&viewfull=1#post297037 and here: http://www.picaxeforum.co.uk/showthread.php?28761-Alternative-to-ERF&p=297138&viewfull=1#post297138 the range does significantly improve over just using the tiny helical antenna.

As I mentioned here: http://www.picaxeforum.co.uk/showthread.php?28761-Alternative-to-ERF&p=296838&viewfull=1#post296838 my primary application needs a tiny antenna that will fit inside a small waterproof plastic box that is outdoors, and the other application I'm looking at (the replacement of time switches with a central radio code clock and command unit) won't tolerate an external antenna, either, as I need to fit the slave switch units inside a standard wall mounted power socket box, and an antenna on the outside could get in the way on some of them.

I have bought some loaded 1/4 wave antennas, with SMA connectors, together with some short SMA to U.FL leads and that seems to be a fairly neat compromise, certainly not so much of a problem as the 173mm stainless whip antenna I'm using on one unit in my garage. The rubberised loaded whips are around 83mm long overall. Here's one fitted to a small Picaxe based control box I made last week, using an HC-12:

Indoor remote control.JPG

Luckily I only need to transfer a handful of bytes reliably, fairly infrequently, and a very slow baud rate wouldn't be a hindrance. The FU4 mode, at 1200 baud (500 baud over-the-air) seems ideal, as even with poor antennas and the power turned down to +8dBm to be legal the range and ability to penetrate through walls still seems to be very good (some ad hoc tests show that the units provide a rock-solid link from within the deepest recesses of the house out to around 100m away outside).
 

Ga-Retired

New Member
Thanks Jeremy and Ibenson for the advice on programming the HC-12's.I thought I read a post along this thread from maybe Technical, saying he "Always used the Axe 027 to program these modules",and of course ,I can't find that post again! I'll give it a try and see how I do.Also I noticed in PE6 ,the Wizards tab, there's an ERF utility, anyone ever used this before? Stan,on that loaded whip antenna,used it on those Dorji Ask modules and and had very good results but ended up just using a straight 173 mm wire with decent performance for my needs anyway.As Jeremy said,may in up sacrificing some performance with the smaller antenna's,but I may have to go the route of that rubber ducky,that makes for a neat setup,thanks everyone,Jeff
 

manuka

Senior Member
Possible handy tip for those after insights on " just what my $%#@#^$% HC-12 transmitter is doing":

When up to your eyeballs in code & cabling it's easy to get task tunnel vision & neglect such basic aspects as the wireless signal itself. Yes- it's quite feasible to monitor your TX with other radio gear at hand ! I've used a Baofeng UV-5R that's also good for the wider legal "70cm band" ham freqs. A simple 433MHz ASK sniffer (see below) may also do -you'll hear the HC-12's FM as "scratches".

Eagle eyes may have noted that although stated as offering 100 channels,HC-12s can in fact be programmed over 128 channels with Rob Rozee's nifty utility. These channels are 400 kHz stepped over ~50 MHz between 433.4000 MHz (Ch.1 ) & 484.2000 MHz (Ch.128), & - at least "down under" - the extended range allows output signal monitoring on cheap RF gear probably already at hand.

By chance a couple of Aus/NZ UHF CB channels (24 & 40) exactly match the HC-12's at a few spots. (Sigh -it's a pity the long neglected designated Ch. 22 & 23 "data" channels don't quite match however...) Down under UHF "walkie talkies" hence may be used to listen in to outgoing HC-12 signals for data/ duty cycles issues/ antenna tweaking benefits/ RF sweet & sour spots etc.
Code:
Aus/NZ UHF PRS ch.         HC-12  ch.                 Freq.                  
          24                 110                  477.0000 MHz                
          40                 111                  477.4000 MHz
Those in UK/EU with PMR 446 or US/Can with FRS equivs. may not be in luck however, as a quick glance at your frequency allocations show no exact matches. Experiment, BUT naturally keenly respect local regs. concerning power & out of band TX settings - at the least set the HC-12 TX power down as low as possible so that signals barely cross the room ! Stan. ( Ham ZL2APS since 1966)
 

Attachments

Last edited:

manuka

Senior Member
Just to hand from fellow Kiwi Robert Rozee - the HC-11/12 graphical config utility man.
Hi - I've just spent a most enjoyable couple of hours reading the picaxeforum.co.uk HC-11/12 thread, and am quite chuffed to see folks getting good use out of my utilities! To check the version, double-click on the "HC-11" or "HC-12" logo and a small popup window will display the release info.

I see the HC-11 version has problems reported with AT commands sent without any delays between them. I only have HC-12 modules here, so the HC-11 version was written 'blind'. I've now updated both utilities (link at top) so that there is a 20mS delay between AT commands.

See the file "HC11 and HC12 config, 25-may-2016.zip" at the following link (this is not a permanent download location): https://storage-us.mail.com/qx/mail_com/?locale=en&guestToken=bcLNnjf3SbCixbLWq7WyIA&loginName=rozee@mail.com

I'd appreciate it if some of the PICAXE forum folks could test that this solves the issue- please feel free to email this zip file to any of them, or post it directly on that forum (or indeed post it elsewhere). I'm more than happy to fix any other bugs that crop up.


My editing of the HC-12 user manual was deliberately carried out with a 'light hand', the goal being to get the diagrams and layout cleaned up, and fix just the worst of the Chinese/English. There were a few amusing bits of 'bad English' that I very deliberately left in. The sources were an older English version (presumably translated from Chinese by the manufacturer) and a much newer Chinese language version that described enhancements like the AT+FU4 command available in later firmware versions.
Any thoughts ? Minor editing via Stan.
 

Attachments

Jeremy Harris

Senior Member
That's great that Robert Rozee has changed the HC-11 utility and been so generous. I'll test the new one out this afternoon and report back as to whether it fixes the error messages that pop up with the older one. I should add that the error messages don't stop it working at all, clicking "OK" on each one as it pops up and then checking the configuration always shows that the HC-11 has been programmed correctly with the original HC-11 programming tool.
 

Jeremy Harris

Senior Member
I've just done a test with the new revised HC-11 utility, and unfortunately it still returns a series of error messages when programming this modules. It programmes them correctly, but the error messages seem similar. The first error messages that comes up is:

"invalid response (3.4)
command <AT+B1200>
response <>"

With an "OK" box

The other error messages come up in sequence for each command sent, so as soon as the "OK" box is ticked on the first one this one comes up:

"invalid response (3.7)
command <AT+C004>
response <>"

and so on through each command sent in sequence, with the final error being:

"invalid response (3.19)
command <AT+UN1>
response <>"

Looking at these I'm guessing that the programming tool is getting an unexpected response back from the HC-11. To try and narrow this down, if I send AT commands to the HC-11, say I send "AT+C004", then the response I get back from the module is "OK-C004", similarly, if I send "AT+B1200" then the response I get back is "OK-B1200". If I check the configuration, by sending "AT+RX", then I get this message back (with the CR and LFs, so it looks exactly like the text below on the terminal screen):

U2
B1200
C004
A000
P8

Unfortunately I've no way of knowing how long the delay is between sending a command via the terminal and the module responding. I have spotted that the messages returned by the HC-12 modules are different, though, and this may be at the heart of the error message issue. If I send "AT+RX" to one of my pre-programmed HC-12 modules, then this is what appears on the terminal screen:

OK+B1200
OK+RC004
OK+RP+8dBm
OK+FU2

A very different response to that from the HC-11. Similarly, sending the single command "AT+B1200" to the HC-12 from the terminal gives a response of "OK+B1200", which is different to the HC-11 response to this command that is "OK-B1200"

Could it be that this is at the heart of the issue, that the HC-11 tool is expecting to get "OK+" as the header to the response when the HC-11 actually returns "OK-" as the header?
 

techElder

Well-known member
Would it be a problem if the "HC-11" tool just returns the response received from the module instead of interpreting whether the response is an error or not?
 
Top