Hi, I'm trying to build an to control a modified rc car
I'm using Arduino Nano, hc-05, L298n, wiring is correct and I'm using divider resistors and also its rx to tx ...
I'm sure data is received on Arduino but its not working as expected (weird behavior on toy car)
rc_soft.ino (2.8 KB)
rc_full.aia (3.9 MB)
this is the block I'm using to send my data to nano. should I replace "join" with "list" maybe? or I should add anything else? I put this in clock block with 200ms interval baud rate is 38400
this is how x and y are seperated with "," as delimeter on arduino side
if(hc05.available()){
//String in = Serial.readString();
String in = hc05.readString();
int x_index = in.indexOf(',');
String x_axis = in.substring(0,x_index);
//Serial.println(x_axis);
x_axis = x_axis.substring(1,x_axis.length());
x = x_axis.toInt();
String y_axis = in.substring(x_index+1,in.length()+1);
//Serial.print(y_axis);
y_axis = y_axis.substring(1,y_axis.length());
y = y_axis.toInt();
hc05.print(x,y);
}
last line is just to send data to phone so I can check if data is fine or not
thank you in advance, I'm not looking for improvements just solution to fix the main problem
I used both aia and code for ino file, even with 0 modification number 27 example didn't work app goes to no responding as soon as I move slider (I connected bluetooth before doing it)
I also tried using it my code result was 5 digit number (like 21312) returning to phone while some of x,y shouldn't exceed 510 they are 255 max each
Dear @saeed_badali,
please aware that the .readString() function waits for characters until a timeout is reached, which is typically 1000 ms.
Therefore if your clock sends data every 200 ms, this could (probably) cause a mess in the receiving buffer of your Arduino.
Neither it seems that by putting a "\n" in your "join" block, as terminator of the string being sent by your app, should make the .readString to end earlier.
In a nutshell, try to send data slower than 1000 ms, then, if it improves, you can set a shorter timeout in your Arduino.
I also tried
Clock1.TimerInterval = 100 and Serial.setTimeout (200) with my own code
as it was part of juan_antonio answer though didn't work, but will work more on it
OK,
then are you sure that your HC05 baudrate is actually set @38400 ?
I had a look to your ino and to your aia.
In your ino there isn't any reference to the timeout setting, but I guess it is an old version,
The feedback sending to the app shall be done with a println() and not with only a print(). This hint is explained below.
In the aia I suggest the following:
At Screen 1 design level you have to untick the checkboxes of the clock1 (Enabled and AlwaysFires) and let a specific procedure to do that:
Please note that I've set the BT "NOT" secure. It's better to start with a more "relaxed" situation.
Then you should enable clock1 only after the BT has been correctly connected. This can be done in the part of your code where you are sure that the BT has been successfully connected.
The transmission shall be separated from the receiving with different clocks: the answer from your Arduino takes time and cannot be handled in the same timeslot (the same clock) as your transmission.
Therefore:
You can see that clock 2 is activated only after a completion of a transmission and it disables itself after a good reception (or after a disconnection). Clock 2 period is set to 50 ms, so within 2 transmissions (period 200 ms) there is the chance to catch the response from Arduino.
I've changed also the string terminator for the receiving block (number of bytes= -1) and I have previously set in the configuration procedure the ASCII character LineFeed (0x0A = 10dec) as terminator.
This complies with the use of println() in your ino code.
I have also added a "\n" in the "join" block so to send a LineFeed also to Arduino. This will not end earlier the readString(), but makes clearer the output to the serial monitor (if you use it).
I hope I have not confused you ! 
Cheers.
1 Like
Send the data received from the App to the Arduino Serial Monitor to check.
yes I'm sure its 38400 I checked it in AT command mode where I changed bt name
it was 4200 baudrate as default which I didn't expect and it bothered me for long time (I was trying 9600 and 38400 while non of them were default and finally found out default was 4200 and I changed it)
this is how my blocks look like now changed as u suggested (I'm not sure if I understood your 3 last paragraphs)
rc_new.aia (3.9 MB)
not sure how to do that .... send data from phone while hc-05 and arduino are connected and also connect arduino to usb and use serial monitor on com port usb?
did this and I get numbers on serial monitor when changing variables on phone but not expected values
its 40 (for both x,y it seems)when im doing nothing and phone just connected and I expect 140
if(hc05.available()){
String in = hc05.readString();
int x_index = in.indexOf(',');
String x_axis = in.substring(0,x_index);
x_axis = x_axis.substring(1,x_axis.length());
x = x_axis.toInt();
String y_axis = in.substring(x_index+1,in.length()+1);
y_axis = y_axis.substring(1,y_axis.length());
y = y_axis.toInt();
hc05.println(y); //this goes to textbox on phone
}
if(Serial.available()) {
Serial.println(x);
Serial.println(y);
}
Your new .aia seems pretty good.
But looking to your new .ino, supposing it is a part of your loop() function, to send data to the Serial monitor (yes by means of USB cable), you don't need to wait for Serial.available, just send the values when you receive them form the app.
Someting like:
Serial.print("X value : ");
Serial.println(x);
Serial.print("Y value : ");
Serial.println(y);
One thing more: I'm not pretty sure that you are "unpacking" correctly the input string.
You get the index of the comma parsing the in string starting from 0 , then you get the x value starting from 1 and not from 0 ? I have no time today to debug it, but probably you could add some Serial.println(x_axis); or Serial.println(y_axis); to show on the PC the itermediate values.
PS 4200 is really a weird baudrate, typically it could have been 4800 
Effectively in my experience I've found some pieces of HC05 with a baudrate factory set @9600 and some others set @38400 depending on the manufacturer, but 4200...never say never.... 
I'll change my .ino accordingly
I tested that code before with serial monitor and it was working though didn't wrote it myself
but can replace it with this one from juan_antonio example:
which looks more clear
if(hc05.available()){
a = hc05.readStringUntil(',');
b = hc05.readStringUntil('\n');
x = a.toInt();
y = b.toInt();
}
edited: it seems to working (correct values) but mobile app stops responding after bt connection
Hi,
yes, @Juan_Antonio's code is pretty neat 
and streightforward..... 
The app stops responding after the first reception or even before ?
If you remove the BT reception blocks, does the app still work ?
Try to separate the various tasks of your app and look whether introducing a specific one, it stops (i.e. clocks, loops...)
1 Like
disabling receive block (clock2) fixed it could be nice to have it but it was just for debugging can forget it
I ran out of AA batteries to test it but it seems its going to work 
but with slightly slow reactions not sure if its normal for hc-05 or I should change something
can I replace L298n with TB6612FNG with no change? it saves more battery right?
Hi,
yes the technology of the TB6612 is MOSFET while the old L298 is BJT, and it features also the STDBY pin which helps in saving the batteries.
Probably some adjustment to the command pins could be necessary, but I believe that it will be not so difficult.
Go on !!! 
EDIT: I've re-read your post, and about the slowness of reaction, please consider the HC05 as just a gateway between the phone and the controller. The BT speed is fast enough to transfer a huge amount of data (i.e. think about a BT earphone how many data does transfer per second), the bottleneck could be the serial communication between the HC05 and the controller, but @38400 baud you can approximate 3840 bytes per second and, since you transmit only a few bytes, I guess there aren't speed problems, there. What you can try to do is to decrease the timings of clocks used to transmit and/or receive the BT data on app side. As far as I have seen in your .aia, clock1 has 200 ms period, try to reduce it at 10 ms and see what happens. If it hangs (probably too fast) do increase it by 10 ms at every step, until you'll find the best compromise.
2 Likes
