JDY-31 Bluetooth SPP module

A friend referred me to a ‘replacement' for the HC-05 Bluetooth module, a JDY-31.

Above is a JDY-31 bluetooth module with header pins fitted. The physical design is poor, the header pins can be fitted from only one side (not plated through holes, no pads on the other side, probably to suit the base board below), and the black plastic part obscures the board labelling of the pins.

Note, the basic module above is specified for maximum of 3.6V, it is not guaranteed for 5V operation. A quick inspection suggested this may be pin compatible with the ‘mother board' for HC-05 modules which provide a 3.3V regulator and level conversion to permit operation from 5V.

The JDY-31 is advertised as “replaces HC-05” and “HC-05 compatible” by various online sellers, and it is cheap, I bought three for under $10 shipped… though it took a couple of months for them to arrive.

Compatibility with HC-05

It is a lie!

The command set is not compatible, the procedure for programming is different.

More importantly, the JDY-31 appears to recognise line endings to trigger transmission, so it is a structured text based channel and may not work with some applications that worked with the HC-05 (which provided a binary channel).

I intialise these things with an expect script. Here is an expect script for intialising a JDY-31 module. Note that the JDY-31 will interpret AT commands any time that it is not paired (differently than the HC-05).

#!/usr/bin/expect

package require Expect
package require cmdline 1.5

#HC06 baud code conversion array
set baud(1200) 1
set baud(2400) 2
set baud(4800) 3
set baud(9600) 4
set baud(19200) 5
set baud(38400) 6
set baud(57600) 7
set baud(115200) 8
set baud(128000) 9

set MyCommandName [::cmdline::getArgv0]
set options {
#  {c.arg "\\\\.\\COM1" "comm port"}
  {c.arg "/dev/ttyUSB1" "comm port"}
  {o.arg "9600" "old baud rate"}
  {s.arg "115200" "new baud rate"}
  {n.arg "test" "name"}
  {p.arg "1234" "PIN"}
  }
set usage ": $MyCommandName \[options] filename ...\noptions:"
try {
  array set params [::cmdline::getoptions argv $options $usage]
  } trap {CMDLINE USAGE} {msg o} {
  # Trap the usage signal, print the message, and exit the application.
  # Note: Other errors are not caught and passed through to higher levels!
  puts $msg
  exit 1
  }

#initialise bluetooth vars
set port $params(c)
set obaud $params(o)
set nbaud $params(s)
set name $params(n)
set pin $params(p)

encoding system iso8859-1

#source [file dirname [info script]]/log.expect
set line "\n***** "
append line [timestamp -format "%Y-%m-%d %H:%M:%S" -gmt]
append line " $argv0 starting...\n\n"
#send_log $line
send_tty $line

send_tty "Open port $port\n";

set com [open $port r+]
send_tty "fconfigure $com -mode $obaud,n,8,1 -encoding binary -buffering none -translation binary\n\n"

fconfigure $com -mode $obaud,n,8,1 -encoding binary -buffering none -translation binary
set spawned [spawn -open $com]
set timeout 2

after 500
send_tty "\nAT+VERSION\n"
send "AT+VERSION\r\n"
after 500
expect {
-re \\+VERSION=.*$ {}
timeout {send_tty "... something wrong here, aborting.\n";abort}
}

after 500
send_tty "\nAT+NAME=$name\n"
send "AT+NAME=$name\r\n"
after 500
expect {
-re OK.*$ {}
timeout {send_tty "... something wrong here, aborting.\n";abort}
}

after 500
send_tty "\nAT+PIN$pin\r\n"
send "AT+PIN$pin\r\n"
#send "AT+PIN\r\n"
after 500
expect {
-re OK.*$ {}
timeout {send_tty "... something wrong here, aborting.\n";abort}
}

after 500
send_tty "\nAT+BAUD$baud($nbaud)\r\n"
send "AT+BAUD$baud($nbaud)\r\n"
after 500
expect {
-re OK.*$ {}
timeout {send_tty "... something wrong here, aborting.\n";abort}
}

send_tty "\n\nAll good...\n";

Conclusions

Cheap, requires different programming procedure, may work with most text based applications, requires 3V supply.