hc-12

friis

Senior Member
Hi hippy,
But I cant see why it gets no answer. It is as if the hc-12 does not function correctly. In the past I saw lists of all the AT-commands, but for the last couple of days I have'nt seen them. I suppose that the response I get in the DPScopeSE screen is the sending of an AT-command and the return "No answer".
torben
 

friis

Senior Member
Hi hippy,
But I can't see from the pgm why there is no answer.And I used to see all the AT-commands when I was running the pgm, but for a few days I hav'nt seen them. That is why I suspect that there is something wrong with the hc-12s and I have ordered new ones. Could what I see in the DPScopeSE screen be the AT-commands and the "No answer" answer?
torben
 

lbenson

Senior Member
If you hook up your loopback PC serial lines (TX to RX), attach the scope to the loop back + ground, start the terminal choosing the appropriate baud rate, and paste into the terminal "ATOK" (don't type it--there will be too much space between the letters), you should see what the signal is supposed to look like. Try to tweak it until it approximates what hippy has drawn out in ascii text. If that looks right, then try it again with the HC-12 attached. If it doesn't look the same, why not?
 

inglewoodpete

Senior Member
Your screenshot of the response in post #29 indicates that the HC-12 is responding with something. I was suggesting you could log the response data waveforms on your oscilloscope so the response message could be decoded. I would like to see what the HC-12's response to the AT+ commands actually is.

That way we can tell if the HC-12 is working properly at the correct baud rate.

Also, if you can get your oscilloscope to trigger further to the left, you will be able to log more of the response waveform on the screen. (Refer to image of my oscilloscope)
 

Attachments

Last edited:

hippy

Technical Support
Staff member
I used to see all the AT-commands when I was running the pgm, but for a few days I hav'nt seen them. That is why I suspect that there is something wrong with the hc-12s
If the scope is showing something coming back from the HC-12 as it appeared to be doing, and that is meaningful data as inglewoodpete says it looks to be, I would suggest the HC-12 are working as expected.

The problem seems to be in the connection of HC-12 TXD to the PICAXE C.3 RX_pin which reads what is sent back.

I have spotted a potential problem in the way no responses are handled when less than 8 bytes are returned. My modified code will report "No Response" even if there was. I will post a solution for that.
 

hippy

Technical Support
Staff member
This should get rid of hex code confusion and make whether you have received anything easier to determine -

Code:
Clear_Response_Buffer:
	bptr = ByteArray					;address of our storage
	for b0 = 0 to 7
		@bptrinc = "?"				;clear 8 bytes
	next b0
	bptr = ByteArray					;address of our storage
	return

Get_Response:
	serin [TwoFiftymS,noAnswer],RX_Pin,HC12Baudrate,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc ; 8 bytes.
noAnswer:
	bptr = ByteArray
	if @bptr = "?" then
	  sertxd(cr,lf,"R:<No response>")
	else
	  sertxd(cr,lf,"R:",@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc)
	end if
	return
 

techElder

Well-known member
serin [TwoFiftymS,noAnswer],RX_Pin,HC12Baudrate,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc ; 8 bytes.
I've been trying to stay out of this, because I can't spend the time necessary, but let me say this without supporting it.

The problem that I found with this type of serin statement is that the HC12 returns variable length responses depending on what was sent. If this serin statement doesn't receive 8 bytes it will always timeout.
 

hippy

Technical Support
Staff member
If this serin statement doesn't receive 8 bytes it will always timeout.
Correct; that's the problem I belatedly identified and have sought to resolve in post #46, with better discrimination between nothing received and something received.

I would personally step back from what programs have already been used, go right back to first principles with much simpler and easier to comprehend code, and then develop that towards what is required -

Code:
#Picaxe 14M2
#Terminal 38400
#No_Data

Symbol HC12_SET     = C.1
Symbol TX_pin       = C.2
Symbol RX_pin       = C.3

Symbol HC12BaudRate = T9600_32

PowerOnReset:
  High TX_pin
  Low HC12_SET
  SetFreq M32
  Pause 16000
  SerTxd( Cr, LF, "Started", CR, LF )

MainLoop:
  Do
    b1 ="?" : b2 = "?" : b3 = "?" : b4 = "?"
    b5 ="?" : b6 = "?" : b7 = "?" : b8 = "?"
    SerOut TX_Pin, HC12BaudRate, ( "AT" )
    SerIn [8000], RX_Pin, HC12Baudrate, b1,b2,b3,b4,b5,b6,b7,b8
    If b1 = "?" Then
      SerTxd( "No response", CR, LF )
    Else
      SerTxd( "R:", b1,b2,b3,b4,b5,b6,b7,b8, CR, LF )
    End If
    Pause 8000
  Loop
 
Last edited:

friis

Senior Member
Hi @
I understand your set-up as follows:

1. connect the breadboard adaptor as if I would load the pgm
2. conect the BPScopeSE with 0 to 0 and the + wire of the BPScopeSE to pin 2 of the breadboard adaptor
3. paste ATOK into the transmit buffer of the Serial Terminal screen and send it

I that correct? That is what I did and I watched the output on the scope. I got a squarely shaped curve with each 1 and 0 about 2 divisions wide. I could not take single shots, so it was a bit difficult. As far as I could see the curve looked the same wether the hc-12 was mounted or not

*****************
I enclose a screen shot with quite a bit of output. As far I could see, using hippy's post, this output starts with AT+. If that is correct, the pgm is acting correctly in reporting that there was no answer - i.e the hc-12 is faulty. I should find out when my new hc-12s arrive.

I used hippy's simpler pgm and got the msg "No response". I think this confirms that the hc-12s are faulty.
torben
 

hippy

Technical Support
Staff member
I used hippy's simpler pgm and got the msg "No response". I think this confirms that the hc-12s are faulty.
No, it really doesn't. Your HC12's might be faulty but that doesn't prove it; there could be some other issue or issues.

Everything else seems to point to the HC-12's working but you cannot use an AXE027 or RS232 cable via a breadboard adapter direct to the HC12's because the signal polarities of the AXE027 and HC12 are the inverse of each other. That won't work.

This is how you should have things wired for testing -

Code:
   AXE027        PICAXE-14M2                HC12
    ____        .-----------.            .--------.
   |    |------>| C.5   C.3 |<---.-------| TXD    |  \|/
===|    |<------| B.0   C.2 |----|--.--->| RXD    |   |
   |____|---.   |       C.1 |----|--|--->| SET    |---'
            |   `-----------'    |  |    `--------'
            |                    |  |
            |                    |  `---> Scope : Send To HC12   
            |                    `------> Scope : Response from HC12
            |                    .------> Scope : 0V
           _|_ 0V            0V _|_
What does the scope show when running my simpler test program, even though it may be reporting "No response" ?

But it might be better to wait for receipt of further HC12's to see how they perform and start afresh.
 

inglewoodpete

Senior Member
@Torben, This image that you posted in #29 tells me that the HC-12 is operational - The PICAXE sends some data and the HC-12 responds. The oscilloscope's sampling rate is too slow to actually show what is being sent and received.
Send+Response.JPG
This image (which you posted and I have modified) shows that your PICAXE is sending the correct command "AT+SL"(EEP).
TorbensHC12Screendump2.png
It would be great if you could capture the response from the HC-12 (at 0.5mS/div), so that I can decode what the response actually is. Then we will have a better idea where the problem is.
 

friis

Senior Member
Hi hippy and Inglewoodpete,
Now neither of the hc-12s answer! I used to have something on both channels while I still got "No response" - I think. I am a little confused now.
I will enjoy having learned a lot while waiting for the new hc-12s.
torben
 

friis

Senior Member
Hi everybody,
I can't quite see why the output from hippy's pgm looks the way it does.
I am still waiting to get new hc-12s
Thank you very much for sticking with me
torben
 

hippy

Technical Support
Staff member
Seems the HC12's are working. The output looks as I would expect it to other than the couple of <No Responses> which perhaps should be responses.

I would suggest changing the 8000 in ...

SerIn [8000], RX_Pin, HC12Baudrate, b1,b2,b3,b4,b5,b6,b7,b8

To 64000, eg ...

SerIn [64000], RX_Pin, HC12Baudrate, b1,b2,b3,b4,b5,b6,b7,b8

That will give the HC12 longer to respond and it may fill in the <No responses> with actual replies.

Of course, it could be that the module just isn't responding for some reason. What are you actually sending, your full code ?

There's only so much second-guessing anyone can do.
 

friis

Senior Member
Hi hippy,
The file I sent with post 54 was wrong - it should have had the following content:

Started
R:OK
????
R:OK
????
R:OK
????


What surprised me was that you only showed OK???? (and not 8 ch.) and that it was split on two lines.
So everything was OK.
torben
 

hippy

Technical Support
Staff member
The file I sent with post 54 was wrong - it should have had the following content:

Started
R:OK
????

What surprised me was that you only showed OK???? (and not 8 ch.) and that it was split on two lines.
The reply was probably "O" "K" "<CR>" "<LF>" and then nothing more so the Terminal prints that, "OK", then the <CR><LF> moves to the start of the next line, and finally prints the four question marks which the receive buffer is filled with.
 

inglewoodpete

Senior Member
It is very reassuring that we are or the correct path and that communication between the 14M2 and HC-12 CAN work. It is disappointing that there have been so many problems, especially for someone just beginning with wireless communication.

From my experience, the HC-12 is very reliable and consistent, particularly during configuration dialogues. Torben says the 64000 timeout made no difference (that's 8 seconds). The 18mS response time to the beginning of the response packet was pretty consistent for me. I'd expect that a SerIn timeout period of 200 (25mS) would give the response reception reliability.

My suspicions are that the 9600 baud clocks in the PICAXE and HC-12 are not the same (Ie bordering on the limits), making communication unreliable. The only way to determine this would be to log just a few bits* of each serial transmission (PICAXE and HC-12) and comparing them. * Ie with the fastest practical oscilloscope sampling rate,
 

kranenborg

Senior Member
The only way to determine this would be to log just a few bits* of each serial transmission (PICAXE and HC-12) and comparing them. * Ie with the fastest practical oscilloscope sampling rate,
In case you do not have an accurate oscilloscope available then maybe the following simple frequency calibration circuit (using only two picaxes): http://www.picaxeforum.co.uk/showthread.php?19603 may be of help to fine-tune your picaxe's internal oscillator. The slave picaxe's frequency calibration constant (through the CALIBFREQ parameter) is estimated in this way. If the master picaxe that you use in this calibration circuit has a resonator or crystal, then the slave picaxe's internal oscillator can be calibrated to absolute measure very accurately. Maybe this helps to rule out serial timing issues in your problem quickly (but it still presumes the HC-12 and the picaxe use the same serial protocol, and for that analysis a (simple) oscilloscope is needed)

/Jurjen
http://www.kranenborg.org/electronics
 

hippy

Technical Support
Staff member
My suspicions are that the 9600 baud clocks in the PICAXE and HC-12 are not the same (Ie bordering on the limits), making communication unreliable.
We don't believe it is so and it doesn't seem that baud rate has been a problem here.

If the problem had been baud rate related we would have seen corrupt data being received rather than there being 'no response' or packets which just contained [00] bytes which we believe would have been the continuous hex codes reported earlier.

It seems to me that the issues here have been wiring errors, flaky breadboard, unreliable connections, a code base which was overly complicated to start from, a mistaken belief that the HC12 were faulty, a sometimes erroneous approach to analysing the issues, some human communication issues, coupled with inexperience in what was being done and seen, meant it was not always clear what the actual issue was and diagnosis was not always as rigorously structured as it could have been.

With reliable hardware, correct wiring and appropriate code; everything has 'just worked' as was to be expected.
 
Top