Hi All-
We're in the process of redesigning our data collection scheme from a set of GlobalStar GSP-1720 connected sites. The idea is to configure the CR1000 to...
* Setup the communication link over the GlobalStar packet data network
* Send data back to the LoggerNet server on a fixed interval (perhaps every 6 hours)
Currently, these sites are setup as asynchronous nodes and data is transferred by scheduled dial-out connections controlled by LoggerNet over public switched telephone network. By making this switch, we hope to save $$$ on connectivity costs associated with asynchronous satellite communications.
We've been somewhat successful in setting up a similar test infrastructure using cellular-based connectivity via the Sierra Wireless LS300 modem. In a nutshell, once we configured and established a PPP connection between the CR1000 and the LS300, the CR1000 program was able to push data updates back to the LoggerNet server with properly configured IPPort/PakBusPort or PakBusTcpServer components. Based on the GlobalStar GSP-1720 documentation, we think a similar design is possible, if we can properly account for setting up access to the packet data network (through the #777 dial string) and establishing a PPP connection between the CR1000 and GlobalStar modem.
Using the Sierra Wireless documentation and Campbell Sci template support, connecting the CR1000 via PPP to the private network supplied by the modem (the LS300 assigns the serially connected CR1000 an IP address of 192.168.15.100) was fairly straightforward. Unfortunately, we can't seem to find the same level of detail around the connectivity with the GlobalStar modem--no definition of establishing a private network between the CR1000 and modem and/or PPP communication.
Any insight into establishing such a CR1000-initiated packet data connection via GlobalStar modems would we greatly appreciated.
Thanks in advance...
In practice you should have the datalogger regularly query the satellite availability and signal strength from the GS modem. When conditions are right you will use the #777 command you mentioned to dial into the network. The logger will initiate the PPP session through the modem and will acquire a GS network IP address. Once the logger has acquired an IP address from the network, you can use the datalogger's IP functionality to connect back to a LoggerNet IPPort or PakBus/TCP Server.
Thanks, Sam, I appreciate your quick response. It helps to clarify the CR1000 will be receiving an IP from the GS infrastructure rather than from the GS modem itself as in the cellular Sierra Wireless scenario.
A couple more clarifications would help defining our path:
* How should the CR1000 be configured using the Dev Config utility? Based on your recommendations, I'm assuming...
Deployment...TCP/IP...PPP...(COM connected to GS modem):
IP Address: 0.0.0.0 (set to accept a DHCP address)
Should the Modem Dial Sting (#777) and Modem Dial Response (CONNECT) fields be filled or left blank?
* CR1000 program - Using some code commonly quoted on the forum to establish modem communications as a start and a little pseudo code:
If "satellite availability tests pass" Then
DialSequence (4094)
DialSuccess = DialModem (Com_Port,38400,"#777","CONNECT")
If DialSuccess Then
SendData(TCPOpen("Server_IP_Address",Port_Num,0),0,4094,Table_Name)
TCPClose(TCPOpen("Server_IP_Address",Port_Num,0))
Code to issue the hang up command - ATH777
EndIf
EndDialSequence (DialSuccess)
EndIf "satellite availability tests pass"
Feedback on the logic and use of the proper CRBasic functions would be helpful. Based on some limited time with CRBasic, I foresee some issues with using the DialModem function within an If statement and using "#777" as a dial string.
I realize this post contains questions that could require a detailed response. Thanks in advance for all your help and recommendations.
http://downloads.globaltel.ru/instructions/english/qualcomm/DataUsersGuide.pdf
I have limited experience.
With DevConfig set ppp interface to that connected to the 1720. Set dial string to #777; leave the rest blank. Set the Pakbus/ TCP client setting to the IP address of your LoggerNet server.
In CRBasic use serial I/O commands to request satellite status information. When the conditions are good, use
Pppopen()
If IP address from pppopen
Sendvariables("Public","Callback")
Delay()
Pppclose()
Or
Pppopen()
If IP address from pppopen
wait for Route() > 0
Senddata()
Pppclose()
* Last updated by: Sam on 12/24/2013 @ 8:33 PM *
If you are not too far down the road on this but are committed to Globalstar, you should consider calling Nupoint Systems. They have a nice field ready product that I've used to send data to LoggerNet with. They are very helpful and responsive.
http://www.nupointsystems.com/
Other constellations that we regularly recommend to customers include Inmarst's BGAN and Iridium. We have done well with the Hughes 9502 that we've sourced through Galaxy 1 (http://www.g1sat.com) and 9522B with Com9522B we source through Campbell Canada and JouBeh (http://www.campbellsci.ca/, http://www.joubeh.com/)
Thanks for all the hints and links to documentation, it helped. Since these are existing sites, the solution includes interfacing with the GlobalStar products.
That being said, I've been successful in establishing a data connection based on quality of service parameters queried from the modem. However, since merely configuring the dial string with the Device Configuration Utility to #777 didn't accomplish this connection. The following got me to a data connection:
SerialOut(Com4,"ATD#777"&crlf,"CONNECT",1,200)
So now that a data connection can be established, the next task is to configure the CR1000 such that it requests a DHCP address from the GlobalStar infrastructure. The #777 dial string (also combined with the CONNECT modem dial response) doesn't appear to set the CR1000 into, for lack of a better term, DHCP client mode. During some experimentation, I changed the dial string to PPP and found some success--the CR1000 requested and received a DHCP-issued IP address. Although this works (i.e. the PPP dial string forces the CR1000 into a DHCP request mode), it also seems to have a major drawback--once configured with the PPP dial string, the CR1000 constantly requests an IP address. In fact, even before the program reaches the SerialOut-based dial command, if satellite connectivity is available, the Device Configuration Utility settings (dial string PPP) seem to place the CR1000 into automatic DHCP request mode. In other words, if it doesn't have an IP address, it's continually making a DHCP request for one. A blank dial string, as found in the documentation, "...indicates that no dialing will take place and will configure the datalogger to 'listen' for PPP connections (basically, to act as a server).", which yielded the same results as the #777 dial string. A dial string of CLIENT (found the documentation related to the PPPOpen command) resulted in the same outcome as #777 and blank dial strings.
With the goal of reducing connectivity costs, is there a way to explicitly control a DHCP request? If the datalogger is constantly seeking an IP address, it will the defeat the purpose of a controlled, datalogger-initiated connection. The closest thing I could find in the CRBasic documentation was the DHCPRenew command, but is only applicable to the Ethernet interface.
I'm looking for an explicit way to control when the CR1000 requests a DHCP address over a PPP configured COM port. A controllable DHCP client of sorts that isn't continually requesting an IP, yet only when told to do so.
Again, the help is appreciated...
I'm having trouble figuring out how to connect the CR1000 through my LS300 at all. I set up port forwarding on ace manager with no luck.
kpeterson, sorry to ask a question and not answer yours, but could you help me figure this out?
I haven't described a lot of detail here so if there is something specific you need I will provide.
So far I have no luck contacting Sierra Wireless customer support.
Thanks!
Hello atm123-
I'd look into two things:
1.) A LS300 template available in the Downloads section of the Campbell Sci website
2.) Configuring the PPP stack (with the LoggerNet tool - Device Configuration Utility) of your CR1000.
I believe your CR1000 will have to acquire a private/NAT IP address from the LS300 in order for port forwarding to function. If the CR1000 doesn't load the TCP/IP / PPP stack, port forwarding will not function.
I can't be 100% certain, but that's what I recall of my efforts.
Hi, kpeterson,
"In short, once we configured and set up a PPP connection between the CR1000 and the LS300, the CR1000 program was able to push data updates on LoggerNet server with ipport / PakBusPort or PakBusTcpServer properly configured components "
I want you to give me the procedure as it has been over a week since I looking to connect my modem CR1000 in LS3000.
Thank you kindly give me a hand.