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.
