I have got Panasonic FZ-G1 with EM7305 GSM wireless modem and I have to get IMEI of the modem. I tried to send command “AT+CGSN” via USB using LibUsbDotNet, but it didn’t work. I used configuration 0x1, interface 0x3 and endpoint 0x5. Is this setup correct, please? Can I send an AT command directly to the usb endpoint?
Thank you very much.
That depends… You should really parse descriptors to validate the endpoint address for the AT command function.
cfg 1 and interface 3 is most likely correct. But endpoint 5 is probably not. Difficult to know for sure without seeing the descriptors. In any case: You don’t tell us how you concluded that “it didn’t work”. You’ll need at least two endpoints for any conclusion like that AFAIK (1 bulk out and 1 bulk in).
Sure. The real question is: Why would you do that? Drivers are there for a reason. It’s a bit simpler to relate to the AT command channel as a serial port instead of 3 USB endpoints…
But you can of course send anything you like directly. After all, that’s what the driver does.
I am using configuration 1, interface 3 and endpoints 4 (I write command into) and 3 (I read). I am getting byte sequence 161,32,0,0,2,0,2,0,0,0 (10 bytes) for every command I try (“AT+CGSN”, “ATI”, …). Please, can anybody help? Thank you very much.
It’s still not clear to me why you want to reinvent the wheel, but your problems have absolutely nothing with the subject to do. Or Sierra Wireless modems. Or modems at all.
You are attempting to write a new USB serial driver. That’s fine. Go to usb.org/ , download the specs, and do it properly. If you cheat, then you fail. The descriptors are there for a reason. The protocol is there for a reason. There is NO reason to start guessing endpoint addresses.
As for the byte sequence you see, I suggest you use some tool to analyze the USB data if you don’t immeditately recognise packets like that one. “a1 20 00 00 02 00 02 00 00 00” looks like a class specific notification on an interrupt endpoint, referring to interface #2. I assume interface #2 is a vendor specific function (but you never provided any descriptors, so who knows…), but I’m guessing it is using standard CDC notifications anyway. If so, then 0x20 is “SERIAL_STATE”. The length (2) is consistent with that guess. The last two bytes (00 00) is the UART state bitmatp.
But please ignore all that. Use one of the gazillion serial drivers already written.
Install the Windows driver. I don’t know how to do that, but I cannot imagine they have made it so hard that it is simpler to reimplement the driver in userspace…
Not that it is that difficult to write a serial USB driver, but it does require a bit more work than you seem to think. At the very least, you do need to parse the descriptors. And you should verify that the endpoints you are using is the the type you expect.
But as I said: It cannot be that much work to install an existing driver. Even in Windows
It seems to me that you disregard all simple solutions without explaining why, or even if you considered them at all. Only to ask about some arbitrary detail about an over-complicated non-generic solution to a problem only you can see. You can of course continue to do that if you like,but I think the strategy is unlikely to produce any useful results.