[Darrik Spaude]

Hi Andrew,

According to our developers, the “RTC initialization failed” message has only been seen after flashing new firmware. A hard reset by removing power from the device has allowed the RTC to be initialized properly.

[Darrik Spaude]

Hi Andrew,

I’m dredging up this old case to ask a question. When you were seeing this problem, were you always using Deep Sleep? Or were you seeing it in both Sleep and Deep Sleep?

[Darrik Spaude]

I’ve sent the link to this thread to our sales team.

[Darrik Spaude]

Hi Kyle,

Log into the Support Portal (same credentials as multitech.net) and create a support case requesting the STEP file. Please specify the model you are interested in (MTQ-H5?).

https://support.multitech.com/

Thanks,
Darrik

[Darrik Spaude]

There isn’t an ETA yet. I believe part of the wait is related to LoRa Alliance and when specs will be finalized for other bands.

[Darrik Spaude]

Hi David,

I don’t believe there is currently a way to limit the channels to avoid interference. We have a feature request to add support for other bands. It is on the list for one of the next releases.

[Darrik Spaude]

Hi Anthony,

You will need at least pin 1 on the mDot connected to VDD (5V or 3.3V). The programming header doesn’t have VDD input. See the developer guide for more info on pin locations. VDD should be sourced from a supply with the same ground reference as that of pin 25 (GND) (e.g. jumper pin 1 of X11 on MTUDK2 to pin 1 on the mDot).

http://www.multitech.com/manuals/s000612_1_6.pdf

[Darrik Spaude]

For instructions to flash from mLinux to AEP, please create a support case at our Support Portal ( https://support.multitech.com ).

[Darrik Spaude]

Klaus created a support case, but unfortunately we have not seen this problem and we are not sure what is causing it. Klaus wondered if the recommended solution [is] to add a bitbake append recipe to the “config” recipe in order to ensure the defaults corresponds to whatever settings we would like. Our response was, yes, try that.

[Darrik Spaude]

Hi David,

I recommend that you take a look at the AT command guide found on the page for your product:

http://www.multitech.com/models/92506902LF

Take a look at the section on “DTE Modem Interface Control” (starting on page 35). ATQ0 would “quiet result codes.” ATE0 would disable echo. ATV0 would use terse responses rather than verbose responses.

[Darrik Spaude]

Just adding this information for others who might be searching for similar answers:

As of this date (12/9/2015), MultiTech does not have support for other frequency bands. We will add support after it becomes part of the LoRaWAN specification.

[Darrik Spaude]

I believe the resolution worked out through our Support Portal was:
–Disable (uncheck) “public” in the Conduit’s LoRa configuration since the mDot’s “public network” was set to off. These settings need to match.

[Darrik Spaude]

Hi Jim,

The MTDOT-EVB is sampling, but it is not released. It will be released with documentation around Feb. 2016.

[Darrik Spaude]

If you are planning on using DeviceHQ, then you should consider the 210A model instead. If not, then consider creating a support case at https://support.multitech.com/ (use the same MultiTech ID at the Support Portal as here on multitech.net).

Best Regards,
Darrik

[Darrik Spaude]

Hi Ed,

Which model do you have? The AEP model has a web interface, but the mLinux model does not. The AEP model includes “210A” in the model name while the mLinux model includes “210L” in the model name.

Best Regards,
Darrik

[Darrik Spaude]

Since the time I wrote my comment in March 2015, the Product Managers have decided to discontinue the iSMS line. Right now the iSMS is in the “Near End-of-Life” state. We had talked about being able to create a 3G replacement card, but that idea was rejected.

If there is enough demand heard through the sales group (e.g. customers contact MultiTech Sales), then the Product Managers may take another look at it.

Sorry,
Darrik

[Darrik Spaude]

I recommend you create a Support Portal case and include all of the affected serial numbers.

https://support.multitech.com/

Thanks,
Darrik

[Darrik Spaude]

Hi Nick,

Use the following command on the MultiConnect OCG products (MTCDP-x and MT100EOCG-x):

mts-id-eeprom –in-file /sys/devices/platform/i2c-gpio/i2c-0/0-0056/eeprom

Look for the device-id and that is the serial number.

For the new Conduit products (MTCDT-x), use the following command:

mts-io-sysfs show device-id

Best Regards,
Darrik

[Darrik Spaude]

The following was already posted in our Support Portal, but I will add it here in case others have the same question:

For the CDMA (our C2) radio, the second parameter in +CSQ is the frame error rate () as a percentage. For AT+CSQ, if the is 99, then assume no errors detected as long as there is a signal strength reported. If +CSQ is 99,99, then the =99 means the frame error rate is truly unknown.

The command #CAI? also includes the along with , but in this command’s response is an integer rather than a percentage.

Example #1 (third number from right in #CAI? response is integer value and corresponds to second value in +CSQ response — here integer=0 and percentage=99 (undetectable)):
at#cai?
#CAI: 299,102,2441,4,384,256,6,6,6,-97,-12,0,2,0,0,0,2,0,0,0

OK
at+csq
+CSQ: 4,99

OK

Example #2 (third number from right in #CAI? response is integer value and corresponds to second value in +CSQ response — here integer=513 and percentage=6 — integer=416 and percentage=6):
at+csq
+CSQ: 5,6

OK
at#cai?
#CAI: 299,102,2713,4,384,88,6,6,6,-98,-10,-13,4,1,1,3,2,513,0,0

OK
at+csq
+CSQ: 6,6

OK
at#cai?
#CAI: 299,102,2713,4,384,88,6,6,6,-97,-7,-11,4,1,1,3,2,416,0,0

OK

The C2 AT command guide is here and includes +CSQ and #CAI:
–> http://www.multitech.com/manuals/s000546.pdf

[Darrik Spaude]

Hi Herraiz,

I just wanted to chime in. Based on the RomBOOT message you get, I think the section “Installing Atmel SAM-BA Utility” is the one to follow. I don’t believe you need to make any hardware modifications. The SAM-BA utility monitors for special characters on the debug port. If you were NOT getting the RomBOOT message, then the bootstrap would be okay but U-boot would be failing and that is probably where the hardware modification is necessary. The RomBOOT message is coming directly from the Ateml processor’s ROM.

Regarding where the files are located, I’ll let Bryan help you with that.

Best Regards,
Darrik

[Darrik Spaude]

Hi Kirk,

I’ve created a feature request in our Support Portal on your behalf.

[Darrik Spaude]

Hi John,

Some of the carriers have already announced plans to shut down 2G networks over the next few years. However, some carriers find that they can offer services to low-bandwidth customers, so it is hard to know which carrier will want to keep it live and which will for sure disable support.

The current iSMS line (SFx00-G) only supports 2G networks. However, our Escalation group is looking into what it would take to create a 3G-capable model (we know it will involve a hardware change, but we don’t know how much time will be needed to make the software changes).

When we have some more information I’ll try to remember to write back to this thread. I’ll copy this thread’s URL into the task we’ve set up for the investigation so that we see it.

[Darrik Spaude]

Hi Kiran,

Try this guide which has a section for Linux installation:
http://www.multitech.com/manuals/s000569.pdf

[Darrik Spaude]

Check the iSMS product page for the latest official release:
http://www.multitech.com/brands/multimodem-isms#gsc.tab=0

Otherwise, for unofficial releases (beta), then check the following:
https://webfiles.multitech.com/engineering/unofficial-releases/iSMS%20(Formerly%20SMSFinder)/Firmware/

[Darrik Spaude]

The following AT command guide also applies to the MTCDP-EV3:

http://www.multitech.com/manuals/s000546.pdf

Best Regards,
Darrik

[Darrik Spaude]

Hi Mark,

I’m going to create a case for you in the Support Portal since this needs more research.

[Darrik Spaude]

Hi Ian,

The vulnerability affects versions 1.14 through 4.3 of GNU Bash. The OCG products have a vulnerable version of bash. We’re still working on what we need to do regarding this security vulnerability, but this product line should be in line for an update to resolve the vulnerability.

[Darrik Spaude]

Hi Rob,

The vulnerability affects versions 1.14 through 4.3 of GNU Bash. The iSMS has a vulnerable version of bash. However, even though the product contains a vulnerable version of bash, it doesn’t necessarily mean the vulnerability is easily exploitable. The iSMS does not use Apache for the web server which was one avenue to exploit. However, since it does have terminal access via telnet there’s always a possibility of vulnerability whether through a bug or through poor password security.

We’re still working on what else we need to do regarding this security vulnerability.

• This reply was modified 10 years, 7 months ago by Darrik Spaude.

[Darrik Spaude]

Thanks for the feedback, Mark.

[Darrik Spaude]

Hi Mark,

Were you able to update the bootstrap and if so did that resolve the problem?

Best Regards,
Darrik

[Author]

Posts