Is BT a data or serial device?

Go To Last Post
26 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not really sure where to ask this and it is not about a specific chip but I'm using BT in my projects and I work with AVR chips. I can send AT commands to my HC-05 BT device with my atmega8 using uart but I'm confused on how things work.

 

After the AT commands are sent I can just send uart strings and I see that on the other side. but I want to send data not characters ? So I figured I could send 0-255. Well first off the Uart will not allow 0, it gets all mad at me, so I reserve 130 as zero. The is seems the receiving end is signed so there is the conversion issue but no big deal. I also need a termination charter so now I need to reserve another. Now I'm thinking this was a bad idea and maybe I need to send strings like '0x00' ...'0xff' but that is going to take a long time to send 64 bytes for example. I'm guessing there is a standard or accepted way of doing this?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What BT device are you using?

Most BT device have a transparent data mode and a command mode.

It sounds like you are in command mode and the BT (modem) is trying to find command with in your data stream, check your doc on how enter data mode and exit back to command mode.

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bluetooth typically uses Profiles to define the data stream.

 

If your BT devise are configured to act as simple wireless UARTs then data transmission after Reset, Discovery, Bonding, and SPPConnecting is straightforward.

 

If your BT HW isn't running as a simple UART then you need more data on how to send your data, or better yet, switch HW.

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 but I want to send data not characters ?   

Find out what the mode changing codes are & avoid those...however, then you don't have true transparency to arbitrary binary data...So you can translate/packetize, in some manner, your binary data, such that a mode changing command is never unintentionally given.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If your BT devise are configured to act as simple wireless UARTs then data transmission after Reset, Discovery, Bonding, and SPPConnecting is straightforward.

 Ok so there is a mode to enter, I do not see it in the data sheet or the tons of write ups?

 

This is an extremely common device. No one here has heard of the HC-05  and HC-06 ? They are often both used in slave to slave when it is not important to have a server. It uses AT commands to set up but those commands also come out from the  connected device. I communicate via UART to it and that just echos over the BT.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

S_K_U_N_X wrote:
This is an extremely common device. No one here has heard of the HC-05  and HC-06 ?

 

Sure, and if you do a search of the site you will find many threads on the devices.

 

Gogole searches also show quite the trove of information.

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sure but that is basically the entire reason for me asking any of this?  I have found a lot of write up on this device, and many examples but they all send characters.  This is not what I'm asking for. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Characters/Data....Same thing.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

itoa converts integers to arrays of characters, ltoa longs to arrays of characters, utoa unsigned integers to arrays of characters, ultoa unsigned long to array of characters, dtostrf double to array of characters.

 

Look in stdlib.h on the avr-libc page:   http://www.nongnu.org/avr-libc/user-manual/modules.html

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you want to be able to send arbitrary binary data & not trip into a command mode, perhaps you need to convert each byte into 2 ascii characters.  However, it appears getting into command mode is instead controlled by a pin...if that is the case you can send any bytwe the same as any other byte.

This link probably has enough info to answer your questions:

http://www.martyncurrey.com/hc-05-with-firmware-2-0-20100601/

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

No, it's just the initial 'AT' that does the commands, but you did bring up a good point, I could always do a 2 byte. That gives me 8 bits for a control mask to signal other things as well, I like that idea. 

 

Also I guess having the module is my main problem because when you said pin 34 I was thinking huh?

I guess this may be the state pin (6)?

 

Last Edited: Mon. Jun 17, 2019 - 12:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The module is nothing more than a BT serial cable.  Whats so difficult?

 

Here:  From the Datasheet, read the first line on the first page:

ftp://imall.iteadstudio.com/Modu...

 

HC-05 module is an easy to use Bluetooth SPP (Serial Port Protocol) module, designed for transparent wireless serial connection setup.

Meaning it does not care what you put through it.  YOu just configure the HC-05 as a master, or a slave.

 

Heres another great hit about the module:

https://alselectro.wordpress.com...

 

So, simply configure the module, and exit the Command state, and off you go one you pair it with another device.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Pin 34 seems to be the button...they soldered a wire on to get full control....you'll have to investigate if that is also header 6/state

 

http://www.martyncurrey.com/hc-05-with-firmware-2-0-20100601/

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

S_K_U_N_X wrote:
Well first off the Uart will not allow 0, it gets all mad at me,
Can you actually define in engineering terms what "not allow" and "gets all mad" actually means in this context ??

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can you actually define in engineering terms what "not allow" and "gets all mad" actually means in this context ??

  My best guess is that the receiver (android) sees 0 as a null and thus crashes the implementation.

 

avrcandies, that helps thx.

 

jgmdesign, the issues was the command state. Your just not following the flow of the topic here, you addressing my original question after the answer was given. In other words we already know what the problem was.

 

 

Thx for all the answers.

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

S_K_U_N_X wrote:
crashes the implementation
Again things like "crashes" don't help us very much to understand in what way the system fails. Can you show some code, say what you expect to happen and what actually happens. Esp. in the case of trying to transmit 0x00.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I understand that but I'm not the android developer as was pretty much told 0's are not going to fly. My weight in this case is not enough to change that. If he posts the issue on stack overflow ill link it ;) But the AVR side is fine, I can send all 0-255 data with no issues. but also keep in mind that the issue here is that the BT chip seems to be in command mode and is echoing all the data to the other BT device. My android developer took the day off so, we wait. 

Last Edited: Mon. Jun 17, 2019 - 02:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's the first thing I've heard about "Android". I thought we were talking about the AVR code that sends the data.

 

If it really is the case that Android cannot handle 0 but you want to send all of 0..255 then you clearly need a translation. One way is binary to ASCII so 12345 becomes "12345" and so on. But it's quite wasteful of data bandwidth. A 2 byte 0..65535 value might becomes 5 bytes (or even more if you need sign characters). Another option is uuendcode which converts 8 bit data to 6 bits and only uses characters in an ASCII range. Three 8bit bytes is 24 bits in total. If you divide that into four lost of 6 bits you end up sending 4 bytes for every 3 bytes of source data.

Last Edited: Mon. Jun 17, 2019 - 03:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well my question was more of a, am I doing this right? Am I missing something.  That more then a problem I need to fix.  

 

 One way is binary to ASCII so 12345 becomes "12345" and so on. But it's quite wasteful of data bandwidth. 

 This is what I meant in my initial post when I said. 

Now I'm thinking this was a bad idea and maybe I need to send strings like '0x00' ...'0xff' but that is going to take a long time to send 64 bytes for example. 

Your other idea is a fine idea along with the sending two bytes for one byte posted earlier. My colleague suggested delimiters. I guess that could work but I favor the two byte or the trick you mentioned.  I guess from my perspective I was hoping there was an AT command for sending data.  "AT+sendd0d1d2d3d4d5d.... Though it arrears I am limited to sending via the UART one charter at a time (or a string of) and as many point out data is data. The Android is the issue in this case and maybe the entire issue here. Strange things are happening. 

 

examples.

 

1) I can not send a 0 as it has issues with that.

2) I need an end character and some times it sees this end charter in the string where it does not exist. 

3) Data sends over randomly. It changes when I send the same data. If I send 1,2,3,4,5 I get 1,2,3,4,120 or 1,2,3,120,4.

 

Not being able to develop on the android side is certainly not helping. I'm being asked to send the data as strings but from a bandwidth point of view that is horribly wasteful. Though I'm in that battle of well, it works with other BT device.... So it's a question of am I doing it right and as far a I can tell, I am. I think the android developer needs to learn how to handle data but he says I'm doing it just like everyone else....Yet he says thigns like maybe I should convert decimal to hex... I'm thinking.. wow, this is what I'm working with?

 

Anyways, not looking for help there, just wanted to make sure I was not over looking something here. I assumed In practices there is nothing wrong with me sending data over UART. A 0 is a 0 is a 'null' and that is that. Maybe more info then was needed at this point but this is the problem I'm dealing with. 

 

I also just notice there are hc-06 and 05's and one or the other his this AT command button on it. I'm going to assume if the button is not pressed or in the case where it is absent there is a pull down resister holding it low. So in all cases it must be in so called data mode. Maybe the AT command I use are echoing on the Android and causes the issues, not sure? More to look in to now.

 

Last Edited: Mon. Jun 17, 2019 - 03:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

S_K_U_N_X wrote:
Not being able to develop on the android side is certainly not helping.
That's for sure because even if you did do something like uuendcode at the sending end you'd need the equivalent uudecode to recover the data at the receiving end so that persumably means developing code for the Android system to depacketize/deocde the data. If you can't change the operation at the Android end then I'm not sure what you could do!

 

For years and years when anyone emailed you a JPEG or something them the way that got from one end to the other across the internet was as MIME/64 data. the JPEG itself was full of binary (0..255 in each byte) but the email servers/clients across the internet that acted as relays to get your message from one end to the other might be very old and out of date and not able to pass very much more than A..Z, 0..9 so that's why the data was MIME/64 encoded at one end (6 bit characters) then passed as plain ASCII, then reconstituted into full 8 bit data on reception.

 

EDIT: the obligatory Wikipedia link:  https://en.wikipedia.org/wiki/Base64

 

However once again this relied on the receiver having code to undo this encoding.

Last Edited: Mon. Jun 17, 2019 - 03:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think uuencode will work and I'm sure there is a library for them android types ;)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh so you are in development control of what runs on the Android? When you said " Not being able to develop on the android side is certainly not helping " did you just mean you are still learning that skill but ultimately you will be able to change the Android based receiver code?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, LOL, let me put this literal then...

 

The guy coding the Android is a pain in the ass millennial, know it all shit heat, that does not understand simple concepts, and thinks his yourtube channel knows everything (thus he does) and I know jack shit.. Trying to help him leads to I know what I'm doing... So I mean I can not even get to the code let a one Debug on it. 

 

I do my part he does his..

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When he says "0's are not going to fly" he probably meant

"the code I copy/pasted from somewhere on the internet doesn't work with 0's" :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The guy coding the Android is a pain in the ass millennial, know it all shit heat, that does not understand simple concepts, and thinks his yourtube channel knows everything

They've been saying that for at least 30 years, it rarely changes. 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When he says "0's are not going to fly" he probably meant

"the code I copy/pasted from somewhere on the internet doesn't work with 0's" :)

 

 

pretty much

Last Edited: Mon. Jun 17, 2019 - 05:56 PM