Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
Call for discussion on Bluetooth HC-05 module
#bluetooth
Anne Ranch
I realize this is not primary purpose of this forum, however, recent discussion of HC-05 Bluetooth module "issue" prompted me to post this.
( I am not in favor of hijacking somebody else thread ) . If it is NOT appropriate to talk about HC_05 and Bluetooth in general, please say so and I will not continue in this thread. Thanks |
William Smith
IMHO it's appropriate, as it seems to be a common 'accessory' that people are interested in.
toggle quoted message
Show quoted text
If anyone is annoyed by it, they have a couple of options at the bottom of every single message posted to this forum to mute this topic, mute this hashtag, or unsubscribe. 73, Willie N1JBJ On Jul 20, 2021, at 9:46 AM, Anne Ranch <anneranch2442@...> wrote: |
Anne Ranch
OK, I shall proceed.
Let me say that I am unable to find HC-05 specification which will actually describe 1. what does the button on my HC_05 do. I realize there are many versions of HC-05 and I am talking abut the one WITH the button - the one I have. 2. My HC_05 ONLY connection is to power - no other connections. I am currently trying to decipher the RED LED functions ON:LY. a. Upon applying power I get very short and very fast flashing of the LED b. After that and MOST of the time the LED is flashing in fast rate c. BUT sometime it will flash in slow rate The doc I found describe 1 Hz or 2 Hz "flashing" and it should be observable on pin x - I have not try that. However - I am not sure if human eye can even see DIFFERENCE between 1 Hz and 2 Hz. 3. My OS - Linux Ubuntu can "discover" the HC-05. Term "discovery /discoverable " Is commonly used describing Bluetooth process to "find" or enabling the Bluetooth device to be found. 4. I can instruct OS to "connect" to HC-05 - it does do that but immediately "disconnects" . ( The process of selecting RF channels MAY be discussed later ) 5. After spending many hours , by choice , coding software I came to a conclusion that "Bluetooth devices must be PAIRED " before they can be connected. Makes sense to me, however I do not get how device can be "discovered " and NOT paired. My OS shows HC_05 as "paired ". |
toggle quoted message
Show quoted text
On Tue, 20 Jul 2021 at 16:56, Anne Ranch <anneranch2442@...> wrote:
OK, I shall proceed. |
William Smith
OK, this is the problem with Chinese cloned parts, anything popular is going to get ripped off, cloned till it's no longer recognizable, and sold for one cent less than the other guys, which is going to drive a race to the bottom (of quality, documentation, repeatability, everything else). Welcome to the world of $10 parts. Not being snarky, but if you want to pay $50 for a BlueTooth interface, it'll come with support, documentation, etc. [I don't want to pay $50 either, and I'm comfortable with the 'self-support' options, which include community support forums like this one.]
toggle quoted message
Show quoted text
As a zeroth step, please tell us exactly which device you have, where you bought it, and when. These things change all the time, but at least we'll have a starting point for helping you. There are dozens of HC05 devices just on Amazon, some of which have buttons and some of which don't. Saying "This one, the one I'm holding in my hand" is less useful to us than a URL. First, take a step back and take one piece at a time. You have a nanoVNA, which works. Put it aside for now, that's not your problem. Power up the BT module and see what it does. While the difference between 1Hz and 2Hz might be difficult to distinguish, try counting off seconds (traditionally "one one thousand, two one thousand, three one thousand") and see how many flashes you get in one second. It'll be close to one or close to two. For your given OS (Ubuntu?), figure out how BT works. Get a BT device (fully functional button or headset or something) and figure out how to discover it, then pair it, then use it, then unpair it, and see if it's discoverable again. Then for this device, discover it, pair it, and see if the flashing changes from fast to slow. If so, it means the flashing tells you your paired state. I'm looking at one device on Amazon that goes into AT mode when you push the button, if yours is the same, don't do that. Most BT devices go into pairing mode on a long press of the one true button, if yours is one of those, then try that. Connect Tx to Rx on the BT device, and see if sending ASCII characters at it causes them to be echoed back to you. This has been previously suggested on this list. Connect a USB to TTL Serial adapter to the Tx and Rx pins, press the button to put it in AT mode (if applicable), and change the baud rate to something compatible with your nanoVNA. Etc, etc, etc. One step at a time, make sure it's working and you understand it's operation at each step before proceeding. 73, Willie N1JBJ On Jul 20, 2021, at 10:56 AM, Anne Ranch <anneranch2442@...> wrote: |
On Jul 20, 2021 15:46, Anne Ranch <anneranch2442@...> wrote:
|
Anne Ranch
Thanks for replies, even the "funny one".
Usual response - don't quit you day job.... Now for real... Murphy said "it works better when you plug it in " and that is MY starting point. I usually troubleshot from START to KNOWN result and if I get no KNOWN result I just back down. I also start with an assumption that the device will respond to START condition. The assumption here - from other similar devices experience - the LED is an indicator , the question posted was - what kind of indicator. START - plug if in - power ONLY RESULT - LED lights up SUCCESS Now - the above SUCCESS needs to be further analyzed . 1. Is in ONLY reacting to power ? 2. Will it supply actual state when probed by software ? Still - no need to have anything wired BUT the power, hence NOT physically connected to other devices. Now lets do this Use OS to see what Bluetooth status is as far as OS goes 1. Device is identified as "HC-05" and state is "Not setup" 2. Clicking on "not set up" Request for ID is made 3. Standard , default, HC_05 , even Chinese ID is "1234" 4. After "Confirm" LED off for few seconds State "Connected" State "Disconnected " LED flashes in about 2 seconds intervals Any comments on that sequence? The fast flashing has not be been reliably duplicated. PS Off topic Chinese may not play fair, however, if they deliberately make junk, as implied by comments, what makes anybody think they are that stupid and will be able to stay in business ? I distinctly recall drill bits , made in another county , which you could not drill holes in cottage cheese with ... That country no longer makes them... |
Did they run out of cottage cheese?
toggle quoted message
Show quoted text
On Tuesday, July 20, 2021, 12:43:34 p.m. EDT, Anne Ranch <anneranch2442@...> wrote:
I distinctly recall drill bits , made in another county , which you? could not drill holes in cottage cheese with ... That country no longer makes them... |
William Smith
Now I'm confused, earier in the thread you said:
/* My OS shows HC_05 as "paired ".*/ Now you are saying: /* State "Disconnected "*/ That one over there, the one I'm pointing at, that one should work just fine. 73, Willie N1JBJ On Jul 20, 2021, at 12:43 PM, Anne Ranch <anneranch2442@...> wrote: |
William Smith
Anne,
toggle quoted message
Show quoted text
You sent us a pointer to the local copy of your manual for some device, can you either send a pointer to where you got it online, or send the actual PDF file, assuming it's not too big? 73, Willie N1JBJ On Jul 20, 2021, at 4:19 PM, Anne Ranch <anneranch2442@...> wrote: |
William,
toggle quoted message
Show quoted text
Try: Don, K5DW On Jul 20, 2021, at 4:11 PM, William Smith <w_smith@...> wrote: |
Anne Ranch
Sorry for the wrong link, senior moment.
Just been reaading the mail on th eorignal HC-05 "problem". One poster made a comment on Windoze response - "Coupled" . Never encountered such term in Bluetooth or Linux. If true, talking about making -up own terminology . Now this is little premature to mention, I like to get the hardware questions sorted out first , but 1. in the other tread they mentioned receiving unwanted characters or working at specific baud rate only my guess it still goes back to understanding the serial communication protocol - not only baud rate but start / stop , parity etc. 2. as far as having tx -rx lines reversed in nanoVNA - could that be done in software much easier than in hardware ? a question to the author of the software - will ask much later |
On Wed, Jul 21, 2021 at 06:16 AM, Anne Ranch wrote:
They are NOT reversed, TX always means output and RX is always input - you should never connect output to output (possible damage) and input to input. |
On 7/20/21 9:16 PM, Anne Ranch wrote:
Sorry for the wrong link, senior moment.For an interface that is so simple at some levels, over the past 50 years, I have had more problems with serial interfaces than any other.? Mostly because there's myriad ways its implemented and options - speed, start/stop/parity - flow control - pinouts - actual voltage levels needed. 2. as far as having tx -rx lines reversed in nanoVNA - could that be done in software much easier than in hardware ?I don't know about that specific microcontroller, but in most of the others I've worked with, the pin functions are fixed.? You might be able to make it a SPI interface, or GPIO pins, instead of UART in/out, but that assignment is fixed. Section 3.17 describes the USARTs (4 of them!) Table 14 shows the pin assignments - 30,31 (on pdf page 41) |
2. as far as having tx -rx lines reversed in nanoVNA - could that be done in software much easier than in hardware ?I'm probably stupid, but for you Tx and Rx these are just labels next to contacts ... just labels, and you propose to programmatically change their meaning simply because you do not understand what it is Great idea. |
William Smith
I wouldn't go that far. 8*)
toggle quoted message
Show quoted text
Sure, you _can_ assign I/O pins in software. However, that leads down the rathole of _both_ sides having to programmatically assign pins of Tx and Rx, and have potentially different meanings for each side, and now we've got four arrangements of software switch in addition to what wire goes where. At the end of the day, we only have to figure out that _this_ hardware pin is an input, and should be connected to the output pin from the other side, and we only have to figure it out _once_, not every time someone changes some stuff in software, or the device gets factory reset, or something. And then there's the UI around how do I tell the software what pin I want to be the input and what one I want to be the output, and what I want to label them (Tx, Rx, Input, Output, SerialTTLtoTheOtherSide, SerialTTLfromtheOtherSide, etc), and how I even tell the software those things without connecting hardware to it and communicating with it, and if I do that I'm done! 73, Willie N1JBJ On Jul 21, 2021, at 9:56 AM, DiSlord <dislordlive@...> wrote: |
serial interface can be implemented in software mode, just use pin bitbang. But this mode slow, need lot or CPU resources (all tx, rx time need control this pins)
you can use software mode only if you CPU not do anything else, only read and send data (on slow speed), and this really stupid idea not use hardware. Most cpu have hardware serial modules, not possible select any wanted pin for it. |
On 7/21/21 7:32 AM, DiSlord wrote:
serial interface can be implemented in software mode, just use pin bitbang. But this mode slow, need lot or CPU resources (all tx, rx time need control this pins)Exactly.. for the particular microcontroller, USART1 connects to those pins, and no others. In a "perfect world" there would be a detailed interface control document that says what Tx and Rx (in this specific case) means, what the voltages are, what the currents are, timing parameters, control registers, etc.? For now, though, it's left to the user to read and understand the schematic, and potentially, the part datasheet, to get all that info. That's why it costs $50 and not $5000 <grin> I've gone down the rathole of lots of configuration options, and it turns out that a) most of them are never used b) it takes more work to explain them, and have configuration files, than to just not make it configurable. One nice point here is that there are open source versions of the firmware, so if you're "ambitious" and "motivated" you are "free" (in the speech, not the beer, sense) to implement something else. I could imagine someone implementing an RS485 style multidrop interface to use multiple VNAs on one control line, and not having to change the board layout. |
to navigate to use esc to dismiss