User Guide to Q4000/QPRO Figure 12-52: DemoAppFFS - Logger output for initial Power On It is possible to view the directory on the modem to ensure that all the files have been created and stored correctly. To do this, on the Logger port type ‘d’ ‘f’. This gives you a menu of file utilities which can be run on NVM. It is possible to list, rename, delete and move files using these utilities. Note: See Appendix D - Debug and utility menus for more information on the debug (d) and utility (U) commands.
User Guide to Q4000/QPRO Figure 12-53: DemoAppFFS - Logger output for next Power On To remove the FFS file and start over, on the Logger port type ‘d’, ‘f’, ‘r’, ‘CRUMBS.DAT.’ This will remove the FFS file created by the application. The next time the application is run, a new file will be created. Document Number 1135-4713 Rev G Page 116 THIS DOCUMENT CONTAINS CONFIDENTIAL AND PROPRIETARY INFORMATION OF QUAKE GLOBAL CORPORATION.
User Guide to Q4000/QPRO 12.4.6 DemoAppTCP The DemoAppTCP sample application demonstrates using TCP to send and receive GSM/GPRS packets. It uses the Turnkey application structure to illustrate sending a TCP message over GPS/GPRS to www.google.com. DemoAppTCP then displays the output on the Logger screen. Note that this sample application uses network-specific calls. Figure 12-54: DemoAppTCP - Selecting the Workspace 2. Now build, load and execute DemoAppTCP.
User Guide to Q4000/QPRO CONFIDENTIAL Information classified Confidential - Do not copy (See last page for obligations) The initialization of TCP upon POWER_ON is shown in the following screen. The user should fill in his/her assigned access point username and password. Note that a web page from www.google.com is being requested. A timer is also set to expire after TK_XMIT_INTERVAL.
User Guide to Q4000/QPRO CONFIDENTIAL Information classified Confidential - Do not copy (See last page for obligations) After the timer expires, MSG_sendTerr() is called to receive the web page data. The timer is then reset to expire after TK_XMIT_INTERVAL. Figure 12-56: DemoAppTCP - Request for web page data Document Number 1135-4713 Rev G Page 119 THIS DOCUMENT CONTAINS CONFIDENTIAL AND PROPRIETARY INFORMATION OF QUAKE GLOBAL CORPORATION.
User Guide to Q4000/QPRO CONFIDENTIAL Information classified Confidential - Do not copy (See last page for obligations) The application is notified that a message has been received by the MSG_RCVD event. Here the web data are printed out to the Logger port, as shown below. Figure 12-57: DemoAppTCP - Web data displayed on the Logger port Document Number 1135-4713 Rev G Page 120 THIS DOCUMENT CONTAINS CONFIDENTIAL AND PROPRIETARY INFORMATION OF QUAKE GLOBAL CORPORATION.
User Guide to Q4000/QPRO 12.4.7 DemoAppADC The Analog to Digital Converter (ADC) example: • takes a number of samples from the designated ADC • gets the median ADC value to remove some variability caused by noise (the median gives a more reproducible value than the arithmetic mean) • converts the value to a voltage based on the supplied conversion factor • prints the voltage value to the Logger port. CONFIDENTIAL 1.
User Guide to Q4000/QPRO 3. After startup, check the Logger output for the line APL DEMO: ADC. This indicates that the correct DemoApp is running. CONFIDENTIAL Information classified Confidential - Do not copy (See last page for obligations) The ADC converter is selected by #define statements in the code, as shown in Figure 12-59. Figure 12-59: DemoAppADC - Definitions Document Number 1135-4713 Rev G Page 122 THIS DOCUMENT CONTAINS CONFIDENTIAL AND PROPRIETARY INFORMATION OF QUAKE GLOBAL CORPORATION.
User Guide to Q4000/QPRO CONFIDENTIAL Information classified Confidential - Do not copy (See last page for obligations) The application prints the ADC data approximately once per second, as shown in Figure 12-60. Figure 12-60: DemoAppADC - Logger data Document Number 1135-4713 Rev G Page 123 THIS DOCUMENT CONTAINS CONFIDENTIAL AND PROPRIETARY INFORMATION OF QUAKE GLOBAL CORPORATION.
User Guide to Q4000/QPRO 12.4.8 DemoAppRTOS The Real-Time Operating System (DemoAppRTOS) sample application demonstrates use of various RTOS and related system features. The primary features demonstrated are creation of two RTOS tasks which run independently, and creation and use of a task message queue to communicate between the tasks.
User Guide to Q4000/QPRO CONFIDENTIAL Information classified Confidential - Do not copy (See last page for obligations) The initRtosDemo() function first creates a mutex semaphore and then creates the primary RTOS Demo task. Figure 12-62: DemoAppRTOS - initDemoRTOS (view 1) Document Number 1135-4713 Rev G Page 125 THIS DOCUMENT CONTAINS CONFIDENTIAL AND PROPRIETARY INFORMATION OF QUAKE GLOBAL CORPORATION.
User Guide to Q4000/QPRO CONFIDENTIAL Information classified Confidential - Do not copy (See last page for obligations) The initRtosDemo() function then creates a message queue and a secondary Demo task. Figure 12-63: DemoAppRTOS - initDemoRTOS (view 2) Document Number 1135-4713 Rev G Page 126 THIS DOCUMENT CONTAINS CONFIDENTIAL AND PROPRIETARY INFORMATION OF QUAKE GLOBAL CORPORATION.
User Guide to Q4000/QPRO CONFIDENTIAL Information classified Confidential - Do not copy (See last page for obligations) The first demo task to be created, rtosDemo(), is the primary task. It samples the supply/battery voltage and does some rudimentary analysis of the data. The task also periodically creates a formatted printable string which it sends to the secondary task via a message queue to be printed.
User Guide to Q4000/QPRO CONFIDENTIAL Information classified Confidential - Do not copy (See last page for obligations) The RTOS demo secondary task, rtosDemo2(), receives a message from the initial RTOS task. The message contains some statistics that the main task has gathered and formatted into a printable string. The secondary task then prints the string.
User Guide to Q4000/QPRO Information classified Confidential - Do not copy (See last page for obligations) CONFIDENTIAL The Logger output from DemoAppRTOS is displayed in Figure 12-66. Figure 12-66: DemoAppRTOS - Logger output Document Number 1135-4713 Rev G Page 129 THIS DOCUMENT CONTAINS CONFIDENTIAL AND PROPRIETARY INFORMATION OF QUAKE GLOBAL CORPORATION.
User Guide to Q4000/QPRO 13 Satellite networks 13.1 ORBCOMM network The ORBCOMM System is a wide area, packet-switched, two-way data communication system. Communications between modems and ORBCOMM Gateways are accomplished via a constellation of Low-Earth Orbit (LEO) satellites. • The ground infrastructure contains the ORBCOMM Gateway, which provides message processing and subscriber management. • The space segment currently consists of 29 LEO satellites and one Satellite Control Center (SCC).
User Guide to Q4000/QPRO • Messages – the modem uses a message to transmit or receive a longer sequence of data. Messages typically have lengths less than 100 bytes, although the ORBCOMM System can handle longer messages (8 Kbytes maximum, but messages of less than 1000 bytes are recommended). • Globalgrams – the modem uses a Globalgram to transmit or receive a single, selfcontained data packet to or from a satellite that is not in view of an ORBCOMM Gateway.
User Guide to Q4000/QPRO For roaming applications that demand the absolute minimum message latency, it is suggested to send two messages: one as a Globalgram, and the other as a message or report. This ensures that both of these delivery avenues are utilized, but may result in higher airtime costs. Note: The term “desirable Gateway” refers to the Desired Gateways List that is maintained in the modem’s Non-Volatile Memory (NVM).
User Guide to Q4000/QPRO 13.2.1 Sequence of events: Mobile Originated–Short Burst Data message (MO-SBD) 1. User’s application loads the mobile-originated-SBD message into the Q4000/QPRO. 2. Application instructs the Q4000/QPRO to send the SBD message to the Iridium Gateway. 3. Iridium Gateway SBD equipment: • receives the SBD message • sends an acknowledgement to the modem • creates an email message with the SBD data message as an attachment to the email. 13.2.
User Guide to Q4000/QPRO CONFIDENTIAL Key points of the system-level architecture: • Message traffic sent to or from mobile devices passes through the SkyWave's IsatData Pro gateway to the Solution Provider’s application servers. • Mobile-originated messages may be from 2 to 6,400 bytes. Mobile-terminated messages may be from 2 to 10,000 bytes.
User Guide to Q4000/QPRO 14 Event driven architecture Event driven architecture is a significant element in the Q4000/QPRO user applications. Events have been defined which correspond to significant internal and external signals and conditions that are likely to appear. These events are then forwarded to the application. Most actions the application takes in response to these events are handled by function calls.
User Guide to Q4000/QPRO A request for a CAN message with a specified Parameter Group Number (PGN) has been processed. A parameter [0-65535] value indicates the PGN of the message received. A second parameter value of 0 indicates the requested message was received; non-zero indicates an error, typically a timeout. 14.1 CELL_NET_IN_VIEW The cell network availability status has changed.
User Guide to Q4000/QPRO 14.9 MTS_DTR The DTR Line on the MTS Serial Port has changed state. If the parameter [0-1] is zero, it indicates that the line has changed from High to Low Voltage; if one, it indicates the line has changed from a Low to a High voltage. 14.10 MSG_MID_CHANGED The message is queued to a secondary network. 14.11 MSG_NAK 14.
User Guide to Q4000/QPRO NMEA has the following application layer protocol rules: • Each message's starting character is a dollar sign. • The next five characters identify the talker (two characters) and the type of message (three characters). • All data fields that follow are comma-delimited. • Where data are unavailable, the corresponding field contains NULL bytes (e.g., in "123,,456", the second field's data are unavailable).
User Guide to Q4000/QPRO 14.19 POSITION_FIX The GPS engine has just completed a position fix and the information is available. The parameter indicates which Sensor Table was used. In the current implementation, the parameter passed to GPS_read should always be zero, and the parameter returned on a POSITION_FIX event should always be zero. 14.20 POWER_ON Application code executed after the POWER_ON event should perform initialization such as starting the appropriate network functions.
