Strange HC-12 configuration

[friis]

Hi,
I am having a strage experience with HC-12 configuration. If I set the configuration normally I get:

Started PowerOnReset
R:f[86][98][86][98][E6][98][18] (AT)
R:f[86][98][86][98][E6][98][18] (AT+B4800)
R:f[86][98][86][98][E6][98][18] (AT+V090)
R:f[86][98][86][98][E6][98][18] (AT+F03)
R:f[86][98][86][98][E6][98][18] (AT+P4)
Slut

If I set it up in a loop with a pause 4000 after each set up I get the same result.

If I set it up in a loop with no pause after each set up I get:

Started PowerOnReset
R:f[86][98][86][98][E6][98][18] (AT)
R:f[86][98][86][98][E6][98][18] (AT+B4800)
R:f[86][98][86][98][E6][98][18] (AT+V090)
R:f[86][98][86][98][E6][98][18] (AT+F03)
R:f[86][98][86][98][E6][98][18] (AT+P4)
Slut

in first run and the result I would expect in the subsequent runs:

Started PowerOnReset
R:OK
R:OK+B4800
R:OK+C090

R:OK+FU3

R:OK+P4
?
Slut

Can anyone explain?
torben

 

[hippy]

I would guess whatever is reading serial in gets out of sync early on but there's a gap before the "(AT...)" which allows things to fall back in sync.

I cannot see any different in the first and second output you posted. So is it the same in all cases, or have I gone 'word blind' ?

What are you using to read the serial, and how are you doing that ?

As to why things go out of synch, it's usually lack of inter-byte gap, the receiver not being ready for when the next character has been sent. It can however be a result of incorrect wiring or other weird things, allowing something to float and shift as consecutive bits are transmitted.

Of course the first thing to do is determine if it is a receive or transmission error.

 

[PhilHornby]

R:f[86][98][86][98][E6][98][18] (AT)
R:f[86][98][86][98][E6][98][18] (AT+B4800)
R:f[86][98][86][98][E6][98][18] (AT+V090)
R:f[86][98][86][98][E6][98][18] (AT+F03)
R:f[86][98][86][98][E6][98][18] (AT+P4)

I've certainly seen the "f" response - I mentioned it here: HC-11 and HC-12 transceiver modules | Page 4 | PICAXE Forum

Previously, a test module had got into a state where it responded with "f", instead of "OK+SLEEP"

I never got to the bottom of it - but I don't think there is a "fix" ... other than throwing that HC-12 away!

 

[friis]

Hi Hippy and PhilHornby,
You (Hippy) know the pgm (it is yours and it has served me very well until now):

PowerOnReset:
    SetFreq M16
    High TXpin
    low HC12_SET
    pause 12000                                                                            *****
    Countt = 1
    SerTxd( Cr, LF, "Started PowerOnReset", CR, LF )

Main:
      high FlashPin
    pause 30000                                                                            *****                                                              
    low FlashPin

Do until Countt = 6
    b1 ="?" : b2 = "?" : b3 = "?" : b4 = "?"
    b5 ="?" : b6 = "?" : b7 = "?" : b8 = "?"


    if Countt = 1 then
            SerOut TXpin, HC12BaudRate, ( "AT" )
        Countt = Countt + 1
    elseif Countt = 2 then
        SerOut TXpin, HC12BaudRate, ( "AT+B4800" )
        Countt = Countt + 1
    .
    .
    .
    Serin [10000], RXpin, HC12Baudrate, b1,b2,b3,b4,b5,b6,b7,b8

    if b1 = "?" OR b1 = "E" Then
        SerTxd( "No response", CR, LF )
    Else
         SerTxd( "R:", b1,b2,b3,b4,b5,b6,b7,b8, CR, LF )
    End if
loop

I have increased the pauses to 10000 and 30000 (*****) and at least the nonsense output comes very rarely. I could live with that (the pgm is used rarely), but there must be a sure-fire solution. I just cant put my finger on it. But it has something to do with "reading serial in gets out of sync early on".

I would hate to throw the HC-12 out - it would need a lot of soldering.
torben

 

[Goeytex]

If you have a scope or a logic analyzer you can verify that the HC-12 is sending data at the correct bit rate by measuring the bit width. It should be very close to 208 us. I am guessing that it will be OK, but verification is good. The logic analyzer serial decoder will show the actual data sent by the HC-12. If it's correct then the issue lies elsewhere.

I am also guessing that the HC-12 defaults to 1 stop bit, while Picaxe serial usually uses 2 stop bits ( or more) to allow serin more time to process data when multiple bytes are received back to back.

I suggest configuring the HC-12 for 2 stop bits to give the Picaxe adequate time to process each received data byte. There should be an AT command for that. I think it is "AT+U8N2" .

The HC12 module operates from 3.3 to 6V, 3.2V -5.5V, however the manual recommends no more than 4.5V to eliminate overheating of the built in LDO. The I/0 level is 3.3V.

Some HC-12 modules have on board 1K resistors in series with TX and RX. These have been known to cause serial issues in some cases. So if you have a scope check the HC-12 TX level. It should be somewhere around 3.0V. This "should" be ok with the Picaxe operating at 4.5V. If the level is less than about 2.7 volts there could be issues if the Picaxe is operating at 5V. Ideally the Picaxe and HC-12 will both be operating at 3.3V.


Many HC-12 modules are fakes/counterfeits that may not meet specifications. You can search the Internet for "fake HC-12" to get more information on that and how to identify if you have a fake or genuine. (If from *bay or *li *press then quite likely a fake.

 

[PhilHornby]

@friis
So you're saying that it sometimes responds with nonsense and sometimes works

One thing that looks 'suspect', is the command to change the Baud rate (because mismatched baud rates results in gibberish). If you want to run the HC-12 at something other than its default 9600 (I never have), then I think you should do it once - as a separate exercise. (Otherwise your program presumably has to switch baud rate at some point....)

(Just clashed with Goeytex's message)

 

[hippy]

I've certainly seen the "f" response

That would fit with what's going on here and potentially a baud rate issue as suggested. I would simply not send any baud rate change command, see if that improves things.

 

[Goeytex]

Deleted my post with bad/wrong information. Sorry .

Setting the Baud rate does indeed set the baud rate for AT commands. However the change is not implemented until the set pin is released from ground and then taken back to ground.

The module is best initially configured using a USB/TTL Adapter and a Terminal Application. I prefer a CP2102 with 3.3V logic levels