How to switch OFF the HC12 Tx function completely?

Projects Networking, Protocols, and Devices
1

Hi,
Is it possible to COMPLETELY disable the HC12 Tx function, so the module becomes a serial receiver only?

I have set the Px to 1 in the command AT + Px, but that gives me a lingering .8mW which still causes me issues as I'm using several HC12 units as receivers to one as a transmitter, and they have high-gain antennae to further compound the issues. btw, 0 is not accepted.

Is there a trace I can cut to completely nuke the Tx component failing a software solution?

excerpt from the manual
• AT+Px
Set the transmitting power of the module, with x selectable from 1 to 8. The
corresponding transmitting power of the module is as shown below:
x value 1 2 3 4 5 6 7 8

Transmitting power of module:
1 2 3 4 5 6 7 8
-1 dBm 2 dBm 5 dBm 8 dBm 11 dBm 14 dBm 17 dBm 20 dBm
(0.8mW) (1.6mW) (3.2mW) (6.3mW) (12mW) (25mW) (50mW) (100mW)

The default value is 8, and the higher the transmitting power, the farther the
possible wireless communication distance. When the transmitting power level is
set to 1, the transmitting power is at the minimum. Generally speaking, every
time the transmitting power is reduced by 6dB, the communication distance will
be reduced by half.
e.g: Send command “AT+P5” to the module, and the module returns “OK+P5”. After
exiting from command mode, the transmitting power of the module will be set to
11dBm.

2

The reason I'm forced to consider this seemingly drastic measure is as follows:
I have one transmitter (Tx) unit generating timing data, and several receiver (Rx) units which receive this data and show it on LED matrixes via Serially commanded Matrix Drivers.

If I run 2 (or more) Rx units I get weird results quite randomly.
Sometimes all goes correctly and the Rx units display the data from the Tx unit just as intended.

However, sometimes the data gets garbled. When this happens the results are randomly strange.

Trying to understand the reasons (I have no scope nor any access to one), I have found that the problem NEVER occurs when only one Rx unit is in play; I can run the system 1:1 all day with no issues.

And, furthermore, the problems can manifest regardless of the separation between the 2 Rx units: 1m to 50m, makes no discernable difference.

This leads me to believe that the issue is to do with signals getting from one Rx to the other Rx as passthrough of the received command and this unwanted signal is interfering with the Tx signals that follow.

So, my solution is to attempt to kill the passthrough signal output on the Rx units.
Hence my question:
Is there a way to completely kill the output of a HC12 unit, rendering it solely capable of receiving?

If anyone has any other ideas, or can see any issue with my thinking, please let me know.

3

If the RX device cannot send an acknowledgement of either correct data message or an error message, your system will not work.

Also from the manual:

However, considering ambient
interference and other factors, if thousands of data bytes are sent
continuously, some number of bytes may be lost. Therefore, the attached devices
at each end of the link should have some sort of response and resending
mechanism to avoid information loss.

Paul

4

Paul_KD7HB:
If the RX device cannot send an acknowledgement of either correct data message or an error message, your system will not work.

Thank you for your response Paul,
But as I've said the system works flawlessly with just one Rx.

It is ONLY when more than one Rx is in play that I get the random issues.

5

OldManNoob:
Thank you for your response Paul,
But as I've said the system works flawlessly with just one Rx.

It is ONLY when more than one Rx is in play that I get the random issues.

I am not surprised if more than one RX is sending an acknowledgement at the same time.

Paul

6

The Hc12 is a bidirectional transceiver, but only at the data input output port.
The RF link is uni directional, and has to be periodically turned around to allow the data port to appear to be bi directional.
The type of data you are sending, the data rate and any pauses in the data being sent will impact on the ability of the data to be received properly.
Try reducing the data rate of whats being sent, and leave gaps in the data so its not continuous, and see if that improves.
The more receivers there are, the more the transmission link has to be reversed.
A HC12 is not really a good solution to what you are trying to do.
You would be better off with something simpler like one of the cheaper 433 Mhz OOK transmitters and receivers using Virtualwire.
The only other way to make this work is to set each receiver on a differant radio channel and then cycle the transmitter through the differant channels transmitting the same data each time.

7

Hi Mauried,
Thank you for taking the time to have a look at my issues.

mauried:
The Hc12 is a bidirectional transceiver, but only at the data input output port.
The RF link is uni directional, and has to be periodically turned around to allow the data port to appear to be bi directional.
The type of data you are sending, the data rate and any pauses in the data being sent will impact on the ability of the data to be received properly.
Try reducing the data rate of whats being sent, and leave gaps in the data so its not continuous, and see if that improves.

I am tricking around today with introducing delays to see the impact.
Of note: The timing module - countdown - works flawlessly regardless of whether or not I have both Rx in play. It is the command to enable the matrix controller/screen setup and the small animation setup that are affected, so I will be looking hard at these areas.
In the case of the matrix setup, I appear to miss a crucial "inverse" signal on one and fail to initialise entirely on the other, resulting in one (either, randomly) screen being in negative, and the other just blank.
In the mini animation (letters scooting across the screen) the font/size parameters sometimes jumble, and in nearly identical fashion on both screens. Both of these faults are completely absent when only one screen (Rx) is in use. Rebooting the Tx (which results in a reboot of the matrix controller on the Rx side) can clear the fault 3/5 times. I wonder if my issues will worsen with 3, or 4 screens?

mauried:
The more receivers there are, the more the transmission link has to be reversed.

I'm not at all sure what you mean by this.
I haven't even got the Serial Transmit pin connected on the Rx unit side, not the Receive on the Tx side, as I'm deliberately attempting to keep the data flow mono-directional, and as an approach with this setup it seems to work since I'm happy for the Rx units to 'pick up' where the stream left off if any data is lost in Tx due to occlusions or interference. It is a timing system, and the timing stream is the important thing.

mauried:
A HC12 is not really a good solution to what you are trying to do.
You would be better off with something simpler like one of the cheaper 433 Mhz OOK transmitters and receivers using Virtualwire.

Looking at these units I see they are incapable of Serial data transmission/reception: "Can we use Serial communication with ? answer is No
ASK receivers require a burst of training pulses to synchronize the transmitter and receiver, and also requires good balance between 0s and 1s in the message stream in order to maintain the DC balance of the message, UARTs do not provide these. They work a bit with ASK wireless, but not as well as this code."

mauried:
The only other way to make this work is to set each receiver on a differant radio channel and then cycle the transmitter through the differant channels transmitting the same data each time.

Sadly this is also not an option afaik, as I am expecting each screen to show the time simultaneously, and to sound off Zero at the same instant. A cascade effect would surely be the result in such a setup?

8

About the only way to achieve what you need is to reprogram the STM8S003F3 Micro on the HC12 board to do what you want, but thats a non trivial task.
You could have a look at Xbees and see if they will do what you need.

9

mauried:
About the only way to achieve what you need is to reprogram the STM8S003F3 Micro on the HC12 board

  • to nuke the ACK component (that I was wholly unaware of until this issue reared its ugly head)?
    My understanding was that the HC12 was a serial wire analog, and would need to be commanded to send - obviously not, it would seem.

Ho hum, back to the drawing board...

10

I thought that in basic mode the TX is on only if i put some data into the RXD 3 pin. The manual is not very clear about what these modes actually do.

11

There are other long range modules. TX only and RX only and Lora modules.

12

Thank you LMI1, Makes me feel less of a dweeb knowing that my reading of the manual was not so different to yours.

LMI1:
There are other long range modules. TX only and RX only and Lora modules.

Have you any pointers, or experience of others? Bearing in mind that they'll need to operate pretty much like the HC12 as virtual Serial wires.

13

I sometimes read what i want it to be and not what is actually written. Normal I quess. HC-12 modules have long range and do not cost much. It is easy to wish too much

I once used in project ISM modules from RF solutions https://www.rfsolutions.co.uk/. They still work perfectly. And have a long range. But they were not as cheap as HC-12. Receiver especially costed around 50 euros or so. We used a module called QMR1. But it was around 2001.
Radiometrix is an other I know but I have not needed their products, so I can't really say anything specific.

In a moving machine, everything (including these modules) must be soldered of course but also glued in place. Othervise they'll shake themselves loose.

If you google ISM transmitter or ISM transmitter modules you'll get plenty of hits. ISM is the license free frequency band.

Regards
Leif M

14

Not only is the HC12 data that is sent and received not error checked, so you have to arrange your own, you cannot definetivly control what the HC12 is doing, the on board micro has control really.

One of the packet based tranceivers, supported by the Radiohead library might be a better idea, RFM22B, RFM24, RFM69 or the LoRa devices.

With these packet based receivers whilst the software might cause you a bit more brain stress, you do have direct control as to what is happening at a low level, if you want an RX only for instance that is easy to setup, and the devices do support CRC checking of packets.

15

Thank you srnet and Leif,
Plenty to get on with in those suggestions.

Following further tests on the HC12s, with particular reference to Mauried's suggestions ref time delays, I've identified where extra millis have largely solved the issues.

It would seem that the matrix driver requires extra time to process commands like setting inverse than they do for other less complex tasks.
So, assuming I'm understanding the process involved, extra delay before commencing transmission of the next command after transmitting one of those is required to allow for the slightly longer delay before the resultant ack response has completed, and especially so when more than one Rx is calling back. And that explains why a single Rx unit operated fine but two or more give rise to bottlenecks in the code at those commands, but only at those particularly complex matrix instructions.

16

If you google hc-12 firmware you'll get hits. Someone has already hacked those things. I did not find anything simple enough for me but we'll see.
And there is code generator from RF ic manufacturer.

17

OldManNoob:
Hi,
Is it possible to COMPLETELY disable the HC12 Tx function, so the module becomes a serial receiver only?

I have set the Px to 1 in the command AT + Px, but that gives me a lingering .8mW which still causes me issues as I'm using several HC12 units as receivers to one as a transmitter, and they have high-gain antennae to further compound the issues. btw, 0 is not accepted.

Is there a trace I can cut to completely nuke the Tx component failing a software solution?

excerpt from the manual
• AT+Px
Set the transmitting power of the module, with x selectable from 1 to 8. The
corresponding transmitting power of the module is as shown below:
x value 1 2 3 4 5 6 7 8

Transmitting power of module:
1 2 3 4 5 6 7 8
-1 dBm 2 dBm 5 dBm 8 dBm 11 dBm 14 dBm 17 dBm 20 dBm
(0.8mW) (1.6mW) (3.2mW) (6.3mW) (12mW) (25mW) (50mW) (100mW)

The default value is 8, and the higher the transmitting power, the farther the
possible wireless communication distance. When the transmitting power level is
set to 1, the transmitting power is at the minimum. Generally speaking, every
time the transmitting power is reduced by 6dB, the communication distance will
be reduced by half.
e.g: Send command “AT+P5” to the module, and the module returns “OK+P5”. After
exiting from command mode, the transmitting power of the module will be set to
11dBm.

Hi,

  1. You need shielding. Connect things to GND correctly to remove noise
  2. If need add small capacitor to filter out peaks in Vcc, give it 100nF or 10nF
  3. Ensure that you have sufficient power to power HC12. I suggest adding between Vcc and GND of the HC12 470uF capacitor to ensure that if it will need power for TX ad RX
  4. Introduce some sort of hash or CRC for your data. This is what i did and now i don't have to worry about mess in the data. That may always come
  5. Try to get different antena as there is small connector for other antena. Or try simply adding like 20cm wire to spiral antena that is builtin

BR
L

18

Something like these:

or this

It is also in Ebay