Encouraged by @Chibiin and @daylanKifky, I thought I'd start a thread of my own build log.

Back in December 2019, when I knew that the system was coming, I had a Raspberry Pi 3 B+ purchased and ready to go, with a vanilla install of Raspbian Stretch and the Notochord software ready to go. I ended up using the Chordata image from the site in the end, and I'm happy for it. The version I made had some hangups that I THINK may be associated with an older version of notochord.

I'm on a Mac, so every time I set up a Raspberry Pi, I normally include netatalk and VNC so I can poke around in there if I need to. I have NOT added these to the Chordata image, but I present this here anyway, in case someone notices something I did that would have conflicted.

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install netatalk
sudo apt-get install x11vnc
x11vnc -storepasswd
cd ~/.config
mkdir autostart
cd autostart
nano x11vnc.desktop

Then add these lines

[Desktop Entry]
Encoding=UTF-8
Type=Application
Name=X11VNC
Comment=
Exec=x11vnc -forever -usepw -display :0 -ultrafilexfer
StartupNotify=false
Terminal=false
Hidden=false

ctrl-X to exit
sudo reboot
to see changes

I connected the Hub in the "Dedicated Power Source" configuration. I've been using a Raspberry Pi power supply, and not a battery, for testing purposes, and that seems to have been OK. Bear in mind that this log ends when I somehow torch the Hub, so if this step is significant, please let me know. The power supply is the usual 5V2A.

Like @Chibiin, I did not immediately catch that the Hub needed jumpers to connect to the Pi. Since I was using a USB to connect the Pi I thought at first the D+/- connectors of the USB might be used to send the data! So that step is not immediately apparent. In future I'd suggest something more rugged than jumpers - I worry they will fall out, and if my trashed Hub is a casualty of a short, then this could be a potential vector. The best would be a specialized cable, but I know that is more cost.

From there the connections were simple. i2cdetect -y 1showed the Hub as "73" and the Kceptors lit up. I ran find_KCs.sh and the output showed the KCeptor was connected. And running./notochordalso showed the Kceptor was running just fine. This is before calibrating, and all was well.

My experience with the calibration box was not the greatest. The PDF printed out quite small (I don't remember telling it to do so, but in the US we have small 21.6cm x 28cm paper, and the length of the box does not fit). I was surprised to see in the video how big it was supposed to be.

But no matter! I realized from the video that the box is just to get you to turn the Kceptor on all axes thoroughly, so I did so without a box, and with total success. The calibration routine reported 5000 samples or so and had no problem writing. UNTIL about the fifth or sixth sensor down, when I started to get a message that the EEPROM had been written, followed by an exit and a SEGMENTATION_FAULT error.

I apologize for not copying the full error in... I closed the terminal window without saving and lost the actual error message, and now with my Hub gone I can't recreate it just yet!

But the Kceptors seemed to calibrate just fine, as I saw later. I could not work out the Blender plugin, but I'm not a Blender user, so I figured that might be part of it. When I saw the video tutorial and followed along, I was very happy! Success! I had only one or two Kceptors with drift, so I put them aside to recalibrate. Seeing the sensor model move in Blender was very exciting, and seeing the precision and detail with which it did move was a thrill!

Then, for reasons I do not quite understand, the Hub died. I already started a thread on just that, but I'll include what I know here for the build log. I had connected a line of three Kceptors on J1 of the Hub to test. I had checked not only the polarity of the connectors (INs to OUTs, etc.) but the jumpers. I started Notochord with the --scan option and the prompts showed me only two of the three registered. I hit command-c to stop Notochord and then manually checked the connections. They did not seem like they were loose or not latched on entirely. It's then when I looked down and noticed the Hub was dead.

There was no blue light, no response from i2cdetect -y 1, nothing. Power continued to go through and supply to the Pi. Unplugged everything, powered down it all, even restarted the Mac, but no sign of life.

My theory is that I "live" connected the Kceptors and that somehow this shorted the Hub. I hope the Hub is designed to accept a live connection - I can predict now that pretty much every end user will at some point accidentally pull a connection or plug one in without powering down. I was not TRYING to do a live connection, but it's my only theory, apart from I just got a defective Hub.

In any event, my tests are down for the moment, until I get another Hub, I guess? More as it happens, and if you read all this, thanks for bothering.

    Hi @NakedRabbit
    Thanks for taking the time to write this log!!

    NakedRabbit I've been using a Raspberry Pi power supply, and not a battery, for testing purposes, and that seems to have been OK

    Yes this is OK, and it's a better choice for testing and calibrating the individual KCeptors

    NakedRabbit In future I'd suggest something more rugged than jumpers

    Absolutely, we have gone trough several revisions for the KCeptors, but the Hub got stock on the first decent version, many things on it have to change.

    NakedRabbit My experience with the calibration box was not the greatest. The PDF printed out quite small

    Yeah, it should be printed in a bigger paper. I guess it's just not specified anywhere

    NakedRabbit I started to get a message that the EEPROM had been written, followed by an exit and a SEGMENTATION_FAULT error.

    That error is not something pretty, but it doesn't affect the calibration. It happens after the processing has being done by the octave interpreter when it is closed and freed. Apparently in the Octave C API there's no routine to close and free the interpreter while keeping the rest of the program running so a dirty hack is used. The plan is to remove the Octave interpreter on future versions, it is another dinosaur on the chordata system, currently only handling the calibration routine.
    For users with no idea of what I'm talking about here:
    TL;DR: don't worry if you get this SEGFAULT at the end of the calibration, as long as you get the message that the calibration has been written to the EEPROM

    NakedRabbit My theory is that I "live" connected the Kceptors and that somehow this shorted the Hub. I hope the Hub is designed to accept a live connection - I can predict now that pretty much every end user will at some point accidentally pull a connection or plug one in without powering down.

    We have also experimented the buck converter in the Hub blowing up when live plugging a line of KCeptors. While this is something completely unacceptable for consumer grade electronics, the hardware included in the betatesting kit is still in prototypical stage and extra precautions should be observed. A more detailed explanation of the problem on the other thread you opened

              Well, it's good to know I'm not completely insane about these few points! I look forward to a newly designed Hub, and I am hopeful about running it from the 3.3v rail.

              And yes, I confirm that the SEGFAULT happens AFTER the EEPROM is written, and it does not seem to affect the calibration.

              I will note that after about a dozen calibrations the Pi seemed to be running sluggy, and I restarted everything, including my Mac. Looking back I wonder if the SEGFAULT is not also causing some usual problem like a memory leak that might make everything slow down. If I run into it again I will try to dump logs and see if there's something in there.

              We might issue a stern waning to other beta-testers not to live plug in any KCeptors! I was not trying to do that, but it's my best theory that I must have, because it's the only physical thing I did at that moment to cause the issue. One of the connectors MUST have been loose, and by live-plugging it in I MUST have blown that buck converter. I'll report more when I've done the multimeter test.

              As per the other thread, it was, indeed, the buck converter as @daylanKifky was able to identify. The unit is now connected via the 3.3v rail and functioning just fine. I will calibrate everything today and move on to the default configuration.

              2 months later

              I've been a bit slow to update here. I'm working on the "suit" now, and have some results to post.

              For my build I had a few restrictions. The first is that I wanted to design a system that would be easy to care for. And that precludes cloth or fabric suits with the sensors sewn in - hard to wash, hard to keep clean, hard to disassemble before washing. A lot of the solutions I've seen so far have to do with strapping the sensors on with velcro straps. But how to keep them from falling down? The upper arm sensors, in particular, seem awfully prone to sliding down, and any fast, active movement could displace them.

              So that's what I'm working towards.

              The first part I've worked out is attaching the sensors to the hand, which I have done to my satisfaction using velcro tape. This is the kind I used:
              https://www.velcro.com/products/ties-and-straps/900604__one-wrap-rolls/
              It can be cut to any size and shape, which is how I came up with the hand attachment. This first picture shows the required materials - three straps cut from the roll of Velcro tape.

              The second shows the top, thinnest band used to secure the KCeptor to the largest band.

              The band is then wrapped around the hand above the thumb:

              Make sure it's comfortable, not cutting into the skin or anything. This should keep it secure, but why not add another strap around the thumb to keep it all in place?

              And here's the completed hand attachment. Swinging it around above my head and everywhere fails to make it budge. I think we're going with this over gloves, which will eventually just get stinky and need a wash.

              More later as I document it properly. But here's a heads up: I'm using a relatively cheap "posture improvement" chest harness to secure the Hub and "nanotape" to attach the sensors directly to my skin to keep them from slipping. Sure, the nanotape pulls your hairs off, but it's washable and resuable.

              a month later

              Been a while, sorry.
              Next step has been to get a vest together. If the limbs can be solved with elastic and velcro, the dorsal section would need some other work. The first thing to do was to house the Hub and the Raspberry Pi. I loved the work that @DigitalStages did with the custom Hub enclosure, but those STL files were never going to print on my crap-ass RepRap clone 3D printer. I tried, and I got some serious spaghetti. Oh well, I just needed something that would work, so I bashed together an enclosure of my own in OpenSCAD.

              That's the case for the Hub - it just fits in there, snugly. I guess you could use a strip of nanotape to adhere it if there was a danger of it falling out. I tried t make everything in this build flexible and removable, in case parts need to be changed out. In heavy production environments things always fail, and if I glue everything together or make it hard to switch out, that could be wasted time.

              That's the lid. The unit is designed to sit in the small of the back, so you can see that the jacks to the Hub are labeled on top so you know which is which.

              The files are here in case anyone feels like looking at them:
              https://www.dropbox.com/s/fevk407juznal38/ChordataHubNR.zip?dl=0
              I found a kind of generic but functioning Raspberry Pi case online, just so I'd have something to protect the Pi.

              I found a vest online. You can get them VERY cheaply, they are sold as posture correcting vests. I paid about $4 for mine, so don't pay a lot! Mine had these annoying MAGNETS sewn into it. That cannot be good for this system to have a bunch of magnets around. Look, here they are:

              Yep, sewn into the back, like ersatz chakras or something. Boy, the things people believe. But that's OK, it's a cheap vest for me, and nothing that a few slices with an X-acto can't fix.

              Here's the back of the vest with a velcro patch hot glued to the back, plus the corresponding velcro patches on the Raspberry Pi case and the new Hub case.

              And here is the whole lot assembled.

              Add the battery to the side and use the already available elastic strap to hold it in. That's just a spare cloth pouch from something hot glued to the vest.

              The dorsal sensor can be placed at the top of the vest. Here again, it's a piece of velcro hot glued to the vest with the Kceptor held in with velcro straps.

              The whole thing fits snug, with the vest strap connecting just under the ribcage. I'm considering threading the connectors for the arms up and over the shoulder straps so that the operator can get in and out of the suit easily.

              Next, the head and base sensors.

              14 days later

              Finally fitted the entire rig tonight.

              Head piece and dorsal sensor were attached using a neoprene pouch, similar to the ones here:
              https://www.musical-instruments-accessories-for-you.com/product/microphone-beltq-carrier-transmitter-instructor/

              But I only used them because they were lying around - good lord, don't pay lots of money for a pouch. So one pouch around the head with the sensor in back, one around hips, sensor in back. Very comfortable.

              As described before, the foot, leg, thigh, forearm, and upper arm sensors were attached using nanotape:
              https://www.getnanotape.com/order
              https://www.aliexpress.com/w/wholesale-nano%20tape.html

              I have NO IDEA if nanotape is hypoallergenic! So you're on your own! I do not react to it. I used a small bit of it on the back of each Kceptor to keep it from moving during capture. The nanotape is extremely sticky and gummy, yet it can be pulled off very easily, WASHED with soap and water, and used again! I used elastic bands, with velcro ends, to secure the sensors a bit more firm. They did not move so far as I know.

              Ouch, though, having a sensor on the front of my shin hurt like hell. I have to come up with something better than that. The rest was comfortable. I will spare you the indignity of any photo of me wearing it.

              The clear advantages here were that the entire rig can be assembled and fitted by a single operator including powering up the Pi (by plugging it in - I use an SSH command to shut it down). All materials are relatively cheap and reusable or replaceable. The Chordata components are not attached in any way that would prevent switching out a bad component. It is fairly comfortable, except for those shins.

              More data as I gather it...

                NakedRabbit I will spare you the indignity of any photo of me wearing it.

                🤣 🤣 🤣 🤣
                But it would make a good scientific evidence for further studies.

                  Uh... yeah, @daylanKifky... for science...

                  NOT HAPPENING.

                  Anyway, glad you're here, because I think this is a short question to answer, considering what I've read in other parts of the forum. Both yesterday and today I got this repeating output from Notochord:

                  info~[ 38966] K_Ceptor r-foot......: setup OK.
                  error~[ 38983] EEPROM not found on r-foot
                  error~[ 38992] Can't find K_Ceptor head

                  Eventually it cancels out with a Floating point exception error. It seems the head was never found, but that foot kept getting found and lost. I am guessing that this is also part of the "cable too long" issue with these hideously long RJ12s?

                  I do have a crimper, although I'm probably low on heads. I think I better get to work. In any event, the cables supplied with the beta kit are pretty darn long anyway. I almost trip over them on my legs, and I'm not a short person; I'm pretty average.

                  In other news, it takes me less than ten minutes to get into the suit, about as much to get out of it. Comfortable and functional. Just need to get it talking to Blender now.

                  Full output here - FOR SCIENCE!

                  info~[      0] Notochord start @ Tue Jun 23 05:03:01 2020

info~[      0] Verbosity level 0
info~[      0] K-Ceptor revision 2
info~[    101] I2C adapter initialied on /dev/i2c-1
info~[    101] Starting Armature xml parsing.
info~[    105] Armature Created.
info~[    105] Starting timer. [NODES < 6 , 15 > = 21 | ODR = 50  | Sleep = 1315us]
info~[    105] Sending rate = 50Hz
info~[    105] Timer started, 21 nodes on scheduler
info~[    630] K_Ceptor r-thigh.....: setup OK.
info~[   1697] K_Ceptor r-leg.......: setup OK.
info~[   2765] K_Ceptor r-foot......: setup OK.
error~[   2782] EEPROM not found on r-foot
info~[   3308] K_Ceptor base........: setup OK.
info~[   4376] K_Ceptor l-thigh.....: setup OK.
info~[   5444] K_Ceptor l-leg.......: setup OK.
info~[   6512] K_Ceptor l-foot......: setup OK.
info~[   7580] K_Ceptor r-forarm....: setup OK.
info~[   8648] K_Ceptor r-arm.......: setup OK.
info~[   9716] K_Ceptor r-hand......: setup OK.
info~[  10784] K_Ceptor dorsal......: setup OK.
error~[  11328] Can't find K_Ceptor head
info~[  11853] K_Ceptor l-forarm....: setup OK.
info~[  12921] K_Ceptor l-arm.......: setup OK.
info~[  13989] K_Ceptor l-hand......: setup OK.
info~[  15059] K_Ceptor r-foot......: setup OK.
[...]
(trimmed output)
[...]
error~[  15076] EEPROM not found on r-foot
error~[  15087] Can't find K_Ceptor head
info~[  15617] K_Ceptor r-foot......: setup OK.

Floating point exception

                  Hi!

                  yes, it look like a problem with the long cables.
                  As I suggested to evryone having this problem:

                  If you are able to crimp RJ11 connectors I suggest you to crimp a new set of cables like the ones described here. We never got problems like this with those cables.

                  The suit we normally use for developing and testing uses even longer ones than the ones we sent, but made with the technique described there and they work pretty well

                  I had an enjoyable time crimping.
                  But I ended up with some perplexing output anyway. I only made a few cables, notably both legs and the connection to the head, which were the ones giving me trouble anyway. Here's what I got.

                  `info~[ 0] Notochord start @ Fri Jun 26 05:43:26 2020

                  info~[ 0] Verbosity level 0
                  info~[ 0] K-Ceptor revision 2
                  info~[ 101] I2C adapter initialied on /dev/i2c-1
                  info~[ 101] Starting Armature xml parsing.
                  info~[ 105] Armature Created.
                  info~[ 105] Starting timer. [NODES < 6 , 15 > = 21 | ODR = 50 | Sleep = 1315us]
                  info~[ 105] Sending rate = 50Hz
                  info~[ 105] Timer started, 21 nodes on scheduler
                  info~[ 630] K_Ceptor r-thigh.....: setup OK.
                  info~[ 106993] K_Ceptor r-leg.......: setup OK.
                  info~[ 108061] K_Ceptor r-foot......: setup OK.
                  info~[ 109129] K_Ceptor base........: setup OK.
                  error~[ 110010] Can't find K_Ceptor l-thigh
                  error~[ 110348] Can't find K_Ceptor l-leg
                  error~[ 110684] Can't find K_Ceptor l-foot
                  error~[ 110853] error switching branch right_arm. Retrying.. (0)
                  error~[ 111041] error switching branch right_arm. Retrying.. (1)
                  error~[ 111230] error switching branch right_arm. Retrying.. (2)
                  error~[ 111418] error switching branch right_arm. Retrying.. (3)
                  error~[ 111607] error switching branch right_arm. Retrying.. (4)
                  error~[ 111627] Too many errors when switching branch right_arm.
                  error~[ 111628] An error ocurred: Can't write to mux
                  `
                  Interesting... so one leg cable is fine, the other is bad? I ran the same command again, without changing ANYTHING, and got this output:

                  `info~[ 0] Notochord start @ Fri Jun 26 05:45:31 2020

                  info~[ 0] Verbosity level 0
                  info~[ 0] K-Ceptor revision 2
                  info~[ 101] I2C adapter initialied on /dev/i2c-1
                  info~[ 101] Starting Armature xml parsing.
                  info~[ 105] Armature Created.
                  info~[ 105] Starting timer. [NODES < 6 , 15 > = 21 | ODR = 50 | Sleep = 1315us]
                  info~[ 105] Sending rate = 50Hz
                  info~[ 106] Timer started, 21 nodes on scheduler
                  error~[ 274] error switching branch right_leg. Retrying.. (0)
                  error~[ 463] error switching branch right_leg. Retrying.. (1)
                  error~[ 652] error switching branch right_leg. Retrying.. (2)
                  error~[ 841] error switching branch right_leg. Retrying.. (3)
                  error~[ 1030] error switching branch right_leg. Retrying.. (4)
                  error~[ 1051] Too many errors when switching branch right_leg.
                  error~[ 1051] An error ocurred: Can't write to mux`

                  So now the right leg is NOT OK? Power down, switch left and right legs at the hub, no good. Switch cables with arms and legs at the hub, etc. etc. After a few trials it seems that the twisted pair cables I made are not very good or something. I'll have to test them one at a time on one Kceptor.

                  🤔 are the jumper cables connecting the RPi and Hub properly connected? sometimes one of them gets loose and causes random trouble on the communications.

                  There's a big gap on the timestamps btw the r-thigh and r-leg setups

                  info~[ 630] K_Ceptor r-thigh.....: setup OK.
info~[ 106993] K_Ceptor r-leg.......: setup OK.

                  Did you noticed a perceivable pause on the execution btw those lines?

                  Perhaps trying the cables one by one and move or bend them while capturing helps confirming they are working fine.

                  OK, more data, @daylanKifky !
                  I connected ONLY my handmade RJ12 cables to the Hub, with ONE Kceptor each, double-checking the jumpers at J5 to make sure they were all set to be the first Kceptor in the chain. So every Hub connector had one handmade cable and one Kceptor.

                  Notochord saw them all; seems like they're good.

                  info~[ 0] Notochord start @ Sun Jun 28 05:14:21 2020

                  info~[ 0] Verbosity level 0
                  info~[ 0] K-Ceptor revision 2
                  info~[ 101] I2C adapter initialied on /dev/i2c-1
                  info~[ 101] Starting Armature scanning.
                  info~[ 101] Scan: [Base Mux] Hub
                  info~[ 101] Scan: [Base Mux] Hub, GATE: CH_1
                  info~[ 102] Scan: K-Ceptor [kc-CH_1-0], value 0
                  info~[ 104] Scan: [Base Mux] Hub, GATE: CH_2
                  info~[ 105] Scan:                   K-Ceptor [kc-CH_2-0], value 0
                  info~[ 108] Scan: [Base Mux] Hub, GATE: CH_3
                  info~[ 108] Scan: K-Ceptor [kc-CH_3-0], value 0
                  info~[ 110] Scan: [Base Mux] Hub, GATE: CH_4
                  info~[ 111] Scan:                   K-Ceptor [kc-CH_4-0], value 0
                  info~[ 113] Scan: [Base Mux] Hub, GATE: CH_5
                  info~[ 114] Scan: K-Ceptor [kc-CH_5-0], value 0
                  info~[ 116] Scan: [Base Mux] Hub, GATE: CH_6
                  info~[ 116] Scan:                   K-Ceptor [kc-CH_6-0], value 0
                  info~[ 119] Armature Created.
                  info~[ 119] Starting timer. [NODES < 6 , 6 > = 12 | ODR = 50 | Sleep = 3288us]
                  info~[ 119] Sending rate = 50Hz
                  info~[ 119] Timer started, 12 nodes on scheduler
                  info~[ 644] K_Ceptor kc-CH_6-0...: setup OK.
                  info~[ 1712] K_Ceptor kc-CH_5-0...: setup OK.
                  info~[ 2780] K_Ceptor kc-CH_4-0...: setup OK.
                  info~[ 3848] K_Ceptor kc-CH_3-0...: setup OK.
                  info~[ 4915] K_Ceptor kc-CH_2-0...: setup OK.
                  info~[ 5984] K_Ceptor kc-CH_1-0...: setup OK.
                  info~[ 11531] End Beta Mangling in 0.2

                  I also tried the OSC Dump you recommended in another thread, just to make sure that not only were the Kceptors connected, but that they were sending out values, esp. when I moved them. I will spare you the entire output, but it seems pretty clear that everything is GOOD.

                  [/Chordata/q/kc-CH_1-0 float32:0.620092, float32:-0.205841, float32:-0.269945, float32:0.707574]
                  [/Chordata/q/kc-CH_6-0 float32:0.630174, float32:-0.644064, float32:-0.344645, float32:0.263985]
                  [/Chordata/q/kc-CH_5-0 float32:0.164427, float32:-0.232863, float32:0.717508, float32:-0.63588]
                  [/Chordata/q/kc-CH_3-0 float32:0.502196, float32:-0.334433, float32:-0.797733, float32:0.00108525]
                  [/Chordata/q/kc-CH_2-0 float32:0.949812, float32:-0.290691, float32:0.0253923, float32:-0.114613]
                  [/Chordata/q/kc-CH_4-0 float32:0.735274, float32:-0.610727, float32:-0.292166, float32:0.0377501]
                  [/Chordata/q/kc-CH_1-0 float32:0.618247, float32:-0.205439, float32:-0.270245, float32:0.70919]
                  [/Chordata/q/kc-CH_6-0 float32:0.635345, float32:-0.63414, float32:-0.359641, float32:0.25551]
                  [/Chordata/q/kc-CH_5-0 float32:0.163343, float32:-0.232983, float32:0.716154, float32:-0.637639]
                  [/Chordata/q/kc-CH_3-0 float32:0.501693, float32:-0.334455, float32:-0.798041, float32:0.00088491]
                  [/Chordata/q/kc-CH_2-0 float32:0.949942, float32:-0.2904, float32:0.0255198, float32:-0.114243]
                  [/Chordata/q/kc-CH_4-0 float32:0.733381, float32:-0.614268, float32:-0.289172, float32:0.0401368]

                  This would suggest to me that I know how to make a damn cable, as I suspected. So my issues were probably having something to do with mixing cables, iffy connections, maybe a loose Pi-to-Hub connector, maybe even a goofed up J5 jumper, who knows?

                  But the answer seems to be to finish making up all new cables (I'm ahead by these six new ones), restring everything extra carefully, and try again.

                  ARE WE HAVING FUN YET? YES. YES, WE ARE.

                  OK, new problem. @daylanKifky , please help!

                  I remade ALL cables. I connected all Kceptors, and Notochord seemed happy. The --scan function showed all Kceptors were OK.

                  info~[ 121] Timer started, 21 nodes on scheduler
                  info~[ 645] K_Ceptor kc-CH_6-2...: setup OK.
                  info~[ 1713] K_Ceptor kc-CH_6-1...: setup OK.
                  info~[ 2781] K_Ceptor kc-CH_6-0...: setup OK.
                  info~[ 3849] K_Ceptor kc-CH_5-0...: setup OK.
                  info~[ 4917] K_Ceptor kc-CH_4-2...: setup OK.
                  info~[ 5985] K_Ceptor kc-CH_4-1...: setup OK.
                  info~[ 7053] K_Ceptor kc-CH_4-0...: setup OK.
                  info~[ 8122] K_Ceptor kc-CH_3-2...: setup OK.
                  info~[ 9191] K_Ceptor kc-CH_3-1...: setup OK.
                  info~[ 10259] K_Ceptor kc-CH_3-0...: setup OK.
                  info~[ 11328] K_Ceptor kc-CH_2-1...: setup OK.
                  info~[ 12397] K_Ceptor kc-CH_2-0...: setup OK.
                  info~[ 13466] K_Ceptor kc-CH_1-2...: setup OK.
                  info~[ 14535] K_Ceptor kc-CH_1-1...: setup OK.
                  info~[ 15604] K_Ceptor kc-CH_1-0...: setup OK.

                  But when I tried Notochord with the default biped, I get this (partial output, the rest is OK)

                  info~[ 11307] K_Ceptor dorsal......: setup OK.
                  error~[ 11851] Can't find K_Ceptor head
                  info~[ 12377] K_Ceptor l-forarm....: setup OK.

                  And of course, repeating that error in a loop until it crashed out with a floating point exception.

                  This is one of the same errors I got before. Have I set up the Kceptors incorrectly for the biped? Do I have the wrong biped?

                  I have a cable coming from the center (J2) of the Hub. It goes to a Kceptor with the jumper at J5 set to "1" since it's the first node on the system. That should be the DORSAL, yes? Then I have a cable to another Kceptor with the jumper at J5 set to "2" since it's the next node on the system. That should be the HEAD, yes? When I run --scan Notochord sees all the Kceptors just fine: the output above shows

                  info~[ 11328] K_Ceptor kc-CH_2-1...: setup OK.
                  info~[ 12397] K_Ceptor kc-CH_2-0...: setup OK.

                  When I open the default_biped.xml with nano I see this:

                                  <Branch Name="body" id="1">
                        CH_2
                        <K_Ceptor Name="dorsal" id="2">
                            1
                            <K_Ceptor Name="head" id="2">
                                2
                            </K_Ceptor>
                    </K_Ceptor>
                </Branch>

                  That all seems fine, right? It has the same hierarchy as other limbs do, with each Kceptor named and given an id# of 2. The arms and legs all have this structure, just one more node on them.

                  So I powered down and traded the Kceptors out for the base and the head, making sure to set the jumpers atJ5 accordingly (1 for the BASE, 2 for the HEAD) and tried again... WITH THE SAME RESULT. I traded cables with the base and the head. AND GOT THE SAME RESULT.

                  So I'm really kind of flummoxed.

                  1. If I can trade the Kceptors and the problem stays with the head, then it's not the Kceptors.
                  2. If I can trade the cables and the problem stays with the head, then it's not the cables. I don't THINK. Is it possible that the cable from the Hub to the DORSAL is somehow goofed up and preventing a signal going THROUGH that Kceptor?
                  3. If Notochord --scan sees everything as OK, then it should not be anything physical about the way they are connected, right?

                  Only Notochord with deafult_biped.xml craps out... I'm so close to getting a proper capture out of this thing!

                  Hi!

                  For some reason the values that get set in the dorsal and head K-Ceptors are 0 and 1, instead of 1 and 2. I can tell by the dump of the --scan mode:

                  info~[ 11328] K_Ceptor kc-CH_2-1...: setup OK. # kc from CHannel 2, value 1
info~[ 12397] K_Ceptor kc-CH_2-0...: setup OK.  # kc from CHannel 2, value 0

                  This is quite strange, but for now in order to get it working you can try to change the values on the xml to:

                                  <Branch Name="body" id="1">
                        CH_2
                        <K_Ceptor Name="dorsal" id="2">
                            0
                            <K_Ceptor Name="head" id="2">
                                1
                            </K_Ceptor>
                    </K_Ceptor>
                </Branch>

                  (The value shuold be set as the content of the <K_Ceptor> node, the id property is deprecated)

                  I'm not sure if the problem is that both KCs on that branch are decreasing their value by one, or if it's just the head which is taking a value of 0. If once it is capturing you get swapped movements btw head and dorsal change the xml to assign: dorsal = 1 / head = 0

                  Looking forward to see that avatar moving!

                  Just for informational purposes, the default_biped.xml in the GitHub has this exact same error.

                  And an error it is, too! Because making those changes fixed my problem. Notochord runs the default_biped and everything shows up!

                  Now BLENDER is a different matter. Immediately I opened it, set up the Chordata Session, and connected. The data dump showed numbers galore! Then... CRASH!

                  Exception Type: EXC_CRASH (SIGSEGV)
                  Exception Codes: 0x0000000000000000, 0x0000000000000000
                  Exception Note: EXC_CORPSE_NOTIFY

                  Termination Signal: Segmentation fault: 11
                  Termination Reason: Namespace SIGNAL, Code 0xb
                  Terminating Process: Blender [26401]

                  Application Specific Information:
                  dyld: in dladdr()

                  I'm on Mac OSX 10.13.6 with the latest Blender and latest Chordata Plugin. BUT... I also ran exactly this configuration a million times to calibrate the KCeptors and I've had this machine on for several days without a restart. So it's too early to tell!

                  I just wanted to log about the error in the GitHub version of default_biped.xml so if anyone else finds it they will know. More later as it happens.

                  Hi!
                  the default_biped.xml in the repo reflects this configuration, which can be found in the wiki.

                  Where you using this numbering scheme or a different one? It the latter, where did you find the reference for it?

                    daylanKifky I was using the default_biped.xml included on the Chordata image. You can see the file here at your own GitLab repository:

                    https://gitlab.com/chordata/notochord/-/blob/develop/default_biped.xml

                    Unless that one was deprecated or something. I will admit, I may need to pull the latest Notochord, and maybe it got fixed and I don't know. I got to that file through this link:

                    https://chordata.cc/downloads/

                    And, like I say, that one was on the disc image I downloaded and set up, but I did so months ago and the change may have been made by now.

                    Look at me! Finding bugs! It's like I'm a real beta-tester or something.

                    EDIT: I'm on the latest Notochord:

                    Chordata's Notochord v0.1.2b #13da69d

                      Even more experiments!
                      I have succeeded in getting a capture from Notochord. It was a crappy capture from the suit with no one in it, so it's not worth posting - just a biped in a crumpled heap. But I have now taken the process all the way to the end:

                      Documentation is a bit scattered. I wrote out the steps I took at the end just in case @PrestonJ or someone else is reading and finds it useful.

                      CAPTURE PROCEDURE

                      1. Open New Project in Blender
                      2. Delete EVERYTHING. That box, the camera, the light, everything.
                      3. Select Window > Chordata > Add a Mocap Avatar to the scene
                      4. Select the "Mocap" tab that appears
                      5. There will be three nodes, the Notochord node, the Armature Node, and a Status Node
                      6. Add a new "Record" Node.
                      7. Connect the "Data Out" output of the Armature Node to the In on the Record Node.
                      8. Set the Target Object in the Record Node to the Chordata Biped.
                      9. Make sure the Notochord node is not in "Demo Mode"
                      10. Start Notochord on the Pi with
                        ./notochord -c ../default_biped.xml <IP ADDRESS>
                        Where "<IP ADDRESS>" is the actual IP address of the computer running Blender.
                        No "<" symbols, just the number.
                      11. Hit "Connect" on the Notochord Node in Blender
                      12. Click "Show Advanced" on the armature Node to reveal Timed Calibration.
                      13. Click that button, making sure to set the timer for the appropriate number of seconds.
                      14. Look towards the SOUTH and assume T-Pose for Calibration.
                      15. When Calibrated, Hit "Record" on the Record node. And click it again to turn off the capture.
                      16. Each pass is saved as an "action." Select the "Active Action" you want from the pulldown menu in the node.
                      17. Hit "Play" on the Record Node to preview.
                      18. Select Chordata_biped in the Collection window of Blender. The motion capture data will show in the timeline.
                      19. Select "Export-> BVH" to make a BVH file to apply in another program, which I'm doing.

                      I really ought to do a better job than this, with screenshots and such. Perhaps soon.

                      This brings to light one other odd discrepancy. I noticed that the default_biped.xml had joints labeled "l-forarm" and "r-forarm" were, in fact, not forearms at all. That part is usually called in English the "upper arm." I've also seen it labeled "shoulder" in some models. What default_biped.xml lists as "arm" is, in fact, what most English speakers would call the forearm.

                      Of course this is no big deal - the joints can be called anything you want, of course. And I'm not trying to impose my big dumb American ideas on this poor figure.

                      But when I was translating my BVH export over to a bog-standard DAZ model I noticed that I had to change the hierarchy at the head of the BVH file to match the model and I noticed the use of "forarm" for "upper arm."

                      My DAZ translation simply required a text edit on the BVH file, substituting:

                      base = Hip
                      dorsal = Abdomen
                      head = Head

                      l-clavicule = Left Collar
                      l-forarm = Left Shoulder
                      l-arm = Left Forearm
                      l-hand = Left Hand

                      r-clavicule = Right Collar
                      r-forarm = Right Shoulder
                      r-arm = Right Forearm
                      r-hand = Right Hand

                      l-thigh = Left Thigh
                      l-leg = Left Shin
                      l-foot = Left Foot

                      r-thigh = Right Thigh
                      r-leg = Right Shin
                      r-foot = Right Foot

                      I should just make a new DAZ_biped.xml. If/when I do, I'll post it. Localized biped.xml files in other languages are also probably a good idea.

                      Anyway, the DAZ render was, as you'd expect, horrible and hilarious. Now I have to do a proper capture of some motion that's worth looking at.