HC05 bluetooth modules - Page 1
Forum section: electronics / general

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: January 30, 2019, 01:47:53 pm
content: I recently purchased two of those bluetooth modules to try out with an Arduino UNO. This one had the 5v to 3.3v level shifting built on a board with 6 edge pins for easy connection. The original BT module was soldered on as a daughterboard on to this slightly larger host board. I diligently followed the tutorials but couldn't get any comms going in command mode. In the end I contacted the #arduino IRC channel and confirmed that I was hooking everything up correctly. Ok, I had missed a RESET to GND link, but that rectified, I still couldn't get a peep from either BT module.Could this be a power issue? I checked and 3.3v from the regulator on the host board was present across the 3.3v input and GND pins on the daughterboard. I got the scope out and with the board in command mode probed the RXD input to the daughterboard and saw my AT+CR+LF string coming in from the Arduino UART via the host board right to the RXD contact on the BT module board. So I then probed the TXD pin and.... nothing. No response to my AT command.Clearly a problem with the actual BT daughterboard then. I checked the other one, which was exactly the same.I noticed that the module itself has USB D+ and D- pins as well as an SPI bus and a 29LV800 EEPRON on board. Querying these would require attaching some wires. I first raised a return request. The seller issued an immediate refund without any quibble so now I could investigate further (or just throw in the bin).I attached a USB lead using the 5v and GND terminals on the edge connector and the D+ and D- connectors on the daughterboard and plugged into a USB port. The LED came on, but the OS did not identify any device. I tried both normal and command mode. It simply does not come up in the list of devices returned by lsusb on my Linux Mint machine.Next, out came the BusPirate and I tried flashrom to see if it would identify the EEPROM chip and pull the firmware. I got "No EEPROM/flash device found". I re-checked the connections to make sure and tried again. Same result.Given that there appears to be no output from both the microprocessor and the EEPROM fails to read, this looks like both chips are just not receiving power. I haven't probed the other board any deeper, but it seems odd that both boards appear to have a similar fault.So what is going on here? Fake components? Mis-matched board and module layout? Badly fitted BGA chips?I guess there is no QA with these devices from the far east so I expect these are common problems with these HC05 devices?I intend to order a couple more, but am a bit concerned that the replacements might be iffy as well.

author: janoc
author_rank: Super Contributor
timestamp: January 30, 2019, 03:29:06 pm
content: The USB pins won't do anything unless you reprogram the firmware to actually support it. The stock firmware doesn't. They just break out all the pins of the SoC but that doesn't mean all that functionality actually works. That Cambridge Silicon Bluetooth SoC is commonly found in Bluetooth dongles and similar devices and has integrated USB phy.If you didn't fry the modules by some mistake, such as connecting 5V to the module itself (they are not 5V tolerant!), I would say you have got duff modules. Not necessarily fake but poorly assembled/damaged. That sometimes happens.Quote from: WaveyDipole on January 30, 2019, 01:47:53 pmThat should be fairly easy to check with a multimeter and a pair of sharp probes. You can also measure current the module draws and watch for changes as the SoC boots. if it works, there should be quite large changes in the current once the SoC starts operating and the radio turns on. If there are no changes at all, the SoC is obviously not working.Quote from: WaveyDipole on January 30, 2019, 01:47:53 pmI wouldn't say that this is a common problem. I have certainly not encountered it and I have got quite a few of these from various vendors. There also certainly is QA - but it all depends on the OEM who made these and the seller you have got it from. Some are completely happy to sell you crap that didn't pass testing at the factory because they know most people won't complain for a $2 component ...If I make a quick scan of AliExpress offers for these things and see some where already the seller's photos show a module with a very dodgy soldering, components askew, etc., basically the whole thing looking as if it was assembled by hand by some unpaid slave in a cubicle under the stairs, it doesn't inspire much confidence that it will work. On the other hand, there are also fairly large vendors selling good quality stuff (including pre-certified modules) where you are very unlikely to have any issues.Just look at this vendor:https://www.aliexpress.com/item/Big-sale-integrated-Bluetooth-Wireless-Bluetooth-RF-Transceiver-Module-serial-RS232-TTL-HC05-HC-05-for/32590103175.htmland compare e.g. with this one:https://www.aliexpress.com/item/HC05-HC-05-master-slave-6pin-JY-MCU-anti-reverse-integrated-Bluetooth-serial-pass-through-module/32340945238.htmlShould give you an idea ...

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: January 30, 2019, 04:55:22 pm
content: Thanks for your comments.Quote from: janoc on January 30, 2019, 03:29:06 pmI was hoping for some sign of life from it, but that would explain it then.Quote from: janoc on January 30, 2019, 03:29:06 pmCan never rule out frying something I guess, but the host board does have a 3.3v regulator and allows a 3.6v to 6v input so it can be powered from the 5v pin on the Arduino. The supply to the actual BT module daughterboard was measured at 3.3v. Most tutorials seems to omit 5v to 3.3v level shifters on the RX/TX pins. I did initially use a shifter board in series but since tutorials don't seem to bother, when it didn't work I removed the level shifter to rule it out.Quote from: janoc on January 30, 2019, 03:29:06 pmI tried that. According to vendor specs:"Working current: matching for 30 MA, matching the communication for 8 MA"I'm taking that to mean that it should have a 30mA running current rising by 8mA when the radio is active. When I power the unit on in command mode, I initially get a surge up to about 20mA for maybe 3 seconds, and it then settles and fluctuates between 0.5mA - 1.5mA as the LED blinks on an off. A current of 0.5mA would be nowhere near the expected current draw, even if it were 8mA. When starting in normal mode, current continually fluctuates rapidly between about 0.46 - 40.2mA. Fluctuations take maybe half a second to a second.Interestingly, in normal mode, it is possible to discover a HC-05 bluetooth device which would suggest that the radio is working. However, it is not discoverable in command mode. I could be that the radio is turned off in this mode, but the low current draw in this mode would perhaps seem to suggest that all is not well with the SoC.Quote from: janoc on January 30, 2019, 03:29:06 pmI take your point about the quality of the assembly. The scribbles on the first one do not look particularly professional either.I have to say that the workmanship doesn't look too bad - everything looks straight. However, there does seem to be a bit of a clearance on the BGA chips and I can see the solder blobs underneath the memory chip. Not sure if they are supposed to sit a bit more flush than they are. The again, I can't see how it would have been flashed if the memory chip was not seated properly, unless they are done in bulk prior to assembly.

author: janoc
author_rank: Super Contributor
timestamp: January 30, 2019, 06:06:12 pm
content: Oh so the LED blinks and the module is discoverable? Well that completely rules out any power issues or bad chip then - it is obviously working. Not being discoverable in command mode is normal, that device is not something that can "multitask", so when in command mode the Bluetooth stack is likely suspended.Your inability to get any communication going is most likely a protocol problem - e.g. baud rate setting (try 9600 or 38400 Bd), end-of-line characters (try sending \r\n, \n only, etc.) or wiring (swapped Rx/Tx signals is a common mistake, also the modules don't all have the same pinout!).Or the module could have some weird firmware installed but even in that case it should communicate.Get an USB to UART converter (e.g. one of those FTDI dongles), connect it directly to the module and try to get it to talk using a terminal emulator program on the PC (e.g. Hyperterminal, RealTerm, Putty, etc.) Only once you are sure it works and you know the correct settings start messing with the Arduino.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: January 30, 2019, 09:01:31 pm
content: Quote from: janoc on January 30, 2019, 06:06:12 pmYes, agreed. I thought that in command mode the current is much too low at 1.5mA, but according to the datasheet it has a standby current of 47uA sp perhaps the low 1.5mA current that I measured is not an issue.Quote from: janoc on January 30, 2019, 06:06:12 pmI did wonder about whether the firmware might be missing or something, but then presumably it would not identify itself as an HC-05. I presume that and the radio starting must be programmed in firmware as must presumably the fact that it is switching modes. However I agree that even if the firmware was an earlier or some odd version, one would still expect it to communicate.Quote from: janoc on January 30, 2019, 06:06:12 pmI have a BusPirate and tried to do something similar using its UART mode. Although the seller says that the serial parameters are 9600,n,8,1, I have tried every baud rate from 300 to 115200. Also tried PuTTy, via the Arduino.

author: janoc
author_rank: Super Contributor
timestamp: January 30, 2019, 10:00:19 pm
content: Quote from: WaveyDipole on January 30, 2019, 09:01:31 pmThat's quite normal current, those 30mA is for when the device is actually transmitting. When it isn't or isn't even connected to anything it will likely go into a lower power mode.Quote from: WaveyDipole on January 30, 2019, 09:01:31 pmTry the RealTerm and do make sure to try different line endings. It may not react to commands unless it sees the correct end of line. Also it may not send anything back by default (especially not in the normal mode when not connected to anything), so you may have to try to type a few AT commands to get a response. And connect the device to PC directly, not through Arduino - if you have a bug in your code or wiring you can fight with it for ages. Minimize the number of things that could go wrong.But do make sure that you have connected the Tx line from Arduino to Rx line of the module and vice versa (i.e.notTx to Tx and Rx to Rx!).

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: January 31, 2019, 05:39:03 pm
content: Quote from: janoc on January 30, 2019, 10:00:19 pmI am trying both ways just in case, but this is interesting since some tutorials have you connecting Tx to Tx and Rx to Rx. Ordinarily this does not make sense since Tx sends to Rx and coversely Rx receives from a Tx so I discussed this with someone on the #arduino IRC channel. It turns out thatwhen using an Arduino as a UARTconnecting Rx to Rx and Tx to Tx does actually make sense. The Arduino pins are marked to correspond with the pins on the ATMega SoC. Anything interfacing with the SoC, including the on-board UART, would connect its Tx to Rx and Rx to Tx. However, when using the Arduino board as a UART, we are ignoring the SoC pins and communicating with the UART chip. To do this the board should have a blank sketch and the processor must be held in RESET (by connecting the RESET pin to GND) to prevent it interfering with comms. Now that we have taken the SoC out of the picture, we are left with the UART Tx on the pin marked Rx and the UART Rx on the pin marked Tx. In this scenario it makes sense to connect the Rx->Rx (UART Tx) and Tx->Tx (UART Rx). It seems that a distinction needs to be made as to whether we are communicating with the device using the SoC via a sketch, or whether we are bypassing the SoC and communicating directly via the UART.Rather curiously and frustratingly, after some head-scratching I discovered that the BusPirate had a problem. Initially it had firmware version 5.1 installed which I recently upgraded to v6.3 so it would work with the flashrom program. Thinking of that adage where once you have eliminated everything then what remains, however improbable, must be the truth, it occurred to me to test this improbability by downgrading to v6.2 of the firmware. Sure enough, I found that I could now see comms between the BusPirate and the Arduino UART, so it would seem that the version 6.3 firmware update broke some UART functions on the BusPirate.This still does not resolve the original problem, as I still cannot communicate with the BlueTooth device. However, curiously I also getting only one-way comms between the BusPirate and the Arduino UART although otherwise the Arduino works fine. Still, serial UART is a 1:1 topology, but when we connect something to Rx/Tx on the board we now have three devices connected together which is not ideal anyway.I take your point about keeping things simple. I have a couple of PL2303's somewhere so I might try rigging one of those up to and see what happens.

author: tsman
author_rank: Frequent Contributor
timestamp: January 31, 2019, 05:44:43 pm
content: I found the BusPirate to awkward to use as a UART. It is fine for playing with I2C and SPI but meh for everything else. Picking up a cheap USB to 3.3V/5V serial dongle is far better and you can get cheap isolated versions as well.If your USB serial dongle is the basic PL2303 and you want to use it under Windows then you'll need to search around for an old version of the driver. The manufacturer got fed up with the counterfeits and just dropped support entirely for that chip in their driver. Only the old versions will work now.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: February 02, 2019, 11:21:58 am
content: Quote from: tsman on January 31, 2019, 05:44:43 pmI think I would tend to agree with you.Quote from: tsman on January 31, 2019, 05:44:43 pmI have the driver installed on my Win7 system, but was intending to do the testing under Linux. However, it seems that the PL2303 is incompatible because it signals using the RS232 signalling standard. I checked the Tx/Rx pins on the PL2303. The Tx pin had -6v, so I believe this dongle signals with LOW = -6v and HIGH=+6v. The Arduino signals using TTL where LOW=0v and HIGH=5v. I will need an RS232 to TTL level shifter to make this work.I think I will just get one of those FTDI dongles suggested by yourself and janoc.

author: janoc
author_rank: Super Contributor
timestamp: February 02, 2019, 11:53:22 am
content: PL2303 is certainly NOT using RS232 voltage levels, it would need a level shifter like MAX232 to be RS232 compatible. The serial protocol is the same otherwise.If you have a dongle with a DB9 or DB25 connector then that one has the level shifters and you can't use it. If you have only a bare board with pin headers or a cable and it doesn't have the DB connectors, then that one is very likely just a bare chip (USB to serial) bridge.Of course, you could always open the dongle and remove the level conversion chip.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: February 02, 2019, 04:44:58 pm
content: Yup, mines a dongle with a DB9 so that explains it. Must have the level shifters to convert TTL to RS232 at the DB9 built in. I don't want to destroy the dongle (which would be required to open it) so I have ordered one of those FTDI boards that is 3.3v/5v switchable. Much simpler that way and it already has the pins to make connections. Thnx for suggesting it.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: March 07, 2019, 11:38:23 pm
content: They took a month to arrive but my replacement HC05 modules finally landed today so I thought I'd give them a test and update the thread. Following on from my last post, I had ordered an FTDI dongle, switchable between 3.3v and 5.0v so I now used this to test the two modules I had just received. Initially neither of them worked as described, but ultimately both did work once the correct baud rate was found. The story has an interesting twist in that the Arduino IDE may have initially led me to an incorrect conclusion about the original modules.The new modules are based around a BC417 chip whereas the ones from the first order are based on a BC352. Both modules are described by the sellers as as operating on 9600 baud. At least that was my educated guess when reading this:QuoteI tried one of the new modules at 9600 baud and got nothing. Since 38400 baud was mentioned earlier in this thread and I discovered in subsequent research that at least some versions of HC-05 firmware work at this speed by default, I tried 38400 baud and voila! It worked - I finally got an AT response to my AT command. But here is where things got a little weird.I had ordered two modules so I tried the second one - and it didn't work, either at 9600 baud, nor at 384 baud. After a little head-scratching and some diagnostics I found that it is not sufficient to just close down the Serial Monitor between tests. It was absolutely necessary to completely close down the Arduino IDE. It seems that the IDE keeps the port open even when the Serial Monitor is closed, even when the module is disconnected from the USB port. When re-connecting the module (or connecting another one) the OS 'sees' that the existing port (e.g. /dev/ttyUSB0 on Linux) is busy and assigns the next consecutive port available (e.g. /dev/ttyUSB1). The IDE and Serial monitor show no error message so there is otherwise no indication that this has taken place, but any subsequent attempts to communicate with the module fail as the connection is still open to the now orphaned port instead of the currently active one.When I discovered that the second module was now being presented on /dev/ttyUSB1, I completely closed down the IDE, unplugged the module, waited a few seconds and plugged it back in again. I then confirmed the port to which it had been assigned and fired up the IDE again. I made sure that the IDE was using the correct port and opened the Serial Monitor. This time, with a connection speed again set to 38400 baud, I got the OK response to the AT command from the second module.Now for the twist. Having discovered this problem, it seemed like a good idea to try both of the modules from the original order. One worked. The other didn't. I re-checked to be sure. Evidently I did have one faulty module but the other one was OK. Now, I did meticulously try every possible baud rate up to 115200 on these modules without success prior to ordering the new ones, but since I only closed the Serial Monitor but not the IDE between tests, I can only assume that I had tested the bad one first and then ended up communicating with the orphaned port when testing the second one. I thought I would mention this gotcha in case anyone encounters a similar issue. It may not be an issue on Windows, but it certainly is on Linux.For good measure, I also tested with alternative terminals. The two I have on Linux are Putty and C-Kermit. With Putty, both the "Implicit CR in every LF" and "Implicit LF in every CR" terminal settings but no matter what I did, I could not get the module to respond.I did have success using C-kermit with the following parameters which saved in a script file:Code:set line /dev/ttyUSB0set speed 38400set parity noneset stop-bits 1set flow-control noneset terminal type ttyset term echo remoteset term newline-mode onset carrier-watch offconnScript can be involved with:Code:kermit -y <scriptfile>So to summarise:- none of the modules work at the advertised 9600 baud by default. They do seem to work at 38400 baud.- the Arduino IDE must be shut down completely before disconnecting/connecting any modules- in Serial Monitor it is essential to use the "NL&CR" line ending setting- I could not get the module to respond using PuTTY no matter what settings I used- C-Kermit can be used to test, but the following command is required to turn on CRLF line endings: set term newline-mode onWith regards to the BusPirate, it transpired that in later versions of the firmware, the UART transparent bridge feature is broken. I raised a bug report and the problem was confirmed, but even with the earlier working firmware, I can still not communicate with a working HC-05 module. I am guessing that it probably sends only a CR and since there is no way to configure the line termination characters, the BitPirate is unsuitable for testing anything that requires a CRLF line ending.Anyone know what the difference is between the two processors, i.e. the BC352 and BC417? I found a datasheet for the latter, but couldn't find one for the former.

author: janoc
author_rank: Super Contributor
timestamp: March 08, 2019, 03:11:14 pm
content: If you are working in Linux, I had the best success using Minicom as a terminal emulator. Also screen and GTKTerm are usable. Putty makes way too many assumption about the protocol and buffering - that's great if you are talking to an actual modem but not so great when dealing with a device with unknown/half-broken firmware as many of these cheap modules come with.