I am currently receiving data from HC-12 modules via USB-TTL that are working in pair . But I want to receive data simultaneously from 4 Hc-12 modules to a single HC-12 module via USB-TTL.
When a HC-12 is transmiting all other HC-12 in his range (using same frequency) are receiving. So if you want your transmiter to talk to one specific HC-12 then to an other and so on, you have to create a kind of "message protocol".
Let's say you have an Arduino with a HC-12 and 4 buttons and want to turn on-off 4 lights, each connected to a HC-12. You can use a binary representation, so a byte, on which each bit as a meaning.
Bit 0 -> at 1 -> turn on the light at 0 turn off
Bit 1-2 -> give the number of the HC-12
So 00000111 -> message for HC12 number 4, tell it to turn on the light. ALL HC-12 will receive the message. So each has to check the incoming byte to see if "it's for me" or nor. If you want one HC-12 to receive from many HC-12, that's the same: the message must contain the "id" of "who is sending".
The problem with multiple transmitter mostly resides in the collision risks. On networking contexts like Ethernet, There is a collision detection protocol making transceiver know that a problem arises, but that doesn't exist with HC-12, so you need something else.
In air contexts like this one, another solutions might to minimize chances of collisions restraining onself to a low bandwidth percentage (e.g.: not more that 10% of the total time) and just ignore lost packets.
However, if you cannot ignore lost packets, you need to implement a synchronisation protocol between receiver and transmitters. A solution would be to make some kind of token bus, where your receiver would poll each transmitter each on his turn to see if it has something to send.
However, since it is not recommended (and sometimes not even legal) to use to much time slices, you should avoid continuously polling all the transmitters.
In this case, what I suggest is that each transmitter can "wake up" the receiver by sending an unattended message. If this doesn't not cause reaction, this is interpreted as a collision detection. Then the transmitter wait for a specific delay (each one having a different delay value) - or a random delay.
When the receiver receives this packet it processes it, Then polls all the other transmitters, and then goes back to sleep mode, until the next time.
If the packets are long it might be better to have a short wake-up packet and to send the real data during the polling phase, and if the packets are short, you can just use the collision avoidance mechanisme alone.