Characters not properly displayed in serial monitor in arduino - bluetooth

Can anyone tell me why the characters are not getting printed properly in the serial monitor of Arduino? I am pasting the arduino code.
#include <SoftwareSerial.h>
#include <LiquidCrystal.h>
// initialize the library with the numbers of the interface pins
LiquidCrystal lcd(12,11,5,4,3,2);
int bluetoothTx = 15;
int bluetoothRx = 14;
SoftwareSerial bluetooth(bluetoothTx, bluetoothRx);
int incomingByte;
void setup() {
pinMode(53, OUTPUT);
Serial.begin(9600);
lcd.begin(16, 2);
lcd.clear();
bluetooth.begin(115200); // The Bluetooth Mate defaults to 115200bps
delay(320); // IMPORTANT DELAY! (Minimum ~276ms)
bluetooth.print("$$$"); // Enter command mode
delay(15); // IMPORTANT DELAY! (Minimum ~10ms)
bluetooth.println("U,9600,N"); // Temporarily Change the baudrate to 9600, no parity
bluetooth.begin(9600); // Start bluetooth serial at 9600
lcd.print("done setup");
}
void loop()
{
lcd.clear();
Serial.print("in loop");
//Read from bluetooth and write to usb serial
if(bluetooth.available()) {
Serial.print("BT here");
char toSend = (char)bluetooth.read();
Serial.print(toSend);
lcd.print(toSend);
delay(3000);
}delay(3000);
}
Can anyone take a look into it. It does not print the character that I provide instead it prints something else like 'y' with 2 dots on top etc. Tried almost all the available solution.

Your issues could be one of a couple things. First and easiest to check is COMMON GROUND. Did you connect just the RX and TX pins or also the GND (ground) pin? Make sure that the ground from the BT mate is connected to the Arduino ground.
If you have done that, then your issue is with the baud rate. I'm pretty sure that SoftwareSerial can't read at baud rates beyond 57600. Arduino.cc docs say it can read at 115200, but other places say it will only write up to 115200.
To test this, you will either need to change the settings for this on the Bluetooth Mate or use a Mega or Leonardo which will have a hardware serial port (other than the one used for USB) which you should be able to configure for 115200.
If you try it with hardware serial either on a Mega or just using an FTDI or something and the messages still look garbled then perhaps the bluetooth mate is not actually configured to talk at 115200 as it claims. Trying reading the docs or testing with other baud rates.

Check whether error is present due to one of the following reasons:-
1) You haven't given any command to exit from the data mode. After setting the baudrate to 9600, you are directly switching to loop. You haven't given the command to exit the command mode.
2) I too had the same problem when I was using RN171 Wi-Fi module. The cause of the problem in my case was because I was sending data to Wi-Fi module in integer format instead of uint_8. While reading from the Wi-Fi module serially with arduino mega, I was reading it in the format of characters.
You have to remember that int is actually signed 16 bit integer. So while sending data to your Bluetooth module you have to send it as uint_8 or ASCII values of the characters that you want to send. You should also read it in the same format as you sent it.
3) If these are not the error then as calumb said, there can be error in setting the bluetooth module in command mode. You haven't checked for reply from bluetooth module whether it is really in command mode or not. You must read an CMD reply from bluetooth module and at the end of every command a reply of ack to conform that its really done what you want it to do.

This may be because of Bluetooth parsing data simultaneously. when sending two different data at the same time this may happens. try to control your data flow.

Related

How to solve Bad File Descriptor for Linux and Modbus

I am trying to setup a Half Duplex RS-485 communication using libmodbus on a Raspberry Pi running Raspian Buster, with a FTDI USB to Serial adapter. My FTDI adapter shows as ttyUSB0 when I run ls /dev/.
I tried the following sample code:
#include <modbus.h>
#include <stdio.h>
#include <errno.h>
#include <string.h>
int main(void) {
modbus_t *ctx = modbus_new_rtu("/dev/ttyUSB0", 19200, 'N', 8, 1);
if (ctx == NULL) {
fprintf(stderr, "Unable to create the libmodbus context\n");
return 0;
}
if (modbus_rtu_set_serial_mode(ctx, MODBUS_RTU_RS485) == -1) {
fprintf(stderr, "Error setting the serial port as RS-485\n");
fprintf(stderr, "errno: %d\n (EBADF == 9)", errno);
modbus_free(ctx);
return 0;
}
}
Compiled with gcc test1.c -I/usr/include/modbus -lmodbus.
And I get errno as 9, or EBADF, even if I run this code with sudo.
There is a very easy solution to your problem: just don't set MODBUS_RTU_RS485, quite likely you don't need it.
This mode is actually a workaround for devices without automatic (hardware) direction control. As you know, Modbus RTU works over a half-duplex RS485 link (only one device is allowed to talk while all others must be listening only), and hence requires an additional (to RX and TX) signal to control what device is writing to the bus at all times (direction control).
So you would only need to set MODBUS_RTU_RS485 if your device lacks this feature, which is nowadays quite unlikely or if you are building your own transceiver. Most devices based on the FTDI chip, in particular, should have this feature since the chip itself has a TXDEN (transmit enable) pin. See here for more details and a trick to expose the TXDEN signal to a non-default pin.
It is when you don't have this feature (one frequent scenario is when you want to use the embedded UART on your Rpi for Modbus over RS485, implementing your own transceiver) that you need a software (or hardware) workaround. And that's where MODBUS_RTU_RS485 should come handy, repurposing the RTS flow control signal. Unfortunately, most serial drivers (including ftdi_sio, the one you are probably using) don't support this mode (refer again to the link above).
Luckily, there are workarounds to the workaround: see here for a complete discussion. You can also take a look at this answer where I explained how to set up libmodbus with support for toggling the direction on the bus using a GPIO pin on a Rpi (also applicable to most SBCs, I've used this method successfully with a Pocket Chip computer, for instance).
You can find more background on this issue elsewhere: here and here.

Crackly audio when sending audio via bluetooth->arduino->DAC->3.5mm breakout board->headphones. Do not know the cause

I wrote a mix of python code and arduino code to make this work. I am sending an array of numbers (audio) to the HC-05 bluetooth module/arduino uno (these are both set to communicate via serial at 115200 baud, at least that is what I set for both (Serial.begin(x) for arduino and through AT commands for HC-05) ranging from 0-4095 as strings from python via bluetooth (bluetoothsocket(RFCOMM)).They are received character by character in the arduino and read into an array which will convert the char array into the single original unsigned int. Up to there I can confirm that chars were received and definitely constructed into integers. Those integer values are passed into a 12-bit DAC via I2C (SDA (A4)/SLC (A5) pins on the arduino. On the webpage (https://learn.adafruit.com/mcp4725-12-bit-dac-tutorial/using-with-arduino) it says that to increase the speed for the transmission you write this "TWBR = 12; // 400 khz" in the arduino script, I'm guessing. Otherwise the DAC will transmit at 100kHz; so I set the transmission speed to 400kHz for the DAC. When I connect the DAC output to the 3.5mm breakout/earbuds I only hear crackling, absolutely no "sound". The earbuds work just fine on my laptop, so the problem is something else. The DAC definitely outputs a voltage (triangle wave file from webpage works) and I tried two 3.5mm breakout boards (maybe shoddy soldering work?). Does anyone have an idea of what the issue could be or steps I could take to find what the error is? My guess is that somewhere the transmission rates/bit transfers do not line up, but that is what I'm trying to find out by asking.
On the python side, the code more or less looks like this:
*initializing socket, setting to non-blocking socket,etc..
for i in range((1000)): #just to test, the file Id like to send is maybe 300,000 strings
HC05_socket.send(soundchars[i])
And this is the arduino code:
#define ledPinr 4
#include <Wire.h>
#include <Adafruit_MCP4725.h>
Adafruit_MCP4725 dac;
int wait =10000; //
void setup() {
// put your setup code here, to run once:
pinMode(ledPinr, OUTPUT);
digitalWrite(ledPinr, LOW);
Serial.begin(115200);
dac.begin(0x62);
TWBR = 12; // 400 khz done in library
Serial.setTimeout(wait); // for now
}
void loop() {
// Read serial input:
char val[4]; // length 4 for 12-bit resolution
if (Serial.available()){
digitalWrite(ledPinr, LOW);
Serial.readBytesUntil(',', val, 4);
int num = atol(val);
dac.setVoltage(num, false);
Serial.print(num);
}
if (Serial.available()==0){
digitalWrite(ledPinr, HIGH);
}
}
Note: ignore the LED code lines, that is just to have an idea of the data flow as I run the program.
There are many reasons that can lead to crackling audio especially in these kind of setups (as I'm sure you're aware).
A couple of things :
Although in the example you link it says to write TWBR = 12, if you look at the source code of the library it checks for the #define TWBR macro. So I would change your code to have #define TWBR 12 before your setup() function.
How often are you receiving the bluetooth data? It doesn't look like you are handling what's happening when you receive no data the DAC will just freeze on whatever value you wrote last
Make sure you are calling the right address -> you didn't mention if A0 is connected to VCC in your setup.
First, be sure to call begin(addr) where addr is the i2c address
(default is 0x62, if A0 is connected to VCC its 0x63)
Side notes:
In my experience people try to avoid using atol(). If you look at adafruit's examples they use pgm_read_word() instead.
12 Bit isn't very high audio resolution for audio playback so most audio will be distorted (other than very basic digital sounds)
Make sure the audio you're sending from Python is playable (I don't know what your test case is)
In the end it could always be the soldering but I think it will be unlikely.

Can I use UART on MSP-EXP430F5529LP from Energia in order to communicate on pins p3.3 and p3.4 (rx and tx respectively)?

Can I use UART on MSP-EXP430F5529LP from Energia in order to communicate on pins p3.3 and p3.4 (rx and tx respectively)?
I already use UART in order to communicate with my PC via USB. To do so, I use Serial.println() and such. Now that one UART is taken, how do I configure and use second UART to go to these pins? Or would it be better to rewire my Bluetooth chip (BlueGiga wt32) to some other pins?
Configuration aside, Serial does not seem to allow for multiple UARTs. How does it know which UART to print to?
For some reason, I could not find any manual on interacting with wt32 from Energia, or on interacting with multiple UARTs on Energia.
Edit: found this link: http://forum.43oh.com/topic/3942-stellaris-lm4f120-multiple-uart-problem/
only, incidentally, they say it does not work. Still, a lead.. but it is my understanding that I still have to configure UART on those two pins, if at all possible.
Edit2 Found MultiSerial example in Energia:
/*
Multple serial test
Receives from the main serial port, sends to the others.
Receives from serial port 1, sends to the main serial (Serial 0).
The circuit:
* Any serial device attached to Serial port 1
* Serial monitor open on Serial port 0:
created 30 Dec. 2008
by Tom Igoe
This example code is in the public domain.
*/
void setup() {
// initialize both serial ports:
Serial.begin(9600);
Serial1.begin(9600);
}
void loop() {
// read from port 1, send to port 0:
if (Serial1.available()) {
int inByte = Serial1.read();
Serial.write(inByte);
}
}
Now, this may sound like a really noob question, but where is my Serial1?? Is it somewhere on my pinout? The corresponding page in Energia manual is just a stub.
Now, this link: http://energia.nu/Tutorial_SerialCallResponse.html has a pinout according to which P1.1 is TXD, P1.2 is RXSD, which is something that I have not seen documented elsewhere. I suspect that it is assigned in this particular example, only I don't see the assignment in the code; also, I suspect that this is the backchannel, unless the switch is turned. Confused!
Edit3: found SoftwareSerial example that turns pins of your choice into a RX and TX. So at least I probably have a software solution. Of course, I'd prefer hardware. The manual for the launchboard says the hardware supports up to 4 serial ports, but how? Where are the pins?
Sorry I keep adding to this. I'll tidy it out when there is a solution.
If you dont need those uart pins to talk to the host you can remove the jumpers on that board that connect rxd and txd and then connect those to your bluetooth module.
Serial.begin(); works for backchannel UART pins(Txd,Rxd between target ic & debugger ic marked in white squares in below image)
http://energia.nu/wordpress/wp-content/uploads/2015/03/2016-06-09-LaunchPads-MSP432-2.0-%E2%80%94-Pins-Maps.jpg
Serial1.begin(); works for P3_2 & P3_3

Software Serial.h Library not working

I created a WP8 App. It connects to the Bluetooth and detected it.and the Bluetooth module connected as well. But the data are not coming from the Arduino to the phone :(
error code
if(btSerial.available()) {
Serial.println(distance);
btSerial.write(distance);
}
else {
Serial.println("error"); -> always prints this
}
in the code always the error part is printing in the serial monitor. I have attached the pins in the Bluetooth device to below pins.
RXD - 11,
TXD - 10,
GND - GND,
VCC - 5v,
Please help me why is btSerial.available() is not firing ?
You have the logic backwards. available() tests whether the Arduino has data in its receive buffer. It does not test if the connection is ready. So the overall pattern of a serial program
if(someserial.available()) {
someserial.read... loop to get input
print stuff received
}
To write, just write.
//no if's just go
someserial.write("my output")
You do not need to wait. With the two wire serial connection, you have no flow control. In other words, there is no signalling between arduino and bluetooth transceiver about ready or other status. Because the baud rate of the bluetooth link exceeds the baud rate of the arduino serial link, you can't really overflow the bluetooth transmit stream.
The bluetooth aspect of negotiating the connection is meant to be transparent to the Arduino. In other words, your program is the same as if you where using a hardware serial port. If for some reason, you need details into the connection, there are special byte sequences that allow communication with the bluetooth hardware.

Arduino Bluetooth Connections

I am trying to send a string from my arduino to the serial monitor.
I am using the sparkfun bluesmirf chip with an arduino UNO.
my code is really simple:
void setup() {
Serial.begin(115200); // begin serial communication at 115200 baud rate
}
void loop() {
Serial.println("hello world"); // write hello world
delay(1000); // delay one second
}
When I open the monitor I recieve gibberish.
When I connect to the arduino with a usb cable everything works fine.
Can anyone please put me in the right direction?
Depending on the version of your bluesmirf, the default baud rate is either 9600 or 115k.
Here's another project that mentions how to set the baud rate for different versions.
Alternatively, just test by setting the arudiono code and serial monitor to 9600.

Resources