Ah - lost in language translation. I want to see where the Sketch originally came from (didn't you mention the Arduino forum?) as there could be key information about it.
Just read the above again. The App should never be running when the cable is plugged in or removed.
Also, because of Google Security Measures, we probably need to have Google Locate switched on (we have found this to be necessary for Apps that use Bluetooth for example).
I don't really understand what you mean. Could you write what the application is doing wrong? Which function specifically?
The phone and the Arduino should be connected to the USB cable before the App is run.
Sorry - my Polish is far worst than your English 
You mean "permission" to use the device, I read somewhere that it can be set, but it's too much for me at once.
And in the application from the "Serial USB Monitor" play store, the permission itself is set once. But to connect, after pressing "connect" resets arduino.
And it shouldn't be connected before that because the message "nickname ..." would not be read by the application.
We have to ask for that permission in the App code, then we can store the granting of permission so that it does not get asked again. However, the SerialOTG extension does not ask and App Inventor does not either - hence the complex solution of editing the APK Manifest.
By 'it', do you mean the USB cable?
I had to put it in code because it reads somewhere as code. xD
The easiest way I can:
1. You connect the cable
2. arduino gets current on 5v and gnd wires
3.The application in arduino starts (void loop () {
// set username
while (username == ""))
4.starts broadcasting:
void setup () {
Serial.begin (115200);
Serial.println ("Enter username ...");
5. Data is sent by arduino to the serial port without checking whether it is open. (I'll check if it can be fixed as well)
6. You turn on the application.
7. The application resets arduino when opening the serial
8. The DTR feature allows the app to initialize the serial and open the serial
That's a part of the Sketch which is wrong. It should first receive a message from the App, then reply with "enter User Name".
Also, the radio writing and reading pipes should have separate addresses.
I can work on this tonight but now I have to get on with my job 
1 Like
Also, a known cause of issues is the baud rate, so for testing we should lower it to 9600.
I tried to give in the loop:
while (! Serial)
but nothing helped.
And in this sketch, the point is that the radios are still listening, if you add ACK then there is no problem with sending and confirming delivery as it is at the moment. I even made such a picture, it is the simplest explanation:
Some notes, but I don’t have an Arduino Mega so I can’t verfify this:
You can reset the CPU if you toggle Dtr as described. You have to test if it is reset by a 1 or 0, You also have to test if you need an Dtr and/or Rts set to 1 to enable communication. That depends on the program in the 16U2. (I think it preprogrammed to do USB-serial communication, but it can be reprogrammed by the user to do something else)
The explanation that the 16u2 generates spikes that will be decoded as character at this baudrate seems reasonable.
The Arduino readStringUntil() has a timeout (default 1000ms). After a timeout it probably returns what has been received so far. This means that you will always receive this “strange” characters.
It seems strange that the app ask for device “null”. You can’t open an OTG serial device until the USB cable is connected to the Mega. (there is no serial device until it’s connected). This also power up the Mega and your program is started after a short delay.
My English is poor and I don't understand a bit but for sure in Arduino Mega after checking with your program (Serial OTG) DTR must be set to 1 to reset arduino and RTS to 0 (sure works)
Ok, Rolf's notes very helpful. Main issue here is the Sketch prematurely sending the 'Welcome' message.
I have edited the Sketch to try to prevent that - it compiles but I can't test it here. I have concentrated on the App-Arduino Serial comms and largely left the radio comms as they were (except addresses).
The attached AI2 Project incorporates Rolf's notes re DTR toggle and supports sending an acknowledgement (ACK) to the Arduino to indicate the App is ready.
Test these two together:
A1_Test4.aia (199.5 KB)
SketchRF.txt (3.4 KB)
Rename SketchRF.txt to SketchRF.ino
- Install the App on your smartphone as an APK. Do not run it until the cables are connected and the Arduino powered up.
The serial USB terminal activates Rts, Dtr as default before opening the device. You can try if this (Set Rts, Dtr to 1 before call to Open() ) eliminates the "strange" characters. It also states that Rts should be set to 1 to enable communication for 32U4 devices like original UNO. This may also be true for Arduino Mega with a 16U2 as USB to serial converter. You can set Rts, Dtr as a property or in the program.
What I wanted to say with my previous replay was: If you get this spikes from the 16U2 when opening the serial device, the sketch will receive them as “strange” characters in the readStringUntil() statement. After a timeout you get the characters in string username. The sketch decodes this as a true input from the user.
It's because the Sketch just rolled into that part of the code - I have replaced it so that it waits for the App to flag readiness.
I found one more reference to the problem:
If you set Rts, Dtr to 1, then the Arduino using 16U2 will be reset and the received characters from the open of the USB serial will be deleted. This together with the default value of Rts, Dtr explains the difference between using USB terminal and SerialOTG. It would be interesting if someone can verify this.