Data integrity while interfacing HC-05 bluetooth module

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

I am planning to interface HC-05 module to Atmega328P. I have uC1 --> Bluetooth Module1 --> Bluetooth Module2 --> uC2.

Simple commands work fine and no issues.

Suppose if I send large data, do I need to consider specific protocol involving Checksum or CRC?

I hope Bluetooth Module1 to Module 2 takes care of data integrity between them. So problem could arise in communication between uCs and bluetooth modules over UART. So my question is do I really need to implement CRC/Checksum for maintaining data integrity while transmitting data from uC1 to uC2 over bluetooth?

In case protocol is needed, I thought of implementing the protocol containing Start Byte, Pay load bytes, CRC or Checksum and two end bytes (something similar to MODBUS protocol). Any other better mechanism and standard way of accomplishing this?

 

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

You may not need CRC if data is "secure" but you do presumably need some kind of "protocol" to define how the commands and data you transfer is laid out. Also consider things like uC2 being switched on part way through a transmission from uC1. Is it going to accidentally mis-read some part of a transmitted data packet as a new command perhaps? SO maybe you need to prefix each command with some kind of recognizable "cookie" so yo ualways send 0xAA,0x55,0xNN when you actually want to send command 0xNN

 

Luckily for you, you are not the first to face this - there must be 1,000s of defined protocols for making two stations able to exchange data. So maybe research something that is already proven/reliable. In fact when you think about it The old Hayes modem "ATxxx" command set is a lot like my 0xAA,0x55 (that I just made up as an example) only they chose to prefix with 'A', 'T'

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

joneewheelock wrote:
I hope Bluetooth Module1 to Module 2 takes care of data integrity between them

Yes, it should.

 

But one thing you need to consider carefully is what happens if when the link drops in the middle of transmission?

 

You need a way to know whether  the entire message was received - and a plan for what to do when it isn't ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You may not need CRC if data is "secure"

If I am not mistaken, CRC is is used even for error detection. As per https://en.wikipedia.org/wiki/Cyclic_redundancy_check

cyclic redundancy check (CRC) is an error-detecting code commonly used in digital networks and storage devices to detect accidental changes to raw data. 

So either checksum or CRC is needed to error check the data. 

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

What I'm saying is that if the Bluetooth data channel already provides end to end data security (presumably by CRC, ECC, etc) then you may not need that. Think of the internet and TCP/IP for example. When you open a TCP data channel to  a distant server the protocol used usually does not need to worry about things like noise, error correction, data ordering and stuff like that because it's already handled in the underlying layers. I'm guessing Bluetooth is modelled on that. But like TCP protocols like FTP, SMTP, POP3, etc you probably do need SOME kind of protocol to decide how to frame/packetize data. You can't just open the channel  and send and endless stream of data bytes and expect the other end to be able to interpret what's going on.

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

I think there may be some confusion on the usage of the word "security" here?

 

clawson is using it in the general sense of  being "secure" against data loss or corruption - not in the sense of encryption, authentication, privacy, etc, etc ?

 

(although BT does give you some of that stuff, too).

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fair enough. I think I will use MODBUS RTU over Bluetooth (ultimately it is MODBUS RTU over UART as for as AVR is concerned). I got code from Kartman at https://www.avrfreaks.net/forum/basic-modbus-rtu-implementation-avr#comment-2488716 but that was initial version I guess. Need to see if any latest version is available.

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

Why do you want to use Modbus? Especially when you speak of sending large data?

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

Initially I do not need to send large data. In any case I would like to study the implementation of MODBUS master and slave code for some other purpose.

I already implemented my own protocol (1 or 2  Start bytes, address (to support multiple slave  if any), length (or end bytes), payload, CRC, end bytes (In the absence of length field). I need to try this with android phone.