TheBackShed.com

Forum Index : Microcontroller and PC projects : HC-12 to HC-12 or ESP-1 as repeaters

Author

Message

Quazee137

Guru

Joined: 07/08/2016
Location: United States
Posts: 600

Posted: 11:29am 22 Jan 2019

Copy link to clipboard

Print this post

Grogster

I was wondering if HC-12(A) set a on channel and HC-12(B) set at different
channel with RX(A) to TX(B) and RX(B) to TX(A) and placed out in the central
greenhouse with the main barn's HC-12 set to talk to Remote (repeater) HC-12(A)
and HC-12(B) talking to 16 other HC-12(B)'s. What kind of range can one get. And
going even further at last HC-12(B) greenhouse do a HC-12(C) to again 16 more.

Data read back is getting Greenhouse info temp, hum, light levels ect.
Data sent is to open/close louvers, misters and sprinklers.

The 2nd way would be to have HC-12 wired to ESP-1 in the same way.

Any thought's

CaptainBoing

Guru

Joined: 07/09/2016
Location: United Kingdom
Posts: 2171

Posted: 12:00pm 22 Jan 2019

Copy link to clipboard

Print this post

having a staging repeater in the middle is quite viable and you are limited only by the number of channels (and your sanity!

)

Have a look at LORA modules first though, you might not need to have a patsy - they have terrific range which is boosted further by lowering the baud rate. If you only have a small data exchange that might work for you.

For any radio comms, I would spend some time developing a protocol so that the repeater can perform actions in it's own right - that code can then be loaded on any "station".

I did something similar to extend reach with automatic discovery in networks of HC-12s and I could ask each in turn if it could "see" another station. Any commands for that remote were then routed through a successful staging station. Developing the protocol where commands could be interpreted, as a "layer" within the software, was a major plus to avoiding spaghetti code. Also, adding new features is a breeze. I ended up with a protocol where the master node could pass data to a given node and once unpacked, the protocol dictated whether the packet was for the recipient or a "my mate fancies your mate" kind of pass-through. The final recipient node's protocol would respond along the same chain. Edited by CaptainBoing 2019-01-23

Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9755

Posted: 02:55am 23 Jan 2019

Copy link to clipboard

Print this post

I've never actually tried it, but I see no reason why not. This kind of repeater is dead-easy to get going, and requires no intermediate processing, you just couple the two HC12's together. I would probably want to keep the receive and transmit frequencies as far apart as possible, just to avoid any kind problem there, but you would probably find it would work fine on adjacent channels if you wanted to try it.

Smoke makes things work. When the smoke gets out, it stops!

LadyN

Guru

Joined: 26/01/2019
Location: United States
Posts: 408

Posted: 07:22pm 25 Feb 2019

Copy link to clipboard

Print this post

CaptainBoing said having a staging repeater in the middle is quite viable and you are limited only by the number of channels (and your sanity!

)

I did something similar to extend reach with automatic discovery in networks of HC-12s and I could ask each in turn if it could "see" another station. Any commands for that remote were then routed through a successful staging station. Developing the protocol where commands could be interpreted, as a "layer" within the software, was a major plus to avoiding spaghetti code. Also, adding new features is a breeze. I ended up with a protocol where the master node could pass data to a given node and once unpacked, the protocol dictated whether the packet was for the recipient or a "my mate fancies your mate" kind of pass-through. The final recipient node's protocol would respond along the same chain.

CaptainBoing, this is EXACTLY what I am trying to achieve with my "mesh" idea that you provided valuable insight on in the other HC12 thread.

Would you either be interested in open sourcing (atleast portions) of this great idea or guide me trying to do it?

CaptainBoing

Guru

Joined: 07/09/2016
Location: United Kingdom
Posts: 2171

Posted: 09:07pm 25 Feb 2019

Copy link to clipboard

Print this post

It is all down to your protocol. Remember; All my master code is VB not MMBasic

Look at it from a slave node's PoV:

A packet is received (we'll assume all the decryption & addressing is resolved and we have a payload)

With my protocol, I determined to have the first four characters of *any* payload as an instruction or reporting "verb"

E.g. slaves in the snooker club code respond to (these are Inbound messages from the master) may be others I have forgotten just off the top of my head.

STAT - reply to me (the master) so you can be registered as discovered. Only ACK0 allowed as a reply verb (see below)
POLL - your chance to tell me something if you want.
SAFE - go into your safe configuration - e.g. isolate your mains output for an engineer to work on you.
FIRE - go into your fire mode - e.g. turn your light on to provide illumination or play an evac message.

The responses to these *can* be (but do not reply if the message was to address 999; broadcast)
ACK0 - this is the end of my reply (and may provide a payload back to the master)
ACK1 - I have more to tell you after this + payload. Master will immediately POLL the same slave.

When I was experimenting I also provided a "stretch cycle" - I mentioned this before... it takes my usual 1.5 second cycle out to 2x2seconds ish. This allows time for the extended reach attempt slave-to-slave. The master sends a LOOK message (can you see this node?) The remote node's address is in the payload. The master then enters its stretch period, then does a POLL of that same slave on the 1.5 second cycle. During this time, the slave has picked the message for the other slave node (a STAT) from the payload and sent it but with its own address as the source (to respond to) - every other node (they are all listening) ignores the packet. If the remote slave does not respond, the local slave does not respond either to the stretched POLL and the master assumes the relay was unsuccessful and moves on. If it gets the ACK0 from the local slave (remote responded to my STAT - the relay was successful) any discovery data is in an embedded ACK0 from the remote in the payload and the master registers the first slave as a potential route for a stretched POLL for the second.

There is no magic to it - it is all down to the protocol and interpreting the "verbs".

I never wrote up this code as it was only ever experimental (unlike the wiki of the basic star which is the working prototype of what went on to become a commercial product). I didn't pursue it. There are major complications with auto discovery - are you going to ask every node to find the possible remaining 970 nodes? This would make a full discovery take about 2 hours! (ok, you could drop the maximum address a bit to help) There is no easy way to auto discover a node that can't directly hear the master or to decide which node might be best suited as a relay without "pre-loading" - which is why I pretty much abandoned the idea especially in the face of the viability of a rock solid hardware repeater with 2xHC12s back to back - It costs <$10 and supports auto-discovery.

Look at the protocol in that wiki article - it is really easy to add new functionality. I won't be releasing any software that isn't in the Wiki - I really don't want the hassle of "having to" maintain it for others. I publish work when I can and you are free to make of it what you like (even as a commercial product) but that is where I want my responsibility to end. I have seen others get hassled over well-meaning acts of altruism. Don't hate me.

Define your own protocol and post here when you get difficulties.

Edited by CaptainBoing 2019-02-27

Print this page

To reply to this topic, you need to log in.