notochord --scan errors question

kmw199614

Hello,
I was able to individually calibrate the k-ceptors. My next step was to connect them all and do the pose calibration on the biped.xml. When all of the k-ceptors are connected, and I run ./notochord --scan, I see that the six channels seem to read but all with a value of 0. Also, there is an error for channel 6 that say EEPROM not found. When I try to run a capture, several k-ceptors are not found, and I believe that (maybe?) the root of the issues starts here. I tried following the troubleshooting, but couldn't figure out why all of my values are 0. Could you explain whether or not these values of 0 are normal, and also what the EEPROM error means?

Thanks for your help!

also: I am a beta tester and couldn't post to that channel because I do not have the permissions

daylanKifky

Hi @kmw199614!
We gave you betatester permissions and changed the tag on this thread.

kmw199614 I see that the six channels seem to read but all with a value of 0

This value is the address of the K-Ceptor. It can be set by moving the plastic Jumper in J5. When capturing the default biped the addresses should be assigned as in this picture:

This should make all your KCeptors discoverable.

kmw199614 there is an error for channel 6 that say EEPROM not found

Is this happening when you plug that KCeptor alone?

kmw199614

daylanKifky Thanks for your help! We were able to correct the values, now the only issue is on the r-foot with the EEPROM error. We were able to do a calibration on it when it was the only KCeptor attached to J1 on the hub. Is that what you mean by plugging it in alone?

Also a side question, what should the sub-target be for the full-body capture in blender? Is there somewhere that says what the values should be for the capture? I couldn't find that info on the wiki.

Thanks again!

daylanKifky

kmw199614 We were able to do a calibration on it when it was the only KCeptor attached to J1 on the hub. Is that what you mean by plugging it in alone

Yes that's what I meant.
Could you confirm that this EEPROM reading error is only happening when there are more KCeptors plugged to the Hub?

Also, could you try to closely inspect the EEPROM's pins with a magnifying glasss? It's unlikely, but sometimes one of them is not properly soldered causing false contacts. Here's an exaggerated example from this thread: https://forum.chordata.cc/d/25-calibration-questions/8

kmw199614

After inspection, it looks like the EEPROM does not have any issues with the soldering. We did further tests, and do not think it is an issue with that individual k-ceptor.

I can confirm that this error is only happening when there are more k-ceptors plugged into the Hub.

Also, when the "bad" k-ceptor is moved from the foot to the base (channel 5), the error appears in the same foot location, and the base reads properly; whereas if it were the k-ceptor that was the issue, then the base would be expected to have the error now.

I am not sure where this EEPROM is coming from. It appears to be an issue only on configurations of 3 kceptors (i.e. the issue appears on arms or legs, and it is not an issue if an individual supposed "bad" kceptor is plugged in alone or with one other k-ceptor (configurations of 2 on a channel). It is also not a single channel that causes an issue, because if we move the 3 kceptor r leg strand from channel 6 to channel 4, then channel 4 will show the error. However, we have seen the error on arms with supposed a "bad" k-ceptor, but cannot confirm a single one causing the issue. Also when a "bad" kceptor is moved from the foot position where it does not find the EEPROM to the thigh position, now the new foot kceptor does not read.

Sorry if this is confusing, we've tried a lot of different combinations, and I'd be happy to clarify any.

Thanks again

UPDATE: We were able to get a configuration of kceptors so that the error does not occur. It appears that certain kceptors give an EEPROM error when they are in the configuration of 3 connected (i.e. if they are in the arms or legs) This method was solved by moving the kceptors around to other channels with only 1 or 2 kceptors.

There still is an issue, where the EEPROM error appears in either the --scan, or in the -c biped.xml ... command, but it appears to resolve itself throughout the scan. Also I have found that at times, I rerun the command and it runs error free (and if I try again, the error appears again). Is there a way to ensure that it runs error-free the first and every time? I am only rerunning the command, not changing any configuration.

UPDATE 2: It appears that we have it up an working, the EEPROM errors went away after trying multiple configurations of kceptors. Thank you for your help. I have added these updates for documentation of the issues and resolution

daylanKifky

kmw199614
Many thanks for the updates, I'm glad you have it working!
In order to give some background about the cause of this errors: They are probably originated by a corruption on the electronic signal which reads the KCeptors. It's normally not meant to be used in long cable runs, but within the few cm of a single PCB.
In the current version of the Chordata system we are pushing it to the limits, and in practice it has given us and the users almost no issues until now.
This explains why even when you change the position of a KC you still get errors on the same place: It's not a malfunctioning KC, it's just that particular cable run which is hard to read, perhaps it's too long.

Can you confirm you are stil using the B+ model of the RPi, and the custom Raspbian Image downloaded at our webpage?
That image contains instructions to configure the bus at the raspberry at a certain speed which makes the reading less problematic. It meant to be used with model >3, so it might set a different speed on other models.
It can also be that the hardware on that model is slightly different.

kmw199614

daylanKifky Hello, I apologize for the late reply. I am using the Raspberry Pi 3 Model B with the custom Raspbian Image downloaded from the website.

DigitalStages

Today, I finally got my system complete and running. I too have the problem on 3 sensors at the end of that long chains. 2 legs and 1 hand. I assume it is the cable length!? Can you confirm this being the issue?
I am going to shorten the cables, if this is the problem.

Cheers

Below the received error messages using ./notochord --scan:

Press a key to perform init...
~>

info~[ 0] Notochord start @ Tue Apr 21 18:43:15 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~[ 102] Scan: K-Ceptor [kc-CH_1-1], value 1
info~[ 102] Scan: K-Ceptor [kc-CH_1-2], value 2
info~[ 105] Scan: [Base Mux] Hub, GATE: CH_2
info~[ 105] Scan: K-Ceptor [kc-CH_2-1], value 1
info~[ 105] Scan: K-Ceptor [kc-CH_2-2], value 2
info~[ 107] Scan: [Base Mux] Hub, GATE: CH_3
info~[ 108] Scan: K-Ceptor [kc-CH_3-0], value 0
info~[ 108] Scan: K-Ceptor [kc-CH_3-1], value 1
info~[ 108] Scan: K-Ceptor [kc-CH_3-2], value 2
info~[ 110] Scan: [Base Mux] Hub, GATE: CH_4
info~[ 111] Scan: K-Ceptor [kc-CH_4-0], value 0
info~[ 111] Scan: K-Ceptor [kc-CH_4-1], value 1
info~[ 111] Scan: K-Ceptor [kc-CH_4-2], value 2
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~[ 117] Scan: K-Ceptor [kc-CH_6-1], value 1
info~[ 117] Scan: ~_K-Ceptor [kc-CH_6-2], value 2
info~[ 119] Armature Created.
info~[ 119] Starting timer. [NODES < 6 , 15 > = 21 | ODR = 50 | Sleep = 1315us]
info~[ 119] Sending rate = 50Hz
info~[ 119] Timer started, 21 nodes on scheduler
info~[ 643] K_Ceptor kc-CH_6-2...: setup OK.
error~[ 759] EEPROM not found on kc-CH_6-2
info~[ 1284] K_Ceptor kc-CH_6-1...: setup OK.
info~[ 2352] K_Ceptor kc-CH_6-0...: setup OK.
info~[ 3420] K_Ceptor kc-CH_5-0...: setup OK.
info~[ 4488] K_Ceptor kc-CH_4-2...: setup OK.
error~[ 4504] EEPROM not found on kc-CH_4-2
info~[ 5029] K_Ceptor kc-CH_4-1...: setup OK.
info~[ 6097] K_Ceptor kc-CH_4-0...: setup OK.
info~[ 7165] K_Ceptor kc-CH_3-2...: setup OK.
info~[ 8233] K_Ceptor kc-CH_3-1...: setup OK.
info~[ 9301] K_Ceptor kc-CH_3-0...: setup OK.
info~[ 10369] K_Ceptor kc-CH_2-2...: setup OK.
info~[ 11437] K_Ceptor kc-CH_2-1...: setup OK.
info~[ 12505] K_Ceptor kc-CH_1-2...: setup OK.
error~[ 12522] EEPROM not found on kc-CH_1-2
info~[ 13046] K_Ceptor kc-CH_1-1...: setup OK.
info~[ 14114] K_Ceptor kc-CH_1-0...: setup OK.
info~[ 15182] K_Ceptor kc-CH_6-2...: setup OK.
error~[ 15298] EEPROM not found on kc-CH_6-2
info~[ 15826] K_Ceptor kc-CH_4-2...: setup OK.
error~[ 15843] EEPROM not found on kc-CH_4-2
info~[ 16375] K_Ceptor kc-CH_1-2...: setup OK.
error~[ 16392] EEPROM not found on kc-CH_1-2
info~[ 16919] K_Ceptor kc-CH_6-2...: setup OK.
error~[ 17035] EEPROM not found on kc-CH_6-2
info~[ 17563] K_Ceptor kc-CH_4-2...: setup OK.
error~[ 17580] EEPROM not found on kc-CH_4-2
info~[ 18112] K_Ceptor kc-CH_1-2...: setup OK.
error~[ 18129] EEPROM not found on kc-CH_1-2

As shown below, all sensors are recognized by find_KCs.sh:

./find_KCs.sh
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
MUX found at 0x73

K-Ceptors in gate 1 ==> [0][1][2]
K-Ceptors in gate 2 ==> [1][2]
K-Ceptors in gate 3 ==> [0][1][2]
K-Ceptors in gate 4 ==> [0][1][2]
K-Ceptors in gate 5 ==> [0]
K-Ceptors in gate 6 ==> [0][1][2]

daylanKifky

Yes it seems like a cable length problem. It seems like the black cables we provided with the last beta testing program are really problematic.

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.

daylanKifky

kmw199614

Thanks!
and how is it going? are you receiving the captures from the KCs on the end of the chains?

kmw199614

daylanKifky Had to take a break for a while on working on mocap, but back at it now! So far we haven't had further issues with the cables provided, although in the future will most likely crimp a new set for better durability

daylanKifky

Hi, I made a video explaining the KC reading problem over long cables:
https://forum.chordata.cc/d/132-beta-testing-troubleshooting-video-series

DigitalStages

Thanks for your reply!
I am just watching the video "KCeptor reading errors over long cables"
After I have shorten the cables you sent with the Beta system, I still get errors in both legs...[6][2] does not show up, and [4][2] spits out an error:

info~[ 120] Sending rate = 50Hz
info~[ 121] Timer started, 20 nodes on scheduler
info~[ 645] K_Ceptor kc-CH_6-1...: setup OK.
info~[ 1713] K_Ceptor kc-CH_6-0...: setup OK.
info~[ 2781] K_Ceptor kc-CH_5-0...: setup OK.
info~[ 3849] K_Ceptor kc-CH_4-2...: setup OK.
error~[ 3866] EEPROM not found on kc-CH_4-2
info~[ 4391] K_Ceptor kc-CH_4-1...: setup OK.
info~[ 5459] K_Ceptor kc-CH_4-0...: setup OK.
info~[ 6527] K_Ceptor kc-CH_3-2...: setup OK.
info~[ 7595] K_Ceptor kc-CH_3-1...: setup OK.
info~[ 8663] K_Ceptor kc-CH_3-0...: setup OK.
info~[ 9731] K_Ceptor kc-CH_2-2...: setup OK.
info~[ 10799] K_Ceptor kc-CH_2-1...: setup OK.
info~[ 11867] K_Ceptor kc-CH_1-2...: setup OK.
info~[ 12935] K_Ceptor kc-CH_1-1...: setup OK.
info~[ 14003] K_Ceptor kc-CH_1-0...: setup OK.

As a result, I am going to order cables und plugs today. Hope it works!

DigitalStages

Ok, now it is worse. I actually created wires and all light up, but the hub is gone. The wiring was wrong on 2 cables, no sensors showed up. After I fixed the poling, the hub is gone. :-(

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~[ 326] Scan: No Hub found
error~[ 3912] Fatal error: No armature, aborting.

Please help!!!

daylanKifky

if you unplug all wires and try the --scan it gives you the same result?

DigitalStages

Thanks for your reply. I did something wrong with the wires. I did turn the plugs visa verse, when creating the wires. Only the mirrored version of wiring works. The hub still works, I used the old cables for testing.
I will check on the cables again. However, is there any tips about wiring for the beta version, that I need to be aware of?

daylanKifky

Our advice, (which was recently confirmed by @NakedRabbit https://forum.chordata.cc/d/98-build-log/21) is crimping your cables using the twited pairs from a regular ethernet cable. Here's an article from the wiki explaining how to do it

https://wiki.chordata.cc/wiki/User_Manual/1._Chordata_parts/1.2._Cables

If you don't feel like crimping the cables by yourself drop us an email.

DigitalStages

Tis is exactly what I did. I bought an ethernet cable crimple tool and plugs and put it all together. Now I am in the testing of that cable. The output of --scan on a cable you sent me with the beta package:
info~[ 0] Notochord start @ Tue Apr 21 22:23:32 2020

I have big problems with the cables I created. They only recognize one kceptor, no matter where and how many I attach to. I swapped cables to confirm it.
If I use a cable you sent me beside, it gets recognized. I do not know, what is the problem.

I check on the cable you sent me, and I see now, that is in same order. I have to redo all wires :-(. Still, I am not sure, if this will work, as I had wires poled that way. I ll let you know, as soon I ll get the new plugs.

DigitalStages

Hi all!
I did now the wiring of all cables using an Ethernet cable as described. It still does not work for the outer sensors on CH6, CH4, CH3 and CH1. Hands and feet are not working. Very short cable make it work on 3 sensors, but CH4 stays silent. I did swapped sensors to test its functionality with the same result, so all sensors are in working condition. I am wondering about the Hub tho. I had this issue with that burned out chip. Could it be, that the hub is not working correctly?

Any further suggestion to help me out with this.
Cheers!

daylanKifky

If the Hub reads at least one sensor it means it's working.
What do you mean by

DigitalStages CH4 stays silent.

You cannot get any readings in that channel?

What model of raspberry are you using? Could you send me the output of this command? scripts/get_i2c_freq.sh (should be run from the notochord folder)