Hi,
I've written this program in crbasic, and have had it working recently, however when I powered up the logger recently it doesn't seem to work at all. I've removed the FTP details for security reasons, but I can always email them.
I know the PPP connection is sometimes working by checking the Public variables from loggernet, however I cannot seem to get the FTPClient to work. I have tried to use the "8192D" trace code, however in the Terminal you only seem to be able to type one character! What am I doing wrong? I have tested the FTP details and am sure that they work.
Here's the program. Any help much appreciated. The odd timing is 1 record every 10 mins, with a file uploaded every 10 mins. Normally this would be every hour or day, but for testing it's useful to make it shorter.
Setup is CR1000 with Wavecom FastTrack Supreme 10, connected with SC-WMI. Connected via serial to loggernet. modem set to dial response 21 and on port CS I/O ME
Public PTemp, batt
'FTP Variables
Public FTPSuccess As Boolean
Public OutStat As Boolean
Public LastFileName As String * 25
Public PPP As String * 25
'FTP Information
Const IPAddress="xxx.xx.x.xx"
Const User="xxxxxx"
Const Password="xxxxx"
'Define Data Tables
DataTable (FTP,1,-1)
TableFile ("USR:FTP",13,-1,0,10,Min,OutStat,LastFileName)
DataInterval(0,10,Min,10)
Average (1,PTemp,FP2,False)
Minimum (1,batt,FP2,False,False)
EndTable
'Main Program
BeginProg
'Scan every second
Scan (1,Sec,1,0)
'Measure Panel Temperature
PanelTemp (PTemp,250)
'Measure Battery Voltage
Battery (batt)
'Call Data Table
CallTable (FTP)
NextScan
SlowSequence
Scan(1,Sec,1,0)
'FTP Data
If OutStat Then
'Turn on modem
SW12 (1)
Delay (0,45,Sec)
PPP = PPPOpen
Delay (0,15,Sec)
FTPSuccess = FTPClient (IPAddress,User,Password,LastFileName,LastFileName,0)
Delay (0,15,Sec)
PPPClose
Delay (0,15,Sec)
SW12 (0)
EndIf
NextScan
EndSequence
EndProg
The FTPClient() instruction may not be working because the last instruction parameter specifies the use of active FTP. In this mode, the FTP server is expected to initiate the data connection back to the client (the datalogger) on an ephemeral port. If the Wavecom modem is set up for NAT (Network Address Translation) and does not have settings to forward all incoming TCP connections to the datalogger, this data connection will fail and, consequently, so will the FTP client attempt. If this theory is correct, specifying a value of 2 (send file, passive mode) may turn the trick.
Please refer to this new version of manual here:
ftp://ftp.campbellsci.com/pub/csl/outgoing/uk/manuals/cs_gprs.pdf
Noting that the baud rate you are using will be slower and some new debug features mentioned at the end of the manual relate to a yet to be released operating system.
The information about capturing logs still applies. If you email them to me, I may be able to help.
Andrew,
Thanks very much for your replies. The point about NAT/passive made sense, however it doesn't seem to have solved the problem.
I have some out the output from the terminal after running the FTP trace. That new PDF was very helpful!
Here it is:
15:31:31.58 ftp client read error 1300
15:31:55.43 ftp client timed out logging in, state 2
15:31:55.53 ftp client not logged in
15:31:55.53 ftp client quit failed
15:31:55.53 ftp client FAILED
Any clues?
If I set the mode to 65535 to get all output, I get a "user closed ppp" statement every second. This doesn't make any sense to me.
Other interesting lines: (I can't copy/paste from the terminal?)
15:51:21.23 TCP ftpc cmd 10.135.170.139:1027 xxx.xx.x.xx:21 established
After that, the messages above. Looks like it could be a network error of some kind?
The User closed ppp is coming out because the program includes a pppclose command and at the time of viewing I would guess the program had not opened the PPP session yet.
The other error messages seem to imply some form of network error after opening the port 21 to the ftp server. Normal ftp requires ports to be open back from the server to the client, which many firewalls will block. This will not normally work for a GPRS connection running on a dynamic IP service, behind a router.
Using passive ftp often overcomes this, so try using option 2 at the end of the ftp client - that is if you ftp server supports passive mode, which most do.
OK - just spotted Jon already suggested the passive mode. Please try it though to see if it makes any difference to the errors in the logs.
Turns out the firewall which I recently enabled was blocking attempts to log in on port 21. I've opened it up now, which should theoretically solve that problem.
Now it seems to have a different problem- I can't even get it to dial where I previously could.
I keep getting "ppp is dialing", followed by "dial TX: A" every single second, and occasionally a "dial failed" somewhat unsurprisingly.
Why is it trying to dial every second, when OutStat is false? This was not occurring a minute ago, and the only difference is the IP is now ip:port.
Thanks alot for your help guys, I really appreciate it.
I think my understanding of the slow sequence must be somewhat out, as I'm not getting "user closed ppp" every second.
Am I right to think the following?
-- The slow sequence runs every second, just like the main program, however if it takes longer to run, it will not slow down the main program
-- The section from "If Outstat Then" to "EndIf" will only be run when the OutStat variable is not 0
-- The OutStat variable remains false EXCEPT when the program is run AND the file is saved to disk. Because it's run every second, this variable only changes from false for 1 second, every 10 minutes, at which point the slow sequence is triggered
If that is the case, I cannot understand why the PPPOpen or PPPClose commands would be run every second.
If PPP is enabled in the settings the logger effectively reviews what it should be doign with the PPP connection every second. If PPPClose had been called at some time in the past you will get the message "user closed ppp" in the trace log, every second or so. It just means the logger checked what it should be doing and found it should be closed, i.e. it does not mean you have called PPPClose at that time.
As soon as you call PPPOpen it changes state to "I need to be connected" and will sit in a loop trying to make the connection. This is when you will see the ppp dialing, interspersed with messages about what it is doing. The first part of this process is to get the modems attention which is why it sends the "A" - it expects the modem to echo this. If not it sends it again repeatedly occasionally trying various modem reset techniques.
If it is repeatedly sending "A" check the modem is powered on, plugged in correctly and the logger is set to the right baud rate and matches the modem setup (38400 baud max for an SC-WMI).
The dialling attempts will continue for about 10 sec after PPPClose is called. With current operating systems PPPOpen is the default state though when the logger is powered on, until the first PPPClose is called, which may be the cause of your confusion. (Put a PPPClose after Beginprog in the program to change this)
Andrew,
Thanks for the information, that now makes complete sense.
I still seem to be getting mixed performance. I've changed the timings so that the file is only written once an hour with no other changes, and it seems to be failing again.
Still- knowing how to use the terminal has transformed how I'll debug this time.
Is there some place where all this information is stored? I seem to be picking up bits and pieces all over the place!
Having thought about this, why does PPPClose not stop the logger from dialling once the slow sequence has been executed the first time?
I've been logged in for a number of hours and it is still trying to dial every second. It's made a couple of uploads but hasn't successfully connection for a couple of hours now.
Would you expect the performance to be so miserable?
Also, how do I export the logs?
Thanks,
Chris
From the end of the new CS-GPRS manual under the section on using the Device Configuration program's terminal mode:
"Click on Start export and enter a filename (end it in .txt). Turn the logger off then on and then leave the logger
trying to connect for some minutes or long enough to capture enough data to cover the problematic event. When done click on end export."
This allows you to save the information to a file. Perhaps you can email it to me along with the status table of the logger.
I would expect things to be more reliable than you report. That CS-GPRS manual is currently the main document we have that details some of these advanced tricks.
Just taking a quick look at your program, in the slow sequence I would have used a Do/Loop instead instead of a Scan/Nextscan. That way you won't get a bunch of skipped scans for the slow sequence. Also, shouldn't the delay type be of type "1" instead of "0"?