Repeater using HC-12 UHF module

MFB

Senior Member
I am attempting to increase the range of a telemetry link by using a radio repeater. The HC-12 based environmental monitoring module is designed to operate for a year from 4 AA batteries. This is easily achieved by powering down the sensors and the HC-12, and allowing the PICAXE to sleep between transmissions. Each transmission is only a few seconds long, at a rate of once every ten minutes.

The problem is, that without the complexity of independent time synchronisation, a battery powered HC-12 based repeater would have to remain permanently on (and drawing about 20mA) whilst listening for telemetry transmissions. I have not been able to find a reference to any low power receive only modes of operation in the HC-12 documentation. Has anyone found a way to do this?
 

hippy

Technical Support
Staff member
It doesn't answer your specific question but you can minimise receiving power by turning off the receiver until the window of time in which a transmission should arrives comes about. That should only require a full 10 minute on period when receiving starts-up and perhaps the same if a transmission does not arrive. That shouldn't be too complicated to organise.
 

MFB

Senior Member
Thanks for the suggestion Hippy, but that's what I meant by "without the complexity of independent time synchronisation". As you know, the timing of sleep commands is not very accurate and it would probably be necessary to add RTCs to the transmitter and the repeater circuitry in order to keep them in sync over a period of weeks.
 

Circuit

Senior Member
it would probably be necessary to add RTCs to the transmitter and the repeater circuitry in order to keep them in sync over a period of weeks.
I think that Hippy is thinking that each time a "receive" occurs then a re-synchronisation occurs too. That way the synchronisation of the two units is never lost.
 

MFB

Senior Member
I think that Hippy is thinking that each time a "receive" occurs then a re-synchronisation occurs too. That way the synchronisation of the two units is never lost.

Thanks, I hadn’t thought of that approach.

Following an initial extended listening period, it should indeed be possible to maintain synchronisation between succeeding transmission bursts. Even the internal RC timing of the transmitter and receiver PICAXEs should be able to remain in sync for ten minutes and a measure of timing overlap can be included to cover a bit of drift.

A good response yet again from this forum!
 

hippy

Technical Support
Staff member
I think that Hippy is thinking that each time a "receive" occurs then a re-synchronisation occurs too. That way the synchronisation of the two units is never lost.
Exactly that. As long as it's awake for one transmission, it can sleep then wake prior to the next, re-synchronises to each reception.

It gets more complex if one wants to wake up as close to transmission time as possible but, if there is some leeway, a wider window, it will still work though won't be as optimal. But even waking up 30 seconds early for a 10 minute period would still amount to a saving of 95%.
 

inglewoodpete

Senior Member
Time for a little SLEEP?

... I have not been able to find a reference to any low power receive only modes of operation in the HC-12 documentation. Has anyone found a way to do this?
I have not tried it (yet) but the HC-12 manual v2.4B indicates that it disables the transmitter when it enters the SLEEP mode. It does not say that the receiver is disabled too - just that power consumption drops to around 22uA and that "This (SLEEP) mode doesn’t allow serial port data transmission." Perhaps there is room for experimenting there? Please report back - I'd like to know too:) but will have to find out in the next few weeks anyway as my current project develops.
 

MFB

Senior Member
I have not tried it (yet) but the HC-12 manual v2.4B indicates that it disables the transmitter when it enters the SLEEP mode. It does not say that the receiver is disabled too - just that power consumption drops to around 22uA and that "This (SLEEP) mode doesn’t allow serial port data transmission." Perhaps there is room for experimenting there? Please report back - I'd like to know too:) but will have to find out in the next few weeks anyway as my current project develops.
Thanks but its unlikely that 22uA would power even the simplest of UHF receivers, so the module probably is just sitting there twiddling its thumbs.

Having had a bit more time to think about using resynchronisation, I realised that it will not be quite as simple as it seems, because (given the nature of radio communications) the repeater will often have to recover from missed transmission bursts. The algorithm thinkens.
 

AllyCat

Senior Member
Hi,

AFAIK, the HC-12 does have a low power mode (called FU2) consuming 80 uA (average). I believe it transmits a very short burst of data, at a high data rate (so the peak current might be quite large), and then sleeps for a time. The "transmission delay" is quoted as 500 ms, which might give an indication of how frequently the receiver looks for data?

But if you want a "Do It Yourself" solution for a period of 10 minutes (which seems rather long if there is a significant risk of many packets being "lost"), then the accuracy of the PICaxe Sleep timer (the PIC watchdog) is not as bad as the manual implies. But for such a system it would be wise not to use just a simple "sync" (delay) method; you should implement a software Phase-Locked-Loop:

After the PICaxe wakes up, it looks in a timing "window" for a few seconds (or as required by the system tolerances and potential maximum number of lost packets). If the transmitted burst is "early" or "late", relative to the centre of the receiver window, then the software adjusts the sleep timing delay accordingly. If no burst is seen then the software sets up the same sleep interval again and hopes that the next burst will be received successfully.

Of course much more complex protocols are possible, as the HC-12 is a full transceiver.

Cheers, Alan.
 

BESQUEUT

Senior Member
If no burst is seen then the software sets up the same sleep interval again and hopes that the next burst will be received successfully..
Your can try that 2 or 3 times (maybe enlarging window...), but if not successfull
you have to wait at least one time for 10 minutes for resynchronisation.
For example, power supply may be lost at receiver ; this will also simplify first power up...

After that, you can also try the 10 mn resynchronisation at regular interval , for example one every day.

After adjusting the "sleep timing delay", you can also adjust the "windows width" according to lasts corrections done.
So at start you can use a "pessimistic" windows witch will be reduced if delay is stable and well adjusted...
 
Last edited:

srnet

Senior Member
I would start coding from the situation where the stations have all just been powered on and are not in sync.

What do you have to do from this situation to get them in sync in the first place ?

You have not said whether this is cost sensitive or not, but there are GPS out there for less than £10 that will run very effectively in hot fix mode. You only need to run them a few seconds every 10s of minutes. They could run for a year or more on a pair of AAs, and would be a very accurate source of time.
 

MFB

Senior Member
I would start coding from the situation where the stations have all just been powered on and are not in sync.

What do you have to do from this situation to get them in sync in the first place ?

You have not said whether this is cost sensitive or not, but there are GPS out there for less than £10 that will run very effectively in hot fix mode. You only need to run them a few seconds every 10s of minutes. They could run for a year or more on a pair of AAs, and would be a very accurate source of time.
I now also think the easiest way to keep the the two ends in sync is to give them both accurate time bases. Although the project is not really cost sensitive, using crystal controlled clocks would be significantly cheaper than GPS modules.

Many years back I used crystal clocks onboard oceanographic bouys to implement a time division multiplexed telemetry network. Worked well for months until a faulty transmitter remained on and jammed all the others😥.
 

manuka

Senior Member
Assorted thoughts - some relate to the actual environmental application, long term or short event use, & geographic location etc:

1. Nature of the data -is it critical (Doors unlocked) or informative (Elvis has left the building)?

2. Does data need confirmation or local actioning via the distant HC12 unit ?

3. How often is data sent ? Could this significantly change during panic situations?

4. Security - what if someone "listens in" &/or locks up a repeater link ?

5. Local interference issues ?

6. By their very nature repeaters tend outdoor mounting (hilltop, building roof etc) & thus are probably solar powered. The HC-12 idle current, although mode related, is in the 10s of mA range & surges while transmitting up to 100 mA. Given adequate sun hence a small solar PV (~2-5 Watts ?) & suitable rechargeable battery (LiFePO4 ?) may be enough to power the repeater & allow the receiver to be always awake & listening.

6. THOUGHT: As send/receive & repeater unit(s) are probably all in the same geographic region then use the onset of prolonged darkness (LDR measured) as a synch?

Stan.
 

MFB

Senior Member
Assorted thoughts - some relate to the actual environmental application, long term or short event use, & geographic location etc:
Look
1. Nature of the data -is it critical (Doors unlocked) or informative (Elvis has left the building)?

2. Does data need confirmation or local actioning via the distant HC12 unit ?

3. How often is data sent ? Could this significantly change during panic situations?

4. Security - what if someone "listens in" &/or locks up a repeater link ?

5. Local interference issues ?

6. By their very nature repeaters tend outdoor mounting (hilltop, building roof etc) & thus are probably solar powered. The HC-12 idle current, although mode related, is in the 10s of mA range & surges while transmitting up to 100 mA. Given adequate sun hence a small solar PV (~2-5 Watts ?) & suitable rechargeable battery (LiFePO4 ?) may be enough to power the repeater & allow the receiver to be always awake & listening.

6. THOUGHT: As send/receive & repeater unit(s) are probably all in the same geographic region then use the onset of prolonged darkness (LDR measured) as a synch?

Stan.
Stan,

The data are river height measurements from an ultrasonic sensor. At a transmission rate of once every ten minutes, it's not a disaster if occasional packets are missed. The distance from the river bank to the house mounted receiver is only about 200 metres but it's difficult to get a LOS path because of buildings. A repeater would increase the choice of sensor locations.

I think synced crystal clocks in the sensor unit and repeater is probably the way to go. They just need to be initially reset at the same time and then keep in step for a year or so. Timing would have to include an sufficient margin to accommodate expected drift over this period.
 

manuka

Senior Member
OK & thanks for insights. As river height no doubt relates to local rainfall you'll have a 2nd opinion available anyway !

Thought- do you really need a repeater ? Just 200m in such terrain is probably very doable for direct point to point LoRa,which typically gives a few km in similar environments. Here at my harbourside NZ location,in a village featuring timber buildings, iron roofing & urban vegetation, 433 MHz head height LoRa signals "flood" the area & are only blocked by rocky headlands some km away - refer picture below which was exploring various Lora settings.

An even more striking confirmation was made by fellow Kiwi Andrew Hornblow, who found LoRa signals (sorry- settings unknown) were "leaping" 50 foot beach cliffs.

Stan.
 

Attachments

Last edited:

manuka

Senior Member
MFB: While pondering "Repeater -we don't need no stinking repeater!" it's perhaps worth considering that much more powerful UHF data signals are UK legal on a UHF slot between 458.5000 & 458.9500 MHz. Luckily an HC-12 can cover this at it's Ch.64 (458.6000 MHz).

When other things are equal a 6dB gain (or x4 the TX power) doubles range,so a near quadrupled range boost may arise when going from 10mW to 100mW. Stan.
 

MFB

Senior Member
OK & thanks for insights. As river height no doubt relates to local rainfall you'll have a 2nd opinion available anyway !

Thought- do you really need a repeater ? Just 200m in such terrain is probably very doable for direct point to point LoRa,which typically gives a few km in similar environments. Here at my harbourside NZ location,in a village featuring timber buildings, iron roofing & urban vegetation, 433 MHz head height LoRa signals "flood" the area & are only blocked by rocky headlands some km away - refer picture below which was exploring various Lora settings.

An even more striking confirmation was made by fellow Kiwi Andrew Hornblow, who found LoRa signals (sorry- settings unknown) were "leaping" 50 foot beach cliffs.

Stan.
Anyone following the excellent work of you and srnet will already be convinced of the atvantages of LoRa but I had already built the telemetry link using HC-12 modules that I had 'in stock'. However, it could well be time time to make a change to newer technology rather than introducing the complexity of a repeater.

BTW, not much chance of 2nd opinions on rainfall because most of the local roads around our village flood when theres too much!
 

manuka

Senior Member
By 2nd opinion I'd meant the classic lo-tech "stick ones hand outdoors & see if it's getting wet" ! OK on the ready to roll setup, but use it to give that HC-12 Ch. 64 a 100 mW whirl. Stan.
 

MFB

Senior Member
If you don't need the time, you could just use a crystal controlled counter on each board.
I had been planning on using a low cost crystal controlled RTC that has a programmable tick output to kick the PICAXE every ten minutes. Certainly no need to read the time over I2C.
 

MFB

Senior Member
By 2nd opinion I'd meant the classic lo-tech "stick ones hand outdoors & see if it's getting wet" ! OK on the ready to roll setup, but use it to give that HC-12 Ch. 64 a 100 mW whirl. Stan.
Thanks for for the Ch. 64 tip, which I will indeed give a whirl.

With all the useful suggestions over the past few days it looks like I'll probably not need to fiddle around with a repeater after all, but its been an interesting discussion. Many thanks to everyone.
 

MFB

Senior Member
By 2nd opinion I'd meant the classic lo-tech "stick ones hand outdoors & see if it's getting wet" ! OK on the ready to roll setup, but use it to give that HC-12 Ch. 64 a 100 mW whirl. Stan.
Just been checking the OfCom frequency allocation tables and don't think 100 mW is legal in UK.
 

srnet

Senior Member
100mW not UK legal ? Up to a paint blistering 500mW e.r.p. is seemingly permitted ! Reference this 2010 document (P.22) and Ofcom's current Strategic Review - P.21 . Ofcom's review response closing date (13th Feb. 2017) is fast approaching, so perhaps shoot them some thoughts !

Note- all manner of equipment type approval fish hooks may need considering... Stan.
High power commercial systems have been around for a while, you can buy them, not cheap.

Most readers of this forum would be using license exempt modules at UHF, for which the power limit is 10mW.
 

manuka

Senior Member
Modest blush, but factor in that I'm half a world away from the crush of UK/EU & experience a different regulatory environment.

Immense distances & low populations down here in the South Seas tend to influence wireless regs. USA sized Australia has just 24 million inhabitants,and ~UK equivalent NZ a mere 5 million. Although "near neighbours" we're approx. as far from each other (> 2000km) as the UK is from Greece.
 

PhilHornby

Senior Member
Door bells!

I am attempting to increase the range of a telemetry link by using a radio repeater. The HC-12 based environmental monitoring module is designed to operate for a year from 4 AA batteries. This is easily achieved by powering down the sensors and the HC-12, and allowing the PICAXE to sleep between transmissions. Each transmission is only a few seconds long, at a rate of once every ten minutes.

The problem is, that without the complexity of independent time synchronisation, a battery powered HC-12 based repeater would have to remain permanently on (and drawing about 20mA) whilst listening for telemetry transmissions. I have not been able to find a reference to any low power receive only modes of operation in the HC-12 documentation. Has anyone found a way to do this?
How do 433MHz RF door bells solve this problem?

The presence of a transmission (i.e. a bell push) is totally unpredictable, yet my 'Status' RF Doorbell responds instantly. The batteries last for months, so it surely can't be on continuously? (It sends 18 bits - each complete code occupies about 18mS and repeats after 12mS for as long as the bell push is pressed.)
 

MFB

Senior Member
How do 433MHz RF door bells solve this problem?

The presence of a transmission (i.e. a bell push) is totally unpredictable, yet my 'Status' RF Doorbell responds instantly. The batteries last for months, so it surely can't be on continuously? (It sends 18 bits - each complete code occupies about 18mS and repeats after 12mS for as long as the bell push is pressed.)


Good question.

The main difference is that a door bell detector is just a very simple and dedicated rf receiver, with no transmitter or microcontroller. The lack of ‘smarts’ probably explains why lightning and car ignition systems can so easily activate them.

Even so, it must be a challenge to design even a simple UHF receiver that will operate for months from a small mercury cell.
 

hippy

Technical Support
Staff member
I would guess a battery powered doorbell receiver is continuously running mostly in low-power mode with hardware which can detect the presence of 433MHz. Wakes up the controller when it sees that, which then reads the RF, goes back to low-power mode when done.

A 1mA draw, with 2400mAh batteries notionally gives some 2400 hours of use; 100 days, 3 months. Longer if the low-power consumption can be reduced. The RF detector might not be permanently on; if on for 1ms and off for 1ms that's a halving of average current, a doubling of lifetime, and that can probably be bettered.
 

manuka

Senior Member
It's the TRANSMITTER on wireless doorbells & car/garage remotes that uses a small cell (usually 3V Lithium coin),& the sender is only "ON" when the button is pushed ! The matching receiver has much larger batteries,& may even be mains powered.

The operation of a cheap & popular 433 MHz ARLEC DC149 type available here in NZ/Australia is probably typical. This receiver is powered by 2 x AA cells & ammeter monitoring shows brief "wake ups" before a cyclic drop back to doze drains of ~0.2 mA. Stan.
 

PhilHornby

Senior Member
Ding dong

The RF detector might not be permanently on; if on for 1ms and off for 1ms that's a halving of average current, a doubling of lifetime, and that can probably be bettered.
That would make sense. In fact, since one complete code only takes 30mS and most of these 'decoders' seem happy when they've received 2 or 3 identical codes, it probably only needs to be awake for a 100mS or so in every second (or whatever the minimum time is, that someone holds their finger on a bell push).
 
Top