USB receiver communication Raspberry Pi
up vote
0
down vote
favorite
I'm wanting to connect a USB receiver to my Pi (3) so to be able to able to receive Rf transmittions from hand help remotes running 403MHz.
I need to gather the transmitters ID through the connected receiver so I can represent it onto a graphic display (not I/O pins on the Pi) on a connected monitor.
The Pi sees the device:
[ 2.768680] systemd[1]: Started udev Coldplug all Devices.
[ 2.802568] usb 1-1.2: New USB device found, idVendor=1111, idProduct=6555
[ 2.802593] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2.802607] usb 1-1.2: Product: Sherlotronics Complex V3
[ 2.802619] usb 1-1.2: Manufacturer: Sherlotronics PTY/01
[ 2.802632] usb 1-1.2: SerialNumber: UÿkPwQI0'%xffffffc2xffffff87060
[ 2.805162] i2c /dev entries driver
/dev/ttyACM0 - Sherlotronics_PTY_01_Sherlotronics_Complex_V3
.... but I need to know how to read off the device so to gather the info off it on the transmitter signals.
Almost like snooping but I will asign each transmitter (80+) a graphic display image.
The device has a driver (dll) written for Windows that windows sees as a Plug n Play but the supplier doesnt have a Linux equivalant.
usb-device ttyusb
edited Nov 23 at 14:15
Rui F Ribeiro
38.2k1475125
asked Feb 13 '17 at 10:44
MimmsBoy
1
|
show 2 more comments
up vote
0
down vote
favorite
I'm wanting to connect a USB receiver to my Pi (3) so to be able to able to receive Rf transmittions from hand help remotes running 403MHz.
I need to gather the transmitters ID through the connected receiver so I can represent it onto a graphic display (not I/O pins on the Pi) on a connected monitor.
The Pi sees the device:
[ 2.768680] systemd[1]: Started udev Coldplug all Devices.
[ 2.802568] usb 1-1.2: New USB device found, idVendor=1111, idProduct=6555
[ 2.802593] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2.802607] usb 1-1.2: Product: Sherlotronics Complex V3
[ 2.802619] usb 1-1.2: Manufacturer: Sherlotronics PTY/01
[ 2.802632] usb 1-1.2: SerialNumber: UÿkPwQI0'%xffffffc2xffffff87060
[ 2.805162] i2c /dev entries driver
/dev/ttyACM0 - Sherlotronics_PTY_01_Sherlotronics_Complex_V3
.... but I need to know how to read off the device so to gather the info off it on the transmitter signals.
Almost like snooping but I will asign each transmitter (80+) a graphic display image.
The device has a driver (dll) written for Windows that windows sees as a Plug n Play but the supplier doesnt have a Linux equivalant.
usb-device ttyusb
edited Nov 23 at 14:15
Rui F Ribeiro
38.2k1475125
asked Feb 13 '17 at 10:44
MimmsBoy
1
Your device got attached as atty, namely/dev/ttyACM0. You can communicate with it by reading from or writing to this device. The format depends on this device, you need some kind of manual or datasheet for it (which you should have received when you bought it). I can't find anything with Google. Alternatively, look for datasheets for the chips used on the device (open it up, look at PCB).
– dirkt
Feb 13 '17 at 14:02
If it's right: ARM2, STM32F103, RBT6, GH24E 9U, CHN GH 350. Hope that is what you are asking for?
– MimmsBoy
Feb 13 '17 at 16:02
If it's an ARM cpu in the device, you are out of luck: The protocol could be literally anything. You need some sort of manual, unless it's a "chatty" protocol that provides help.
– dirkt
Feb 13 '17 at 16:11
Would it make a difference if the program was written for Windows 10 ioT for the Pi or is it the ARM2 chip that is an issue for Linux or ioT? If I find an alternative device, is there a chipset that I should source? I will contact the supplier and ask about the manual or technical spec. Many thanks Dirkt
– MimmsBoy
Feb 14 '17 at 5:51
The issue is not the ARM2 chip, the issue is there's no information about the protocol, and the ARM is a general CPU, so the protocol is determined by whatever program runs on that CPU (there's no datasheet where one could look that up). If you have any other kind of source of information, e.g. a working Windows driver, a working Windows example program, some output if you just connect withminicomand press return, infro from the company you bought it from, or anything else, one can go from there.
– dirkt
Feb 14 '17 at 6:48
|
show 2 more comments
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I'm wanting to connect a USB receiver to my Pi (3) so to be able to able to receive Rf transmittions from hand help remotes running 403MHz.
I need to gather the transmitters ID through the connected receiver so I can represent it onto a graphic display (not I/O pins on the Pi) on a connected monitor.
The Pi sees the device:
[ 2.768680] systemd[1]: Started udev Coldplug all Devices.
[ 2.802568] usb 1-1.2: New USB device found, idVendor=1111, idProduct=6555
[ 2.802593] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2.802607] usb 1-1.2: Product: Sherlotronics Complex V3
[ 2.802619] usb 1-1.2: Manufacturer: Sherlotronics PTY/01
[ 2.802632] usb 1-1.2: SerialNumber: UÿkPwQI0'%xffffffc2xffffff87060
[ 2.805162] i2c /dev entries driver
/dev/ttyACM0 - Sherlotronics_PTY_01_Sherlotronics_Complex_V3
.... but I need to know how to read off the device so to gather the info off it on the transmitter signals.
Almost like snooping but I will asign each transmitter (80+) a graphic display image.
The device has a driver (dll) written for Windows that windows sees as a Plug n Play but the supplier doesnt have a Linux equivalant.
usb-device ttyusb
edited Nov 23 at 14:15
Rui F Ribeiro
38.2k1475125
asked Feb 13 '17 at 10:44
MimmsBoy
1
I'm wanting to connect a USB receiver to my Pi (3) so to be able to able to receive Rf transmittions from hand help remotes running 403MHz.
I need to gather the transmitters ID through the connected receiver so I can represent it onto a graphic display (not I/O pins on the Pi) on a connected monitor.
The Pi sees the device:
[ 2.768680] systemd[1]: Started udev Coldplug all Devices.
[ 2.802568] usb 1-1.2: New USB device found, idVendor=1111, idProduct=6555
[ 2.802593] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2.802607] usb 1-1.2: Product: Sherlotronics Complex V3
[ 2.802619] usb 1-1.2: Manufacturer: Sherlotronics PTY/01
[ 2.802632] usb 1-1.2: SerialNumber: UÿkPwQI0'%xffffffc2xffffff87060
[ 2.805162] i2c /dev entries driver
/dev/ttyACM0 - Sherlotronics_PTY_01_Sherlotronics_Complex_V3
.... but I need to know how to read off the device so to gather the info off it on the transmitter signals.
Almost like snooping but I will asign each transmitter (80+) a graphic display image.
The device has a driver (dll) written for Windows that windows sees as a Plug n Play but the supplier doesnt have a Linux equivalant.
usb-device ttyusb
usb-device ttyusb
edited Nov 23 at 14:15
Rui F Ribeiro
38.2k1475125
asked Feb 13 '17 at 10:44
MimmsBoy
1
edited Nov 23 at 14:15
Rui F Ribeiro
38.2k1475125
asked Feb 13 '17 at 10:44
MimmsBoy
1
edited Nov 23 at 14:15
Rui F Ribeiro
38.2k1475125
edited Nov 23 at 14:15
Rui F Ribeiro
38.2k1475125
edited Nov 23 at 14:15
Rui F Ribeiro
38.2k1475125
38.2k1475125
asked Feb 13 '17 at 10:44
MimmsBoy
1
asked Feb 13 '17 at 10:44
MimmsBoy
1
asked Feb 13 '17 at 10:44
MimmsBoy
1
1
Your device got attached as atty, namely/dev/ttyACM0. You can communicate with it by reading from or writing to this device. The format depends on this device, you need some kind of manual or datasheet for it (which you should have received when you bought it). I can't find anything with Google. Alternatively, look for datasheets for the chips used on the device (open it up, look at PCB).
– dirkt
Feb 13 '17 at 14:02
If it's right: ARM2, STM32F103, RBT6, GH24E 9U, CHN GH 350. Hope that is what you are asking for?
– MimmsBoy
Feb 13 '17 at 16:02
If it's an ARM cpu in the device, you are out of luck: The protocol could be literally anything. You need some sort of manual, unless it's a "chatty" protocol that provides help.
– dirkt
Feb 13 '17 at 16:11
Would it make a difference if the program was written for Windows 10 ioT for the Pi or is it the ARM2 chip that is an issue for Linux or ioT? If I find an alternative device, is there a chipset that I should source? I will contact the supplier and ask about the manual or technical spec. Many thanks Dirkt
– MimmsBoy
Feb 14 '17 at 5:51
The issue is not the ARM2 chip, the issue is there's no information about the protocol, and the ARM is a general CPU, so the protocol is determined by whatever program runs on that CPU (there's no datasheet where one could look that up). If you have any other kind of source of information, e.g. a working Windows driver, a working Windows example program, some output if you just connect withminicomand press return, infro from the company you bought it from, or anything else, one can go from there.
– dirkt
Feb 14 '17 at 6:48
|
show 2 more comments
Your device got attached as atty, namely/dev/ttyACM0. You can communicate with it by reading from or writing to this device. The format depends on this device, you need some kind of manual or datasheet for it (which you should have received when you bought it). I can't find anything with Google. Alternatively, look for datasheets for the chips used on the device (open it up, look at PCB).
– dirkt
Feb 13 '17 at 14:02
If it's right: ARM2, STM32F103, RBT6, GH24E 9U, CHN GH 350. Hope that is what you are asking for?
– MimmsBoy
Feb 13 '17 at 16:02
If it's an ARM cpu in the device, you are out of luck: The protocol could be literally anything. You need some sort of manual, unless it's a "chatty" protocol that provides help.
– dirkt
Feb 13 '17 at 16:11
Would it make a difference if the program was written for Windows 10 ioT for the Pi or is it the ARM2 chip that is an issue for Linux or ioT? If I find an alternative device, is there a chipset that I should source? I will contact the supplier and ask about the manual or technical spec. Many thanks Dirkt
– MimmsBoy
Feb 14 '17 at 5:51
The issue is not the ARM2 chip, the issue is there's no information about the protocol, and the ARM is a general CPU, so the protocol is determined by whatever program runs on that CPU (there's no datasheet where one could look that up). If you have any other kind of source of information, e.g. a working Windows driver, a working Windows example program, some output if you just connect withminicomand press return, infro from the company you bought it from, or anything else, one can go from there.
– dirkt
Feb 14 '17 at 6:48
Your device got attached as a
tty, namely /dev/ttyACM0. You can communicate with it by reading from or writing to this device. The format depends on this device, you need some kind of manual or datasheet for it (which you should have received when you bought it). I can't find anything with Google. Alternatively, look for datasheets for the chips used on the device (open it up, look at PCB).– dirkt
Feb 13 '17 at 14:02
Your device got attached as a
tty, namely /dev/ttyACM0. You can communicate with it by reading from or writing to this device. The format depends on this device, you need some kind of manual or datasheet for it (which you should have received when you bought it). I can't find anything with Google. Alternatively, look for datasheets for the chips used on the device (open it up, look at PCB).– dirkt
Feb 13 '17 at 14:02
If it's right: ARM2, STM32F103, RBT6, GH24E 9U, CHN GH 350. Hope that is what you are asking for?
– MimmsBoy
Feb 13 '17 at 16:02
If it's right: ARM2, STM32F103, RBT6, GH24E 9U, CHN GH 350. Hope that is what you are asking for?
– MimmsBoy
Feb 13 '17 at 16:02
If it's an ARM cpu in the device, you are out of luck: The protocol could be literally anything. You need some sort of manual, unless it's a "chatty" protocol that provides help.
– dirkt
Feb 13 '17 at 16:11
If it's an ARM cpu in the device, you are out of luck: The protocol could be literally anything. You need some sort of manual, unless it's a "chatty" protocol that provides help.
– dirkt
Feb 13 '17 at 16:11
Would it make a difference if the program was written for Windows 10 ioT for the Pi or is it the ARM2 chip that is an issue for Linux or ioT? If I find an alternative device, is there a chipset that I should source? I will contact the supplier and ask about the manual or technical spec. Many thanks Dirkt
– MimmsBoy
Feb 14 '17 at 5:51
Would it make a difference if the program was written for Windows 10 ioT for the Pi or is it the ARM2 chip that is an issue for Linux or ioT? If I find an alternative device, is there a chipset that I should source? I will contact the supplier and ask about the manual or technical spec. Many thanks Dirkt
– MimmsBoy
Feb 14 '17 at 5:51
The issue is not the ARM2 chip, the issue is there's no information about the protocol, and the ARM is a general CPU, so the protocol is determined by whatever program runs on that CPU (there's no datasheet where one could look that up). If you have any other kind of source of information, e.g. a working Windows driver, a working Windows example program, some output if you just connect with
minicom and press return, infro from the company you bought it from, or anything else, one can go from there.– dirkt
Feb 14 '17 at 6:48
The issue is not the ARM2 chip, the issue is there's no information about the protocol, and the ARM is a general CPU, so the protocol is determined by whatever program runs on that CPU (there's no datasheet where one could look that up). If you have any other kind of source of information, e.g. a working Windows driver, a working Windows example program, some output if you just connect with
minicom and press return, infro from the company you bought it from, or anything else, one can go from there.– dirkt
Feb 14 '17 at 6:48
|
show 2 more comments
1 Answer
1
active
oldest
votes
up vote
0
down vote
Ok, so now the question has become "given the DLL file, reverse engineer the protocol so one can use it under Linux".
The DLL file without the hardware isn't that useful, because it's a lot of work to completely reverse engineer a binary.
Instead, you can run it on Windows together with the hardware, and snoop the communication. With a bit of trial and error and guesswork, it should be possible to figure out the protocol. After all, it's just an RF receiver, the protocol shouldn't be that difficult.
You can monitor USB communcations via usbsnoop. The equivalent of ttyACM on Windows should be a virtual serial port or virtual COM port, I'm not sure if portmon works with that but it's wort a try. Google for more tools.
There's also the reverse engineering stackexchange.
edited Apr 13 '17 at 12:49
Community♦
1
answered Feb 15 '17 at 10:37
dirkt
16.1k21234
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
Ok, so now the question has become "given the DLL file, reverse engineer the protocol so one can use it under Linux".
The DLL file without the hardware isn't that useful, because it's a lot of work to completely reverse engineer a binary.
Instead, you can run it on Windows together with the hardware, and snoop the communication. With a bit of trial and error and guesswork, it should be possible to figure out the protocol. After all, it's just an RF receiver, the protocol shouldn't be that difficult.
You can monitor USB communcations via usbsnoop. The equivalent of ttyACM on Windows should be a virtual serial port or virtual COM port, I'm not sure if portmon works with that but it's wort a try. Google for more tools.
There's also the reverse engineering stackexchange.
edited Apr 13 '17 at 12:49
Community♦
1
answered Feb 15 '17 at 10:37
dirkt
16.1k21234
add a comment |
up vote
0
down vote
Ok, so now the question has become "given the DLL file, reverse engineer the protocol so one can use it under Linux".
The DLL file without the hardware isn't that useful, because it's a lot of work to completely reverse engineer a binary.
Instead, you can run it on Windows together with the hardware, and snoop the communication. With a bit of trial and error and guesswork, it should be possible to figure out the protocol. After all, it's just an RF receiver, the protocol shouldn't be that difficult.
You can monitor USB communcations via usbsnoop. The equivalent of ttyACM on Windows should be a virtual serial port or virtual COM port, I'm not sure if portmon works with that but it's wort a try. Google for more tools.
There's also the reverse engineering stackexchange.
edited Apr 13 '17 at 12:49
Community♦
1
answered Feb 15 '17 at 10:37
dirkt
16.1k21234
add a comment |
up vote
0
down vote
up vote
0
down vote
Ok, so now the question has become "given the DLL file, reverse engineer the protocol so one can use it under Linux".
The DLL file without the hardware isn't that useful, because it's a lot of work to completely reverse engineer a binary.
Instead, you can run it on Windows together with the hardware, and snoop the communication. With a bit of trial and error and guesswork, it should be possible to figure out the protocol. After all, it's just an RF receiver, the protocol shouldn't be that difficult.
You can monitor USB communcations via usbsnoop. The equivalent of ttyACM on Windows should be a virtual serial port or virtual COM port, I'm not sure if portmon works with that but it's wort a try. Google for more tools.
There's also the reverse engineering stackexchange.
edited Apr 13 '17 at 12:49
Community♦
1
answered Feb 15 '17 at 10:37
dirkt
16.1k21234
Ok, so now the question has become "given the DLL file, reverse engineer the protocol so one can use it under Linux".
The DLL file without the hardware isn't that useful, because it's a lot of work to completely reverse engineer a binary.
Instead, you can run it on Windows together with the hardware, and snoop the communication. With a bit of trial and error and guesswork, it should be possible to figure out the protocol. After all, it's just an RF receiver, the protocol shouldn't be that difficult.
You can monitor USB communcations via usbsnoop. The equivalent of ttyACM on Windows should be a virtual serial port or virtual COM port, I'm not sure if portmon works with that but it's wort a try. Google for more tools.
There's also the reverse engineering stackexchange.
edited Apr 13 '17 at 12:49
Community♦
1
answered Feb 15 '17 at 10:37
dirkt
16.1k21234
edited Apr 13 '17 at 12:49
Community♦
1
edited Apr 13 '17 at 12:49
Community♦
1
edited Apr 13 '17 at 12:49
Community♦
1
1
answered Feb 15 '17 at 10:37
dirkt
16.1k21234
answered Feb 15 '17 at 10:37
dirkt
16.1k21234
answered Feb 15 '17 at 10:37
dirkt
16.1k21234
16.1k21234
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f344598%2fusb-receiver-communication-raspberry-pi%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Your device got attached as a
tty, namely/dev/ttyACM0. You can communicate with it by reading from or writing to this device. The format depends on this device, you need some kind of manual or datasheet for it (which you should have received when you bought it). I can't find anything with Google. Alternatively, look for datasheets for the chips used on the device (open it up, look at PCB).– dirkt
Feb 13 '17 at 14:02
If it's right: ARM2, STM32F103, RBT6, GH24E 9U, CHN GH 350. Hope that is what you are asking for?
– MimmsBoy
Feb 13 '17 at 16:02
If it's an ARM cpu in the device, you are out of luck: The protocol could be literally anything. You need some sort of manual, unless it's a "chatty" protocol that provides help.
– dirkt
Feb 13 '17 at 16:11
Would it make a difference if the program was written for Windows 10 ioT for the Pi or is it the ARM2 chip that is an issue for Linux or ioT? If I find an alternative device, is there a chipset that I should source? I will contact the supplier and ask about the manual or technical spec. Many thanks Dirkt
– MimmsBoy
Feb 14 '17 at 5:51
The issue is not the ARM2 chip, the issue is there's no information about the protocol, and the ARM is a general CPU, so the protocol is determined by whatever program runs on that CPU (there's no datasheet where one could look that up). If you have any other kind of source of information, e.g. a working Windows driver, a working Windows example program, some output if you just connect with
minicomand press return, infro from the company you bought it from, or anything else, one can go from there.– dirkt
Feb 14 '17 at 6:48