diff --git a/debug/continuity-errors.txt b/debug/continuity-errors.txt
new file mode 100644
index 00000000..581510fe
--- /dev/null
+++ b/debug/continuity-errors.txt
@@ -0,0 +1,21 @@
+A problem with the original firmware and satip-axe firmware is that
+sometimes there are many continuity errors in the stream. Also, sometimes
+the 8192 PID (means FULLMUX) does not work (bandwidth only few KB instead
+megabytes).
+
+The CC errors are visible using 'axe-debug pti vdev 0' or
+'grep -v AAAAAAAAAAAA /proc/STAPI/stpti/PTI0/vDeviceInfo'.
+The CC errors are not detected by the PTI interface when 8192 PID (fullmux)
+is used.
+
+So there is a data-loss somewhere between STV0900 (demux) and STx7018 (PTI).
+
+The data-loss is visible more when multiple tuners are used together.
+
+Possible steps:
+
+- decode I2C communication with the demodulator
+- try to inject I2C commands to STV0900
+- write own axe-fe module ? because nothing else depends on it,
+  it could be replaced, the only big thing is to determine the i2c
+  connection to STx7018
diff --git a/debug/hardware.txt b/debug/hardware.txt
new file mode 100644
index 00000000..97a9d7cd
--- /dev/null
+++ b/debug/hardware.txt
@@ -0,0 +1,25 @@
+Hardware:
+=========
+
+* CPU STx7108, 32-bit kernel
+  6 x PTI interface (used first four - 0-3)
+      (appears something like programmable transfer interface or so)
+* Demodulators 2x STV0900 (dual)
+* 2x LNBH24 - Dual LNB supply and control IC with step-up and I2C interface
+
+I2C address map:
+================
+
+0x10 - LNBH24 #1 / section A : cfg write
+0x11 - LNBH24 #1 / section A : diagnostic read
+0x12 - LNBH24 #1 / section B : cfg write
+0x13 - LNBH24 #1 / section B : diagnostic read
+0x14 - LNBH24 #2 / section A : cfg write
+0x15 - LNBH24 #2 / section A : diagnostic read
+0x16 - LNBH24 #2 / section B : cfg write
+0x17 - LNBH24 #2 / section B : diagnostic read
+
+0xd0 - STV0900 #1 - write
+0xd1 - STV0900 #1 - read
+0xd2 - STV0900 #2 - write
+0xd3 - STV0900 #3 - read
diff --git a/debug/proc.txt b/debug/proc.txt
index bbeab9de..1ec83216 100644
--- a/debug/proc.txt
+++ b/debug/proc.txt
@@ -4,12 +4,34 @@
 
 echo "deb 0xffffffff" > /proc/bus/nim_sockets
 
+# AXE-firmware command
+axe-debug tuner
+
 #
 # Enable i2c debug
 #
 
 echo "i2c_dbg_trans 1" > /proc/bus/ivo_i2c
 
+# AXE-firmware command
+axe-debug i2c
+
+#
+# Disable debugging
+#
+
+echo "deb 0" > /proc/bus/nim_sockets
+echo "i2c_dbg_trans 0" > /proc/bus/ivo_i2c
+
+# AXE-firmware command
+axe-debug off
+
 #
 # proc PTI files - see PTI.txt
 #
+axe-debug pti
+axe-debug pti dmesg <fe_num_0-3>
+axe-debug pti pid <fe_num 0-3>
+axe-debug pti util <fe_num 0-3>
+axe-debug pti pdev <fe_num 0-3>
+axe-debug pti vdev <fe_num 0-3>
diff --git a/debug/software.txt b/debug/software.txt
new file mode 100644
index 00000000..fc789843
--- /dev/null
+++ b/debug/software.txt
@@ -0,0 +1,17 @@
+TS flow
+*******
+
+main_axe.out binary initializes paths using STAPI from PTI to the dmxts interface
+which provides buffers of size 2695168 bytes per queue.
+
+Kernel modules
+**************
+
+Demodulators and LNB supply/DiseqC chips are driven from the axe-fe module
+(which uses axe-i2c module doing the I2C I/O).
+
+The frontend (probably only LED control ?through I2S bus?) is driven from
+the axe-fp module.
+
+The dmx module is not used but it works as a section decoder. Unfortunately,
+there is no DVR module to collect output and to offer standard DVR API.