• WIP
  • Mini K-Ceptor design

Hi,
I'm Val and I'm new to Chordata. I'd like to thank you guys for this awesome open source project.

While waiting for my parts to arrive I've started working on a smaller version of the K-Ceptor with some ideas in mind.
As I shared in other posts, I'd like to power every K-Ceptor via the 5V to allow extending the hiearchy with other HUBs powered by one ore more Raspberry Pi Zero W. My "Mini K-Ceptor" has it's own low dropout regulator to feed the board with 3.3V from the supplied 5V. This gives a better flexibility in future should there be any need for 5V supply without additional cabling.

The ENABLE pin is dropped and I've relocated the available wiring for extra power.

The two layer board ends up being 43x16mm which is quite close to the size of the two 6p6c modular jacks plus the requred spacing between them, back to back.

All components are SMD. IC packages are still the same package types from the BOM, however the resistors and decoupling capacitors are 0805. Power capacitors and "address translation" resistors are 1206 size.

This will be my work-in-progress thread 🙂

Looks really neat!

Since you are using 6p6c connectors and duplicating the VCC and GND lines, it would be better to switch the positions of #2 and #4, in order to follow the wiring pattern advice in the I2C-bus specification and user manual (UM10204), Chapter 7.5. This will also make it compatible with the current version of the Hub (at least midly compatible, there's still the ENABLE line in the middle). By the way, regarding your question about the Hub in the other thread, send us an email to contact at chordata dot cc.

In the last revision we have also added an i2c buffer (TCA9517), I merged the branch to master so you can take a look at it here: https://gitlab.com/chordata/PCBs

It is not absolutely necessary, but would improve the bus stability under long cables.

You can drop JP1 and JP2 if you need some space. They are just there to ease prototyping, allowing to bypass U2, and sometimes used as testpoints.

Looking forward to see this working!

And remember: Since you are basing your development in open sources, it is a good practice to keep a public repository (or online folder) of the work you are doing from the beginning, and include the open hardware logo somewhere in your design.

    admin added the WIP tag and removed the Meta tag .

    daylanKifky
    I thought about following the recommended wiring layout for decoupling, but it would have required rerouting one of the 5V pins. But from my experience it is an overkill considering that the maximum length of a single i2c branch is basically from the hub to the longest extermity which is going to be well under the capacitances limits. I've had i2c sensors dangling on 3 meter cables at 400kHz. But as you know, all comes down to how individual vendors implemented their i2c in their sensors. I can look at it again if stability would be an issue, before considering the TCA9517 buffers.
    I'll drop you en email regarding getting hold of a HUB PCB.
    The design is open source and available at https://easyeda.com/Muza/vals-chordata
    I'll make github repo once i've tried the PCBs. I forgot to add the open hardware logo, i'll get it fixed today 🙂

    I figured, the unshielded version of these Amphenol connectors are slightly smaller, while still having hold-down brackets so I've updated the design. It's was not critical for the Mini K-Ceptor PCB but for the Mini Hub it would save some space since they could be soldered right next to each other without having the hold down tabs interfering. The size of the board is still the same (43x16mm).
    Most component labels are moved under the body of the parts which keeps the assembled board a bit cleaner. Troubleshooting without looking at unpopulated PCB photo will get trickier tho.

    I've rerolled a bit smaller, 50x50mm Mini HUB boards as well. Here's a quick rendering based on the board SVG exported from Easycad and the connector CAD from Amphenol

    I'm going to drop the USB connectors in favor of a two wire silicone (or flexible PVC) cable with USB-A connector at the end to be pluggable into USB power banks. The board can also back feed the 5V to Raspbery Pi (if SBC5 jumperpad is soldered-short.

    For the casing, I'll come up with some 3D printable designs.

    11 days later

    The boards have just arrived. I'll see if I have time this weekend to build a few sensors and hubs.




    I've built a pair of HUBs (always nice to start with two for initial troubleshooting) and 8 Mini K-Ceptors.
    Both HUBs and all K-Ceptors get found by the SBC without any issues. I've also tested each and every port on the HUBs.

    So my initial impression is that both PCBs work as intented and require no immediate revisions.

    I had a quick look at Blender instructions and managed to get the plugin running with v2.79. However I was not able to get any motion data even if IP address of the SBC gets found and the Connected status on the plugin shows up green. Clicking "Receive" sometimes crashes the Blender, sometimes hides the Unico model and sometimes shows a Python exception. The SBC was running notochord with --scan option and the IP address of the client PC where Blender was installed.


    The text under the pugin window says "Chordata operator | Calibrating... Pres ENTER to start posing"
    Do I have to wait whilte it calibrates?
    The screenshots above shows notochord started with the K-Ceptor connected to CH6, but I get the same problem even if I connect the K-Ceptor (#0) to CH1

    I've never used Blender, so I might be missing something trivial.

      valor So when testing out your K-Ceptor in the testcube blend file, you have to copy and paste the name of the K-Ceptor to replace the Unico object name. I also believe you have to do this testing on CH 1.

      So, if you had the above K-Ceptor plugged into CH1, the object name you would have to enter in Blender would be kc-CH1-0

      Hope this helps!

      Thanks, looking at your Test #1 thread, i did the same as one of the last screenshots and used kc-CH_1-2
      But the box does not move.

      Is there a way to check whether or nor the notochord is sending any data to the client?

        I've attached a logic analyzer directly to the SCL_T and SDA_T lines behind address translator and I'm able to see IMU i2c communication at address 0x6B. Checking the SCL and SDA lines towards the HUB shows bi-directional i2c traffic as well.
        Am I missing a step?

        @valor I'm very much an end user, so I can't really troubleshoot your setup beyond what is in the wiki. However, you shouldn't copy the object name in my screenshot. The number after the dash needs to match the ID value of your K-Ceptor. For instance, the "-2" after "kc-CH_1" indicates that the K-Ceptor has an ID value of 2. I didn't have to build the boards from scratch, so I'm not sure exactly how ID is determined, only that is has something to do with the configuration of a specific resistor on the PCB.

          Thanks, I just hoped it might work for me if it works for you, given that I connected the K-ceptor to the right port and used the sensorname which notochord found during the startup.

          AxonSpark
          1) can you show a screenshot of your Blender screen with the testcube loaded and the Outliner area with the scene and all children unfolded?
          2) When you are testing one K-ceptor, do you have other K-ceptors disconnected from the hub?
          3) Which parameters do you start the notochord with, when you are testing with testcube?
          Thanks in advance 🙂

          @valor
          1) You shouldn't need to make any changes to anything in the Outliner (I never have).
          2) You should only have 1 K-Ceptor connected to the Hub, and it needs to be connected to
          Gate #1 (aka J1 or Channel 1).
          3) For the most part I stick to the default parameters in the testcube blend file. Just make sure under Notochord Transmission Method, you have it set to Unicast and the Local Address set to your computer's IP address. Also in the Advanced dropdown, make sure the Notochord Hostname is notochord.

          If that doesn't work, I think the developers will be back on the forum on or around the 7th.

            AxonSpark If that doesn't work, I think the developers will be back on the forum on or around the 7th.

            😁 I'm impressed. How did you guess?

            Hi @valor. Your development looks amazing!
            The blender workflow with the current version is kind of painful for non-blender people. The new release will make everything easier.

            Did you managed to make it work?

            Hi daylanKifky
            Thanks a lot 🙂
            I found the calibration thread and managed to run some tests on my mini K-ceptors. Both the i2c tool commands work as expected and the calibration data gets saved according to the notochord verbose output.
            Running the notochord with scan parameter and having it output to a csv file I can confirm that the raw data gets saved into the file...and is more or less consistent with the timings of when I left it stable, and when I moved it.

            The whole setup just refuses to work with Blender.
            I've disabled all firewalls.

            What does the Debug mode on the Chordata Blender plugin do?
            I will try your script when I get home later today.

              valor What does the Debug mode on the Chordata Blender plugin do?

              it dumps to console every message it receives, so you can tell if data is reaching blender.

                daylanKifky Great, that'll be useful.
                What is the state of the v2.8 plugin. Is it in better state than v2.79?

                  Okay! I've installed the osc4py3 and ran the script. And could finally see the OSC data flowing in!

                  Right after that, I closed the script and launched the Blender. Everyting started magically working! 😄

                  Could the problem have been due to missing Python dependencies?
                  Anyway, i had prepared 12 more Mini K-ceptors which I was holding off until I verified that the data was reaching the Blender. I will now proceed with soldering them. 🤣