[START]
[DBG] Module ATCommandsInterface.cpp - Line 794: AT Thread started
[DBG] Module ATCommandsInterface.cpp - Line 797: AT Processing on hold

OK this is odd. Is there any way you can share your code with us so we can test it here?

If you don't want to do that, would it be possible to make another program with your proprietary bits stripped out, that still shows the bug?

Ashley

Ok that's bad. I also want to compile it offline. It would be nice to see a bit of support from mbed_official on this? Anyone?

Ashley

Hi guys,

Looked at this this morning, and changed a few things within the code to have it compile properly, however the linkage fails because the static data cannot fit the RAM. The issue is that GCC ARM Embedded uses newlib as implementation for the C library which is way less memory efficient than the ARMCC toolchain implementation.

Cheers,

Donatien

Hi, that's not good. But what kind of memory map you used and how much too big it was? Would it be possible to fit it by changing the default memory map: MEMORY { FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 512K RAM (rwx) : ORIGIN = 0x100000C8, LENGTH = 0x7F38

USB_RAM(rwx) : ORIGIN = 0x2007C000, LENGTH = 16K ETH_RAM(rwx) : ORIGIN = 0x20080000, LENGTH = 16K }

I'm also interested what g++ compiler options you had to use.

Br KL

Hi,

I think I've found what my power problem is. I'm using the '5.0V USB Out' pin to power the usb dongle, this would seem the logical place. It does provide a nice 5V output when the USB cable is plugged in. However, when it is removed the voltage drops to 0.5V. Is this the correct behaviour or do I have a duff mbed?

Cheers

Andy

Hi Andrew, don't use MBED to power the USB dongle. It does not have enough current driving capability. You need a separate 5V power for the dongle as shown in a picture here: http://mbed.org/cookbook/VodafoneUSBModem.

Br KL

ok thanks. Dont think that was there on the original when I built it up many months ago, jsut the hand drawn sketch.

thanks

Andy

Yep, as Kari points out, that'll do it!

I made the same mistake myself the first or second time I used the mbed.

For power supplies, we normally use 5V regulated supplies. These are pretty easy to find without spending any money since most phone chargers are 5V (except you-know-who).

If you use a micro USB breakout and just take the power rails off then you don't have to butcher the power supply, and you can still use it to charge the phone. For example:

http://proto-pic.co.uk/breakout-board-for-usb-microb/

I don't know exactly what the required peak current draw is. This is something we need to do some experiments on.

Nick has a bench supply with a current limiter, which he sets to 500mA (so we should maybe consider that the known minimum).

I use a random 5V wall-wart that has a peak of 2.5A. The door and question mark demos use TUV-certified power supplies with 5A peaks: this should definitely be considered overkill!

I'll confess here, that once we plugged a variable voltage power supply into a dongle, when it was accidently left at 15V... he no longer responds to commands.

Anyone else want to share what power supplies they are using?

I'll stick on our todo list to do something more thorough.

Ashley

Thanks guys.

Currently running with 5V/2A psu that powers the mbed, mini thermal printer and vf K3770 dongle. I did have 4 Sure Electronics 8x32 LED matrix displays connected but they didnt like 12V being accidentally connected to them (one reason to use voltage regulator!) when I plugged the wrong psu in! I quite liked the scrolling messages so have now ordered some replacement displays.

It seems to be working fine, leaving it for a longer test. I've added extra code to retrieve the time and set rtc using USSD and to display a 'Starting' message plus timestamp. What I'm seeing is that the task is restarting occasionally even though the main loop is in a while(1) loop.

My code is based on the SMS demo with the added printer code from Ashleys 3G printer application (current code looks is still using beta library so needs an update). Thanks for the printer library Ashley. Other additions include timestamps for each of the printed messages and the 'Starting' message.

I'll do further tests to see if I can nail down the problem, it may be that I just need a couple of bigger capacitors on the power rails or a different power supply.

I have a number of other 5V supplies to try, but most mobile phone ones are not rated high enough. I do have a 6V/1200mA but measured it over 8V. So need to look for ones that are regulated. Thanks for the tip regarding the breakout board. I do have a couple of smd micro usb sockets and they are a pig to solder by hand!

Cheers

Andy

Hi Andy,

for testing purposes on the dwarf door we built - I made my door controller send me a text message every time it went through a restart. I wanted to know how often this type of event happened for whatever reason.

I had the door in an 'alive' state for 6 weeks. We did notice periodic restarts, some we found out were down to power being switched off by cleaners or work on the building in the evening. Some we don't know yet.

So it would be great to find out any information if you notice the mbed or modem doing a restart. For embedded devices you need to expect this. Even commercial grade modems in industrial machines have a pull down sequence to restart a modem in case it crashes.

From power requirements in the lab where coverage is fantastic and the modem is not drawing much power I power the mbed and modem straight from my usb port on the PC. While working from home where I can only get GSM at a push and often watch the modem lose coverage I need a power supply. I used the maplins dual phone charger which has 1500 millamps. You can plug two USB ports onto this and it works well for me.

Hope this helps, Nicholas.

I don't believe the *mbed itself* should crash, ever, unless the programmer does something wrong. The RTOS and associated libraries need to be bulletproof. OK, they are not written in Haskell or Z, or some other language in which functions can be "proved" correct, but the mbed base libraries really should not be producing random resets.

If it's resetting due to a software bug, then I hope that it's in the dongle driver, as this is a much smaller piece of code to debug than the RTOS or the lwip stack.

But Nicholas is right in saying that you shouldn't expect *any* external module, that is effectively a black box in terms of the code *it* runs, to run perfectly. This is one of the reasons we put the power gating stuff in: just in case.

The dongle library should manage this itself, and be able to detect if the dongle crashes, and power cycle it accordingly. At the moment this bit hasn't been written.

On my todo list is to create a soak test that cycles through the following:

1. SMS send and receive
2. PDP construction and teardown
3. Socket/HTTP send and receive
4. Measurement of signal strength

Using a battery-buffered power supply that will survive short power outages.

I will make it periodically publish it's uptime to a server, so that we will have a record of how long it runs.

Ashley

Sound's cool. I started making a UV LED matrix display recently on stripboard, more as a therapeutic exercise than anything else. A lot of needless track-cutting, soldering, and jumper-wire creation. Using chained TI 74HC595 8 Bit Shift Registers as a driver. I suppose I should finish it off, but I'm sure I can find other ways to relax. Where did you buy your Sure Electronics matrices?

Ashley

I got the displays originally from Earthshine electronics but they seem to be out of stock permanently now. I ordered them from Sure Electronics direct via their store on ebay. Estimated delivery from 21st onwards. Look for ebay user lcdsmartie. They have lots but prices can be in various currencies depending on which country they are targetting.

Hope this helps.

Cheers

Andy

Ok thanks, I'll check 'em out.

Hi Nicholas!

Here in Finland it seems extremely difficult to get either of the supported dongles. I would like to try Huawei E367 instead. Is it possible for you to provide information on the initializer, VID, PID and possible flip string? In debug trace I can see the following:

[DBG] Module WANDongle.cpp - Line 62: Found one device reset it

[DBG] Module WANDongle.cpp - Line 70: Enumerate

[DBG] Module WANDongle.cpp - Line 185: *initializer=10001f4c

[DBG] Module WANDongle.cpp - Line 186: (*initializer)->getSerialVid()=12d1

[DBG] Module WANDongle.cpp - Line 187: (*initializer)->getSerialPid()=14c9

[DBG] Module WANDongle.cpp - Line 185: *initializer=10001f60

[DBG] Module WANDongle.cpp - Line 186: (*initializer)->getSerialVid()=19d2

[DBG] Module WANDongle.cpp - Line 187: (*initializer)->getSerialPid()=1181

[DBG] Module WANDongle.cpp - Line 78: Device has VID:12d1 PID:1446

[DBG] Module WANDongle.cpp - Line 46: Trying to connect device

[DBG] Module WANDongle.cpp - Line 62: Found one device reset it

Br Kari L

Hi Wakwak!

Did you succeed with huawei E220?

Br Kari L

Following on from the restart issues I've been experiencing, there seems to be a possible pattern. It looks like something is causing the whole mbed to restart. The sequence of events I am experiencing are:

1. Mbed prints out a starting message with timestamp.

2. Receiver task prints a starting message.

3. Use USSD to get current date/time and set mbed rtc.

4. Wait for SMS

5. When SMS received its printed along with the timestamp.

6. Mbed restarts most of the time - back to 1.

I'm going to double/triple check the code to make sure there is nothing obvious and compare to sms receive examples.

I was originally thinking it was a power issue, but that would more than likely have shown a restart when the printer starts or the printer didnt print, not after its finished. I've not left it running with a console connected so cant see any detailed debug messages, thats the next step.

Other things I'm going to check are the memory and stack usage for the task, just to make sure this isnt causing a problem - big buffers for received messages etc. Also need to brush up on my concurrent programming and the mbed rtos library too.

Any further suggestions?

Thanks

Andy

Ok, this is is useful. Next week I'm going to deep dive into the code (got droidcon NL this week).

Are you using the bleeding edge version of the library? If not, can you try it?

http://mbed.org/users/donatien/code/VodafoneUSBModem_bleedingedge/

There was a race condition fixed a couple of weeks ago, which I notice has not been pushed into:

http://mbed.org/users/mbed_official/code/VodafoneUSBModem/

I've just sent an email about this, and to find out what their update cycle is.

Ashley

When I spoke to Donatien a few days ago, he said he used the standard gcc export, in which case the options should be as so (obtained by doing an export to gcc myself a few minutes ago):

LIBRARY_PATHS = -L./mbed/LPC1768/GCC_ARM 
LIBRARIES = -lmbed -lcapi 
LINKER_SCRIPT = ./mbed/LPC1768/GCC_ARM/LPC1768.ld

############################################################################### 
CC = $(GCC_BIN)arm-none-eabi-gcc
CPP = $(GCC_BIN)arm-none-eabi-g++
CC_FLAGS = -c -Os -fno-common -fmessage-length=0 -Wall -fno-exceptions -mcpu=cortex-m3 -mthumb -ffunction-sections -fdata-sections 
ONLY_C_FLAGS = -std=gnu99
ONLY_CPP_FLAGS = -std=gnu++98
CC_SYMBOLS = -DTARGET_LPC1768 -DTOOLCHAIN_GCC_ARM -DNDEBUG -D__CORTEX_M3


AS = $(GCC_BIN)arm-none-eabi-as

LD = $(GCC_BIN)arm-none-eabi-gcc
LD_FLAGS = -mcpu=cortex-m3 -mthumb -Wl,--gc-sections
LD_SYS_LIBS = -lstdc++ -lsupc++ -lm -lc -lgcc

So NDEBUG has been specified so this disables calls to ASSERT, so those are stripped

no -g flag, so no debug symbols taking up space

-ffunction-sections -fdata-sections are specified along with -gc-sections which should result in a smaller binary being produced, since it should only link those functions and data elements used (see http://elinux.org/Function_sections).

no -s option for symbol stripping, does this matter?

it's been optimised for size with -Os, but is this really the best set of optimisations to reduce overall RAM usage? Perhaps a customized set would do better?

This needs someone familiar with newlib and gcc to take a good look.

Looking at threads like:

http://mbed.org/forum/mbed/topic/3235/?page=1#comment-20264

It looks like they are already working on reducing the memory footprint of newlib.

Ashley

Hi Kari,

this modem looks like the premier modem being shipped by the mobile operator '3' in the UK.

I don't actually know the flip string for this modem and or PID/VID values.

What you could do is try it in an up to date Linux machine and use usb_modeswitch to try and backwards engineer it. However on my Linux machine this modem is not supported! (I'm using Kbuntu 10.04).

Or you could put a USB sniffer on a Windows machine and insert your dongle. You should be able to capture the flip string on the USB bus as windows sends it to the modem.

You could also try and see if it's actually controlled via a small web server running on the modem - which many modern modems are starting to do. When you run the stick on Windows - it you control via a web page then this would mean it might be using this method. The modem will be using CDC modem for communications rather than legacy AT commands.

Last option is to try and contact Huawei technical support to see if they can provide answers...:-/

Would be interesting to know how you get on.

Kind regards, Nicholas.

Ok, converting to other kind of modems would be complicated. I just want to use k3772 (simple without Z at the end) . I understood that this it's made by HuaWei.

To enable k3772 what should I do ?

I am asking because on local market are available only those k3772

Kind Regards, Daniel

Hi Nicholas,

thanks for information. Let's see what I can do. But I wonder if Huawei E220 would be easier, you said some time ago (in response to Wakwak) that it would be interesting for Vodafone. Would a modified VodafoneK3770Initializer do the job for it?

(I only need to get HTTP working)

Br Kari L

Looks like I dont have access to the bleeding edge code :-(

Andy

Following on from the bleeding edge code, I've checked the library versions, the one I was using is revision 58, the latest available is 63 including revision 61 with a comment refering to race condition.

I'll give this one a try. I couldnt update my exsiting library as I'd hacked the core/dbg.cpp to allow alternative serial ports to be used as debug output. The current code is fixed to the usb output.

Thanks

Andy

Hi Nicholas!

I managed to flip the E367 to the mode "1506" in two different ways. The first one exposes 4 modem protocols and the second exposes 5.

Maybe you can tell if this is hopeless. I tried to attach 2 first serial ports but the result was as follows:

flip string 0x55, 0x53, 0x42, 0x43, 0x00, 0x00, 0x00, 0x00, 0, 0, 0, 0, 0, 0, 0, 0x11, 0x06, 0x00, 0, 0, 0x01, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #0; Class:ff; SubClass:01; Protocol:01
[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #1; Class:ff; SubClass:01; Protocol:07
[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #2; Class:ff; SubClass:01; Protocol:03
[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #2; Class:ff; SubClass:01; Protocol:02
[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #2; Class:08; SubClass:06; Protocol:50
[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #2; Class:08; SubClass:06; Protocol:50
[DBG] Module WANDongle.cpp - Line 78: Device has VID:12d1 PID:1506
[DBG] Module WANDongle.cpp - Line 82: m_pInitializer=10001f4c
[DBG] Module WANDongle.cpp - Line 83: m_pInitializer->getSerialVid()=12d1
[DBG] Module WANDongle.cpp - Line 84: m_pInitializer->getSerialPid()=1506
[DBG] Module WANDongle.cpp - Line 87: The dongle is in virtual serial mode
[DBG] Module WANDongle.cpp - Line 96: Connecting serial port #1
[DBG] Module WANDongle.cpp - Line 97: Ep 10003574
[DBG] Module WANDongle.cpp - Line 98: Ep 100035bc
[DBG] Module WANDongleSerialPort.cpp - Line 64: Read packet on 10002914
[DBG] Module WANDongle.cpp - Line 96: Connecting serial port #2
[DBG] Module WANDongle.cpp - Line 97: Ep 10003604
[DBG] Module WANDongle.cpp - Line 98: Ep 1000364c
[DBG] Module WANDongleSerialPort.cpp - Line 64: Read packet on 100029ec
[DBG] Module WANDongle.cpp - Line 102: Device connected
[DBG] Module ATCommandsInterface.cpp - Line 52: Opening AT interface
[DBG] Module ATCommandsInterface.cpp - Line 71: AT interface opened
[DBG] Module ATCommandsInterface.cpp - Line 801: AT Processing started
[DBG] Module ATCommandsInterface.cpp - Line 79: Sending ATZ E1 V1
[DBG] Module ATCommandsInterface.cpp - Line 812: Trying to read a new line
[DBG] Module ATCommandsInterface.cpp - Line 154: Executing command ATZ E1 V1
[DBG] Module ATCommandsInterface.cpp - Line 276: Trying to read a new line from stream
[DBG] Module ATCommandsInterface.cpp - Line 186: Sending command ready signal to AT thread & aborting current blocking read operation
[DBG] Module ATCommandsInterface.cpp - Line 193: Trying to enter abortRead()
[DBG] Module ATCommandsInterface.cpp - Line 292: Read was interrupted
[DBG] Module ATCommandsInterface.cpp - Line 814: Trying to send a pending command
[DBG] Module ATCommandsInterface.cpp - Line 545: status = 32, msg = 268447420
[DBG] Module ATCommandsInterface.cpp - Line 555: Sending pending command
[DBG] Module ATCommandsInterface.cpp - Line 812: Trying to read a new line
[DBG] Module ATCommandsInterface.cpp - Line 276: Trying to read a new line from stream
[DBG] Module ATCommandsInterface.cpp - Line 207: Trying to enter abortRead()
[WARN] Module ATCommandsInterface.cpp - Line 211: Command returned no message
[DBG] Module ATCommandsInterface.cpp - Line 292: Read was interrupted
[WARN] Module ATCommandsInterface.cpp - Line 88: No response, trying again

The other case exposed 5 protocols but I was not able to attach port to protocol 9:

[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #0; Class:ff; SubClass:01; Protocol:01
[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #1; Class:ff; SubClass:01; Protocol:09
[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #2; Class:ff; SubClass:01; Protocol:08
[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #2; Class:ff; SubClass:01; Protocol:03
[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #2; Class:ff; SubClass:01; Protocol:02
[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #2; Class:08; SubClass:06; Protocol:50
[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #2; Class:08; SubClass:06; Protocol:50

Is this hopeless? I don't have much time... Br Kari L

OK, latest is that I'm now trying the latest library, revision 63 however I've only done limited testing. One other thing I did was to increase the stack size to double what it was originally on the SMS receiving thread. I'm leaving it running for a couple of days while I'm away from home and will check results when I get back. If this stil works then I'll try reducing stack size to see if it starts to show signs of restarting.

Cheers

Andy

WARNING

Just updated one of my apps to the latest mbed 44 library and it seems that an incompatibility has crept in. The messages I see are:

class "mbed::Serial" has no member "RxIrq"
class "mbed::Serial" has no member "TxIrq"

This is in file VodafoneUSBModem/serial/io/IOSerialStream.cpp, affected code is:

IOSerialStream::IOSerialStream(mbed::Serial& serial) : m_serial(serial), m_serialTxFifoEmpty(true),
m_availableSphre(1), m_spaceSphre(1), m_inBuf(), m_outBuf()
{
  m_availableSphre.wait();
  m_spaceSphre.wait();
  //Attach interrupts
  m_serial.attach(this, &IOSerialStream::readable, mbed::Serial::RxIrq);
  m_serial.attach(this, &IOSerialStream::writeable, mbed::Serial::TxIrq);
}

/*virtual*/ IOSerialStream::~IOSerialStream()
{
  m_serial.attach(NULL, mbed::Serial::RxIrq);
  m_serial.attach(NULL, mbed::Serial::TxIrq);
}

My guess is that some name has changed or the definition has moves to a different file.

Without having the mbed library source code its not an easy one for me to track down.

Cheers

Andy

Hi Andy,

You guessed right, as part of the complete refactoring of the mbed library we moved the parameter type definitions from the C++ API to the C API. The missing interrupt enum has moved from Serial.h to serial_api.h: serial_api.h

Cheers, Emilio

Just looking at this, the file Serial.h is being included by VodafoneUSBModem/serial/io/IOSerialStream.h, which in turn includes serial_api.h so things should still work as before.

One for the Dongle library developers.

Thanks

Andy

Hi Kari,

sorry about the delay. We can't spend any time on modems that we don't support. So it's just spare time and Love for queries like this.

It looks like you are on the correct track. In that the modem is acting as a serial device. It might be waiting for the correct AT command sequence to get into a working state. (e.g. what mode is the modem sending commands back across the AT interface? Could be GSM or UCS?)

What I would do is stick the modem into your Linux machine, bring up cutecom on your ttyACM0 endpoint. The send some simple AT commands to the modem to find out what format messages are coming back.

Post what you get on this forum - there should be someone who can help figure out what's wrong.

Make sure you use usb_modeswitch to flip the modem too! :-)

Kind regards, Nicholas.

flip string 0x55, 0x53, 0x42, 0x43, 0x00, 0x00, 0x00, 0x00, 0, 0, 0, 0, 0, 0, 0, 0x11, 0x06, 0x00, 0, 0, 0x01, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #0; Class:ff; SubClass:01; Protocol:01
[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #1; Class:ff; SubClass:01; Protocol:07
[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #2; Class:ff; SubClass:01; Protocol:03
[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #2; Class:ff; SubClass:01; Protocol:02
[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #2; Class:08; SubClass:06; Protocol:50
[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #2; Class:08; SubClass:06; Protocol:50
[DBG] Module WANDongle.cpp - Line 78: Device has VID:12d1 PID:1506
[DBG] Module WANDongle.cpp - Line 82: m_pInitializer=10001f4c
[DBG] Module WANDongle.cpp - Line 83: m_pInitializer->getSerialVid()=12d1
[DBG] Module WANDongle.cpp - Line 84: m_pInitializer->getSerialPid()=1506
[DBG] Module WANDongle.cpp - Line 87: The dongle is in virtual serial mode
[DBG] Module WANDongle.cpp - Line 96: Connecting serial port #1
[DBG] Module WANDongle.cpp - Line 97: Ep 10003574
[DBG] Module WANDongle.cpp - Line 98: Ep 100035bc
[DBG] Module WANDongleSerialPort.cpp - Line 64: Read packet on 10002914
[DBG] Module WANDongle.cpp - Line 96: Connecting serial port #2
[DBG] Module WANDongle.cpp - Line 97: Ep 10003604
[DBG] Module WANDongle.cpp - Line 98: Ep 1000364c
[DBG] Module WANDongleSerialPort.cpp - Line 64: Read packet on 100029ec
[DBG] Module WANDongle.cpp - Line 102: Device connected
[DBG] Module ATCommandsInterface.cpp - Line 52: Opening AT interface
[DBG] Module ATCommandsInterface.cpp - Line 71: AT interface opened
[DBG] Module ATCommandsInterface.cpp - Line 801: AT Processing started
[DBG] Module ATCommandsInterface.cpp - Line 79: Sending ATZ E1 V1
[DBG] Module ATCommandsInterface.cpp - Line 812: Trying to read a new line
[DBG] Module ATCommandsInterface.cpp - Line 154: Executing command ATZ E1 V1
[DBG] Module ATCommandsInterface.cpp - Line 276: Trying to read a new line from stream
[DBG] Module ATCommandsInterface.cpp - Line 186: Sending command ready signal to AT thread & aborting current blocking read operation
[DBG] Module ATCommandsInterface.cpp - Line 193: Trying to enter abortRead()
[DBG] Module ATCommandsInterface.cpp - Line 292: Read was interrupted
[DBG] Module ATCommandsInterface.cpp - Line 814: Trying to send a pending command
[DBG] Module ATCommandsInterface.cpp - Line 545: status = 32, msg = 268447420
[DBG] Module ATCommandsInterface.cpp - Line 555: Sending pending command
[DBG] Module ATCommandsInterface.cpp - Line 812: Trying to read a new line
[DBG] Module ATCommandsInterface.cpp - Line 276: Trying to read a new line from stream
[DBG] Module ATCommandsInterface.cpp - Line 207: Trying to enter abortRead()
[WARN] Module ATCommandsInterface.cpp - Line 211: Command returned no message
[DBG] Module ATCommandsInterface.cpp - Line 292: Read was interrupted
[WARN] Module ATCommandsInterface.cpp - Line 88: No response, trying again

[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #0; Class:ff; SubClass:01; Protocol:01
[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #1; Class:ff; SubClass:01; Protocol:09
[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #2; Class:ff; SubClass:01; Protocol:08
[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #2; Class:ff; SubClass:01; Protocol:03
[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #2; Class:ff; SubClass:01; Protocol:02
[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #2; Class:08; SubClass:06; Protocol:50
[DBG] Module WANDongleInitializer.cpp - Line 117: Interface #2; Class:08; SubClass:06; Protocol:50