Darrik Spaude
Forum Replies Created
-
AuthorPosts
-
Darrik Spaude
KeymasterConrad,
What is the full model name of the device you have? I assume it is the H4, but is it the H4-P1 or H4-P2?
Regarding the interfaces listed, there is no 3G interface. Instead it is the PPP interface (ppp0) and that only is shown when the 3G dial-up connection is made.
KeymasterOnly the USB host port would be able to supply power. The Mini-B port is the USB device port and devices do not supply power back to the host (devices only draw power).
KeymasterThis type of feature is not supported right now. I will add it to our list of feature requests.
KeymasterBen,
As far as a replacement for HyperTerminal, you could use TeraTerm:
http://logmett.com/index.php?/products/teraterm.html
If you SSH into the MTCDP, then you may use something like minicom to give AT commands directly to the radio (you would need to select the appropriate TTY device, like /dev/ttyUSB3, for example). If you are wanting to dial out, then it would be up to chat scripts which are provided in the MTCDP.
The MTCDP itself doesn’t take AT commands directly. It’s an embedded Linux system that has a radio attached as a device. Any AT commands to be given must be given directly to the cellular radio (in this case the H4) via serial access to the radio device (e.g. /dev/ttyUSB3).
KeymasterHi Ben,
This link is essentially the user guide for the MultiConnect OCG-D products:
http://www.multitech.net/developer/products/multiconnect-ocg/
You may find some datasheets and such here:
http://www.multitech.com/en_US/PRODUCTS/Families/MultiConnectOCGD/
AT commands for the H4 radio are found here (the resources page has an older version):
http://www.multitech.com/en_US/DOCUMENTS/Collateral/manuals/S000483B.pdf
GPS info is also at this link:
http://www.multitech.net/developer/products/multiconnect-ocg/references/
KeymasterHi Ben,
You could periodically check the output of the following command:
/sbin/lsusb
Best Regards,
Darrik
April 24, 2012 at 3:40 pm in reply to: Re: OCG-D and CO2 sensor kit interfacing – D/A resolutions matching. #3793KeymasterThe A/D on the OCG is 10 bit with a 0-5V range. So the basic calculation gives about a 5 mV resolution.
Of the two outputs on the CO2 sensor, we recommend using OUT1 with a 0-4V swing. This is because the OCG A/D converter will not be linear at the top end of the 0-5V range. The buffers that are protecting the A/D inputs to the processor are limited to approximately 4.9V maximum.
KeymasterI’d still like to see the actual string that is received by the iSMS. In the world of URLs, a plus (+) is used in place of a space. I’m assuming you need to encode your message before sending it to the iSMS, but it would be nice to know what the iSMS is actually receiving because then we could determine why it falls over.
See section 2.2 of RFC 1738:
http://www.ietf.org/rfc/rfc1738.txt
This may also be of use:
April 23, 2012 at 10:13 pm in reply to: Re: OCG-D and CO2 sensor kit interfacing – D/A resolutions matching. #3792KeymasterVivek,
We’re researching your question.
KeymasterKamran,
What is the actual URL that is being sent to the iSMS?
KeymasterHi Brian,
You may need to encode the characters if they are delivered via URL. See section 2.2 of RFC 1738:
http://www.ietf.org/rfc/rfc1738.txt
This may also be of use:
http://www.ozzu.com/website-design-forum/can-have-special-characters-url-names-t73983.html
http://www.w3schools.com/tags/ref_urlencode.asp
So, the following might work:
KeymasterWhat version of the iSMS firmware is in the unit?
KeymasterHi Charles,
Regarding the IP addresses, they are negotiated in the IPCP phase. The server is NOT allowing the client to know its IP address even though the client wants to know what it is:
Apr 11 17:27:41 fedoraVM pppd[2532]: rcvd [IPCP ConfReq id=0x0]
Apr 11 17:27:41 fedoraVM pppd[2532]: sent [IPCP ConfNak id=0x0 <addr 0.0.0.0>]
To avoid an endless loop, the client accepts the server’s non-information:
Apr 11 17:27:41 fedoraVM pppd[2532]: rcvd [IPCP ConfReq id=0x1]
Apr 11 17:27:41 fedoraVM pppd[2532]: sent [IPCP ConfAck id=0x1]
March 7, 2012 at 9:28 pm in reply to: Re: Reset modems in ISI Multi-Tech 8 Port Analog Modem cards #3718KeymasterISIPortModemReset uses Exar’s XR17D15 chipset to access the MPIO0 through MPIO7 pins (depending on the number of modems) to reset the modems. MPIO0 corresponds to Modem 1 and MPIO7 corresponds to Modem 8.
You may want to read the document “AN 209 – Windows & Linux API interface code for PCI/PCIe UARTs’ drivers” on Exar’s web site for the XR17D15 chipset:
Otherwise, what about writing a script in an interpreted language (Ruby, Python, Perl) to periodically monitor the ports and then call the ISIPortModemReset executable to do the reset as needed?
KeymasterThe iSMS currently does not support email to SMS, but it is something we are looking into implementing. I will forward your request to our product managers.
September 14, 2011 at 9:47 pm in reply to: can you retain GPS almanac when modem is powered off #3375KeymasterCurrently it is not possible to keep the GPS unit alive when the SocketModem is powered off. The GPS chip we use does have a battery back-up capability, but it requires a hardware modification to accommodate this. We will add your request to the hardware revision list.
KeymasterNoah,
I’ll send your e-mail address to Bryan.
KeymasterHi,
Did you review the receive API?
http://www.multitech.net/developer/products/isms/isms-receive-api/
Do you have an example of what you tried to do (sample code)? What URI did you post to?
-
AuthorPosts