From Chordata documentation
Jump to: navigation, search
Banner for the version 0.1.0a of the custom chordata linux image. Since the notochord is the most important program running on it, the whole system on the SBC often takes its name

The main software running inside the Microcomputer, it's in charge of reading the sensors and sending the processed data to the Client.

In this documentation we sometimes refer to the SBC, or the operating system running inside of it as the notochord.


This section contains some of the more common problems that you might find when running the Notochord. It is built upon the doubts or problems of others before you. If you have some issue that's not covered here, please ask in the forum

i2c adaptor not found[edit]

If you get an error like:

error~[    101] An error occured when trying to initialize the i2c adaptor on the system:
The i2c adapter is not available on this system

Most of the times means that the i2c functionalities on your SBC are not activated. See this section of the wiki

Error switching branch[edit]

This occurs when the notochord is able to use the i2c adapter on your SBC (in other words the i2c port is enabled and working), but it can't find the Hub.

The error message would look like this one:

error~[    102] error switching branch left. Retrying.. (0)
error~[    124] error switching branch left. Retrying.. (1)
error~[    144] error switching branch left. Retrying.. (2)
error~[    165] error switching branch left. Retrying.. (3)
error~[    185] error switching branch left. Retrying.. (4)
error~[    206] Too many errors when switching branch left.
error~[    206] An error ocurred: Can't write to mux

This might be due to a wrong address for the Hub on the configuration file. A wiring problem, or a malfunction of the SBC's i2c port.


On the SBC terminal environment run i2cdetect -y 1. It should find a device with the address 0x73.
  • If it did find that device, then double check that the address on the configuration file is 0x73.
  • If it didn't find that device, then make sure your wiring is correct and the Hub is powered (the blue led is on). It is also a good idea to connect another i2c device to your SBC and run i2cdetect -y 1 to see if the SBC is able to find that one.

Can't find K-Ceptor[edit]

This is one of the most common errors:

error~[    102] Can't find K_Ceptor the_KCeptor

The Notochord is expecting to find a K-Ceptor with a particular translation value, in a particular Branch. But that K-Ceptor is not there.


Check on your configuration file if the value of that K-Ceptor matches the one physically connected to the Hub. Also check that it is on the correct Branch
For example if you are using the Chordata.xml you can do:
nano Chordata.xml
To open the GNU Nano text editor. Once inside it search the name of the K-Ceptor that was causing troubles with the command Ctrl + W
if you find, for example, something like this:
<Mux Name="main" id="0">
    <Branch Name="left" id="1">
        <K_Ceptor Name="the_KCeptor" id="2">

Then the Notochord will expect a single K-Ceptor with value 1 on the Gate 1 of the Hub. Does this description match the way your K-Ceptor is connected?

If you are sure the Hierarchy described on your configuration file is correct, then you should look for a connectivity problem. A common one is to connect one of the K-Ceptors backwards. You can run the utility script ./ within the notochord folder to get a list of all K-Ceptors found connected to the Hub.

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

An output like this would mean that the K-Ceptor connected to the gate 1 has a value of 2. While..

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

The output above tells you that the value of the connected K-Ceptor is indeed 1, but it is connected to the gate 2

Both situations would give you K-Ceptor not found errors when executing the Notochord with the XML used as an example on this section.

XML validation error[edit]

If you edited a configuration file by hand, you might get a scary error error like:

error~[     32] Program aborted because of an error:
Error parsing Chordata's config files 
Cause: Error on xml file validation:
/home/pi/notochord/bin/../Chordata.xml:47: parser error : error parsing attribute name
		<Mux Name="main" id="0">
/home/pi/notochord/bin/../Chordata.xml:47: parser error : attributes construct error
		<Mux Name="main" id="0">
/home/pi/notochord/bin/../Chordata.xml:47: parser error : Couldn't find end of Start Tag Armature line 46
		<Mux Name="main" id="0">
/home/pi/notochord/bin/../Chordata.xml:56: parser error : Opening and ending tag mismatch: Chordata line 2 and Armature
/home/pi/notochord/bin/../Chordata.xml:57: parser error : Extra content at the end of the document

This means that there's an error on the way your XML configuration file is structured. The nature of these errors can be:

  • XML syntax errors like the one reported above, caused by just deleting the trailing ">" from a tag. If you have no experience with the XML syntax the best way to solve those problems is to start over with a fresh copy of the Chordata.xml file.
  • Schemas validity errors are caused by a well formed XML, but containing elements or attributes that wouldn't make sense for the Notochord.