The HC-05, honestly

Mokxi does not model Bluetooth. What it models is the only half of an HC-05 a circuit can see, which is a UART.

That turns out to be nearly all of what a sketch does with one.

The little blue board with the button on the end is sold as "Bluetooth for Arduino", and what it actually is could not be simpler: a wireless extension cable for a serial port. Bytes into RXD come out of the phone at the other end; bytes the phone sends come out of TXD. That is the whole of the device from the board's side, and a sketch cannot tell the difference between a paired HC-05 and a wire to a terminal.

Where the far end is

The serial monitor. The module has a host channel, exactly as a board's UART does, so it appears in the serial pane under its own part id with its own input box beside the boards. Typing a line there is the phone sending; what the sketch prints through the module appears there.

Click the module on the canvas to hang up and redial. STATE follows: high while there is somebody on the other end, low while there is not, which is how a sketch knows whether it is talking to itself.

That is the whole of the pretense and it is an honest one. What you cannot learn here is everything on the other side of the antenna: pairing, the PIN, the master and slave roles, range, interference, and why the module wants EN held high while power comes up. Those are real, and they are not in this model.

What is real, and it is the half that goes wrong

The bytes are not teleported. TXD and RXD carry 8N1 at the module's baud, bit by bit: a start bit low, eight data bits least significant first, a stop bit high.

So the failure everybody has actually had is reproducible here on purpose. Open the module's properties, set baud to 4800 while the sketch still samples at 9600, and the stop bit lands in the middle of a byte: the frame is thrown away and the log fills with framing errors. It is the commonest HC-05 problem in the world and it is worth causing once, deliberately, with the wires in front of you.

The module ships at 9600 baud in data mode, which is why every tutorial starts with Serial.begin(9600).

Three volts, not five

The board takes 3.6 to 6 V on VCC through its own regulator, and its logic is 3.3 V. TXD swings to 3.3 V, which an AVR reads as a high with room to spare.

RXD is the pin that matters on a real bench: it is not 5 V tolerant, which is why every tutorial puts a divider on the board's transmit line. Nothing in Mokxi can be damaged, so the gallery circuit does not carry one, but TXD really does only reach 3.3 V here, so a circuit that compares it against the 5 V rail behaves the way the real one does. Add the divider on hardware.

Two pins, and one hardware UART

An Uno has one hardware UART and it is the serial monitor's, so the module gets a software one, which is what SoftwareSerial is, and why it exists. At 9600 baud a bit is 104 microseconds, which is a very long time at 16 MHz; the btlamp sketch counts one out by hand so the whole of it is visible in thirty lines.

AT mode

EN (marked KEY on some boards) high puts the module into command mode: bytes on RXD are commands for the module itself rather than traffic for the far end, and the answers come back on TXD. The subset answered here is the one a lesson uses:

command	answer
`AT`	`OK`
`AT+VERSION?`	`+VERSION:3.0-20170601` then `OK`
`AT+NAME?`	`+NAME:<name>` then `OK`
`AT+NAME=<text>`	`OK`, and the name changes
`AT+UART?`	`+UART:<baud>,0,0` then `OK`
`AT+UART=<baud>,0,0`	`OK`, and the rate changes
`AT+ADDR?`	`+ADDR:98d3:31:fb1234` then `OK`
anything else	`ERROR:(0)`

Commands end with CR LF, as the real one requires.

One deviation, written down. The real module talks AT at 38400 baud whatever the data rate is set to. This one answers at baud, because a second rate would mean a second UART in the model for one lesson's worth of gain. It is the only place the AT half differs from the sheet.

What is not modeled

The radio, and everything that hangs off it: pairing, AT+ROLE, AT+CMODE, AT+BIND, AT+INQ and the discovery they belong to. The button on the end of the board, which on a real one is the other way into AT mode. Flow control, which the header does not bring out. Any framing but 8N1. And the delay between a byte reaching the module and leaving the far end. Here it is instant, where a real link is tens of milliseconds and jitters.

The circuit to open

Bluetooth lamp: type on, off, blink or status at the module in the serial pane and the lamp answers, with STATE wired so the sketch can tell you when nobody is listening.