sending data efficiently between 2 bluetooth modules via arduino - bluetooth

I'm able to pair and send data no problem, but i've come across an issue where the receiver will receive and interpret the data byte by byte instead of a string of bytes. This is a problem because we are the data sent are values read from a potentiometer. If the potentiometer changes too fast, the receiver isnt able to read the changes fast enough. Any suggestions on how to do this?
My current setup is an HC-05 paired with a HC-06, powered by 2 arduino micros. Baud rate of sender is 30400 and receiver 9600(i have no idea why 30400 wont work on the receiver).

Having different Baud Rates of two units communicating using a serial interface is usually not a good idea. Why can't you set the sender baud rate to 9600? If you can, that's where I recommend you start. Also, if you could post your code, that would be great.

Related

Decoding Bluetooth signal and packets using GnuRadio

I am currently working on a project which aim to detect Bluetooth and decode Bluetooth packets (I use a Hack RF One to make the detection). I have made a Gnuradio Flowgraph in order to demodulate Bluetooth signal and I am trying to decode visualy the packets by searching a Bluetooth frame on a binary file.
Unfortunately, I didn't succeed to recover a clear view of the Bluetooth signal. To be precise, I am pretty sure that I detect Bluetooth on my sinks but when sending this to a Clock Recovery + Binary Slicer blocks, I am unable to recover interresting data in the binary file (especially the MAC adress of the sending device, which is part of the a Bluetooth packet). Moreover, I would like to know what type of network layer (physical, transport, baseband...) is intercepted in this type of process. In my case, I aim to intercept baseband layer packets.
Additionaly, I am interrested in knowing how to use the gr-bluetooth because I can't find a lot of documentation concerning this block. I think this can be interresting for the development of my project.
Could you please, give me your view, opinion about this problem ? I am stucked at this stage without knowing the exact origin of my issue. (Here is my flowgraph GnuRadio_Flowgraph and a screenshot of one of my Bluetooth detection Detected signal at 2.402GHz).
Thank you very much,
You probably need an ubertooth instead https://www.sparkfun.com/products/10573
I read that the bluetooth frequency skipping is spread wider than the HackRF can read, so at-best, you're going to miss 75% of frames if you only have one hackrf connected.

How does BLE handle sending multiple packets per inteval with a 1-bit sequence number?

As far as I unterstand BLE uses two 1-bit fields for applying sequence numbers to packets (SN, NESN). From my (admittedly basic) knowledge about (wireless) communication a 1-bit sequence number is perfectly fine as long as a sender does not continue sending data until the last message is acknowledged by the receiver.
Because of that it is trivial to understand how BLE works with a one-packet-per-interval scheme. However BLE allows multiple packets in a single connection interval. So far I couldn't find any information on how this scenario is handled without allocating more bits for larger sequence numbers.
Any pointers in the right direction on where I'm going wrong or where I can read up on this would be appreciated.

Arduino Random Characters sent to Bluetooth TX during Code Upload

When I upload code to my Arduino while the TX and RX pins are connected to my HC-05 module, a bunch of random characters are sent to the TX buffer, and when I connect to a device, those characters are sent and mess up communication. Is there a way that I can clear this buffer after uploading the code? I've just been disconnecting the wires whenever I upload, but I'd like to find an easier way. Thanks!
Well, if you use a serial port to both send data and the program of course you will see it on the other side of the BT... Possible solutions:
disconnect the BT module every time you want to program the Arduino
shut down the other BT device (or just disconnect it) when you have to program the Arduino
shut down the HC-05 (or keep it in reset state) until the arduino says that it is communicating (so use a GPIO to control the reset pin or a transistor to power the BT on at the beginning of the program)
use a 3-state driver between the HC-05 and the Arduino serial ports (one driver for TX and one for RX) and activate its outputs at the beginning of the arduino program.
I don't like djUniversal's solution because you cannot control what the PC transmits; if, for instance, you decide to use the byte 0xAA to signal the start of the transmission then if the PC sends 0xAA the other device thinks that the Arduino is transmitting. Choosing longer bytes sequences helps, because the sequence becomes less probable, but.....
Moreover you have to send it at EVERY command, not just at the beginning, because you have to reset the arduino to program it (and so the other device is not aware of WHEN to stop considering the data).
The only other way around it is to send a header of maybe a couple of bytes each time to send a message. The other program can wait for these characters before it starts to take commands. Until those characters are read from the buffer you would just do a Serial.read() loop to get rid of the garbage.
Also, if garbage characters are going to screw up your program really badly you might want to think about creating some kind of crude checksum also to confirm the correct transmission.
Need help coding? Let me know.

Read Data from unknown Bluetooth Device while communicating

I am trying to figure out how the FORA d15b blood pressure monitoring system communicates via Bluetooth. I want to be able to eventually write an Android app that can receive blood pressure data from the device.
More specifically, I want to know the exact data to send to the device in order to request blood pressure information. I also want to know the data that the device sends out. However, I don't even know the format of the data being sent/received.
I know that FORA has a PC app that can communicate with the d15b device via Bluetooth but I don't know what information its sending/receiving over Bluetooth, and that's what I want to know.
Here is Bluetooth information I know about the d15b device:
Bluetooth Carrier Frequency: 2400MHz to 2483.5MHz
Bluetooth Modulation Method: GFSK, 1Mbps, 0.5BT Gaussian
Transmission Power: +3dBm to –20dBm; Power control 4 stage
Receiving Signal Range: -88dBm to -20 dBm
Receiver IF Frequency: 1.5MHz center frequency
Maximum Data Rate: Asynchronous:723.2kbps/57.6kbps;
Synchronous: 433.9kbps/433.9kbps
I'm struggling to even find a starting point. Any help is appreciated! Thanks in advance.
I am familiar with C, Java, and Arduino if that helps at all...
NOTE:
Unfortunately, I am new to Bluetooth. After doing some research, I am still pretty clueless on how to solve this problem. In the title, I say unknown Bluetooth device because I just want to be able to read what I/O of an unknown Bluetooth device, which in my case happens to be the d15b that I know nothing about. Sorry if the question has been addressed already or if this is an inappropriate place to post this question. I wasn't sure.
Bluetooth data is encrypted. So it's not possible to hack it easily.
Forget it.

how to prove working of RS 232 full modem,RS 422 working PC to PC and LOOP BACK

Hello there I am a newbie trying to prove the working of RS 232 Full modem and also one RS 422( RX,TX,RTS,CTS)
These 2 ports are on a custom designed board and I need to prove they are working.
I am able to confirm the working at register level but I need to prove the working using softwares like Minicom or any other custom program.
How can I prove the working of these ports from one PC to a different PC using DB 9 connections and LOOP BACK too
Can someone help me with this? Do I need to use any extra hardware to prove the working of this in Linux?
The most common type of serial port test is probably a loopback test. Create a test fixture that connects output pins of the port to the input pins (TX->RX, RTS->CTS, etc). If you do not have matching input pins for every output pin, you will need to do a three-way connection.
After you create the loopback, you will need to write software that exercises the pins. If TX and RX are connected, you can send a byte and verify that it was echoed back. For the control pins, toggle them and make sure the other side of the connection saw the transition. Make sure you exercise every pin of the serial port.
Note that you should run a TX->RX data loopback at multiple baud rates. It is possible for there to be a signal integrity issue in the design that only shows up at higher bauds rates. It is also possible for there to be a bad signal connection on the board that is masked by inductance and capacitance at higher baud rates. Therefore, it is a good idea to run a data loopback at the slowest baud rate, the fastest baud rate, and 1-2 in the middle.
Another thing you should do is a baud rate accuracy test. This will prove the clock driving the UART is running at the right frequency, and being divided properly. Transmit X amount of bytes at a certain baud rate and verify they arrived in the expected amount of time. To get an accurate number, you will need to bypass any buffering in the OS serial port driver (e.g. use direct register I/O), and make sure to accommodate for any start/stop bit overhead (see comments below).
However, a loopback test is not exhaustive. It only proves the device can talk to itself. The device may still have some flaw (e.g. voltage levels) that cannot be detected locally. So, you should also run some tests with external hardware. Cable your board to another system and run a test (e.g. with minicom). Make sure they can talk to each other.
Even an external communication test can miss something. You can still have poor signal quality from your board, but it happens to be good enough for the other device. To accurately verify the signal quality/timing, you need an oscilloscope.
While you are running communication tests, connect the scope probes to the various signals and verify the signal integrity. Make sure that voltage levels are valid, that you see clean low/high bit transitions, and that the timing of the data pin appears correct for the specified baud rate. (A scope can be a more accurate way to measure baud rate than the software-based method described earlier.)

Resources