Bluetooth communication problem.

micrometal

New Member
I have been trying for some time to communicate with an 08M2 using Bluetooth. I am using a AXE091 board. I have an HC-05 and an HC-06 module. I know that the modules are good because if I wrap Rx and Tx on the board everything that I send comes back. What I am trying to do is a wrap test through the 08M2. Here is my code ...

Code:
    ; HC-05/06  testbed
    ; C.0 is output to Rx of Bluetooth module
    ; C.1 is input from Tx of Bluetooth module
    ; C.2 is indicator output to LED

        setfreq        m8
main:    b0 = 0            ' clear data
        debug        b0
        serin         [2000],C.1,T9600_8,b0

        if b0 = 0 then goto main
        high C.2
        debug        b0
        pause        2000
        serout        C.0,N9600_8,(b0)
        pause        2000
        low C.2           
        goto main

    end
Two remarks that I need to make here ...
1. I am using 1200 baud because when I ran the Rx/Tx wrap test and looked at the signal on an oscilloscope it appeared to be 1.2khz. But using 9600 baud gives the same results anyway.
2. I use Txxxx for serin and Nxxxx for serout because I am using a common emitter transistor to buffer the 5v/3.3v levels, which inverts the signal.

To test the circuit I send single bytes. The LED illuminates, but what is received at the 08M2 is not the byte that I transmitted; it is a repeatable but otherwise random value. And nothing is transmitted back.

It would be helpful if anyone can suggest how I can verify the baud rate that the BT modules are expecting. Even better, tell me that there is something wrong with my code.
 

PhilHornby

Senior Member
Have a read through this blog: https://blog.zakkemble.net/getting-bluetooth-modules-talking-to-each-other/

Note that the HC-05 and HC-06 firmwares are radically different - though they're rumoured to be the same hardware. Lots of people on here have had problems with the HC-06, that I didn't encounter on the HC-05 in Slave mode. (I abandoned my use of bluetooth, as the range wasn't good enough for the project in question).

The key to getting them working, is to use a pair of USB-Serial adapters and Realterm/Putty/Teraterm etc to prove they communicate, at the baud rates you expect. (When buying such adapters be aware that some of them that claim to be 3.3V/5V switchable aren't (they just alter the voltage to a VCC pin)).
 

micrometal

New Member
Thanks - I will read and digest. When I first started testing out the HC-05 I was able to transmit character strings successfully, and to receive back (always slightly garbled) the same strings, so I know that I can do better than I am doing now. But in trying to fix that problem something got chhanged and I cannot track down what that was.
 

AllyCat

Senior Member
Hi,
1. I am using 1200 baud because when I ran the Rx/Tx wrap test and looked at the signal on an oscilloscope it appeared to be 1.2khz. But using 9600 baud gives the same results anyway.
I can't help with the Bluetooth interface, but your code doesn't appear to be running at 1200 baud; I think you are probably misunderstanding the DEBUG command; the parameter b0 has no effect, DEBUG always transmits about 50 bytes of an unspecified serial data rate and format via the c.0 pin. However, since your code doesn't change b1 - b27, etc., most bytes will be zero, so the pattern may look like some other serial data format. Normally, a SEROUT would be sent to a different pin (e.g. c.4) to avoid confusion with the DEBUG and any SERTXD data output on c.0.

Your PAUSE 2000 and Timeout = 2000 will each take about 1 second and DEBUG up to 100 ms, so there appears to be a significant opportunity for input data to be "lost", particularly with the first goto main loop at each timeout. Also note that SEROUT and SERIN are both implemented by firmware so full Duplex (multitasking) is impossible.

Cheers, Alan.
 
Last edited:

hippy

Technical Support
Staff member
The first step would be to get reception working, and I would disconnect the transmit from pin C.0 and put that on something else. That way you can use DEBUG and SERTXD to monitor what is being received -
Code:
#Picaxe 08M2
#Terminal 9600
#No_Data

Symbol RX = C.1 ; Receive from Bluetooth
Symbol TX = C.4 ; Transmit to Bluetooth

SetFreq M8
Do
  SerIn RX, T9600_8, b0
  SerTxd( "Got ", #b0, " '", b0, "'", CR, LF )
Loop
 

PhilHornby

Senior Member
2. I use Txxxx for serin and Nxxxx for serout because I am using a common emitter transistor to buffer the 5v/3.3v levels, which inverts the signal.

To test the circuit I send single bytes. The LED illuminates, but what is received at the 08M2 is not the byte that I transmitted; it is a repeatable but otherwise random value. And nothing is transmitted back.
I just used a simple resistive divider to do the level shifting - this has the advantage of not inverting the signal. See here for a more in-depth look at the subject.

You will almost certainly need to use the serin command with a 'qualifier', so that it can posted before any expected data from the other end. (The "M" series Picaxe has no 'typeahead' or buffering capability for its serial I/O ... if the serin is not active before the expected data, it will just be lost).
 

micrometal

New Member
My thanks to all of you. I am not sure that I understand all of it at the moment - I am more of a software man (desktop and Android) than a hardware man - so it may take me a while to understand the timing intricacies of serial commands. But as I said earlier, I know that it can be done, so must keep trying.
 

micrometal

New Member
One thing that I have learned from the replies above is that I know less about what I am doing than I thought. But never mind; I am here to learn.

I am certainly unclear about the relationship between the serout and sertxd software instructions and the "Serial Out" pin (pin 7 on an 08M2). Is it the case that when you are using "debug" and/or "sertxd" instructions then you cannot use C.0 as an I/O pin (because it is being used to stream data back up the serial cable to the Picaxe editor)?

But anyway, I tried the code sample provided by @hippy. I connected to my HC-05 using my Android 'phone and sent various messages from there. I looked at the responses using the Serial Terminal in the Picaxe editor (something that I had not really used before). What I saw in the Terminal were the character counts of the messages that I sent. If I sent "AB" the response was "Got 2 '[02]'; sending "12345" produced "Got 5 '[05]'. Does this tell me something useful?
 

PhilHornby

Senior Member
Is it the case that when you are using "debug" and/or "sertxd" instructions then you cannot use C.0 as an I/O pin (because it is being used to stream data back up the serial cable to the Picaxe editor)?
Correct.
Does this tell me something useful?
The bluetooth protocol has almost certainly 'batched-up' the characters you typed and sent them as one packet, when you stopped typing. Trying to read them a byte at a time at the Picaxe end is fraught with difficulty - it cannot get around the loop fast enough and misses some most of them. It could be that effect you're seeing. (The HC-05 will just splurge them out, whether or not the Picaxe is ready)
If you type really slowly, so it sends a s-i-n-g-l-e character at a time, does that work?
 

inglewoodpete

Senior Member
1. I am using 1200 baud because when I ran the Rx/Tx wrap test and looked at the signal on an oscilloscope it appeared to be 1.2khz. But using 9600 baud gives the same results anyway.
I have to question the baud rate you measured.

You say your oscilloscope is showing 1.2kHz. How are you measuring this? 1200baud is not 1.2kHz - it is 1200 bits-per-second, with each bit taking about 830uS. If the oscilloscope measured one (square-wave) cycle at 1.2kHz, it would have a 1 and a 0, with each bit taking approximately 415uS.

If each bit takes about 415uS, the default baud rate would be 2400baud.
 

Goeytex

Senior Member
The best way to determine the baud rate rate is to enter The HC-05's AT Command mode and do a query. There are many videos on Youtube as to how to do this. If using an AXE027, both signals (RX/TX) will need to be inverted and the signal to the HC-05 RX pin will need to be level shifted to 3.3V. Sticking a Picaxe between the HC-05 and a serial terminal only complicates things.

It would to better to NOT use the AXE027 and instead use a CP2102 USB/TTL adapter that supports 3.3V logic levels and uses the correct polarity, so that inversion is not necessary.

To use these modules properly you must first understand how to enter and use the AT command mode to query and configure the module .
 

micrometal

New Member
If you type really slowly, so it sends a s-i-n-g-l-e character at a time, does that work?
If I send a single character then I see "Got 1", consistent with the other responses. Incidentally I am now using a voltage divider to make the level adjustment.

Interestingly (or perhaps not) if I modify @hippy's code to use N9600 rather than T9600 then I get these responses : Send "A" -> "Got 127 ('7F')" and Send "AA" -> "Got 191 ('BF')". I don't know if this provides any clues.
 

micrometal

New Member
I have to question the baud rate you measured. How are you measuring this?
I measured the baud rate by wrapping Rx and Tx on the HC-05, sending a longish stream of 0xAA bytes and looking at what passed through the link on an oscilloscope. This looked like a 1.2kHz pulse stream but, you are quite right, that is 2400 baud, not 1200. However it was certainly not 9600 baud and that, plus the fact that I could not replicate my previously semi-successful communicatiion with the HC-05, makes me think that the HC-05 baud rate has changed.
 

micrometal

New Member
It would to better to NOT use the AXE027 and instead use a CP2102 USB/TTL adapter
Yes - I was looking at USB/TTL converters yesterday - before that I did not know they existed. Interfacing with an 08M2 provides too many opportunities for error - at the moment I don't know what problem I am trying to fix.

To use these modules properly you must first understand how to enter and use the AT command mode
Yes - again. I have been trying to do that because I believe that will reset the baud rate to 9600. I don't think that I have succeeded. I think that I I need to apply a high signal to the EN pin on the HC-05. If I do that while I power on the module then it does go into a different mode (the LED flash pattern changes) but I am not sure that this is a reset. I think that the correct methid is to take the EN pin high after powering up the HC-05, but I have not got that to work yet. So I guess that I do not yet understand how to enter AT mode.
 

PhilHornby

Senior Member
If I send a single character then I see "Got 1", consistent with the other responses.
But does it print the (correct) ascii character that you sent as well?
I get these responses : Send "A" -> "Got 127 ('7F')" and Send "AA" -> "Got 191 ('BF')".
When the bluetooth link is up, it's effectively an error-free piece of wire (though the inter-byte spacing will not be preserved).

Hippy's code cannot handle a stream of characters sent at pace (because the time taken to print the debug message after each one, means that the next received character will have been missed). But if your baud rates (and polarity) are correct and the link is definitely up (IIRC there's a status signal), then you should be able to type single characters, slowly and deliberately, and see them received by the Picaxe.

Incidentally, I routinely set the Picaxe frequency to 32MHz when serial comms is involved. (I believe that frequency interferes with some of the 'servo' related commands, but I don't use them anyway).
 

AllyCat

Senior Member
Hi,
If I send a single character then I see "Got 1"......... if I modify @hippy's code to use N9600 rather than T9600 then I get ...."Got 127 ('7F')" and .... "Got 191 ('BF')".
Hippy's code (in #5) is designed to receive and display the ASCII value as a decimal number (the effect of the # prefix) followed by the character itself (between single quotes ' ' ) for a single character (only b0 is used), so there is no point in sending more characters (concurrently). "Got 1" suggests that 1 0 0 0 0 0 0 0 (serial binary bits) were received (lsb first) which is a "non-printing" character (they start at 32 with "space" and end around 127). So "Got 1" won't be followed by a printed character, but I would have expected to see it followed by '' or ' '. Similarly "Got 127" suggests that 1 1 1 1 1 1 1 0 (binary bits) were received (which is almost the inverse); but in both cases the received code might have been simply "kicked off" by a spurious edge or a pulse rather than any real data byte. 127 is questionably a "printing" character, but it looks as if the PE Terminal Emulator may have the "Show Unprintable characters as Hex" option selected , i.e. 127 decimal is $ 7F (Hex) and 191 decimal is $ BF (Hex).

Personally, for "fast" code I normally use 16 MHz, because the Servo and time functions do work correctly and the power drain is about 35% lower than at 32 MHz. But IMHO, for anything approaching "concatonated" (i.e. continuous groups of) characters, you need the program to be designed to receive a "string" using either multiple variables (often @BPTRINC) and/or the hardware UART (HSERIN command). Generally the "background receive" of an X2 chip is recommended, but it is possible (at least for reasonably experienced program-writers) to use the UART hardware in any of the M2 chips.

Particularly if you have a 'scope (and know how to use it), then most of your "clues/observations" above can be explained, but you have quite a steep learning curve, so the best advice I can give is to "Keep It Simple" and not to jump between different test setups until each issue is understood.

Cheers, Alan.
 
Last edited:

micrometal

New Member
Thank you all for your help. I think that my next steps will be to buy another HC-05 to try and get back to where I was, and a CP2102 cable to better understand where I am now.

By the way, I have a couple of applications in mind; both essentially data loggers. For instance, a battery powered box that records ambient temperature every 30 minutes. Leave it in the greenhouse overnight and wander up in the morning with your Android 'phone. Download a couple of dozen bytes over Bluetooth and see a graph of the overnight temperature profile. Sounds pretty straightforward - should be a doddle.
 

hippy

Technical Support
Staff member
Interestingly (or perhaps not) if I modify @hippy's code to use N9600 rather than T9600 then I get these responses : Send "A" -> "Got 127 ('7F')" and Send "AA" -> "Got 191 ('BF')". I don't know if this provides any clues.
Given that with T9600 you were receiving something entirely meaningful, an accurate binary count of the number of characters sent, I would say that proves the baud rate is 9600 and Txxxx polarity is correct.

A binary 1 sent with T9600 protocol would be received as binary 127 when incorrectly read with N9600 baud.

It has been a long time since I did any Bluetooth but I am more than prepared to bow to PhilHornby's assertion it's a straight through byte at a time transfer.

Which begs the question why you are recieving a count of characters and not at least the first character sent ?

That suggests there is something more to what's going on. It would help to detail exactly what you do have in its entirety so people can figure it out.

But going back to the my original test code. Assuming that count then characters are being sent, then this should show the first character which was sent. It would be worth giving that a try.

Code:
#Picaxe 08M2
#Terminal 9600
#No_Data

Symbol RX = C.1 ; Receive from Bluetooth
Symbol TX = C.4 ; Transmit to Bluetooth

SetFreq M8
Do
  SerIn RX, T9600_8, b0, b1
  SerTxd( "Sent ", #b0, " bytes, first character was ", #b1, " '", b1, "'" , CR, LF )
Loop
 

PhilHornby

Senior Member
.... PhilHornby's assertion it's a straight through byte at a time transfer...
As in, the link status is either UP or DOWN. If it's DOWN, you can't send anything - if it's UP, your error-corrected data pops out of the other end (at some point - either when some buffer is full, or a timeout occurs).

The difficulty I encountered - at the extremes of range (through a thick wall) - was that it can be very difficult to establish the link in the first place. In my application, the link was initiated by multiple remote nodes - though it was only left in place long enough for a data transfer. However, if multiple Masters tried to connect to the same Slave simultaneously (which is what I was doing), then NONE of them would connect - I had to introduce a random back-off to counter this. :(

Looking back, through my old , abandoned code, I noted that the Link UP status can be up to 125mS later at the receiver, than at the sender...

All I can say, is: thank heavens for the HC-12 :)

I'm half remembering, that when you configure an HC-05, the baud rate used is fixed at 38400. The "AT+BAUD" "AT+UART" command sets the baud rate used in normal operations...

My code used T9600, but I noted that the ends of the links do not actually need to match - the HC-05 would handle the difference.

These memories are just too painful - I'm going to have to stop now :cry:

:D
 
Last edited:

micrometal

New Member
Hi @hippy. I tried your modified code, but not a great step forward. Sending any single ASCII character produced the following response ...

Sent 1 bytes, first character was 0 '[00]'

Sending 'n' characters results in "Sent n bytes ..." but no other change.

You are probably right about the HC-05 still running at 9600 baud, but I did rerun your code with serin set to T2400_8 and with it set to T1200_8. These were the responses at the Serial Terminal ...

Sent 66 bytes, first character was 254 '[FE]'
Sent 226 bytes, first character was 226 '[E2]'

In both cases the message sent was a single ASCII uppercase A. Sending "B" resulted in the same response.

It would help to detail exactly what you do have in its entirety so people can figure it out.
Not quite sure what you are asking here. My setup is ultra-simple. The HC-05 TXD pin goes directly to 08M2 C.1 and the 08M2 C.4 pin goes to the voltage divider (two 3.3k resistors in parallel with another 3.3k in series) with the mid-point connected to HS-05 RXD pin. That's it.
 

micrometal

New Member
Are you trying to transmit and receive on the same, single, 08m2?
Yes - I am. My underlying aim at the moment is to understand the Bluetooth communication process by sending and receiving back messages via a Picaxe module.
 

AllyCat

Senior Member
Hi,

With one HC-05 or two? And if two, then what is handling the loopback? If only one, then you can only expect responses to any of the appropriate AT commands.

AFAIK neither the 08M2 (using SERIN/OUT) nor the HC-05 support Full Duplex operation (i.e. transmit and receive at the same time) so the expected "data flow" (timing) can be crucial. Also, it would be much better to copy and show the EXACT test code that you're using (within [code ] .. [/code] tags) and the responses cut directly from the Terminal Output. It's far too easy to confuse 0 / O , 1 / l , : / ; , " / '' , ( / { / [ , etc. (i.e. each side of the / symbol), which can have totally different functions in PICaxe Basic. Also the default/options set up in the Program Editor can make a significant difference (and of course PE5 or PE6).

Cheers, Alan.
 

Goeytex

Senior Member
@micrometal

You seem to have several misconceptions as to how Bluetooth communication works and what a Picaxe is capable of.

The first step is to configure the HC-05 using "AT" Commands. You should start here. If you cannot issue AT commands and get valid responses then there is no point going any further until you can do so. A Picaxe is not required to do this.

You will need an USB/TTL Adapter (other than an AXE027) unless you can invert both serial lines using transistors or something like a 74HC14 inverter. The TX from the USB/TTL adapter will need to be level shifted down to 3.3V unless it is already 3.3V.

I suggest getting a CP2102 based adapter as these generally use 3.3V logic levels and will not need inversion.

25207

Follow the diagram and instructions above, then get back to us when the HC-05 is blinking slowly.

When in AT command mode a terminal application is used to send and receive configuration data to and from the HC-05. The Terminal must be configured to use the com port used by the CP2102 Adapter. If unsure as to what com port to use, open Device Manager/Ports to see the available ports.

The default baud rate is 38400 for the HC-05. So set the baud rate in the Terminal to 38400.
The Terminal must be configured to add CR/LF to the end of each data packet. If using PE6 Terminal, open the terminal then settings then put a check next to " Add CR/LF on send".

You should now be able to type AT into the send window and get an "OK" Response from the HC-05
 
Last edited:

PieM

Senior Member
Yes - I am. My underlying aim at the moment is to understand the Bluetooth communication process by sending and receiving back messages via a Picaxe module.
I think it would be better to test with smartphone and Bluetooth Terminal HC-05 Pro (free on Play store) . One transmiter (picaxe / Phone) and one receiver (Phone /Picaxe)
 

micrometal

New Member
Thanks @alleycat and @Goeytex and @PieM. I am getting overwhelmed with advice here, so lets have a reset.

First of all, when I started looking at Bluetooth (several months ago) things went fairly well straight out of the box. I could send short strings of bytes from an Android 'phone to an 08M2 and get the same bytes back, but always with a couple of spurious bytes included. In trying to fix that problem I did something - I don't know what - and I lost control. I did some other stuff for a while, but now I have come back to try to sort things out. I thought I could do that using a Picaxe but now I understand, as Goeytex says, that there is a better way. I have ordered a CP2102 and when it arrives I will use it to look at the HC-05 in AT mode. I was previously aware of AT mode, but not of CP2102. I have been watching the videos and reading articles on the web - the ones that don't assume you are using an a-----o.

Here, for @AllyCat, is what I have been working with up to now. I am using a single 08M2 and, for the purposes of this thread, the coding listed in post #1 (except when I have tried @hippy's code samples). I have at times modified the code in post #1 with different baud rates. My aim was to receive a (single) incoming character and then, after a delay, send it back - effectively a wrap test but using the 08M2 to do the wrapping. I thought that once I could do that I could build up to proper communication. I am using an Android 'phone app to send and receive to and from the HC-05; this works perfectly when I do a hard-wire wrap test so I know it is good. It is the same software that I was using right at the beginning when I sucessfully exchanged strings.

I hope to be back in a few days.
 

hippy

Technical Support
Staff member
It would help to detail exactly what you do have in its entirety so people can figure it out.
Not quite sure what you are asking here. My setup is ultra-simple. The HC-05 TXD pin goes directly to 08M2 C.1 and the 08M2 C.4 pin goes to the voltage divider (two 3.3k resistors in parallel with another 3.3k in series) with the mid-point connected to HS-05 RXD pin. That's it.
It was more; what else do you have, what is sending data to this HC-05, what is receiving what it sends out..

It is fair enough to have an HC-05 receiving data, the 08M2 trying to show what it receives; but what is sending data to it, and in what form ?

Data for the HC-05 has to come from somewhere and that hadn't been described as far as I could see.
 

micrometal

New Member
I hope to be back in a few days. ...
Well, it has been more than a few days but I felt that I should finish off this thread with the end of the story which I reached, I think, just a few minutes ago.

When the CP2102 module arrived (along with a second HC-05 module) from my usual UK supplier I discovered that neither HC-05 would respond to the CP2102. That was disappointing and I left things there for a while. Recently I bought another HC-05 from a different source and this one works perfectly. I have managed since to get unreliable communication with the two original HC-05s, but really they appear to be duds.
 

johndo

Member
Try and establish a solid connection with both bluetooth modules first. Connect 2 modules to the same computer via some usb/ttl converters, pair them and use a program like termite to communicate with them and set them up. Once you have established that you can communicate with the modules, then move on to the picaxe side of things...And use 2 HC-05's together.
 

micrometal

New Member
When I try talking to these HC-05 modules with a USB/TTL converter I don't even get a response to an "AT" command. Yet they seem to work well in a hard wire wrap test. It is as if they speak a dialect of "serial" that only they understand. But again, in certain circumstances (that I cannot define) they intermittently transmit data from an 08M2.
 

Goeytex

Senior Member
Some basic information:

1) HC-05 Modules are Factory set to 38400 Baud. Baud can only be changed in AT Mode
2) For 2 modules to communicate with each other one must be Master modes and the other Slave mode. Mode is set in "AT mode"
3) CP2102 Modules use 3.3V Logic levels. Therefore no voltage divider is required or wanted when using a CP2102 adapter.

If you cannot enter AT Mode, then you cannot correctly set up the HC-05 modules to connect with each other as one MUST be set to slave. So the first thing needed is to be able to enter AT mode and configure the HC-05 modules.

1) Connect the CP2102 to one of the HC-05s as shown in the diagram below. Leave the 5V out from the CP2102 disconnected.
2) Press and hold the button on the HC-05 module.
3) While the Button is held down, connect the 5V from CP2102 to the HC-05. Then release the button.
The LED on the HC-05 should now blink slowly (every 2 seconds) indicating that it is in AT mode
4) Open the PE6 Terminal and set it to the correct port for the CP2102 Module. Set the Baud rate to 38400
5) In the input box at the bottom type in AT, then press Send. The Module should reply with OK

If the module does not reply with "OK", then try each baud rate starting at 1200 until you get an OK response.

When you are able to enter AT mode, let us know

My apologies for repeating the same thing again. I see that I previoulsy posted most of this stuff.

On thing to consider is that on some CP2102 modules the 3.3V TX output is rather noisy. This can be eliminated by connecting a 10uF capacitor from the CP2102 - 3.3V pin to ground.


25291
 
Last edited:

micrometal

New Member
My apologies for repeating the same thing again. I see that I previoulsy posted most of this stuff.
@Goeytex - I feel bad about you apologising when you are being so helpful, but I must now apologise myself for repetition ...

Let me be clear, I have three HC-05 modules ...

Module A : About a year old and with a wide experience of life, including many attempts to establish and/or possibly change its baud rate.
Module B : About two months old, from same source as A, but still virtually as it came out of the box.
Module C : About two weeks old, from a different source.

Module C follows the text book exactly, both on a USB/TTL adapter and in the Picaxe testbed circuit that I have been using. It is a total success. That makes me feel happy that I am interpreting the information that I get from the Picaxe manuals and the web and YouTube and this forum correctly. And also it confirms that the USB/TTL adaptor is okay.

Modules A and B behave in identical ways. I followed @Goeytex instructions exactly but failed at Step (3). When I attach the 5v line the modules continue to blink fast (pairing mode). However, if I connect the second (5v) line before plugging the adapter into the PC then the LED immediately blinks slowly (paired mode). And I tried every baud rate (not for the first time) from 110 to 921600 without getting any response.

Module C performs perfectly on the USB adaptor. It communicates at the expected 38400 baud rate in AT mode and reports its (factory set) baud rate of 9600 as one would expect.

Moving on to @PhilHornby comment ...

So at some point, you must have had at least one of these modules in "Command/AT mode", and paired it with something in the past...
Yes, modules A and B have always paired quite readily and in some circumstances operate, after a fashion, at 9600 baud, but that is their factory setting - I have never succeeded in establishing AT mode. My current 08M2 test program waits for a (single) incoming ASCII character and then responds by sending that character followed by two ASCII strings of half-a-dozen characters in separate SEROUT commands. Typically the first attempt fails completely, the second attempt succeeds, and further attempts degrade until only the last few characters are being received. Putting short pauses (20-50 msec) between the SEROUT commands tends to be an improvement. But remember, module C, in exactly the same environment, always transmits the complete concatenated string perfectly. There is nothing seriously wrong with the 08M2 code.

So although I am baffled, I do have a way forward.
 

PhilHornby

Senior Member
Moving on to @PhilHornby comment ...
Yes, modules A and B have always paired quite readily and in some circumstances operate, after a fashion, at 9600 baud, but that is their factory setting - I have never succeeded in establishing AT mode.
There's something not quite right here...

First of all, "Pairing" is the act of exchanging security keys and is only done once. The establishment of the actual connection is called "Linking" and is normally set to occur automatically (when the module is enabled), though it can be set as a manual operation.

Even if two HC-05's have the same default PIN ("1234?"), I believe you still have to go through the "Pairing" process. One of them must also be set to "Master mode", since they would both have been Slaves originally. Both(?) these operations require successfully entering "Command/AT mode" ... which implies they've worked as advertised at some point.

But remember, module C, in exactly the same environment, always transmits the complete concatenated string perfectly.
If I was you, I would throw modules A and B away o_O
(I'm just about to do to same with an ESP8266-01 ... which just doesn't want to behave like any of the others. Defeatist, I know - but you have to pick your battles!)
 

PhilHornby

Senior Member
Or have I read this all wrong ...

Are you trying to get HC-05 modules to talk to one another ... or some other device?

Is there ever more than one HC-05 up and running in Master mode? (From experience, I know that stops any slaves from linking).
 

Goeytex

Senior Member
It seems to me that the first two HC-05/06 (A and B) are duds or they are counterfeits/fakes. Or could they possibly have been damaged by an incorrect voltage level applied to the RX pin.

In any case let's be clear ... What is the end goal ?

Is it to connect a single Picaxe to a Smart Phone ? ... Or is it to connect 2 Picaxe's via Bluetooth?

If it is to connect a Picaxe to a Smart Phone then as I understand it you have one Bluetooth module ( C) that works without error. IF this is the case then everything seems to point to A and B being bad/blown/or fakes given that neither A nor B will enter AT mode in the normal manner.

Why not post some clear photos of your Bluetooth modules as well as a photo of your setup/breadboard or whatever way you are wiring them up.

Honestly at this point I have no clue as to what you are doing.
 
Last edited:

micrometal

New Member
Or have I read this all wrong ...
Honestly at this point I have no clue as to what you are doing.
Yes - I can understand those comments. This is a long and drawn out thread spread out over months. It is all here somewhere, but even I have had to restate the story at times just to make the posts readable. Also, whenever anyone takes the trouble to post something I feel obliged to respond, even though it may not move anything forward.

My aim is to communicate between a Picaxe and an Android 'phone via a (slave mode) HC-05. I am writing the code at both ends, and I am now achieving what I want with Module C. The kindest thing that I can say about modules A and B is that they are different, but they are heading for the scrap bin anyway. (Although with a wire wrap they would maybe make good Bluetooth repeaters? - no, just joking).

My post #28 was meant to be a summing up, but I discovered again that everyone here likes to help if they can. Thank you for your earnest responses, but I consider this thread closed.
 
Top