hc-12

friis

Senior Member
Hi,
I have a statement in a pgm:

Init_HC12

which is preceded by two macros:

Code:
#macro Talk_HC12(msg)
        ;
        ; Send commands to the HC-12
        ;
        sertxd ("CCCC",cr,lf)                        ;that we can get here before it sends its response.   *****************
      gosub Clear_Response_Buffer        ;Clear out the buffer we use       
        
      Serout TX_Pin,HC12BaudRate,(msg)    ;send the command
        
      gosub Get_Response            ;and accept the returned data. The HC-12 is slow enough,
        
        Pause FortymS                ;wait to 'ensure' HC-12 has accepted the command
    #endm

    #macro Init_HC12
        ;
        ; Initialise HC-12.
        ;
        
      low HC12_set                ;take set pin low - Enter Command Mode
        Pause FortymS                ;wait 40mS
        ;
        ; Some sample commands you might use...
        ;
        sertxd ("AAAA",cr,lf)                        ;that we can get here before it sends its response.    *****************
      Talk_HC12("AT")                ;just a bit of a clearout, of any rubbish in the buffer
        sertxd ("BBBB",cr,lf)                        ;that we can get here before it sends its response.    **********************
      Talk_HC12("AT+P8")            ;20dBm - 100mW
        
      Talk_HC12("AT+C064")            ;458.6MHz
         
        high HC12_set                ;take set pin high, which actions the command(s)
        Pause EightymS                ;wait 80mS for any changes to take effect, before entering pass-thru
      
    #endm
When I run the pgm AAAA is written to the Serial Terminal followed by a never ending series of hex-codes - but neither BBBB nor CCCC appear. Can anyone see what is happening here?
best regards
torben
 

PhilHornby

Senior Member
I suspect the problem lies elsewhere in the code ;) ... maybe there's a SETFREQ lurking in there somewhere, that's altering the Baud rate of the Serial connection?
 

inglewoodpete

Senior Member
I wrote my HC-12 code for a 20X2, using background serial reception. It is based on Phil's code, though and there is very little difference.

To add to Phil's response, (1) which PICAXE? (2) what is the pin definition for TX_Pin? (3) what is the definition of HC12BaudRate? ...and what Phil asks: (4) what is the clock speed of the PICAXE at the point where the SerOut and SerIn commands are executed?

Your initialisation code and definitions probably hold the key but we can't see that.

What happens if you adjust the Serial Terminal's baud rate while the "ever ending series of hex-codes" is being received? Can the PE be synched at another baud rate?
 

hippy

Technical Support
Staff member
There's no obvious reason why "CCCC" is not appearing after "AAAA". In the macro expanded code it should be two SERTXD, one after the other, so if "AAAA" comes out so too should "CCCC". You could try temporarily try this -

Code:
#macro Talk_HC12(msg)
        sertxd ("CCCC",cr,lf)
#endm

#macro Init_HC12
       low HC12_set
       Pause FortymS
       sertxd ("AAAA",cr,lf)
       Talk_HC12("AT")
       sertxd ("BBBB",cr,lf)  
#endm
The only thing I can think is that there is something causing the PICAXE to reset but not at all sure why that would be after the "AAAA" but before the "CCCC".

What exactly are the hex codes sent after the "AAAA" ?
 

friis

Senior Member
Hi hippy,
I am sorry - I had an extra sertxd (cr,lf,"AAAA") in there, that made things confusing. But you can see below that the formal problem has been solved.

Hi I and P,
Getting the frequencies in order solved the problem. But now I am getting the response:

R:[00][00][00][00][00][00][00][00]

for all the AT commands. I shuld get "OK", etc. - right?

I think the text below answers your qustions:

#picaxe 14M2

;Assumes 32MHz operation, for 9600baud comms...

#terminal 38400

;
; HC-12 "458MHz ;-)" FSK RF module connections...
;
Symbol HC12_SET = C.1 ;"SET" pin (marked Set on hc-12)
Symbol TX_pin = C.2 ;output to HC-12 (marked TXD on hc-12)
Symbol RX_pin = C.3 ;input from HC-12 (marked RXD on hc-12)

Symbol HC12BaudRate = T9600_32 ;HC-12 Baud rate
.
.
.

**********************************************************************************
;
; Start Program
;

Setfreq M32 ;Assuming you're using the default 9600 baud, I assume you
;crank up the clock freq too.

Init_HC12 ;send some initial parameters. (Success or failure is not checked)
.
.
.
*************************************************************************************

This is my first attempt at using hc-12 so the code is "borrowed" - from I and/or P?
torben
 

hippy

Technical Support
Staff member
But now I am getting the response:

R:[00][00][00][00][00][00][00][00]

for all the AT commands. I shuld get "OK", etc. - right?
If it's in command mode one would expect an OK response to an AT command but there's no sign of any command terminator being sent in your code.

The [00] suggests the variables have not been set at all. Perhaps the receive code is wrong, or timing out.

You would need to post the full response receiving code to assess that.
 

hippy

Technical Support
Staff member
Symbol TX_pin = C.2 ;output to HC-12 (marked TXD on hc-12)
Symbol RX_pin = C.3 ;input from HC-12 (marked RXD on hc-12)
The HC-12 datasheet I looked at shows the HC-12 TXD is the output from the HC-12, the HC-12 RXD pin is the input to the HC-12.

You are using SEROUT on TX_pin so are sending to an output pin on the HC-12, any SERIN on RX_pin will be reading from the HC-12 input pin.

Your wiring or SYMBOL assignments need changing. Outputting to an output pin may damage the PICAXE and/or the HC-12, may have damaged it already if you have not fitted current limiting resistors between the PICAXE and HC-12.
 

friis

Senior Member
Hi hippy,
You were right - I changed the wiring and now I get the right answers.
I should have read the comments in the pgm carefully!!!
Now I can go on exploring the hc-12. Thankfully, I hav'nt destroyed anything.
Thank you.
torben
 

hippy

Technical Support
Staff member
Thankfully, I hav'nt destroyed anything.
Further reading of the particular HC-12 datasheet I have suggest there is in-line current limiting within the HC-12 module to mitigate against that mistake.

It will often be a guess whether RXD and TXD is with respect to the module, or what it connects to, without consulting a datasheet, and both standards do get used.

Anyway; glad to see things are on the right path now.
 

friis

Senior Member
Hi P,
It works now - I have changed the wires. But:

I have set up a sending and receiving pgm. Once the AT-commands have been issued, is'nt the hc-12 not open simply as a communication channel?
I have sending:

serout TXpin,HC12BaudRate,(PreambleByte,PreambleByte,PreambleByte,PreambleByte,PreambleByte,SomeByte,"A","B",EOMbyte,Postamblebyte,Postamblebyte,Postamblebyte,Postamblebyte)

which seems to work, and receiving:

serin RXpin,HC12BaudRate,(PreambleByte,SomeByte),Data1,Data2,EOMbyteRec,PostambleByteRec,PostambleByteRec,PostambleByteRec,PostambleByteRec

which does not work. The pgm stops at the serin.
Can anyone see what is wrong?
best regards
torben
 

hippy

Technical Support
Staff member
How do you know sending is working ?

And is that from the same HC12 you are then trying to receive with or another HC12 on a different PICAXE ?
 

friis

Senior Member
Hi hippy,
I have sertxd statement before and after the serout and they both show up in the Serial Terminal screen so at least the serout is issued.
I have the sending pgm on one breadboard and the receiving pgm on another.
But it is correct, that the two hc-12s should act as a communication channel with serout and serin?
I have used serout/serin a lot with simple 433 MHz modules.
torben
 

inglewoodpete

Senior Member
I suggest you do some debugging with the PICAXE's Tx output connected to the HC12's Rx pin. (And the HC12's Set and 0v pins connected appropriately too.) Then connect the HC12's Tx and 0v to back to the programming lead's input to the computer with the PE's terminal program running. That way, you can watch the responses (rather that relaying them from the PICAXE) from the HC12 and confirm the baud rate too. Regularly send "AT" commands into to HC-12 every two seconds and watch the response.

I have not had anything like the problems you are reporting.
 

friis

Senior Member
Hi I ,

Just to make sure:
1. connect C.2 to RXD of the hc-12
2. connect the Set pin of hc-12 to GND
3. connect the GND of the hc-12 to GND of the breadboard adaptor
4. connect the TXD pin of the hc-12 to the 2. pin of the breadboard adaptor

I am using Picaxe 14M2, but the pins C.1, C.2 and C.3 appear to be OK.

I have your pgm sending "AT" commands and watch the Serial Terminal screen. When I do that a hex. code appears every now and then - that's all.

Is my set-up OK?
torben
 

hippy

Technical Support
Staff member
Just to make sure:
2. connect the Set pin of hc-12 to GND
From the earlier code it would seem that the Set pin of the HC-12 should be connected to C.1.

And given "Symbol HC12_SET = C.1 ;"SET" pin, when low, places module into command mode", that if you have connected it to GND the HC-12 will permananetly be in AT command mode.
 

friis

Senior Member
Hi hippy,
Yes, that is right. But now have only one hc-12 connected to picaxe 14M2 which is sending "AT" every second - and hc-12 should send something to the breadboard adaptor.
Right?
torben
 

inglewoodpete

Senior Member
If you try different baud rates while you are trying to log the HC-12 responses, do you get anything intelligible? Since the default data rate for the HC-12 is 9600 baud, I would expect the PE terminal would need to be set to that speed.
 

friis

Senior Member
H I,
Below 38400 (what the pgm is set to) I get nothing. At 38400 I get a mixture of {FF] and {7F] and above 38400 I get only {FF].
torben
 

hippy

Technical Support
Staff member
Hi hippy,
Yes, that is right. But now have only one hc-12 connected to picaxe 14M2 which is sending "AT" every second - and hc-12 should send something to the breadboard adaptor.
Right?
I'm really not sure. I don't see how sending "AT" every second would send anything through the air if that's a command to the HC-12, not something to transmit.

I'm not sure what this "breadboard adpater" is, what it connects to or how it's being used, what you are actually looking at with your terminal or where that comes from.

I think you may have to post a circuit digram of how you have your transmitter and receiver are wired, and to what, and the program code used.
 

inglewoodpete

Senior Member
I'm really not sure. I don't see how sending "AT" every second would send anything through the air if that's a command to the HC-12, not something to transmit.

I'm not sure what this "breadboard adpater" is, what it connects to or how it's being used, what you are actually looking at with your terminal or where that comes from.

I think you may have to post a circuit digram of how you have your transmitter and receiver are wired, and to what, and the program code used.
As a step in debugging the problem, in post #14 I suggested having the PICAXE send an (any) AT command regularly. Then, rather than have the PICAXE report what it receives, redirect the 9600baud response from the HC-12 to the PE Terminal via the breadboard adaptor (to USB/Serial lead) to see what the HC-12 is actually echoing.

Torben reports that the PE terminal is receiving FFs and 7Fs, which suggests either a response in the opposite polarity to what is expected, or the actual baud rate from the HC-12 is significantly lower than what the PE Terminal is set to. It would be better to look at the serial response from the HC-12 on an oscilloscope to determine the actual baud rate.
 

friis

Senior Member
Hi I,
How can I get the frequency with an oscilloscope? I only have Picaxe's DPScopeSE.

When I take a reading between TXD and GND i get an almost regular curve, but it is a jagged line with pointed tops and bottoms and some lower tops in between (that is the only way I can describe it). It is not at all the curve I normally see. I have attached a screen shot.

I also get a series of FFs and FEs if I chose 110 as frequency - I did'nt check that before because I though it was ridiculously low.
 

Attachments

AllyCat

Senior Member
Hi,

That's a horrible waveform and something is obviously wrong (probably a missing/bad earth connection).

The spikes are 4 divisions apart at 5 ms/div, so the period is 20 ms. Invert that (divide into unity) to get the frequency which is 50 Hz, so it's almost certainly just "mains hum".

Measuring frequency with the DPScope is easy: Enable the Cursors and move the vertical lines to two adjacent spikes (or whatever period you want to measure). At the bottom of the screen it should say something close to "dt: 20.00 ms 1/dt: 50.00 Hz" ("dt" is the time difference and "1/dt" the frequency).

Take a look at the photo at the foot of post #1 here for an example of what "RS232" data typically may look like.

Cheers, Alan.
 
Last edited:

inglewoodpete

Senior Member
I concur with Alan, after my first thought (bad ground connection), I saw the 20mS repeating waveform. We have a 50Hz mains frequency in Australia and anything with a 20mS period suggests mains hum.

I popped the top off the master-end of my HC-12 link. This is for a wireless link to our car, to monitor its door, doorlock and ignition states.

The 3 images are
  1. the HC-12 module mounted on the Veroboard/stripboard
  2. a capture of one of the AT commands from PICAXE and HC-12's response during the unit's startup procedure
  3. a magnification of the response waveform from the HC-12.
These waveforms are captured on an 8-bit resolution oscilloscope with 75MHz bandwidth but your setup should give reasonably square data waveforms.

Your HC-12 may not be working at all or it may not be working properly. Check all of the connections and the voltages on the HC-12. (The Tx pin should have a little less than the supply voltage on it when idle Ie "idle high".) Check the waveform being output from the PICAXE on your oscilloscope. Finally, if the PICAXE is outputting clean data, try swapping the HC-12 module with your other one.

LinkMaster.jpgHC12-SetupAndResponse.PNGHC12-ResponseWaveform.PNG
 

hippy

Technical Support
Staff member
@ friis : Thanks for the circuit. I think I am understanding what you are doing; sending from the PICAXE to HC-12 and looking to see what comes back from the HC-12 on a terminal.

As noted that scope trace looks horrendous so something is wrong there.

With respect to the circuit; I am guessing that's an AXE029 Breadboard Adapter being used to connect an AXE027 download cable to the HC-12.

If that's so then the polarity of the HC-12 output will be inverted (T) with respect to what the AXE027 expects to see (N). This would explain the 'random hex values' at all baud rates rather than what would be expected to be seen.

You need to invert the signal for it to be understood correctly by an AXE027 or other RS232 cable, or will need to use a USB to UART adapter which expects the polarity the HC-12 uses.
 

friis

Senior Member
Hi
@Inglewood: Running your(?) pgm without changes it looks as if it is diving straight into the first macro (Talk_HC12(msg)) when it starts. I have entered:

;
; Start program
;
sertxd ("AAAA",cr,lf) 'I ENTERED THAT
.
.
.

but AAAA does not appear. Instead I get a series of R:....... (Presumably from Talk_HC12(msg))

@AllyCat: It appears that it was a bad GND connection - a faulty breadboard.

@hippy: I checked the waveform/freq. as suggested by AllyCat and got 300 (far from 9600) which turns out to produce a series of 00s in the Serial Terminal. The pgm contains the statement:

Symbol HC12BaudRate = T9600 _32

I changed it to:

Symbol HC12BaudRate = N9600 _32

but that did'nt make much difference.
torben
 

inglewoodpete

Senior Member
@Torben - You will not be able to log SerTxds from the PICAXE and data output from the HC-12 with only one cable.

I see that your oscilloscope has two channels. Can you log both the HC-12's Rx pin (data from the PICAXE) and the HC-12's Tx pin on the oscilloscope. You should get two traces like the 2nd image that I posted, with the HC-12 responding about 18mS after receiving the complete command from the PICAXE.

Also, in your post #26 to hippy, you say "Symbol HC12BaudRate = T9600 _32".
This should be "Symbol HC12BaudRate = T9600_32", with no space character after 9600.

Do not use N9600_32.
 

friis

Senior Member
Hi
@inglewoodpete: I am sending attached the two-channel screen dump. The 18 ms seems to be right. You can see on the screen dump that I am sending AT-commands and I suppose that the red curve represents AT and the blue one represents OK.

You cannot see that I have tried to change the pgm:

;
; Start program
;
sertxd ("AAAA",cr,lf) 'I ENTERED THAT
.
.
.

but AAAA does not appear. Instead I get a series of R:[00]....... (Presumably from Talk_HC12(msg)). Why dont I get AAAA?

I assume that I am sending AT-commands from TX-pin to the hc-12's RXD and OK from the HC-12's TXD to the RX-pin (abour 18 ms later). I assume that when transmitting and receiving data the only difference is that HC-12 is enabled?

@hippy: HC12BaudRate = T9600 _32 did not contain a space in the pgm and I did use the "T".
torben
 

Attachments

inglewoodpete

Senior Member
Hi
@inglewoodpete: I am sending attached the two-channel screen dump. The 18 ms seems to be right. You can see on the screen dump that I am sending AT-commands and I suppose that the red curve represents AT and the blue one represents OK.
The oscilloscope trace looks good. The oscilloscope's sample rate is too low for us to be able to decode the serial data but we can see that data is being sent and the HC-12 is responding in the expected time frame.

You cannot see that I have tried to change the pgm:

Code:
;
;     Start program
;
sertxd ("AAAA",cr,lf)   'I ENTERED THAT
.
.
but AAAA does not appear. Instead I get a series of R:[00]....... (Presumably from Talk_HC12(msg)). Why dont I get AAAA?
As I have said before, for this exercise you have disconnected the PICAXE's logging output pin (for SerTxd) and connected the HC-12's Tx pin. So the "AAAA" string will be sent by the PICAXE but then lost.

I assume that I am sending AT-commands from TX-pin to the hc-12's RXD and OK from the HC-12's TXD to the RX-pin (abour 18 ms later). I assume that when transmitting and receiving data the only difference is that HC-12 is enabled?
This looks good. The PICAXE is sending commands to the HC-12 and the HC-12 is responding as expected.

You should now be able to connect all of the wires between the PICAXE and the HC-12 {0v--0v, C.2(Tx)-->Rx, C.3(Rx)<--Tx, and C.1(Set)-->(Set)} and return your code the PhilHornby's original.

You can still use your oscilloscope to monitor the data to and from the HC-12.
 

hippy

Technical Support
Staff member
The oscilloscope trace looks good.
I am not sure that it is. Looking at the red trace, sending from the PICAXE; that should be showing "AT" being sent.

"A" is $41 or %01000001
"T" is $54 or %01010100

Serial is sent lsb first so on a scope those should appear as -

10000010 00101010

The signal polarity is "T", idle high, so each will be preceded by a 0 start bit and followed by a 1 stop bit giving -

0100000101 0001010101

Which looked at on a scope should appear as -

Code:
_ _ _   _           _   _ _ _       _   _   _   _ _ _
     |_| |_________| |_|     |_____| |_| |_| |_| 
      0 1 0 0 0 0 0 1 0 1     0 0 0 1 0 1 0 1 0 1
At 9600 baud, each bit is about 104us. There are 10 bits per byte sent so the complete transmission time of one byte should be about 1ms, some 2ms for sending both bytes, though there will be a gap between each byte.

Though it is not easy to see exactly what is happening or its timing with a timebase of 10ms/div the scope trace doesn't look much like I would expect it to be.

Even though the PICAXE does not send bytes back-to-back with SEROUT the inter-byte gap period should be fairly short. I would expect the length of the transmission to be more 2ms than 10ms. If two bytes did fill a 10ms period I would expect an 8ms high period between the two bytes and that doesn't appear to be there.
 

hippy

Technical Support
Staff member
Looking at the scope trace, the baud rate might be wrong and I'm not certain but it may be we are seeing a single "A" sent.

As said before; please post your complete code.
 

friis

Senior Member
Hi,
@hippy: I enclose a screen dump with more detail. It does not show a complete transaction though. Does it help?
I also enclose a print of "my" pgm.

@Ingelwoodpete: Now when I run your pgm the transmissions are shown on the PBScopeES screen, but in the Serial Terminal window I get a never ending series of hex. codes. I have ordered new HC-12s - I think the ones I have may be destroyed. At an earlier stage I saw all the sertxds - incl. AT-commands.
torben
 

Attachments

hippy

Technical Support
Staff member
in the Serial Terminal window I get a never ending series of hex. codes.
And what are these code values ?

There are a number of possibilities -

1) You have configured the serial terminal to display hex codes rather than ASCII characters.

2) You have the wrong baud rate selected and the terminal doesn't see what is received as ASCII characters so is displaying them as hex codes.

3) The data being sent from your program is exactly as is being shown.

Let's rule the first two out ...

Code:
#Picaxe 14M2
#Terminal 38400
SetFreq M32
Do
  Pause 8000
  SerTxd( "ABCDEFGHIJKLMNOPQRSTUVWXYZ", CR, LF )
Loop
 

hippy

Technical Support
Staff member
I would also change your -

Code:
Clear_Response_Buffer:
	bptr = ByteArray					;address of our storage
	for b0 = 0 to 7
		@bptrinc = 0				;clear 8 bytes
	next b0
	return
Code:
Clear_Response_Buffer:
	bptr = ByteArray					;address of our storage
	for b0 = 0 to 7
		@bptrinc = 0				;clear 8 bytes
	next b0
	bptr = ByteArray					;address of our storage
	return
And -
Code:
Get_Response:
	bptr = ByteArray					;address of our storage
	serin [TwoFiftymS,noAnswer],RX_Pin,HC12Baudrate,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc ; 8 bytes.
noAnswer:
	;
	;DEBUG: Print the 1st 8 bytes of the response 
	;
	bptr = ByteArray
	sertxd(cr,lf,"R:",@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc)
	return
Code:
Get_Response:
	serin [TwoFiftymS,noAnswer],RX_Pin,HC12Baudrate,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc ; 8 bytes.
	;
	;DEBUG: Print the 1st 8 bytes of the response 
	;
	bptr = ByteArray
	sertxd(cr,lf,"R:",@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc)
	return	
noAnswer:
	sertxd(cr,lf,"R: <No response>")
	return
 

inglewoodpete

Senior Member
The screen dump looks valid. It is "AT+SL".... which would be the "AT+SLEEP" command being sent in line 116 of your code. It would be good if you can capture and post the HC-12's response to one of the AT commands.

I think the HC-12 is working correctly. You just have some debugging problems where the data being returned in not being interpreted correctly. Stay with it!! I think we can get the program working correctly.
 

friis

Senior Member
Hi hippy,
Here are the results:

Test1:
#Picaxe 14M2
#Terminal 38400
setfreq M32

do
pause 8000
sertxd ("ABCDEFGHIJKLMNOPQRSTUVXYZ",cr,lf)
loop

ABCDEFGHIJKLMNOPQRSTUVXYZ
ABCDEFGHIJKLMNOPQRSTUVXYZ
ABCDEFGHIJKLMNOPQRSTUVXYZ
ABCDEFGHIJKLMNOPQRSTUVXYZ
ABCDEFGHIJKLMNOPQRSTUVXYZ
ABCDEFGHIJKLMNOPQRSTUVXYZ
ABCDEFGHIJKLMNOPQRSTUVXYZ
ABCDEFGHIJKLMNOPQRSTUVXYZ

Test 2:
After your changes I get:

R: <No answer>
R: <No answer>
R: <No answer>
R: <No answer>
R: <No answer>
R: <No answer>
R: <No answer>
R: <No answer>

In both cases it makes no difference wether I chose ASCII or raw in the ST.
torben
 

hippy

Technical Support
Staff member
It seems then that whatever the HC-12 is putting out it isn't being received by the PICAXE.

The continuous hex codes you were seeing were most likely the cleared buffer which was being shown even when the PICAXE did not see a reply.
 

friis

Senior Member
The screen dump looks valid. It is "AT+SL".... which would be the "AT+SLEEP" command being sent in line 116 of your code. It would be good if you can capture and post the HC-12's response to one of the AT commands.

I think the HC-12 is working correctly. You just have some debugging problems where the data being returned in not being interpreted correctly. Stay with it!! I think we can get the program working correctly.
Hi Inglewoodpete:
Here is what I get in the ST screen when I run your pgm:

blanc
R:[00][00][00][00][00][00][00][00]
R:[00][00][00][00][00][00][00][00]
R:[00][00][00][00][00][00][00][00]
R:[00][00][00][00][00][00][00][00]
R:[00][00][00][00][00][00][00][00]
R:[00][00][00][00][00][00][00][00]
R:[00][00][00][00][00][00][00][00]
R:[00][00][00][00][00][00][00][00]
R:[00][00][00][00][00][00][00][00]
R:[00][00][00][00][00][00][00][00]
R:[00][00][00][00][00][00][00][00]
.
.
.

Is that what youu wanted? I used to get all the AT-commands.

The DPScopeSE screen looks normal.
torben
 

hippy

Technical Support
Staff member
Here is what I get in the ST screen when I run your pgm:
R:[00][00][00][00][00][00][00][00]
As per post #38 which may have got missed in cross-posting ....
It seems then that whatever the HC-12 is putting out it isn't being received by the PICAXE.

The continuous hex codes you were seeing were most likely the cleared buffer which was being shown even when the PICAXE did not see a reply.
Alter the program you have to produce a "<No Response>" as per the earlier code and you should see they aren't [00]...[00] responses, but non-responses.
 
Top