Hi,
I have one 4G cape board (Yantrr VAYU2-4GEC25-E) like http://yantrr.com/vayu2-4gec25-e and mount it on BeagleBone Green Wireless.
I insert hologram sim and follow VAYU2-4GEC25-E user guide (VAYU2 - Yantrr Wiki) to build a PPP connection. But it fails.
My vwdial file is as following :
GNU nano 2.7.4 File: /etc/wvdial.conf
[Dialer Defaults]
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Init3 = AT+CGDCONT=1,"IP","hologram"
Modem Type = USB Modem
Phone = *99***1#
ISDN = 0
Username = " "
Password = " "
Modem = /dev/ttyUSB3
Baud = 9600
Stupid Mode = on
Auto DNS = 0
Carrier Check = yes
Auto Reconnect = yes
NEW PPPD = yes
Dial Command = ATDT
The error message :
--> Sending: AT+CGDCONT=1,"IP","hologram"
AT+CGDCONT=1,"IP","hologram"
ERROR
--> Bad init string.
Your command to set the APN, AT+CGDCONT=1,"IP","hologram" , looks correct to me. So does the wvdial. Based on the error message saying its a Bad init string my guess that this is a syntax/code error.
PS: I test the network latency via ping google.com.
The log attaches below.
root@beaglebone:/sys/class/gpio/gpio45# ping google.com
PING google.com (172.217.20.78) 56(84) bytes of data.
64 bytes from ams15s33-in-f14.1e100.net (172.217.20.78): icmp_seq=1 ttl=47 time=617 ms
64 bytes from ams15s33-in-f14.1e100.net (172.217.20.78): icmp_seq=2 ttl=47 time=618 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 2 received, 33% packet loss, time 2268ms
rtt min/avg/max/mdev = 617.723/618.281/618.839/0.558 ms
root@beaglebone:/sys/class/gpio/gpio45# traceroute google.com
traceroute to google.com (172.217.17.78), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 218.102.244.87.jtglobal.com (87.244.102.218) 835.753 ms 835.553 ms 835.341 ms
5 90.160.35.5.jtglobal.com (5.35.160.90) 840.466 ms 840.255 ms 840.036 ms
6 120.160.35.5.jtglobal.com (5.35.160.120) 839.828 ms 291.236 ms 290.820 ms
7 16.160.35.5.jtglobal.com (5.35.160.16) 291.582 ms 291.407 ms 290.792 ms
8 133.160.35.5.jtglobal.com (5.35.160.133) 295.050 ms 294.819 ms 289.387 ms
9 145.160.35.5.jtglobal.com (5.35.160.145) 293.883 ms 293.484 ms 291.314 ms
10 ae68-3000.edge6.Paris1.Level3.net (213.242.120.93) 290.708 ms 288.687 ms 291.669 ms
11 * * *
12 72.14.218.78 (72.14.218.78) 292.007 ms 291.596 ms 289.918 ms
13 108.170.245.6 (108.170.245.6) 290.469 ms 108.170.244.197 (108.170.244.197) 292.695 ms 108.170.244.198 (108.170.244.198) 292.267 ms
14 108.170.233.114 (108.170.233.114) 312.569 ms 209.85.251.216 (209.85.251.216) 309.365 ms 108.170.238.162 (108.170.238.162) 289.413 ms
15 216.239.48.37 (216.239.48.37) 295.279 ms 295.223 ms 294.814 ms
16 108.170.238.210 (108.170.238.210) 301.822 ms 302.933 ms 301.232 ms
17 209.85.254.48 (209.85.254.48) 305.786 ms 216.239.43.26 (216.239.43.26) 303.491 ms 301.704 ms
18 108.170.241.225 (108.170.241.225) 301.274 ms 302.209 ms 108.170.241.193 (108.170.241.193) 299.380 ms
19 108.170.236.139 (108.170.236.139) 299.455 ms 297.317 ms 108.170.236.141 (108.170.236.141) 301.807 ms
20 ams16s30-in-f14.1e100.net (172.217.17.78) 301.045 ms 301.301 ms 301.286 ms
Great to hear this worked out! What did the trick?
Due to the added complexity in our network from aggregating 550+ carriers there is always going to be a bit more latency with us compared to your local carrier however we normally see values of around 300ms when pining google. We tested in various different countries, but not Taiwan so it could be that either data traffic happened to congested when you ran the test or that data is a bit slower than our network average in Taiwan.