wipSoft Problems

[Wallace]

In Dec 2006 I have tried the beta version of wipSoft for Q24xx series
http://www.wavecom.com/modules/movie/scenes/forums/viewtopic.php?t=846

At the end of Jan 07 version 2.01 (assumed formal release) is available. Yet I still feel it is far from acceptable…

Some unsolved old issues :

4. TCP data “Umap” mode (AT+WIPDATA=2,x,0,y) does not work (show ERROR) !!!
Now NO MORE UNMAP MODE data transfer mentioned in new manual! Must use continuous mode

5. In continuous mode, if local side to send ETX character will close socket , but com port will NOT back to command mode automatically, Only after pressing “+++” will see “+WIPPEERCLOSE: 2,1” message
Same. Wavecom assume this is normal behaviour

7. Opening continuous mode TCP data , the “CONNECT” will not appear on new line
Same

8. If TCP continuous mode is successful, and after some data transfer, pressing “+++” back to command mode will reveive a lot of unsolicited codes +WIPDATA…
Same. Wavecom assume this is normal behaviour

9. For TCP client opening (AT+WIPCREATE=2,1,xxx) if first attempt is fail will get CME ERROR: 834, but retry will ALWAYS get error …
I got the answer now ! For a chosen index (‘1’ in the above example) if the channel creation is fail you CANNOT use it again (unless reset module)!
You need to use other index (e.g. AT+WIPCREATE=2,2,xxx…)

10. DLE/ETX pairing in continuous mode cannot be disabled !?)
    Same

And I see more :

1. In continuous mode, if you enter (control-C) first to close socket, then “+++” back to command mode, then you can never back data mode even new TCP socket is connected , need restart

2. For FTP, the first time getting file (using AT+wipfile…) is successful, but you cannot repeat this again ! Must need to reset

I don’t know if other fans here have tried the wipSoft or not. But I believe it is still a disaster for old AT# users to migrate. Not only bugs but some “behaviours” of the program makes some old applications unusable.

As stated by Wavecom wipLib is in-house developed, why they cannot build a better wipSoft based on her own Lib ?? And don’t forget SMTP/POP3 feature is not ready at this moment.

My suggestion to coming wipLib users : if you get any ERROR when using any AT+WIPxxx command, better restart your module.

[tobias]

1. In continuous mode, if you enter (control-C) first to close socket, then “+++” back to command mode, then you can never back data mode even new TCP socket is connected , need restart

That part is still there in 2.02 which is the latest version I received.
Been trying to get hold of my distributor to see if there’s any newer version around.

[t91]

I’ve managed to get a copy of SDK 3.15 (not found among SDKs available for downloading from official web site, there is only 3.14 followed by 3.16), and discovered its WIP version was 3.00.20.

This allowed me to successfully run my SMTP application on Q24xx series, although not very stable. The documentation on WIP 3 is also not quite clear on certain points, like getting SMTP error code and associated string via WIP_COPT_SMTP_STATUS_CODE.

From what I have been told by my distributor, an updated version of SDK for Q24xx series containing WIP version 3 would become available within days.

[tobias]

@t9

I’ve managed to get a copy of SDK 3.15 (not found among SDKs available for downloading from official web site, there is only 3.14 followed by 3.16), and discovered its WIP version was 3.00.20.

That’s the wip library, not the WIPSoft application.

[tobias]

1. In continuous mode, if you enter (control-C) first to close socket, then “+++” back to command mode, then you can never back data mode even new TCP socket is connected , need restart

Problem still there in WIPSoft 3.01

[awneil]

@tobias

That’s the wip library, not the WIPSoft application.

Have I correctly understood the distinction here: wavecom.com/modules/movie/sc … =6523#6523

[tobias]

1. In continuous mode, if you enter (control-C) first to close socket, then “+++” back to command mode, then you can never back data mode even new TCP socket is connected , need restart

WIPSoft 3.11 is supposed to be available by end of december and should fix this issue, as well as an issue with incoming UDP not showing peer ip/port.

[Wallace]

@tobias

1. In continuous mode, if you enter (control-C) first to close socket, then “+++” back to command mode, then you can never back data mode even new TCP socket is connected , need restart

WIPSoft 3.11 is supposed to be available by end of december and should fix this issue, as well as an issue with incoming UDP not showing peer ip/port.

Finally…hope this will come true as promised…

[Wallace]

@tobias

1. In continuous mode, if you enter (control-C) first to close socket, then “+++” back to command mode, then you can never back data mode even new TCP socket is connected , need restart

Problem still there in WIPSoft 3.01

I tried WIPSoft 3.01 but will not face this issue again.
Note, after “+++”, you will see unsolicited code like “+WIPPEERCLOSE…”, yet you still have to enter command AT+wipclose=2,1 to close the socket completely (!) before you make new one…

[mlttech]

Can anyone tell me if it is possible to use the AT commands provided by WIPSoft when you create an Open AT application that uses the WIP library? i.e. I would like to use the WIP API in my Open AT application as well as being able to send AT+WIPCFG-type commands through the UART1. Does any know if this is possible? (Using Q2686)

[wismo_coder]

Unfortunately you cannot use both. You have to choose which one you want to use, since WIPSoft is just like an OAT application and you cannot use two applications at the same time.

[awneil]

@mlttech

I would like to use the WIP API in my Open AT application as well as being able to send AT+WIPCFG-type commands through the UART1. Does any know if this is possible? (Using Q2686)

As already explained, no it’s not.

But, if you explained why you want to do this, people might be able to offer suggestions…

As it’s no longer really related to the subject of this thread, you should probably start a new one - you could include a link for reference…

[fft]

If your hardware target has at least 256KB RAM for application, you can handle bearer connections from Open AT Lua, over pretty much what you want (UART, SMS, Telnet, “AT+LUA=…” command…).

Setting up a GPRS bearer works like this:

wip.bearer_client("GPRS", {
  apn      = 'orange-mib',
  login    = 'mportail',
  password = 'mib',
  pin      = 1234})

Alternatively, you can save the config in flash if you don’t want to retype it:

GPRS_CONFIG={
  apn      = 'orange-mib',
  login    = 'mportail',
  password = 'mib',
  pin      = 1234}

function gprs_up()
  wip.bearer_client('GPRS', GPRS_CONFIG)
end

function gprs_down()
  local b = proc.bearers.GPRS
  if b then b:close() end
end
-- Save config and functions to flash:
save ('GPRS_CONFIG', 'gprs_up', 'gprs_down')

from now on, you can start the bearer with “grps_up()”, and stop it with “gprs_down()”. You can even update the config setup in GPRS_CONFIG: the new setup will be kept until you reboot, or will be kept upon reboots if you do another “save ‘GPRS_CONFIG’”. Bearers setup from Lua remain usable from C code.

[mlttech]

Thanks for the help. The reason I’m trying to do this is because I’m currently using cooperative mode, i.e. an external processor sending AT commands, and now I’m starting to implement some Open AT, but still retaining most of the control of the Wismo on my external processor. I think I may have to develop my own AT commands for accessing the WIP library or use AT+LUA. (Thanks for the code!)

[tobias]

@Wallace

@tobias

1. In continuous mode, if you enter (control-C) first to close socket, then “+++” back to command mode, then you can never back data mode even new TCP socket is connected , need restart

WIPSoft 3.11 is supposed to be available by end of december and should fix this issue, as well as an issue with incoming UDP not showing peer ip/port.

Finally…hope this will come true as promised…

WIPSoft 3.11 - ETX problem still there, UDP problem fixed.

[gavin]

UDP Mode Drop Out on receiving certain data packets from the wireless side
I have discovered a major problem with WIP 3.11 running on Fastrack Supreme modems.
When sending UDP data from a host UDP socket to a client UDP connection on the modem, if the data packet contains certain specific sequences, particularly lots of DLE and ETX characters, the modem crashes, dropping the UDP connection and returning AT status commands +CREG: 0 and +CGREG: 0
The sequence that triggers this is VERY data dependent (and very hard to trace). One example is 36 characters long and contains 6 DLE and 6 ETX characters. Changing any one of these DLE or ETX characters, or removing some other character within the data packet makes it work fine (with the various DLE and ETX characters being correctly sent out on the serial port with DLE stufffing).
An example bad packet is
16 16 FC 22 00 22 6E 19 00 10 02 03 19 10 03 10 02 03 23 44 53 49 4E 47 48 31 10 03 10 02 03 24 10 03 80 EE (this is hex representation of actual 36 charact packet data)
Changing data to the following with every non-DLE/ETX changed to 00 has the same effect (crashes out)
00 00 00 00 00 00 00 00 00 10 00 03 00 10 03 10 00 03 00 00 00 00 00 00 00 00 10 03 10 00 03 00 10 03 00 00
Changing the last ETX to $00 makes the packet work fine.
00 00 00 00 00 00 00 00 00 10 00 03 00 10 03 10 00 03 00 00 00 00 00 00 00 00 10 03 10 00 03 00 10 00 00 00
Removing one (non-DLE/ETX) character from the original packet also works fine
16 16 FC 22 00 22 6E 19 00 10 02 03 19 10 03 10 02 03 23 44 53 49 4E 47 48 10 03 10 02 03 24 10 03 80 EE

This is VERY bad because it means that I can not send certain data sequences to my mobiles without them crashing and requiring reconnection.
If I knew exactly what the "bad: sequences were, I could avoid sending them, but so far all I know is that anything with lots of DLE and ETX characters is bad, but adding a few more DLE or ETX characters can make the packet acceptable.
Better would be a version of software that does not have this “feature”. Is there a later release than 3.11

I can supply detailed information of configuration sequences and other data if helpful.

HELP!!

[dikens]

@Wallace

2. For FTP, the first time getting file (using AT+wipfile…) is successful, but you cannot repeat this again ! Must need to reset

I’m currently experiencing that error (running WIPSoft 3.11) : I was praying that it was not a WIPSoft problem, and that maybe I was doing something wrong. So I’m happy to read your post, as it means I’m not totally crazy and completely fool, but it also means I now have two issues linked to my WIPSoft version and I still can’t get the latest WIPSoft from my manufacturer… Will I have to change to another brand of modem ?

[fft]

if you’re running a Q26 or a WMP100, the following Lua sample implements basic AT commands for FTP upload and download. It does no character translations, instead it explicitely takes the file size as a parameter (or sends it as a partial AT response for downloads).

Usage:

AT+GPRSUP=<APN>,<LOGIN?>,<PASSWORD?> # start GPRS connection

AT+GPRSDOWN # stop GPRS connection

AT+FTPUPLOAD="ftp://<LOGIN>:<PASSWORD>@<FTP_SERVER>/<FILE_PATH_AND_NAME>", <FILE_SIZE>
+FTPUPLOAD: reading <FILE_SIZE> bytes
<uart switches to data mode; input FILE_SIZE bytes; uart switches back to AT mode>
+FTPUPLOAD: contacting <FTP_SERVER>
+FTPUPLOAD: uploading <FILE_PATH_AND_NAME>
OK

AT+FTPDOWNLOAD="ftp://<LOGIN>:<PASSWORD>@<FTP_SERVER>/<FILE_PATH_AND_NAME>"
+FTPDOWNLOAD: contacting <FTP_SERVER>
+FTPDOWNLOAD: downloading <FILE_PATH_AND_NAME>
+FTPDOWNLOAD: <FILE_SIZE>
<uart switches to data mode; FILE_SIZE bytes are printed; uart switches back to AT mode>
OK

It probably requires the latest Lua, accessible at svn.anyware-tech.com/wavecom/openat-lua/

Example:

AT+GPRSUP="websfr.fr"
OK
at+ftpdownload="ftp://anonymous:dummypassword@ftp.free.fr/pub/support/index.pl"
+FTPDOWNLOAD: contacting ftp.free.fr
+FTPDOWNLOAD: downloading pub/support/index.pl
+FTPDOWNLOAD: 425
<file content dumped here>
OK
AT+GPRSDOWN
OK

It does no error hanlding.

The program itself:

at.commands ["AT+GPRSUP="] = function (cfg, apn, login, password)
   wip.bearer_client ('GPRS', {apn=apn; login=login; password=password})
   at.response (cfg.port, 'rsp', "\r\nOK\r\n")
end

at.commands ["AT+GPRSDOWN"] = function ()
   proc.bearers.GPRS :close()
   at.response (cfg.port, 'rsp', "\r\nOK\r\n")
end

at.commands ["AT+FTPUPLOAD="] = function (cfg, url, size)
   local login, password, server, filename = 
      url :match "ftp://(.-):(.-)@(.-)/(.*)"

   -- Read the file content from UART
   at.response (cfg.port, 'int', "\r\n+FTPUPLOAD: reading "..size.." bytes")
   local uart = wip.fcm (cfg.port)
   local content = uart :read ('*'..size)
   uart :close ()

   -- Send it to FTP
   at.response (cfg.port, 'int', "\r\n+FTPUPLOAD: contaction "..server)
   local session = wip.ftp_client (server, { user=login, password=password, passive=true })
   at.response (cfg.port, 'int', "\r\n+UPDLOAD: uploading "..filename)
   local transfer = session :put (filename)
   transfer :write (content)

   -- Cleanup
   transfer :close()
   session :close()

   at.response (cfg.port, 'rsp', "\r\nOK\r\n")
end

at.commands ["AT+FTPDOWNLOAD="] = function (cfg, url)
   local login, password, server, filename =
      url :match "ftp://(.-):(.-)@(.-)/(.*)"
   at.response (cfg.port, 'int', "\r\n+FTPDOWNLOAD: contacting "..server)

   -- Read file from FTP
   local session = wip.ftp_client (server, { user=login, password=password, passive=true })
   at.response (cfg.port, 'int', "\r\n+FTPDOWNLOAD: downloading "..filename)
   local transfer = session :get (filename)
   local content = transfer :read '*a'
   transfer :close()
   session :close()

   -- Write it on UART
   at.response (cfg.port, 'int', "\r\n+FTPDOWNLOAD: "..#content.."\r\n")
   local uart = wip.fcm (cfg.port)
   uart :write (content)
   uart :close()
   at.response (cfg.port, 'rsp', "\r\nOK\r\n")
end