New Firmware

[TomNB]

The receive char function starts like this:

void ProcessReceivedChar(int fd, char c)
{
static int rx_state;
static int rx_post;
static int beginrx;

if (beginrx == 0)
{
beginrx = 1;
SendToAll((char*) "Received from stamp:[", 0, FALSE);
}

so for each received char you will see it echoed on the telnet debug. In your video they come in very slow. If an entire command is not received in 1 second, the pink issues an error/timeout and aborts. So if your command does not received within 1 second, the pink will abort. We have now been exercising every function in a test for 2 days with no slow down. Do you have any way to look at the tx data from the stamp to the pink? I also check the support logs, and there are no other reports of slow performance. I'm not saying it cant be the pink, but at this point the only difference is the stamp program.

Also, there is no flow control on the serial port. So if the stamp sent the entire command in less than a second, and the pink was slow, it would not receive the entire command. Data would be lost and you would not see the entire command in the telnet session.

[Mike2545]

That is just strange, my program has moved past that string by 8 minutes and is communicating with the RTC, I know the PIC cannot do 2 things at once so this is very puzzling.

I'll test with another serial terminal listening to the PIC to PINK line and let you know.

This is Normal communications:
Left is telnet, Middle is the line from PIC to PINK, Right is my Debug terminal from the PIC
https://www.youtube.com/watch?v=jJJxTo-HKzY

[Mike2545]

This is where the PINK is not responding. Note at the end of the video the PINK all the sudden catches up with my transmissions.
Left is telnet, Middle is the line from PIC to PINK, Right is my Debug terminal from the PIC
https://www.youtube.com/watch?v=hH0023oiC4I

[Mike2545]

These are screenshots of the Diagnostic page with and without the Error.
Hope these help.

[Mike2545]

Here is a Notepad ++ log of the day, this is tx from the Stamp to the PINK...
This data was collected with Docklight V2.0 RS232 Terminal / Monitor in ASCCI form.

[TomNB]

Hi Mike,

I'm not quite sure where to go with this. We have run the test program for 5 days straight and not have been able to reproduce this behavior. I'm attaching our test code in case you want to take a look and maybe do the equivalent in basic.

There are many tests. The one we are running is:
6 - Get PINK system status and write all vars Continuous

This test loops forever reading the system config and writing all 99 variables:
"!NB0RSI",
"!NB0RSN",
"!NB0RSG",
"!NB0RSD",
"!NB0RHP",
"!NB0RFW",
"!NB0RST",

void WriteAllDataVariables()
{
char buf[80];

uint32_t secStart = Secs;
iprintf("Writing vars 0 - 99\r\n");
for ( int i = 0; i < 100; i++ )
{
siprintf(buf, "!NB0W%02d:%d", i, i);
SendWriteCommand(buf);
iprintf("%d\r", i);
}
iprintf("\r\ncomplete (approx. %ld seconds)\r\n", Secs - secStart);
}


One next step could be to write a very simple program that does exactly this and see if the behavior changes in your setup. We use another netburner device to run the test program and connect to the pink's serial port.

[Mike2545]

Thanks for the input Tom, But you guys may be running the wrong test.
you need to write the vars anyway you want, like in your program.
but you need to read them back
The error is when you ask PINK what those Vars are. Read vars = timeout
The Stamp/PIC/ uC will timeout waiting for the PINK to send data in the allowed wait time.

An optional Timeout and Label may be included to allow the program to continue if a character is not received within a certain amount of time. Timeout is specified in units of 1 millisecond. If the serial input pin stays idle during the Timeout time, the program will exit the SERIN2 command and jump to Label.

If you don't use a timeout & label your program will just hang.
<EDIT>
Checking the logs for today things went real smoothly. I had the telnet port opened through the router for some time, (many months/years?) I disabled the throughput on the router this morning and after that ~10:00 AM to ~9:30 PM and no errors in that time period. Will keep my fingers crossed? But you should still set up reading of the PINK vars on your end to see the timeout I am seeing

[TomNB]

Read of all vars has been added. Running 15 hours so far with no errors. Will let it continue.

[Mike2545]

Since not having the telnet port forwarded to the PINK (about 28 hours) , no errors.
I am beginning to think my telnet port was being hacked and was disrupting PINK
You guys should set up your test pink with an open telnet port (23) to the web and see what the bots do to it.

[TomNB]

Hi,

The purpose of the telnet port is only for debugging during development. It is not intend for it to be always open or exposed to the internet. I can't think of a way it could be vulnerable off hand, but if you don't have any failures then that is a possibility in your configuration.