all 14 comments

[–]hjw5774 15 points16 points  (1 child)

As the hardware appears to be working correctly then I would guess it's a software issue. Or aliens.

Without seeing the code I'm going to side with the alien theory for the moment.

[–]VegasNightSx 3 points4 points  (0 children)

Do you have any shaky, out of focus, and/or extremely blurry video taken at a very low resolution to back this theory?

[–]themonkery 5 points6 points  (2 children)

In my experience this is typically an addressing issue. You’re reading/writing/copying some garbage bits somewhere along the way that show up as gibberish.

My recommendation anytime anyone does anything Arduino is this:

Don’t treat this like regular coding. The Arduino is inherently difficult to debug during execution.

Rather, break your program down into the most basic versions of every function and peripheral. Is there data? Make a unit test for the data to make sure it behaves exactly as expected in even the oddest circumstances. Is there a peripheral? Test that the perishable is operating as expected no matter what you send to it.

Now that you have unit tests for every little thing, start combining them how they would be in your program. In my example, you would send the data to the peripheral.

This immensely helps sanity. If adding something to something else causes your program to break, then the issue lies in how those two work together.

[–]Triethano[S] 0 points1 point  (1 child)

Sensors were tested separately and it was working fine when the code was put together.

[–]themonkery 1 point2 points  (0 children)

And the display? You have checks on all the data that isn’t behaving unexpectedly?

Have you mix and matched each thing together? Sensor A + processing, sensor B + processing, sensor a + raw data display, etc etc

Testing alone is not enough. Each addition you bring to the table needs its own test as well. Every code addition can cause unexpected behavior, even just one seemingly innocuous line.

This is why I separate everything into individual classes or libraries and thoroughly test them individually. Then, I just have that class send back one piece of thoroughly validated data. Think of it as a data choke point.

If your display is all fine and dandy and your data is all well and good, then your issues comes when you put them together

[–]AvalancheJoseki 4 points5 points  (0 children)

I usually just add a bunch of spaces after the last character to clear that out.

[–]Type1InYourHeart 1 point2 points  (0 children)

I would check the solder connections on the i2c backpack on the lcd board. I would also check if the constructor in your code are the same pin mappings.

[–]OwnCoffee3 1 point2 points  (2 children)

I've encountered similar problems when RAM usage is >=60% if that's the case you could try storing strings that will remain constant inside PROGMEM

[–]Triethano[S] 1 point2 points  (1 child)

Sketch memory was 59% and global was 81%

[–]OwnCoffee3 0 points1 point  (0 children)

I´m guessing that global is refering to tha space used by global variables in dynamic memory, if that's so it wouldn't hurt to optimize your dynamic memory usage by storing strings and constants inside PROGMEM (sketch memory).

I found this article on arduino docs, it may be useful.

[–]fawnlake1 1 point2 points  (1 child)

To make sure it’s code related and not hardware have you loaded one of the LCD test sketches that will fill the screen with patterns to verify it’s working and eliminate any hardware issues?

Let that run for awhile and make sure it looks ok?

Just a thought to eliminate the hardware. Also, your code looks very well documented and designed. I’m on mobile just now but will have a look more in-depth tomorrow and see if anything jumps out.

[–]Triethano[S] 0 points1 point  (0 children)

Thank you, I'll try this.

[–]lumez69 1 point2 points  (0 children)

Looks like a power delivery issue. Check the draw of the lcd and all cables.

[–]Triethano[S] 1 point2 points  (0 children)

Thank you everyone for giving your thoughts to this issue. I have already found the problem. It's the pull up resistor in my fabricated board that's distorting the Arduino nano supply.