The cable/connector does indeed look interesting, if easily available ... possibly with more pins... I wish they had more details, from the thumbnail[0] they posted of the board edge PCB footprint, I don't see how it could be reversible... The short finger (presumably VDD) would need to be on opposing sides top and bottom, and it's always on the right. Or is my thinking messed up?
The original jackplug was also just as simple. Instead of 3.5 they could have gone for the 2.5" to avoid confusion as an audio out. But the new proposed cable? Is it available? Seems to be more work to offer.
/me checks taobao again
Nope, still not.
Kittenbot devices came with a standard audio jackplug. Easy cabling, off the shelf.
Although, thinking about it, I wonder if the connector is designed for sequencing (power/ground first, then data) and if the linear insertion of the jack plug caused issues with that, since when the plug is being inserted the connector nearest to the outside contacts all three of the rings on the jack in turn.
It can be. K-bus in BMW and Rover cars is (was?) RS-232 plus collision sensing running at, I think, 19.2 k bps. It has single ended drivers with pull up resistors instead of push pull drivers. The K stands for karosseri meaning body.
I guess the differentiator is that Jacdac is a higher level protocol. RS232, RS485 and CAN are just 'send some data down this pipe' deals, and RS232/RS485 don't even have a particularly standard way of framing data. I haven't used SPI or I2C enough to know about them, but from looking them up, they also seem to just offer a way to send arbitrary data.
Jacdac both offers a standard way of using devices (from the website: 'devices with the same functionality but different hardware implementations can be substituted without having to recompile the application that uses them. For example, two different models of accelerometer hardware can replace each other because they share the same software interface.') and a standard way of finding devices (because all devices advertise the services they provide every 500ms).
Honestly, as somebody whose job involves a lot of interfacing with random bits of hardware, this would make my life a heck of a lot easier! There have been way too many times I've received a device manual for e.g. a Modbus-over-RS485 interface and had to go 'okay, is this list of register IDs zero-based or one-based? floating point or fixed point? big-endian or little-endian (or both in the case of one awful device!)' etc etc.
Indeed! Lots of Jacdac is not about the cable or the UART-based signaling, but about the service standardization and definitions.
Now if only we could get all these silicon vendors to put Jacdac directly on their current I2C/SPI sensors... It's definitely possible given that basic Jacdac implementation runs on PMC150C with 64 bytes or RAM and 1.5k of ROM, but it may be a hard sell since they seem to like lock-in.
I worked with a similar single-wire protocol when working with a large German appliance maker. This looks pretty close to the same idea, they even used PCB edge connectors like this to save a few pennies.
I'll just add that getting the software and hardware right is a lot trickier than it looks. Bus arbitration and collision recovery at the hardware level isn't always the easiest when working with low speed microcontrollers. And, by the time you have it all working, you've reinvented CANBUS but without the differential signalling so you need to keep the cables short.
And all of this is supposed to fit on a single 'cute' board with a pushbutton or tricolor LED? Hardware overkill.
It probably has some use in the hobbyist sector, I'd love to see Sparkfun or Lady Ada pick it up but they're very smart groups and have their own direction with things like Qwiic (which is just I2C, something already on a lot of MCUs in hardware) The proprietary connector, fixed to 3 pins only, is a huge turnoff too. I can get a lot more mileage out of putting FTDI parts on each side of a board and using USB-C patch cords I bought at the gas station.
It was developed IIRC by an intern as part of his thesis and included in the microbit tooling on makecode. After this it got more standardized, but they went to a less obvious connector (Kittenbot came with a standard jack) and now they describe a custom plug. This increased the barrier of entrance and building came less appealing to me.
Yeah it totally has that 'quickly-launched-short-lived summer intern project' vibe to it which is fine but is something I'd typically expect out of Google, but not Microsoft.
The main issue with audio jack cables is that they are not designed to carry much power (Jacdac cables are rated at 1A). You get different voltage drop depending on what cable user bought at the gas station. This is a problem is you want to run a small servo or even a few neopixels on a module.
Another issue is that the connector often short while plugging-in and out which may cut the power to your entire bus, resetting everything. Not a great end-user experience. There is also a risk users will plug Jacdac to their headphones, possibly burning them.
Yeah. Something like a standard set of protocols on top of an existing peer-to-peer bus, with a good set of supporting libraries, would have been great. I love the idea of service advertising and standard service APIs.
Indeed, if you know how to design a custom PCB, have it made, and write embedded software, then Jacdac might be an overkill for you.
The Qwiic cables have to be really short (Jacdac cables can be a few meters) and are not designed for easy plug-in and out thousands of times. Also, the I2C devices are not standardized meaning you need a new driver in your software environment for every single accelerometer. Finally, I2C doesn't let you have multiple instances of the same device because of address collisions.
This is like a software engineer's idea of modular hardware. Looks like fun and may be great for one-offs. The problem for using a system like this for early prototypes and proof-of-concept is that the hardware AND software of a cost-optimized production device is going to be from a completely different planet.
I like the edge connector though - nice way to get a maybe-someday connector on a board without adding visible BOM cost. The board routing involved will cost money, of course, and the gold plating shown, if necessary, is also a cost adder.
If you want to make a million copies of something, Jacdac is unlikely to help you much outside early prototyping. OTOH, if you want 10 copies of something it may simplify things - you don't have to solder any wires 10 times. If you want more, you can get a PCB with holes matching holes on modules and screw them in with M3 screws (skipping the cables - the holes carry signals), or solder them down.
Gold plating is not strictly necessary, depending if you plan to use the plug thousands of times.
Edit: also very good observation on top of the comment - Jacdac is indeed a way to bring "modern" software engineering practices to hardware design.
26 comments
[ 2.9 ms ] story [ 67.5 ms ] threadThat seems interesting on the cost side if the cable is not too expensive.
[0]: https://microsoft.github.io/jacdac-docs/overview/connectorca...
[0] - https://microsoft.github.io/jacdac-docs/ddk/design/#pcb-edge...
/me checks taobao again
Nope, still not.
Kittenbot devices came with a standard audio jackplug. Easy cabling, off the shelf.
But this wasn't originally for rocket science, but simple DIY projects or kids projects. If repositioned it will have a hard time getting adopted.
Jacdac both offers a standard way of using devices (from the website: 'devices with the same functionality but different hardware implementations can be substituted without having to recompile the application that uses them. For example, two different models of accelerometer hardware can replace each other because they share the same software interface.') and a standard way of finding devices (because all devices advertise the services they provide every 500ms).
Honestly, as somebody whose job involves a lot of interfacing with random bits of hardware, this would make my life a heck of a lot easier! There have been way too many times I've received a device manual for e.g. a Modbus-over-RS485 interface and had to go 'okay, is this list of register IDs zero-based or one-based? floating point or fixed point? big-endian or little-endian (or both in the case of one awful device!)' etc etc.
Now if only we could get all these silicon vendors to put Jacdac directly on their current I2C/SPI sensors... It's definitely possible given that basic Jacdac implementation runs on PMC150C with 64 bytes or RAM and 1.5k of ROM, but it may be a hard sell since they seem to like lock-in.
https://web.archive.org/web/20191130155328/https://jacdac.or...
I worked with a similar single-wire protocol when working with a large German appliance maker. This looks pretty close to the same idea, they even used PCB edge connectors like this to save a few pennies.
I'll just add that getting the software and hardware right is a lot trickier than it looks. Bus arbitration and collision recovery at the hardware level isn't always the easiest when working with low speed microcontrollers. And, by the time you have it all working, you've reinvented CANBUS but without the differential signalling so you need to keep the cables short.
And all of this is supposed to fit on a single 'cute' board with a pushbutton or tricolor LED? Hardware overkill.
It probably has some use in the hobbyist sector, I'd love to see Sparkfun or Lady Ada pick it up but they're very smart groups and have their own direction with things like Qwiic (which is just I2C, something already on a lot of MCUs in hardware) The proprietary connector, fixed to 3 pins only, is a huge turnoff too. I can get a lot more mileage out of putting FTDI parts on each side of a board and using USB-C patch cords I bought at the gas station.
Another issue is that the connector often short while plugging-in and out which may cut the power to your entire bus, resetting everything. Not a great end-user experience. There is also a risk users will plug Jacdac to their headphones, possibly burning them.
The Qwiic cables have to be really short (Jacdac cables can be a few meters) and are not designed for easy plug-in and out thousands of times. Also, the I2C devices are not standardized meaning you need a new driver in your software environment for every single accelerometer. Finally, I2C doesn't let you have multiple instances of the same device because of address collisions.
I like the edge connector though - nice way to get a maybe-someday connector on a board without adding visible BOM cost. The board routing involved will cost money, of course, and the gold plating shown, if necessary, is also a cost adder.
Gold plating is not strictly necessary, depending if you plan to use the plug thousands of times.
Edit: also very good observation on top of the comment - Jacdac is indeed a way to bring "modern" software engineering practices to hardware design.