A BeagleBone actually is the right sort of answer.
I fully understand the problem. A BeagleBoard is vastly overpowered for this job. it is inefficient and physically vulnerable.
There's no technical reason you couldn't get this down to a small, reliable, compact, durable $5 adapter, with USB on one end and 3 screw terminals on the other. Such adapters exist for USB to RS-232, for example.
The reason such adapters do not exist is simple: low potential sales volume.
The first step towards the ideal, starting from a general-purpose development board like the BeagleBone, is to switch to the smallest microcontroller that can drive both a USB and I²C bus simultaneously at the full data rate of the I²C side.
This is how the early USB to RS-232 adapters worked. They were rather costly and bulky by current standards, but because they were made entirely from off-the-shelf hardware, they were quick to get to market.
Because of the low potential sales volume, I'd expect to pay at least $20 for such thing, and would only expect to find it from a company like Adafruit or SparkFun, since their product diversity combines many small income streams into a single large one.
The reason you've found others charging much more than this is that is that a specialist manufacturer must go for the high end of the market. It's the only way to survive when the market size is naturally small.
Consider PC database systems.
In the early days of personal computing, general-purpose database systems didn't really exist for PCs. Many of the dedicated geeks who bought these early PCs solved problems we'd now solve with a DBMS with custom BASIC code, or even assembly. If you have any personal computing magazines from the late 1970s or early 1980s, look for the ads by companies selling $100 sorting programs!
That level of technology is analogous to what you're doing now: writing BeagleBone code to lash I²C peripherals to a USB bus, so they can talk to a computer that doesn't have an external I²C bus.
Getting back to the historical analogy...
In the early 1980s, word processors and spreadsheet programs started to get bundled with simple general-purpose DBMSes. By the mid-1980s, most everyone had a database system. The software bundle often came with the computer.
As the 1980s wore on, many of the uses for PC DBMSes started being better addressed by custom software, shrinking the user set size for DBMSes, increasing specialization. Feature set sizes and complexity grew, so that by the early 1990s, DBMSes started dropping out of office suites, because they had turned into software developer tools.
The PC DBMS market eventually stabilized, with a wide gap between Excel-as-DBMS and Access/FileMaker, because the middle ground is unprofitable. (As a Mac user, you probably watched the failure of Bento, which sat itself right in the middle of that gap.)
The gap continues to widen. Access and FileMaker are development environments unto themselves, and will continue to get more complex as they focus more on custom development and less on one-offs by solo dilettantes. I expect them to die off, too, at some point, as DBMS development moves to mobile and the cloud, further increasing complexity and specialization.
The I²C equivalent in this analogy is that I²C is now a commodity microcontroller peripheral, a datasheet checklist item. In the same way that true DBMSes are now served by a cadre of specialist software developers, most I²C work is done by specialist EEs writing code to talk to their μC's I²C peripheral.
The only way to get from that point to the point where you could expect to buy a $5 plastic-molded mass-produced adapter from the local computer store is for someone to come out with a custom IC, an I²C equivalent of the ubiquitous PL2303. I can't see this happening, ever.
The market size is fundamentally limited but the fact that USB is an outside-the-case sort of interconnect, but I²C is an inside-the-case interconnect, owing to the combination of relatively high data rate and single-ended signaling. The only reason USB to RS-232 adapters exist — despite the fact that RS-232 is also single-ended — is that RS-232 normally maxes out at 115,200 bps, just barely faster than the slowest I²C links. At normal I²C speeds, you really need differential signaling if you're going a long distance outside a shielded enclosure.
The point is, USB to I²C adapters are going to remain special-purpose things, hence expensive, bulky, clumsy, and/or overpowered.
What is your I2C speed? Depending on the speed and distance, I2C can go as low as 1k for high-speed low-impedance bus. See http://www.ti.com/lit/an/slva689/slva689.pdf
What do you exactly mean by:
The crossing only occurs at the sensor's end of the cable (less than 1 inch), not in the middle of it
By "crossing" the wires, the good practice consists in not having the two I2C lines running side by side. For example, this is bad practice for a long ribbon cable:
- VCC
- GND
- SDA
- SDL
A "better" way of doing things:
- VCC
- SDA
- GND
- SDL
This way, GND shields SDA from SDL. However, GND itself can generate noise if the bypassing isn't sufficient on either side of the cable.
The best way would be to have additional wires, for the sole purpose of shielding the signals:
- VCC
- GND
- SDA
- GND
- SDL
- GND
This is used on all IDE ribbon cables for example.
Best Answer
The only way to know if two IIC devices are compatible in this context is to compare their IIC interface in the two datasheets very carefully. IIC may be largely standard, but it says nothing about the payload data carried over IIC.
If a particular product becomes popular, competitors will often make theirs compatible. However, there is no guarantee that any two devices are compatible. Each could use a different format for sending the data, require different settings in different registers that are accessed differently to select features, etc.
Unless you know they are compatible, assume they are not.