At work, we're somewhat limited in what we can install on the office PCs. Therefore I listen to music on an iPod, rather than streaming.
To control the music on the iPod, I have a USB sniffer that picks up the media keys on my keyboard, and sends serial packets to the iPod.
I should rewrite taradov's code using RTOS threads to allow capture and sending at the same time, but what have now works well enough for my use case. If I press a key during the parse phase then it doesn't pick up, but I can always just press it again and usually it gets through.
For newer devices I've got an Arduino that take iPod remote commands and converts them to a TRRS headphone jack remote. So I could use the media keys on the keyboard to control a phone, for example.
Soon I plan to use Arduino Audio Tools to build an iPod remote -> Bluetooth A2DP remote using an ESP32 (note that -C and -S don't support A2DP, just ESP32).
Every time I change the volume or track on my iPod during a work day, I'm using this USB Sniffer, and it's been very reliable.
This is my favourite HN comment of the day: you’ve been told you can’t install Spotify or whatever on your work machine for security reasons so you’ve built a custom hardware keylogger to change the songs on your phone. Truly glorious.
And that right there should curdle the blood of the folk who won't allow Spotify. (I don't mean to suggest this is a security risk, I don't think it is, but those words ...)
Open hardware so you could build your own for fairly cheap. I bought a clone (is it a clone if the creator never sold them? I'd have preferred to buy it from him...) off aliexpress for ~$50.
It lets you see the raw underlying packets like IN, OUT, SETUP, DATA0/1, etc. That capability would be most useful for USB device firmware developers who might want to see these packets to track down an issue with the DATA0/1 toggling or something like that which wouldn’t be visible in a higher-level software trace like USBpcap or usbmon.
Also, it lets you sniff USB traffic of a different host machine, e.g. USB communication between a game console and a USB controller.
That is my question as well. I've always been interested on the binary blobs that go to HID moce and keyboards. I wonder if this would make cracking those any easier?
I've had a lot of luck capturing USB packets using a Windows virtual machine and Wireshark on a Linux host. Most recently I've used this to reverse engineer the configuration protocol of the Pulsar X2 v2 Mini gaming mouse.
I've also used this to capture the firmware update flow for the gamepad on a GPD Win 2. A physical sniffer wouldn't be ideal here since the gamepad - while USB - is embedded within the device.
I know this is a bit off-topic, but does the RP2040 contain an ARM core, namely the ARM royalties must be paid?
If yes, is there a derivative or version of this chip without the ARM core?
That said, this is the same issue if there are MPEG codecs, or HDMI related blocks. That's why AV1 codec and DisplayPort should be at least there, and actively prefered.
Yes, and it also contains other IP block (for example the USB from Synopsys) for which fees will be paid by the manufacturer. The Cortex-M0+ cores in the rp2040 are probably pretty cheap, so they don't impact the final price much.
> is there a derivative or version of this chip without the ARM core?
No. There might be future versions (they are, in general, looking at Risc-V stuff), but there isn't too much benefit.
> That said, this is the same issue if there are MPEG codecs [..]
No it isn't. The issue with those is that not only does the creator of the IP block itself need to get paid, but also the patent pool behind it, which is usually much more expensive. For most products from a smaller company (and even many larger ones), an AV1 hardware codec or a DisplayPort output will also be an IP block bought from someone else.
Yes, it has an arm core. The manufacturer pays the royalty to arm. Very different ball game in my opinion to proprietary codecs. There are no non-arm derivatives. The closest non-arm MCU you'll find is the esp32 but that's completely different, and lacking probably the most useful thing about the rp2040: the PIO.
Work once, get paid once is the model that most drives efficiency and innovation. If an entity is getting paid without working or innovating (work once, get paid forever), they have no reason to further work or innovate. This hampers the progress of science and the useful arts instead of furthering it.
ARM continues to innovate (“work”). They release new core IPs every year. It’s gotten to the point that companies stopped making their own implementations and just license ARM’s versions.
ESP32-C3 and ESP32-C6 are pretty close. Many products could be made with either. The RMT unit is not as flexible as PIO, but will handle basic I/O cases at least.
Name one which offers something similar to the RP2040 state machines (PIO) which I can actually buy (not to speak of the RP2040's very competitive prizing) outside of China?
We should be able to buy a RP2350 with a hardware fuse burned to disable the ARM cores for good. Ofc, those RP2350 should be cheaper since ARM royalties would not be paid.
Can't wait to the day, when I finally can get a RP2350 for $0.78 instead of the current $0.80. Think of the possibilities of what to do with those savings! I gladly forget everything I ever learned about ARM for such.
If I am a chip designer, I don't want to implement an ISA which requires to pay royalties (where those are legal), I would prefer to be free and go RISC-V which does a more than good enough job.
With the RP2040 host port connected to your development host and the listed pins connected to the DUT, yes. However keep in mind that then those two computers (development host and DUT) are galvanically coupled via the shared USB GND line. There's a risk of creating ground loops. If both are connected to utility power, then they better be on the same outlet and physically close.
So it should be possible to bridge wired USB wirelessly over 802.11n (2.4 GHz) and Bluetooth BLE 5.2 with two RP2040w, or one and software on a larger computer on the other side with e.g. google/bumble
An example of a use I have deployed via another solution for my wife. She often works from home. She often has to markup up documents and finds it much easier to do so from paper copies. When connected to her work VPN she isn’t allowed access to the local network. We have two offices and the printer is in mine because I frequently need to use it for printing invoices. She used to have to bring her laptop into my office and connect it via usb to print or disconnect from the work VPN. I deployed a usb over network extender. Now she can print from her office without disconnecting from the VPN.
Unfortunately my wife’s IT department locks things down enough that isn’t possible. To setup the printer she had to have the IT department remote in, whitelist the usb printer and install the drivers. Even to get that to happen required several levels of approval.
At work, we're somewhat limited in what we can install on the office PCs. Therefore I listen to music on an iPod, rather than streaming.
To control the music on the iPod, I have a USB sniffer that picks up the media keys on my keyboard, and sends serial packets to the iPod.
I should rewrite taradov's code using RTOS threads to allow capture and sending at the same time, but what have now works well enough for my use case. If I press a key during the parse phase then it doesn't pick up, but I can always just press it again and usually it gets through.
For newer devices I've got an Arduino that take iPod remote commands and converts them to a TRRS headphone jack remote. So I could use the media keys on the keyboard to control a phone, for example.
Soon I plan to use Arduino Audio Tools to build an iPod remote -> Bluetooth A2DP remote using an ESP32 (note that -C and -S don't support A2DP, just ESP32).
Every time I change the volume or track on my iPod during a work day, I'm using this USB Sniffer, and it's been very reliable.