Some code only works when USB serial port connected

Supernovali:
Serial is only an object in the Arduino IDE. You can make multiple serial objects. If you are using the same serial for your sensors as you are for the usb port. You can get unpredictable results if one hasnt cleared the buffer and another one starts reading/writing. In order to prevent this, do a Serial.begin() for the serial monitor, then do something like GPSserial.begin() for your gps serial so the buffers dont get scrmabled.

do you mean by using software serial port ? so I have to declare something like this:

SoftwareSerial GPSserial (2,3)

is that what you mean ?

Ok, now would be a good time to show a diagram of how you have the serial interface hooked up. Are you using SPI as in MOSI/MISO? That's the SPI protocol. Or are you using the TX/RX pins? Because that's Serial. And you CANNOT be using serial with print to the Serial monitor AND communicating with the device.

And that, my friend, is possibly why you had a hard time earlier, before you deleted the Serial.print commands. You get erroneous data to both the usb serial interface and the sensor and vise versa.

You can define multiple Serial objects, only if you have multiple serial ports or serial multiplexing. If you are using SPI, you can have virtually as many devices as you have RAM for and different addresses for each one.

On serial, each device MUST be connected to their own TX, RX, pins and must have a common ground.

On SPI, each device is connected in parallel to all other devices, with a common ground.


On another note, this is why it's important to give us all the information. As @SteveMann said:

Welcome to the forums. You will find a lot of regulars here who just want to help. In the future, please don't call a Fritzing Lego picture a "schematic". As your projects get more complex, the Fritzing pictures are less useful to useless.

In order for us to really be effective, have resolved this last night, it would have been useful to have all pertinent info on hand.

Anywho, hope that clears some of it up for you.

If you still need help after this, we will need those schematics :wink:

Supernovali:
Ok, now would be a good time to show a diagram of how you have the serial interface hooked up. Are you using SPI as in MOSI/MISO? That's the SPI protocol. Or are you using the TX/RX pins? Because that's Serial. And you CANNOT be using serial with print to the Serial monitor AND communicating with the device.

And that, my friend, is possibly why you had a hard time earlier, before you deleted the Serial.print commands. You get erroneous data to both the usb serial interface and the sensor and vise versa.

You can define multiple Serial objects, only if you have multiple serial ports or serial multiplexing. If you are using SPI, you can have virtually as many devices as you have RAM for and different addresses for each one.

On serial, each device MUST be connected to their own TX, RX, pins and must have a common ground.

On SPI, each device is connected in parallel to all other devices, with a common ground.


On another note, this is why it's important to give us all the information. As @SteveMann said:In order for us to really be effective, have resolved this last night, it would have been useful to have all pertinent info on hand.

Anywho, hope that clears some of it up for you.

If you still need help after this, we will need those schematics

Here I attached my schematic design:

SteveMann:
That still tells me that you have a power issue. You should not have to press the reset button on the uno.

I have attached my schematic design, could you please check it for me?

Looking through your code again and the schematic, yes, you are using the UART pins for USB. Define another Software serial on different pins for your GPS. Then, in all of your code where you read and write to ANY of your serial devices, you MUST first check to see if they are still reading or writing before you can start reading/writing to another device. This is due to the limitation of the Software Serial library using the same buffers and only being able to handle one device at a time. This library could possibly be improved, but its limited by hardware interrupts so it using "polling code".

Make those changes and see how it goes, then get back to us.

Note: when you free up TX/RX for the UART, you will have debugging capabilities again :slight_smile: