Telit UL865 3G Modem ATD*99***1# Command “NO CARRIER” Response - embedded

Currently, I am working on Telit UL865-EUD 3G Modem. I worked with Telit GL865 GPRS modem before that's why I am familiar with AT commands and initialization logic.
My problem is that my UL865 modem always returns "NO CARRIER" to ATD*99***1# command. It is not only specific to ATD*99***1#. It results also same with other ATD Commands.
UL865 module is working. I attached to the network and open TCP socket. I tested them. But Dial Commands are not working.
My AT Command Log output is in below
Firmware Version : 12.00.616
AT
OK
AT&K=0
OK
AT#SCFG=3,1,300,600,300,10
OK
AT#SLED=2,2,2
OK
AT#SLEDSAV
OK
AT#FRWL=1,"1.2.3.4","0.0.0.0"
OK
AT+CGDCONT=1,"IP","mgbs"
OK
AT+CGSN
355855052854914
OK
AT#ICMP=2
OK
AT+CSQ
+CSQ: 24,2
OK
AT+CCLK?
+CCLK: "17/10/05,18:55:06+12"
OK
AT#SGACT=1,1,"mgbs",""
#SGACT: 5.***.***.***
OK
AT+COPS?
+COPS: 0,0,"TURKCELL",2
OK
AT+CREG?
+CREG: 0,1
OK
AT#USERID=""
OK
AT#PASSW=""
OK
AT#GAUTH=0
OK
AT#GPPPCFG="000.000.000.000"
OK
ATD*99***1#
NO CARRIER
Is there anybody who faces the same problem before?

Before the ATD command, try send:
AT+CUSD=1
This command in the Telit 3G Modules AT Commands Reference Guide:
allows control of the Unstructured Supplementary Service Data
Note that you are sending an USSD command (e.g. ATD*100#).

Related

Facing issue to connect with GPSD with UART

We connected L89 GNSS module to processor via UART. I may running gpsmon and gpspipe commands on board but but not getting NMEA logs. But when we were connected L89 to processor via USB, that time I am getting NMEA logs on gpsmon and gpspipe, what is issue with UART?
I edit /etc/default/gpsd file.
# Default settings for gpsd.
# Please do not edit this file directly - use `dpkg-reconfigure gpsd' to
# change the options.
START_DAEMON="true" command to continue
GPSD_OPTIONS=""
DEVICES="/dev/ttyS1"
USBAUTO="false"
GPSD_SOCKET="/var/run/gpsd.sock"
but I am not getting NMEA data using gpsd...

How to find it out BLE device is got unpair and connect it again

In bluez5.50, after connection establishment has done if I unpair a device and again put in discovery mode it's not able to connect(expected behavior ). But I want to connect BLE device to same running stack.
hcidump also showing the same event while BLE device goes to sleep mode or while got unpair form device side.
HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 69 reason 0x16
Reason: Connection Terminated by Local Host
So not able to find it out which event exactly occur (sleep/unpair). can someone provide me solution how to find it out unpair event and try to connect it again?
What are you using for your connection pairing? Can you try doing this over bluetoothctl as follows:-
#bluetoothctl
[bluetoothctl]scan on #Scan for a few seconds until you find your device
[bluetoothctl]scan off #Stop scanning once you have found your device
[bluetoothctl]connect 00:11:22:33:44:55
[bluetoothctl]pair 00:11:22:33:44:55
[bluetoothctl]disconnect 00:11:22:33:44:55
[bluetoothctl]remove 00:11:22:33:44:55 # This is if you want to forget the device.
[bluetoothctl]scan on #Scan for a few seconds until you find your device
[bluetoothctl]scan off #Stop scanning once you have found your device
[bluetoothctl]connect 00:11:22:33:44:55
If this doesn't work, try and use btmon in another terminal and see why the connection is failing.
I hope this helps.

Spark Streaming: Inputs are received but not processed

I am running a simple SparkStreaming application, that consists in sending messages through a socket server to the SparkStreaming Context and printing them.
This is my code, which I am running in IntelliJ IDE:
SparkConf sparkConfiguration= new SparkConf().setAppName("DataAnalysis").setMaster("spark://IP:7077");
JavaStreamingContext sparkStrContext=new JavaStreamingContext(sparkConfiguration, Durations.seconds(1));
JavaReceiverInputDStream<String> receiveData=sparkStrContext.socketTextStream("localhost",5554);
I am running this application in a standalone cluster mode, with one worker (an Ubuntu VM) and a master (my Windows host).
This is the problem: When I run the application, I see that it successfully connected to the master, but it doesn't print any lines:
it just stays this way permanently.
If I go to the Spark UI, I find that the SparkStreaming Context is receiving inputs, but they are not being processed:
Can someone help me please? Thank you so much.
You need to perform below.
sparkStrContext.start(); // Start the computation
sparkStrContext.awaitTermination(); // Wait for the computation to terminate
Once you do this , you need to post the messages at port 5554 , for this you will first need to run Netcat (a small utility found in most Unix-like systems) as a data server by using and start pushing the stream.
For example , you need to do like below.
TERMINAL 1:
# Running Netcat
$ nc -lk 5554
hello world
TERMINAL 2: RUNNING Your streaming program
-------------------------------------------
Time: 1357008430000 ms
-------------------------------------------
hello world
...
...
You can check similar example here

Telnet with Bad Request 400

Have a look at the following post:
How to telnet google using command prompt?
I've tried the same thing, but keep getting a Bad Request! (400!) I'm working on a Windows 8 PRO machine. I just want to try a few things using Telnet, but as long as I keep getting this 400-error I can't really achieve much!
All I'm doing is the following:
o www.google.com 80 (PRESSING ENTER TWICE!!!)
GET / HTTP/1.1 (ENTER)
Host: www.google.com (PRESSING ENTER TWICE!!!)
Any help appreciated!
This problem can be solved by typing in the Telnet Commands exactly, so capitalize where needed and vice versa! Check this source for more detailed information on how to setup Telnet as a Instant HTTP Client. The source also explains that once you use a BACKSPACE to retype a command that the server receiving the command may interpret it as
<bs>
and if so, declares it as an illegal request! (This is what happened to me!)
Conclusion
It seems that you can communicate the Backspace-character properly if you have the host and client communicating properly! There's an article here that explains more about it on a technical level. To get this to work for the Windows Telnet Client, I do not know how and I'm not sure whether its possible! To get around this I would like to suggest using a program like PuTTY which is a free (MIT-licensed) Win32 Telnet and SSH client. There's an option available in the PuTTY client that allows you to change how the Backspace is generated in PuTTY, that is, which one is acceptable to you're host (if at all!)!
Please read the documentation section 4.4.1 for configuring this option "properly" (if all hosts are using this protocol; otherwise you probably need to read this article and somehow configure PuTTY to be accepted by you're host or vice versa!)!
Also, in the previous example I used Google which may need other parameters to get that working, but this may not have been the best choice to get a 200-status code immediately! Try bing.com instead (working for me at the moment!)!
o www.bing.com 80 (press ENTER twice!!!)
GET / HTTP/1.1 (press ENTER)
Host: www.bing.com (press ENTER twice!!!)

Telnet Automation with Expect: Slow authentication?

I'm sending a command to a Mikrotik router using Telnet.
telnet 192.168.100.100 -l admin
Password: pass1234
[admin#ZYMMA] > /interface pppoe-server remove [find user=aspeed13]
[admin#ZYMMA] > quit
It works fine.
Now I want to automate it using expect tcl script:
#!/usr/bin/expect --
spawn telnet 192.168.100.100
expect "Login:"
send "admin\r"
expect "Password:"
send "pass1234\r"
expect "\[admin#ZYMMA\] >"
send "/interface pppoe-server remove \[find user=aspeed13\]\r"
expect "\[admin#ZYMMA\] >"
send "quit\r"
It works, but after authentication (line 6: send "pass1234\r") when the Router CLI is loading it freezes for ~10seconds with the following characters ^[[?6c^[[24;3R
Then the scripts runs ok.
My question is why Telnet loads fast when accessed manually and it takes too much time when accessed via expect script? I read in forums about telnet automation they say telnet is slow, but since manually it's too fast why it takes time to load with expect?
What you're seeing is blow-back from terminal negotiation, which is because you're not running in a real terminal. (Strictly, you are – that's expect's magic – but it's not behaving as a normal terminal does.)
The easiest fix is to set the terminal to something else before spawning the telnet session, e.g.:
#!/usr/bin/expect --
set env(TERM) dumb
spawn telnet 192.168.100.100
# Rest of your script goes here ...
Alternatively, you could try to respond correctly to the request to enter VT102 mode and the report of the cursor location (which feels like a lot of work) or you could rewrite your code so that it does everything inside interact (which connects the other end with the real terminal that you're running inside). But if setting an environment variable fixes it, why go to all that extra hassle?
(NB: I suggest setting the terminal to dumb here, but the key is that you want the stupidest terminal that works. Dumb terminals are ideal, because they're just about totally stupid, making it easy to pretend to be them…)
My answer is possibly too late. This is "Telnet autoconfig command"...I was this problem and found at Mikrotik Wiki this solution:
Add +t after login name. This switch autodetect to off.
Example:
send "admin+t\r"
It is works great and not "wait cca 10 sec" after login by expect.
There is link to Mikrotik WiKi help with more "switches":
http://wiki.mikrotik.com/wiki/Manual:Console_login_process#FAQ
P.S.: Sorry for my English.
Did you try with netcat, with telnet emulation enabled?
A little bit late to answer.
But if you want to speed up your character input with expect.
Try to generate the script with "autoexpect" command, which will save the
interaction in a file named "script.exp" in the same directory from where
you ran the command.
For instance:
cd $HOME
autoexpect telnet 192.168.100.100
# some more telnet commands here
exit
All the above commands will be saved in ~/script.exp
About Tcl, I don't know if ths script can be ran via tcl.