summaryrefslogtreecommitdiff
path: root/ir
diff options
context:
space:
mode:
authorWerner Almesberger <werner@almesberger.net>2014-08-26 17:03:16 -0300
committerWerner Almesberger <werner@almesberger.net>2014-08-26 17:03:16 -0300
commit44e23ebee61cfb0cb7ac92cd4324838589ee591b (patch)
treeb5d886243293383ec5321f885bc60049329ae7ae /ir
parent25a4c84e337c29193127da8595b1ee3710d0bd64 (diff)
downloadmisc-44e23ebee61cfb0cb7ac92cd4324838589ee591b.tar.gz
misc-44e23ebee61cfb0cb7ac92cd4324838589ee591b.tar.bz2
misc-44e23ebee61cfb0cb7ac92cd4324838589ee591b.zip
ir/: prepare final version (still needs proof-reading)
Introduction: - resolved to call the device "GTA04b7", never "Neo900" (i.e., remove to do item, no text change) Section "IR modes" - indicate that SIR and IR-UART RX are not terribly important can could be dropped if they add too many difficulty Section "IR-UART" - change lowest "common" data rate from 19.2 kbps to 9.6 kbps Section "Received signal processing" - branch IR receiver to audio codec before high-pass filters - add high-pass filter at tentatively 10 Hz in IR-UART mode. The suggested range was 1-100 Hz, so I picked the middle. Incandescent lightbulbs flicker at 100-120 Hz, so even 100 Hz would be marginal for anything but daylight filtering yet could already interfere with low bit rates. - added drawing of filter selection and with output amplifier Section "CPU powered down" - specify that IR shell be off Section "Configuration" - assume that hackerbus doesn't need the ability to override the configuration of the IR subsystem (i.e., remove the "to do" item, no text change) Section "Reset" - in CPU reset state, bq27200 POR state selects IR-UART and non-POR state (i.e., GPIO explicitly set to "0") disables IR - leave use of bq.GPIO past CPU reset state to the implementor: "When the CPU has left its reset state and can actively control the IR subsystem, it is also able to change the state of bq.GPIO. bq.GPIO can therefore be used (or ignored) as the implementation sees fit." Added bq.GPIO with dashed lines to all IR configurations under CPU control. - confirmed: do not mention hypothetical debug messages from the ROM boot loader Section "IR deactivated" - add "and use as little power as possible for any filters and/or amplifiers." Section "Undriven signals" - specify that the IR circuit has to be tolerant against undriven UART signals but leave the rest to the implementation. Section "Overload protection" - rewrote, now with circuit simulation example
Diffstat (limited to 'ir')
-rw-r--r--ir/Makefile2
-rw-r--r--ir/cir.fig12
-rw-r--r--ir/filter.fig62
-rw-r--r--ir/ir.tex163
-rw-r--r--ir/irda.fig12
-rw-r--r--ir/sys.fig6
-rw-r--r--ir/uart.fig12
7 files changed, 198 insertions, 71 deletions
diff --git a/ir/Makefile b/ir/Makefile
index 285d5fb..41d4c5f 100644
--- a/ir/Makefile
+++ b/ir/Makefile
@@ -1,4 +1,4 @@
-FIGS = sys cir irda uart window
+FIGS = sys filter cir irda uart window
.PHONY: all clean
.SUFFIXES: .fig .pdf
diff --git a/ir/cir.fig b/ir/cir.fig
index 06c4c2c..98061fb 100644
--- a/ir/cir.fig
+++ b/ir/cir.fig
@@ -62,10 +62,13 @@ Single
1350 2565 1125 2565
2 1 0 3 32 7 50 -1 -1 0.000 0 2 7 0 0 2
1755 2250 3600 2250
+2 1 1 3 0 7 50 -1 -1 8.000 0 0 -1 0 0 3
+ 1800 4680 1800 4365 2610 4365
+2 1 1 3 0 7 50 -1 -1 8.000 0 0 -1 0 0 2
+ 2700 1125 2700 1710
4 0 0 50 -1 22 12 0.0000 4 135 660 3420 1890 CIR LED\001
4 1 0 50 -1 22 12 0.0000 4 135 165 2925 4275 IR\001
4 1 0 50 -1 22 12 0.0000 4 105 540 2925 4410 sensor\001
-4 1 0 50 -1 22 12 0.0000 4 135 1005 2880 5130 Audio codec\001
4 0 0 50 -1 22 12 0.0000 4 135 330 3645 2970 RTS\001
4 0 0 50 -1 22 12 0.0000 4 135 225 3645 3285 RX\001
4 1 0 50 -1 22 12 4.7124 4 135 840 4140 2700 Hackerbus\001
@@ -78,5 +81,8 @@ Single
4 2 0 50 -1 22 12 0.0000 4 165 1125 1080 2610 uart3_cts_rctx\001
4 2 0 50 -1 22 12 0.0000 4 165 990 1080 2295 uart3_tx_irtx\001
4 2 0 50 -1 22 12 0.0000 4 180 570 1080 1395 gpio(s)\001
-4 1 0 50 -1 22 12 0.0000 4 180 510 1575 4095 control\001
-4 1 0 50 -1 22 12 0.0000 4 180 510 1575 1260 control\001
+4 1 0 50 -1 22 12 0.0000 4 135 570 1575 4095 control\001
+4 1 0 50 -1 22 12 0.0000 4 135 570 1575 1260 control\001
+4 1 0 50 -1 22 12 0.0000 4 135 1005 2925 5130 Audio codec\001
+4 1 0 50 -1 22 12 0.0000 4 180 645 2700 1080 bq.GPIO\001
+4 1 0 50 -1 22 12 0.0000 4 180 645 1800 4860 bq.GPIO\001
diff --git a/ir/filter.fig b/ir/filter.fig
new file mode 100644
index 0000000..cedfb80
--- /dev/null
+++ b/ir/filter.fig
@@ -0,0 +1,62 @@
+#FIG 3.2 Produced by xfig version 3.2.5c
+Landscape
+Center
+Metric
+A4
+100.00
+Single
+-2
+1200 2
+2 2 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 5175 6300 5625 6300 5625 6750 5175 6750 5175 6300
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 3
+ 5265 6390 5265 6660 5535 6660
+2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 5625 6525 6075 6525
+2 3 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4725 5715 4725 6705 4275 6525 4275 5895 4725 5715
+2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 3
+ 3825 6975 4500 6975 4500 6615
+2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 3
+ 5625 5895 6075 5895 6075 7200
+2 2 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 5175 5670 5625 5670 5625 6120 5175 6120 5175 5670
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 3
+ 5265 5760 5265 6030 5535 6030
+2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 5175 5895 4725 5895
+2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 5175 6525 4725 6525
+2 2 0 3 0 7 50 -1 -1 0.000 0 0 7 0 0 5
+ 6660 5985 7290 5985 7290 6435 6660 6435 6660 5985
+2 1 0 3 0 7 50 -1 -1 0.000 0 0 7 0 0 2
+ 7380 6165 7470 6120
+2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 6660 6210 6075 6210
+2 1 0 3 0 7 50 -1 -1 0.000 0 0 7 0 0 2
+ 7380 6255 7470 6210
+2 3 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 4
+ 3825 5985 3825 6435 3420 6210 3825 5985
+2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 4275 6210 3825 6210
+2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 3
+ 3465 6210 3150 6210 3150 5625
+2 2 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 3060 5220 3240 5220 3240 5625 3060 5625 3060 5220
+2 1 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 3150 4725 3150 5220
+3 2 0 2 0 7 50 -1 -1 0.000 0 0 0 3
+ 5397 6623 5440 6458 5535 6435
+ 0.000 -1.000 0.000
+3 2 0 2 0 7 50 -1 -1 0.000 0 0 0 3
+ 5310 5985 5392 5829 5535 5805
+ 0.000 -1.000 0.000
+4 1 0 50 -1 22 12 0.0000 4 135 1005 6075 7380 Audio codec\001
+4 1 0 50 -1 22 12 0.0000 4 135 90 4500 6525 0\001
+4 1 0 50 -1 22 12 0.0000 4 135 90 4500 6030 1\001
+4 1 0 50 -1 22 12 0.0000 4 135 510 5400 5580 ~10 Hz\001
+4 1 0 50 -1 22 12 0.0000 4 135 600 5400 6975 ~20 kHz\001
+4 1 0 50 -1 22 12 0.0000 4 135 165 6975 6210 IR\001
+4 1 0 50 -1 22 12 0.0000 4 105 540 7020 6345 sensor\001
+4 1 0 50 -1 22 12 0.0000 4 135 225 3150 4680 RX\001
+4 2 0 50 -1 22 12 0.0000 4 135 690 3780 7065 IR-UART\001
diff --git a/ir/ir.tex b/ir/ir.tex
index 8661b39..f1170e4 100644
--- a/ir/ir.tex
+++ b/ir/ir.tex
@@ -14,7 +14,7 @@ Werner Almesberger%
\footnote{Specification details and illustrations.}
%~\url{<werner@almesberger.net>}
}
-\date{July 22, 2014}
+\date{August 26, 2014}
\def\TODO{{\bf TO DO}}
\def\todo#1{\begin{center}{\bf TO DO:} #1\hfill~\end{center}}
@@ -32,8 +32,6 @@ It is intended to be used both as tentative specification and as
documentation of actual functionality, and may be revised as
focus shifts over time from requirements to implementation.
-\todo{In this context, do we call it ``GTA04b7'' or ``Neo900'' ?}
-
% -----------------------------------------------------------------------------
\section{System overview}
@@ -86,6 +84,10 @@ Likewise, since the IR data path is shared between CPU and Hackerbus,
conflicting configurations are possible. Their resolution is described
in section \ref{conflict}.
+Note that we don't consider IR-UART reception and SIR to be important
+features. If their implementation should prove to be overly troublesome,
+there could therefore be omitted.
+
% -----------------------------------------------------------------------------
\section{Physical layer}
@@ -153,7 +155,7 @@ the following characteristics:
\begin{tabular}{l|cll}
Parameter & Value & Unit \\
\hline
-Data rate & 19.2--115.2 & kbps (typical) \\
+Data rate & 9.6--115.2 & kbps (typical) \\
Duty cycle & 9.1--91 & \% &%
\footnote{The duty cycle range of 9.1--91\% (1/11 to 10/11) is for 8 bits with
even parity, as used by the DM3730 ROM boot loader.
@@ -163,9 +165,6 @@ without parity format.} \\
\end{tab}%
\end{savenotes}%
-\todo{Just assumed some common bit rates. Are they reasonable for our
-scenario ?}
-
% - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
\subsection{Combined characteristics}
@@ -219,16 +218,14 @@ we would consider unacceptable.
In order to improve its range, the transmitter should be driven with as
high a current as reasonably possible. This current would be well above
the permissible continuous forward current In CIR and IrDA mode. Note
-that incorrect use could cause the IR LED to overheat and the length of
+that incorrect use could cause the IR LED to overheat and the energy of
a pulse therefore has to be limited. We discuss this in section \ref{overload}.
-\todo{Mention ``low-current'' mode here, too, if approved.}
-
% - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
\subsection{Received signal processing}
-% High=pass RX filter
+% High-pass RX filter
%
% Jul 07 23:57:01 <DocScrutinizer05> for the RX we want a phototransistor
% with filter gear to implement a highpass with cutoff @ ~20kHz
@@ -241,18 +238,35 @@ a pulse therefore has to be limited. We discuss this in section \ref{overload}.
On the receiving side, the signal should go through a high-pass filter with
a cutoff frequency of about 20 kHz and then be shaped into a digital
-signal for the RX line. The analog signal should also be sent to an unused
-input of the audio codec. We have no further specification for the analog
-signal from the IR sensor at this time.
+signal for the RX line. The unfiltered analog signal should also be sent to
+an unused input of the audio codec. We have no further specification for the
+analog signal from the IR sensor at this time.
+
+\begin{center}
+\includegraphics[scale=0.9]{filter.pdf}
+\end{center}
+
+Given that IR-UART can have very long high or low pulses, a high-pass
+filter with a much lower cut-off frequency has to be used when IR-UART mode
+is selected. A cut-off frequency of about 1--100 Hz should be sufficient
+for DC blocking. The figure above illustrates the concept.
% Analog IR RX TBD
%
% Jul 17 03:43:57 <DocScrutinizer05> IR RX: I have nothing specific in mind,
% and I don't think we need to specify it right now. Will care about it later
-\todo{Given that IR-UART can have very long high or low pulses, should
-the cutoff frequency not be in the range of bps/10, e.g., 2 kHz if we
-assume 19.2 kbps to be the lowest supported data rate ?}
+%
+% Jul 23 15:48:26 <DocScrutinizer05> "ToDo HPF" we don't use HighPass
+% filtering for UART mode, at least not with 20kHz, rather a DC-offset
+% (aka background light) blocking filter at maybe 1Hz..100Hz (TBD)
+%
+% Jul 23 15:48:51 <DocScrutinizer05> This applies to UART mode only. SIR
+% needs a 20kHz HPF
+% Jul 23 15:49:21 <DocScrutinizer05> err, CIR needs that. SIR I'm currently
+% clueless
+%
+
% -----------------------------------------------------------------------------
@@ -261,11 +275,6 @@ assume 19.2 kbps to be the lowest supported data rate ?}
The IR subsystem can be configured for several different modes of operation.
The following sections detail the various configurations.
-\todo{J\"org once mentioned the possibility of Hackerbus overriding the
-CPU's configuration signals.
-The following assumes that the CPU is exclusively in charge of configuring
-IR. Is that okay ?}
-
The following sections show the configuration of both the transmitter and
the receiver. In many real-life situations, only one direction will be
used at a time while the other is deactivated. A deactivated transmitter
@@ -275,7 +284,13 @@ or receiver should behave as described in section \ref{off}.
\subsection{CPU powered down}
-\todo{What do we do ? Turn IR off, follow bq.GPIO, something else ?}
+If the CPU is powered down, the IR subsystem shall be deactivated as
+described in section \ref{off}.
+
+%
+% Jul 23 15:51:50 <DocScrutinizer05>
+% "ToDo CPU power down" we want IR to be disabled then, right?
+%
% - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@@ -295,15 +310,18 @@ by EEPROM content and is therefore retained across power-cycling,
the open-collector output is always set to ``1'', i.e., it is high-Z.
If bq.GPIO is high-Z and the CPU's control signals are in their reset
-state, the IR subsystem shall be deactivated as described in section
-\ref{off}.
-
-If bq.GPIO is ``0'' and the CPU's control signals are in their reset state,
+state,
both transmitter and receiver shall be active and operate in IR-UART mode.
The purpose of this mode is to allow the CPU's ROM boot loader to try to boot
from UART3 via infrared.
-\todo{Do we agree that bq27200 power on reset defaults to ``IR off'' ?}
+If bq.GPIO is ``0'' and the CPU's control signals are in their reset state,
+the IR subsystem shall be deactivated as described in section
+\ref{off}.
+
+When the CPU has left its reset state and can actively control the IR
+subsystem, it is also able to change the state of bq.GPIO. bq.GPIO can
+therefore be used (or ignored) as the implementation sees fit.
The following table summarizes the IR configuration in power-down and
after CPU reset:
@@ -312,10 +330,10 @@ after CPU reset:
\begin{tabular}{ll|l}
CPU.controls & bq.GPIO & IR configuration \\
\hline
-CPU off & any & \TODO \\
-reset state & ``1'' (High-Z) & off (minimum power) \\
- & ``0'' & IR-UART TX/RX \\
-active & ignored & defined by controls \\
+CPU off & any & off (minimum power) \\
+reset state & ``1'' (High-Z) & IR-UART TX/RX \\
+ & ``0'' & off (minimum power) \\
+active & to be defined & defined by controls \\
\end{tabular}
\end{tab}%
%
@@ -324,8 +342,6 @@ section \ref{cfg:iruart}.
Note that Hackerbus can override the receiver and the CPU can therefore
boot from (wired) UART even if the IR-UART configuration is selected.
-\todo{Also mention hypothetical debug messages from the ROM boot loader ?}
-
% - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
\subsection{IR deactivated}
@@ -336,7 +352,8 @@ or one at a time, through the control signals to the IR subsystem.
When deactivated, the IR subsystem must draw as little current as possible.
The transmitter must ignore its data inputs, e.g., TX and CTS, and under no
-circumstance activate the IR LED. The receiver must not drive the RX line.
+circumstance activate the IR LED. The receiver must not drive the RX line
+and use as little power as possible for any filters and/or amplifiers.
% - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@@ -465,9 +482,6 @@ operate at a lower voltage.
% Jul 08 00:54:44 <DocScrutinizer05> don't worry about "color2 filtering,
% we already ahve a apparently completely black window
-\todo{I selected a photodiode with daylight filter since relying on the IR
- window just seems too risky. Agreed ?}
-
The characteristics of the daylight filter integrated in the IR
window of the N900 case are unknown,
our design will add multiple internal light sources
@@ -494,8 +508,6 @@ available SMT parts all had rise and fall times in the order of 15 $\mu$s,
which would limit the maximum signal frequency to only about 30 kHz,
and did not allow improving their response by biasing the transistor.
-\todo{Is the use of ``biasing'' correct here ?}
-
% -----------------------------------------------------------------------------
\section{Component placement}
@@ -555,17 +567,18 @@ before entering the RX line.
\section{Undriven signals}
-If a UART signal is driven by neither CPU, Hackerbus, or the IR receiver,
-...
-
-\todo{What do we do then ? Let it float ? Add a hardware pull up/down ?
-In the latter case, which way ?}
+The IR circuit must be tolerant to a UART signal being driven by neither
+CPU, Hackerbus, or the IR receiver. Whether this tolerance is achieved by
+pulling the signal to a safe state or by implementing a more general
+protection against incorrect inputs is left as an implementation choice.
Control signals that float after CPU reset and that are not ignored by the
IR subsystem must be pulled to a safe state.
% -----------------------------------------------------------------------------
+
+
\section{Overload protection}
\label{overload}
@@ -574,21 +587,55 @@ IR subsystem must be pulled to a safe state.
% Jul 07 23:54:20 <DocScrutinizer05>
% make sure the pulsewidth at 500mA gets limited by hw to 100us
-Since the IR LED can be driven with a current significantly above its
-permitted continuous forward current, the pulse width at high current
-must be limited. This shall be enforced by hardware, apply to any mode
-but IR-UART (see below),
-and the maximum continuous pulse width shall be 100 $\mu$s.
+To improve its range, the IR LED can be driven with a peak current
+significantly above its permitted continuous forward current. If the
+diode is driven at such a high current for too long, it could overheat
+and suffer permanent damage.
+
+While some of the IR protocols operate with low duty cycles that allow the
+transmitter to cool down between bursts or pulses, the circuit should not
+rely on software always
+setting up things correctly. Also, the IR-UART protocol can have duty cycles
+of up to 91\% and would require special handling.\footnote{One possible use
+of IR-UART it to output kernel diagnostics. This sort of text would have a
+duty cycle of about 50--60\% if sent as 8 bit characters with a start and a
+stop bit each and the LED lit during every ``0'' bit.}
+
+We considered simply limiting pulse length to the peak duration of 100
+$\mu$s commonly specified for IR LEDs, but this would still leave
+many dangerous patterns and would conflict with correct use of IR-UART
+where the maximum nominal pulse at 19.2 kbps is already 469 $\mu$s.
+
+We therefore suggest a simple analog circuit that limits long-term
+average current to the diode's continuous forward current but that stores
+energy for short bursts in a capacitor. Use with low duty cycle would give
+the capacitor time to recharge between pulses while high duty cycle would
+empty the capacitor in a brief initial flash and then proceed at the
+``safe'' continuous current.
+
+This reflects the thermal processes inside the diode, where the
+continuous current corresponds to heat dissipation and the
+peak energy transferred from the capacitor corresponds to the diode's
+thermal energy.
+
+\begin{center}
+\includegraphics[scale=0.74, trim=30 0 180 0, clip]{ir-ilim-cc.pdf}
+\end{center}
+
+\noindent
+Example current-limiting circuit: continuous current through the
+IR LED D1 is limited by R1 and R3. Short pulses in the 100 $\mu$s range
+can draw extra current from C1. The peak current is then limited by the
+constant current transistor circuit. This example uses a Darlington
+configuration to obtain a current gain $\beta \gg 100$.
-\todo{We didn't discuss this property of IR-UART yet. It okay to introduce
-this ``low-current'' mode ?}
+The simulation illustrates the operation of the circuit with an infinite
+pulse starting at 100 $\mu$s. Note that the model is only a rough approximation
+and should be confirmed by lab measurements. The source of the Qucs simulation
+can be found here:
-Since IR-UART mode can operate with a duty cycle of up to 91\%,
-IR LED current should be reduced to the LED's maximum continuous
-forward current in this mode. Furthermore, the maximum nominal pulse
-length at 19.2 kbps is 469 $\mu$s and pulse width limiting must
-therefore not be applied.
+\noindent
+\url{http://neo900.org/git/?p=misc;a=blob;f=ir/ilim-cc.sch;hb=HEAD}
\end{document}
-
% Jul 09 16:47:10 <DocScrutinizer05> re any multiplexing: I expect the whole IR section to get powered down by asserting a GPIO pin to a non-POR-default state, so the IR is active by default after power on reset. By connecting the whole IR via some series resistors to the UART, I expect anything on hackerbus to be able to override what comes from IR, particularly when IR is powered down
diff --git a/ir/irda.fig b/ir/irda.fig
index eaa913e..6c49c33 100644
--- a/ir/irda.fig
+++ b/ir/irda.fig
@@ -62,10 +62,13 @@ Single
1350 2160 1755 2160 1755 2340 1350 2340 1350 2160
2 1 0 3 0 7 50 -1 -1 0.000 0 2 -1 0 0 2
1350 2250 1125 2250
+2 1 1 3 0 7 50 -1 -1 8.000 0 0 -1 0 0 2
+ 2700 1125 2700 1710
+2 1 1 3 0 7 50 -1 -1 8.000 0 0 -1 0 0 3
+ 1800 4680 1800 4365 2610 4365
4 0 0 50 -1 22 12 0.0000 4 135 660 3420 1890 CIR LED\001
4 1 0 50 -1 22 12 0.0000 4 135 165 2925 4275 IR\001
4 1 0 50 -1 22 12 0.0000 4 105 540 2925 4410 sensor\001
-4 1 0 50 -1 22 12 0.0000 4 135 1005 2880 5130 Audio codec\001
4 0 0 50 -1 22 12 0.0000 4 135 330 3645 2970 RTS\001
4 0 0 50 -1 22 12 0.0000 4 135 225 3645 3285 RX\001
4 1 0 50 -1 22 12 4.7124 4 135 840 4140 2700 Hackerbus\001
@@ -78,5 +81,8 @@ Single
4 2 0 50 -1 22 12 0.0000 4 165 1125 1080 2610 uart3_cts_rctx\001
4 2 0 50 -1 22 12 0.0000 4 165 990 1080 2295 uart3_tx_irtx\001
4 2 0 50 -1 22 12 0.0000 4 180 570 1080 1395 gpio(s)\001
-4 1 0 50 -1 22 12 0.0000 4 180 510 1575 4095 control\001
-4 1 0 50 -1 22 12 0.0000 4 180 510 1575 1260 control\001
+4 1 0 50 -1 22 12 0.0000 4 135 570 1575 4095 control\001
+4 1 0 50 -1 22 12 0.0000 4 135 570 1575 1260 control\001
+4 1 0 50 -1 22 12 0.0000 4 135 1005 2925 5130 Audio codec\001
+4 1 0 50 -1 22 12 0.0000 4 180 645 2700 1080 bq.GPIO\001
+4 1 0 50 -1 22 12 0.0000 4 180 645 1800 4860 bq.GPIO\001
diff --git a/ir/sys.fig b/ir/sys.fig
index 8dedc29..5c59e26 100644
--- a/ir/sys.fig
+++ b/ir/sys.fig
@@ -68,7 +68,6 @@ Single
4 0 0 50 -1 22 12 0.0000 4 135 660 3420 1890 CIR LED\001
4 1 0 50 -1 22 12 0.0000 4 135 165 2925 4275 IR\001
4 1 0 50 -1 22 12 0.0000 4 105 540 2925 4410 sensor\001
-4 1 0 50 -1 22 12 0.0000 4 135 1005 2880 5130 Audio codec\001
4 0 0 50 -1 22 12 0.0000 4 135 330 3645 2970 RTS\001
4 0 0 50 -1 22 12 0.0000 4 135 225 3645 3285 RX\001
4 1 0 50 -1 22 12 4.7124 4 135 840 4140 2700 Hackerbus\001
@@ -83,5 +82,6 @@ Single
4 2 0 50 -1 22 12 0.0000 4 165 1125 1080 2610 uart3_cts_rctx\001
4 2 0 50 -1 22 12 0.0000 4 165 990 1080 2295 uart3_tx_irtx\001
4 2 0 50 -1 22 12 0.0000 4 180 570 1080 1395 gpio(s)\001
-4 1 0 50 -1 22 12 0.0000 4 180 510 1575 1260 control\001
-4 1 0 50 -1 22 12 0.0000 4 180 510 1575 4095 control\001
+4 1 0 50 -1 22 12 0.0000 4 135 570 1575 1260 control\001
+4 1 0 50 -1 22 12 0.0000 4 135 570 1575 4095 control\001
+4 1 0 50 -1 22 12 0.0000 4 135 1005 2925 5130 Audio codec\001
diff --git a/ir/uart.fig b/ir/uart.fig
index 88ce574..03e3db4 100644
--- a/ir/uart.fig
+++ b/ir/uart.fig
@@ -62,10 +62,13 @@ Single
3330 4320 3420 4275
2 1 0 3 0 7 49 -1 -1 0.000 0 2 7 0 0 2
1125 3195 3600 3195
+2 1 1 3 0 7 50 -1 -1 8.000 0 0 -1 0 0 3
+ 1800 4680 1800 4365 2610 4365
+2 1 1 3 0 7 50 -1 -1 8.000 0 0 -1 0 0 2
+ 2700 900 2700 1710
4 0 0 50 -1 22 12 0.0000 4 135 660 3420 1890 CIR LED\001
4 1 0 50 -1 22 12 0.0000 4 135 165 2925 4275 IR\001
4 1 0 50 -1 22 12 0.0000 4 105 540 2925 4410 sensor\001
-4 1 0 50 -1 22 12 0.0000 4 135 1005 2880 5130 Audio codec\001
4 0 0 50 -1 22 12 0.0000 4 135 330 3645 2970 RTS\001
4 0 0 50 -1 22 12 0.0000 4 135 225 3645 3285 RX\001
4 1 0 50 -1 22 12 4.7124 4 135 840 4140 2700 Hackerbus\001
@@ -78,5 +81,8 @@ Single
4 2 0 50 -1 22 12 0.0000 4 165 1125 1080 2610 uart3_cts_rctx\001
4 2 0 50 -1 22 12 0.0000 4 165 990 1080 2295 uart3_tx_irtx\001
4 2 0 50 -1 22 12 0.0000 4 180 570 1080 1395 gpio(s)\001
-4 1 0 50 -1 22 12 0.0000 4 180 510 1575 4095 control\001
-4 1 0 50 -1 22 12 0.0000 4 180 510 1575 1260 control\001
+4 1 0 50 -1 22 12 0.0000 4 135 570 1575 4095 control\001
+4 1 0 50 -1 22 12 0.0000 4 135 570 1575 1260 control\001
+4 1 0 50 -1 22 12 0.0000 4 135 1005 2925 5130 Audio codec\001
+4 1 0 50 -1 22 12 0.0000 4 180 645 2700 855 bq.GPIO\001
+4 1 0 50 -1 22 12 0.0000 4 180 645 1800 4860 bq.GPIO\001