This isn’t going to be like my standard type of post. Instead of writing paragraphs I’m going to be working in a bullet point Q&A format where I’m just going to be hammering out every thought I’m having here, instead of working out of a notebook/piece of paper, and see what sticks.

I know I said that I wanted this to be quick, and have still somehow come up with 6 different things to try off the top of my head.
In no particular order, they are:

• Review what exactly causes a (28)

• comment out LCD splashscreen message and try again - if prog runs, move splashscreen to the loop and try again.

• would RTC make a difference with scheduling wifi uploads?

• Would a serial snIF work to make sure line is free?

• Retool timing on Serial push from Uno?

• On demand data from Uno instead of autolaunch?

• Have Uno listen / respond to requests from Node?

• Unique Serial print commands on every other line in order to determine what piece(s) of code are triggering the exception.

• reduce screen display/update time from 2000 millis to 1500 or 1000 millis per row (milli is Arduino slag for millisecond)

• use a counter to keep track of which line of text the LCD should print, in order to tighten up loop time. (vs printing each line once before looping)

• Reduce number of lines being printed on display? - counter from 9 would fix as only 1 line would be loaded at a time.

Did I say 6 ideas? Once I start brainstorming, they tend to just keep coming… I haven’t even had a chance to complete my first test, and I’ve increased my list size by over 50%…

OK, I’ve now got my first asnwer: Exception (28) is a request for an invalid memory address, caused by either a cache that has been turned off, or a “wild pointer” (think of pointer as the arduino equivalent of a desktop icon for a string of data you’re working with)

• Leads me to wonder at what point is the SenPak data actually purged? - Why can’t I see it?
  Is it a case of making sure data is copied to LCD before being uploaded?

• Does data upload need to be handled by scheduled function to avoid?
  
  

The confusing this is that my TEST data stream is received and posted to the spreadsheet, but when I switch to using a similarly formatted, piece of live data the NodeMCU starts crashing almost instantaneously. I think that there is something in the way the data is being received that is doing me in… what is so different between the data strings? Format type? (String vs char vs float, etc), is a process being interrupted by incoming data?

This is probably something…. I’m looking at my test data sting again, and noticed that the spreadsheet isn’t getting all the data that is being sent.
The way that the line with the data starting 999.99 only appeared the once on the spreadsheet tells me that info is absolutely moving or changing before it can be accessed. The test file I’m using pushes 3 strings of SenPakA data and one piece of SenPakX data ar regular intervals, so I would have thought I would have seen equal measures of each piece of the 3 SenPakAs in a repeating sequence. It reinforces my idea that I’m going to have to put something in place where data isn’t refreshed until the NodeMCU wants it to be replaced… prefereably at the end of the LCD display sequence.

• Between the setup and loop, I found 13 seconds of questionable delays in the code… if its a watchdog timer issue, could this be triggering it?
  -shortened set up loop by reducing character delays in the LCD splash message (If reading debug info correctly, it crashed at line 190 which occurs after a 3 second delay am removing this delay)

• idea: if data is missing when LCD updates, can I control the migration of data from the “buckets” to the “A values” through the loop, instead of automatically transfer/pushing all the way through as soon as the data is received?

• Adding a layer of LCD holding buckets that we control the refresh of?

Without a data stream the NodeMCU crashes - there doesn’t seem to be a contingency in the code for what it should do if the “new data” flag isn’t flagged. Alternatively, when I have the Uno transmitting my looping test data it now crashes somewhere around displaying current senpak data. This is a weird development; Though intermittent, I’m pretty sure my test data was accepted without crashing, yesterday.

With the datastream running, the NodeMCU generates the Exception(28) at the point where it is trying to create the file to upload to the spreadsheet…

Wait…I’m starting to get confused - NodeMCU just booted up without a datastream and crashed here, at the point where it was creating the upload file, instead of at the point where it was waiting for the upload file… WHAT THE HONK!?! - Not worrying about it now going to keep pushing ahead on a fix for the spreadsheet upload… I noticed an errant > in the upload string, and I’m thinking this might be what did me in? - uploading new file to test now.
No difference, still crashing at same point… Next - going to print the individual data points to serial and see if they are still there - might have to go backwards to see when they vanished.

Wait a tic… is it crashing because it’s trying to compile nonexistent sensor data? If so popping in some place holder values should do the trick…
Placeholders made no difference to the upload, and the placeholders are recognized in the serial print line I added immediately above the command that stitches the data together for the upload… so there is something wrong with the actual line of code that organizes the data I’m sending to the spreadsheet. Maybe the string is too long? I will reduce it, so its only pulling TDS, Temperature and Humidity data as the previous incarnation was able to upload those successfully.

Progress: Changing 1) the data type from char to String, and 2) populating the SenPakUpload file by manually stringing the pieces together w/o the snprintf command seems to have helped with getting my default 5 pieces of data posted to the spreadsheet.

Going to try it with my test data stream from the Uno now and see how it reacts…

It reacts well - varying sensor data is being uploaded depending on when the void loop meets the data stream.

Time to try with live data…

Live data is going to the spreadsheet, but completly bypassing the LCD.
I am going to try adding some simple text lines for the LCD to print as the computer runs, to see if I can figure out why nothing is on my screen.

OK… I don’t understand this, but somehow my adding the test LCD text to my script has fixed the issue?
I have live data appearing on both the screen (interspersed with bits of my test text), as well as being uploaded to the spreadsheet.

I’m going to let this run for a while and see how stable it is.
I’m feeling fairly confident now, as I have booted up the Colonel twice now without issue, the last of which was 30 mins ago.
(Maybe the LCD troubleshooting lines I added were enough to break up a loop detected by the watchdog?)