Darrik Spaude
Forum Replies Created
-
AuthorPosts
-
Darrik Spaude
KeymasterHi Greg,
There were 4 topic submissions that were flagged as spam. Do you want the content of this one modified since it is a public forum?
Darrik Spaude
KeymasterIf you have trouble with the module (trying to flash in the image) or you have more than one module that was received that booted to ROM rather than U-boot, then please create a support case and mention the serial numbers.
https://support.multitech.com/
Thanks,
DarrikDarrik Spaude
KeymasterThe iSMS hardware isn’t obsolete yet and the latest firmware was just generated yesterday. We haven’t done an official release for quite some time, but we haven’t stopped fixing bugs or adding minor features. Read the ReadMe.txt file for the 1.51.25 firmware to see if there is something new that would help:
Darrik Spaude
KeymasterFor those having a problem similar to this one, we have a document that provides information related to accessing OCG resources using the MultiConnect SDK from user permissions other than root. If you need that document, then please create a new case at Multi-Tech’s Product Support Portal and request the MultiConnect SDK Resource Permissions document.
Darrik Spaude
KeymasterIf the tarball is extracted in a Linux VM, then the file system should be case sensitive unless some other file system format is used–I would assume Linux always enforces case sensitivity. However, extracting the tarball on the Mac OS X side (not inside the VM) could lead to trouble since by default the drive is formatted as HFS+, journaled (not case sensitive).
Darrik Spaude
KeymasterNo, that doesn’t appear to be normal. We have done testing with that utility and didn’t notice the malformed responses.
Which product/model are you using?
Which version of CoreCDP are you using?
Darrik Spaude
KeymasterCase created.
Darrik Spaude
KeymasterHi Steven,
Yes, 1.51.14 is a test/beta version of the iSMS firmware. However, 1.51.14 has been through quite a bit of testing but it hasn’t been through the official release testing which would then send the firmware to the production line. It takes a fair amount of time to go through full release testing, so we prefer to get more features/fixes into the final release and as a result we put out more test/beta versions in between.
Darrik Spaude
KeymasterYes, PDU mode will probably be the most robust solution.
Darrik Spaude
KeymasterAre you using PDU mode or text mode? Try PDU mode if you were using text mode.
Sometimes this issue shows up when sending SMS across different carriers or even between different SMSC equipment within the same carrier’s network.
Darrik Spaude
KeymasterGood to hear. A search of the Internet gives several examples including this one:
http://codesamplez.com/programming/serial-port-communication-c-sharp
Darrik Spaude
KeymasterPlease give the following iSMS firmware a try for sending multi-part SMS messages.
For SF100:
For SF400 and SF800:
Darrik Spaude
KeymasterWhat device are you sending messages from?
What carrier are you using?
Have you tried sending a text SMS from the MTCMR-H5 to itself? Does that work as expected?
Darrik Spaude
KeymasterBy the way, if it is a concatenated SMS message then switch the device to PDU mode and read the PDU message. Convert the PDU data to text using a PDU decoder such as the following:
http://twit88.com/home/utility/sms-pdu-encode-decode
If it appears to be a meaningful message then likely it is a concatenated SMS.
The secondary check would be to put the SIM in another device and view the same message. Does it appear as normal meaningful text in text mode?
Darrik Spaude
KeymasterDo you know if this was a concatenated SMS?
Were there other related SMS messages before or after this message or others that hadn’t yet been received?
Darrik Spaude
KeymasterHello,
The current Multi-Tech rCell products will not work for you if you need to have two dataloggers with one of them being a USB device. You would need to use the MTCDP product line as you first thought.
Like Bryan said, you would need to do some of your own programming or script writing to make this work. My thought was that you might possibly be able to do the following:
1) Write a cron job (a periodic task in the Linux system) that periodically polls the dataloggers for information and stores that information into a file or files.
2) Write another cron job that periodically (once daily?) sends the files to a pre-determined e-mail address or web site. This would mean you wouldn’t need to call into the MTCDP to request data–if calling into the MTCDP is a requirement, then it is much more difficult. Having the MTCDP push data to something would be much simpler.
3) Point your PC monitor software to fetch data from the files.
Which dataloggers are you considering?
Do you have a limit on cellular data usage/cost?
Darrik Spaude
KeymasterHi Victor,
Are you wanting to implement a hardware-type of watchdog circuit? Are you wanting a way to reset the rCell periodically? There is an option in the web interface of the rCell that allows for periodic rebooting.
Please provide more details.
December 6, 2012 at 3:26 pm in reply to: MTSMC-H4-U: WCDMA 2100 not in the list, PH-NET PIN instead of READY #4427Darrik Spaude
KeymasterI created a case for you since you had already logged in. You should have received an e-mail.
December 6, 2012 at 3:22 pm in reply to: MTSMC-H4-U: WCDMA 2100 not in the list, PH-NET PIN instead of READY #4426Darrik Spaude
KeymasterThe P2 model is for AT&T networks. The P1 model is generic for any network including AT&T. However, if you deploy the unlocked model (P1) in the USA for use on AT&T’s network, then if there are network issues you may not get help from AT&T in resolving the problem. They approved the P2 model and expect AT&T customers to use that model.
Please create a Support Portal case and we will help you with your other questions. Your login is the same as for multitech.net.
https://support.multitech.com/
Thanks,
Darrik
Darrik Spaude
KeymasterResolution to this question was done via Multi-Tech’s Support Portal. However, I will post the general resolution to this question here for others to see.
There really isn’t a “simple” way to determine the device type. Some amount of comparing against known devices used by Multi-Tech will be needed. The ATI3 command usually gives the name of the radio used in the product. For example, knowing that a “WMP50” is known as Multi-Tech’s “G2” product, then you would know it is a GSM device. The SocketModem IP and SocketModem WiFi respond to ATI with the model name (MT100SEM-IP and MT800SWM-IP, respectively).
December 3, 2012 at 4:00 pm in reply to: iCell – Any issues using Reset Pin on a regular basis… #4353Darrik Spaude
KeymasterHi Rick,
Sorry for the delay in response. We’ve been waiting for “the list” (of dos and don’ts) from the carriers for quite a while and still have not received it. You would have to try contacting your carrier of choice for such info.
The main issues the carriers have had with customer applications are:
1) For CDMA carriers: Monitor the status of the radio to make sure it is not receiving an update. If receiving an update, then wait for it to finish before resetting the radio.
2) Some carriers have re-dial timers to prevent the radio from attempting to dial too frequently. However, a reset clears that re-dial timer and would allow the radio to re-dial too frequently which could result in a forced loss of service by the carrier.
Best Regards,
Darrik
Darrik Spaude
KeymasterHi Carel,
This is on the road map as a requested feature (possibly early 2013). We’ll inform you via the Support Portal case that you created.
November 6, 2012 at 3:27 pm in reply to: iCell – Any issues using Reset Pin on a regular basis… #4351Darrik Spaude
KeymasterHi Rick,
The main reason for concern regarding the hardware reset first of all depends on the type of radio (CDMA versus GSM/HSPA), second is in regard to the radio hardware itself, and third is in regard to what the carrier approves.
1) Resetting a CDMA radio while it is receiving an update from the carrier can be bad and may require the radio to be sent in for repair. (see recommendation in #2)
2) Resetting the radio without first properly shutting it down can result in flash memory corruption meaning the radio would need to be replaced. AT#CFUN=0 and waiting for a +WIND response indicating the radio is ready for shutdown is what we recommend.
3) The carriers do not approve products for their networks that circumvent their timers and re-try thresholds. Resetting the device can be seen by the carrier to be a potential area of abuse on their network. We recommend that your application comply with the specific carrier’s requirements.
Based on the above three areas of concern, that is why we recommend that the reset pin only be used in an emergency. We recommend having access and control of the reset pin by your application, but it should be used carefully. If the radio for some reason doesn’t respond for a long period of time, then using the reset pin may be necessary. However, if it is a CDMA modem then just make sure that the device isn’t receiving a update from the carrier. You may have to wait several minutes. Unfortunately the carriers right now can push updates at any time whether or not your application is in a critical state (like sending updates from a medical device to a doctor regarding a patient’s heart condition).
Darrik Spaude
KeymasterNilesh,
I found a case from you with similar questions. I’ll just re-open that one.
Darrik Spaude
KeymasterHi Nilesh,
To clarify, you would like to access the MTSMC-G2-GP GPS data from the public Internet, correct? In other words, you would like to access the UDP server on your Linux board via MTSMC-G2-GP which is providing the GPRS link to the Internet and retrieve GPS data from the MTSMC-G2-GP attached to your Linux board?
Would your UDP server be able to send AT commands to the MTSMC-G2-GP to retrieve the GPS data?
Maybe a CMUX protocol might work, but I haven’t tried something like this. If you would open a Support Portal case, then we may be able to help you further and possibly provide a firmware update (use your multitech.net login and password on the Support Portal).
Best Regards,
Darrik
Darrik Spaude
KeymasterNilesh,
Are you wondering if you can have one socket for GPRS and one socket for GPS?
Darrik Spaude
KeymasterHi Robert,
Do you know if there is a specific carrier for the iPhones that don’t receive the SMS? For example, does the extended message get through to AT&T iPhone but not Verizon iPhones? Some customers of various products (not necessarily our own) are having problems with Verizon iPhones.
https://community.verizonwireless.com/thread/495728
However, if you are finding that this is a general problem (affects AT&T, Verizon, Sprint, etc. iPhones), then it would be best to start a support case.
Also, have you tried contacting Apple regarding this issue? If so, what is the radar number?
Darrik Spaude
KeymasterThis type of feature is not supported right now. I will add it to our list of feature requests.
Darrik Spaude
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:
Darrik Spaude
KeymasterKamran,
What is the actual URL that is being sent to the iSMS?
-
AuthorPosts