TASCAM FW1082 - Service UART (Magyar | English)
2015.03.30.
back to the main page...

On the backplate of the product (on CPU board), there is a 5pins connector. This is a factory test uart port. Lets look, what we can do with this...
This is a simply consol port. We can send from a PC to the device several commands, and we can get some textual informations from the device back. The typing is very annoying, because ther's no backspace or delete implemented. There's no command list help or similar user friendly solutions. The only way to get some help if the command gets some wrong argument, because in this case we gets a hint for the right arguments. I taked a look for the end of the firmware binary, and I find some textual constants there, which was the textual commands...
The connector is not conform with rs232 voltages, but uses CPU low level voltages. So I used a ftdi usb uart modul, to connect the FW1082 to my computer.
CPU Board P3 connector
Pin 1: GND,
Pin 2: nc,
Pin 3: tascam_tx,
Pin 4: tascam_rx,
Pin 5:(power 5V)

FW1082 Main partition version 183 executing.
CRCs: boot=8589 main=940C fpga=1ED7
      midi=C216 perA=7D92 perB=6E41
Loading FPGA.........done, rev=50.
SW/HW Platform Configuration: 1082-ES.
Persistent data partition A: VALID, B: VALID - Using A (gen=1335).
Cumulative operating time: 1224876:21 minutes.
GUID=00022EFF19E5EC3D (434498621)
enabling link interrupts...done.
host gone @474.
Reading MIDI table.
FW1082>
Funny, but the tascam download page says the last version number is 49 and not 50 for the FPGA binary. But in this product we gets 50 for version number. The firmware (cpu code) version numbers are the same 183, which is the latest one, what can be download from tascam site.
The flash storage are organised to partitions. There is Boot, Main, Fpga code, MidiMap, PerA, PerB partitions. The storable configurations, like latest fader positions, etc are stored persistently in two separated place. This method could help to eliminate the data loss at mains power failures, even if user switch off the device while it stores one of the copy. The partitions are protected by CRC32. At boot time, the device checks the CRC, one persistent storage can be damaged quietly, it is normal. When a persistent partition is wrong, it will be formated first, then last version of the storage will be copied to the place. This double buffering technics is usual in embeded world.
This product was run 1.2 million minutes (in powered on state). This is aproximately 20 thousand hours, which is aprox 5years continously. I guess this machine can be 11 years old. There is a GUID field, which is globally uniqe identifier for this product. It is a standardized identifier number in firewire and other industry standards. It contains 3 bytes manufacturer id (6 hexa number, usually last 4 is used). In this product this number is 00 02 2e. The 022e is registered for TEAC. In the firewire standard, we must fill a model number fields too. But this device doesn't send real model number, unfortunately.
FW1082> show
usage: show phy|interrupts|timebase|topology|encoders|1394
FW1082> show phy
base phy registers:
  0: 0x02
  1: 0x3F
  2: 0xE2
  3: 0x41
  4: 0x80
  5: 0x10
  6: 0x00
  7: 0x01
phy page0, port0:
  8: 0xF8
  9: 0x10
phy page0, port1:
  8: 0xF8
  9: 0x10
I guess this is the register map of the PDI1394P23BD physical interface of the 1394 firewire ports.
Base Register Configuration
ADDRESSBIT POSITION
01234567
0Physical ID RCPS
1RHBIBRGap Count
2Extended(111b)RsvdNum_Ports(0010b)
3PHY_Speed(010b)RsvdDelay(0001b)
4LCtrlCJitter(000b)Pwr_Class
5RPIEISBRCTOICPSISTOIPEIEAAEMC
6Reserved
7Page_SelectRsvdPort Select
Page 0 (Port Status) Registers Configuration
ADDRESSBIT POSITION
01234567
8AStatBStatChConBiasDis
9Peer_SpeedPIEFaultReserved
10Reserved
11Reserved
12Reserved
13Reserved
14Reserved
15Reserved
FIELDSIZETYPEDESCRIPTION
Physical ID6RdThis field contains the physical address ID of this node determined during self-ID. The physical-ID is invalid after a bus reset until self-ID has completed as indicated by an unsolicited register-0 status transfer.
R1RdRoot. This bit indicates that this node is the root node. The R bit is reset to 0 by bus reset, and is set to 1 during tree-ID if this node becomes root.
CPS1RdCable-power-status. This bit indicates the state of the CPS input terminal. The CPS terminal is normally tied to serial bus cable power through a 390k resistor. A 0 in this bit indicates that the cable power voltage has dropped below its threshold for ensured reliable operation.
RHB1Rd/WrRoot-holdoff bit. This bit instructs the PHY to attempt to become root after the next bus reset. The RHB bit is reset to 0 by a hardware reset, and is unaffected by a bus reset.
IBR1Rd/WrInitiate bus reset. This bit instructs the PHY to initiate a long (166 ms) bus reset at the next opportunity. Any receive or transmit operation in progress when this bit is set will complete before the bus reset is initiated. The IBR bit is reset to 0 after a hardware reset or a bus reset.
Gap Count6Rd/WrArbitration gap count. This value is used to set the subaction (fair) gap, arb-reset gap, and arb-delay times. The gap count can be set either by a write to the register, or by reception or transmission of a PHY_CONFIG packet. The gap count is reset to 3Fh by hardware reset or after two consecutive bus resets without an intervening write to the gap count register (either by a write to the PHY register or by a PHY_CONFIG packet).
Extended3RdExtended register definition. For the PDI1394P23, this field is 111b, indicating that the extended register set is implemented.
Num_Ports4RdNumber of ports. This field indicates the number of ports implemented in the PHY. For the PDI1394P23 with the TWOPORT pin high this field is 2. With the TWOPORT pin low this field is 1.
PHY_Speed3RdPHY speed capability. For the PDI1394P23, this field is 010b, indicating S400 speed capability.
Delay4RdPHY repeater data delay. This field indicates the worst case repeater data delay for this PHY, expressed as 144+(delay × 20) ns. For the PDI1394P23, this field is 1.
LCtrl1Rd/WrLink-active status control. This bit is used to control the active status of the LLC as indicated during self-ID. The logical AND of this bit and the LPS active status is replicated in the L field (bit 9) of the self-ID packet. The LLC is considered active only if both the LPS input is active the and LCtrl bit is set. The LCtrl bit provides a software controllable means to indicate the LLC active status in lieu of using the LPS input. The LCtrl bit is set to 1 by hardware reset and is unaffected by bus-reset. NOTE: The state of the PHY-LLC interface is controlled solely by the LPS input, regardless of the state of the LCtrl bit. If the PHY-LLC interface is operational as determined by the LPS input being active, then received packets and status information will continue to be presented on the interface, and any requests indicated on the LREQ input will be processed, even if the LCtrl bit is cleared to 0.
C1Rd/WrContender status. This bit indicates that this node is a contender for the bus or isochronous resource manager. This bit is replicated in the “c” field (bit 20) of the self-ID packet. This bit is set to the state specified by the C/LKON input terminal by a hardware reset and is unaffected by a bus reset.
Jitter3RdPHY repeater jitter. This field indicates the worst case difference between the fastest and slowest repeater data delay, expressed as (Jitter + 1) × 20 ns. For the PDI1394P23, this field is 0.
Pwr_Class3Rd/WrNode power class. This field indicates this node’s power consumption and source characteristics and is replicated in the pwr field (bits 21–23) of the self-ID packet. This field is reset to the state specified by the PC0–PC2 input terminals upon hardware reset, and is unaffected by a bus reset.
RPIE1Rd/WrResuming port interrupt enable. This bit, if set to 1, enables the port event interrupt (PEI) bit to be set whenever resume operations begin on any port. This bit is reset to 0 by hardware reset and is unaffected by bus reset.
ISBR1Rd/WrInitiate short arbitrated bus reset. This bit, if set to 1, instructs the PHY to initiate a short (1.3 ms) arbitrated bus reset at the next opportunity. This bit is reset to 0 by a bus reset. NOTE: Legacy IEEE Std 1394–1995 compliant PHYs are not capable of performing short bus resets. Therefore, initiation of a short bus reset in a network that contains such a legacy device results in a long bus reset being performed.
CTOI1Rd/WrConfiguration time-out interrupt. This bit is set to 1 when the arbitration controller times-out during tree-ID start, and may indicate that the bus is configured in a loop. This bit is reset to 0 by hardware reset, or by writing a 1 to this register bit. NOTE: If the network is configured in a loop, only those nodes which are part of the loop should generate a configuration time out interrupt. All other nodes should instead time out waiting for the tree-ID and/or self-ID process to complete and then generate a state time-out interrupt and bus-reset.
CPSI1Rd/WrCable-power-status interrupt. This bit is set to 1 whenever the CPS input transitions from high to low indicating that cable power may be too low for reliable operation. This bit is set to 1 by hardware reset, and set to 0 by writing a 1 to this register bit.
STOI1Rd/WrState time-out interrupt. This bit indicates that a state time-out has occurred. This bit is reset to 0 by hardware reset, or by writing a 1 to this register bit.
PEI1Rd/WrPort event interrupt. This bit is set to 1 on any change in the connected, bias, disabled, or fault bits for any port for which the port interrupt enable (PIE) bit is set. Additionally, if the resuming port interrupt enable (RPIE) bit is set, the PEI bit is set to 1 at the start of resume operations on any port. This bit is reset to 0 by hardware reset, or by writing a 1 to this register bit.
EAA1Rd/WrEnable arbitration acceleration. This bit enables the PHY to perform the various arbitration acceleration enhancements defined in P1394a (ACK-accelerated arbitration, asynchronous fly-by concatenation, and isochronous fly-by concatenation). This bit is reset to 0 by hardware reset and is unaffected by bus reset.
EMC1Rd/WrEnable multispeed concatenated packets. This bit enables the PHY to transmit concatenated packets of differing speeds in accordance with the protocols defined in P1394a. This bit is reset to 0 by hardware reset and is unaffected by bus reset. NOTE: The use of multispeed concatenation is completely compatible with networks containing legacy IEEE Std 1394–1995 PHYs. However, use of multispeed concatenation requires that the attached LLC be P1394a compliant.
Page_Select3Rd/WrPage_Select. This field selects the register page to use when accessing register addresses 8 through 15. This field is reset to 0 by a hardware reset and is unaffected by bus-reset.
Port_Select4Rd/WrPort_Select. This field selects the port when accessing per-port status or control (e.g., when one of the port status/control registers is accessed in page 0). Ports are numbered starting at 0. This field is reset to 0 by hardware reset and is unaffected by bus reset.
Port status descriptions
AStat2RdTPA line state. This field indicates the TPA line state of the selected port, encoded as follows: Code: Arb Values are 11:Z, 01:1, 10:0, 00:invalid
BStat2RdTPB line state. This field indicates the TPB line state of the selected port. This field has the same encoding as the ASTAT field.
Ch1RdChild/parent status. A 1 indicates that the selected port is a child port. A 0 indicates that the selected port is the parent port. A disconnected, disabled, or suspended port is reported as a child port. The Ch bit is invalid after a bus-reset until tree-ID has completed.
Con1RdDebounced port connection status. This bit indicates that the selected port is connected. The connection must be stable for the debounce time of 330ms–350ms for the Con bit to be set to 1. The Con bit is reset to 0 by hardware reset and is unaffected by bus reset. NOTE: The Con bit indicates that the port is physically connected to a peer PHY, but the port is not necessarily active.
Bias1RdDebounced incoming cable bias status. A 1 indicates that the selected port is detecting incoming cable bias. The incoming cable bias must be stable for the debounce time of 41.6ms–52ms for the Bias bit to be set to 1
Dis1Rd/WrPort disabled control. If 1, the selected port is disabled. The Dis bit is reset to 0 by hardware reset (all ports are enabled for normal operation following hardware reset). The Dis bit is not affected by bus reset
Peer_Speed3RdPort peer speed. This field indicates the highest speed capability of the peer PHY connected to the selected port, encoded as follows: Code:Peer Speeds are 000: S100, 001: S200, 010: S400, 011–111: invalid. The Peer_Speed field is invalid after a bus reset until self-ID has completed. NOTE: Peer speed codes higher than 010b (S400) are defined in P1394a. However, the PDI1394P23 is only capable of detecting peer speeds up to S400.
PIE1Rd/WrPort event interrupt enable. When set to 1, a port event on the selected port will set the port event interrupt (PEI) bit and notify the link. This bit is reset to 0 by a hardware reset, and is unaffected by bus-reset.
Fault1Rd/WrFault. This bit indicates that a resume-fault or suspend-fault has occurred on the selected port, and that the port is in the suspended state. A resume-fault occurs when a resuming port fails to detect incoming cable bias from its attached peer. A suspend-fault occurs when a suspending port continues to detect incoming cable bias from its attached peer. Writing 1 to this bit clears the fault bit to 0. This bit is reset to 0 by hardware reset and is unaffected by bus reset.
FW1082> show interrupts
  max event q: 7
  clk resync:  1
  tick(sec):   60.943
At this moment, I uderstand only this are some statistical counters. Max event q: counted events (what?).. Clk resync: I guess this is relation to AK4117VF chip irq pin. Somehow its reports clk jitter, and syncronization events. Probably this is a counter of the resync irq handler called, or similar... tick(sec): even if tick usualy means periodic sw timing, here something is different. This shows the time in sec (milisec resolution) after reset.
FW1082> show timebase
  sample rate measurement:
     FPGA internal = 44.153 Khz
    word clock BNC = 0.000 Khz
     adat receiver = 0.000 Khz
    spdif receiver = 0.000 Khz
  target_timebase = 0101 (internal/44.1)
  actual_timebase = 0101 (internal/44.1)
These are the different audio subsystems sampling frequencies. I guess there is a SRC (Sample Rate Converter) in the FPGA. I beleive this, other case the measurements will be non-sense, if we don't runs different digital audios together. IE: the spdif can be operate even if we choose other Fs for internal clock, but this way we have to do SRC on slave inputs.
FW1082> show topology
topoMap.s.length = 0x0
topoMap.s.generation_number = 0x1
topoMap.s.node_count = 0x0
topoMap.s.self_id_count] = 0x0
1394 bus topoligical information. Here was no connection to other devices.
show topology
topoMap.s.length = 0x4
topoMap.s.generation_number = 0x3
topoMap.s.node_count = 0x2
topoMap.s.self_id_count] = 0x2
topoMap.s.self_id_packet[0] = 0x80488060 (local node)
topoMap.s.self_id_packet[1] = 0x814889D6
Here we have a connection to a PC. So we have two nodes.
FW1082> show encoders
     1     2     3     4     5     6     7     8     9    10    11    12
     0     0     0     0     0     0     0     0    16     0     0    -3

Rotary encoders states. So user can increment or decrement this values.
FW1082> show 1394
Showing devices on 1394 bus:
  node count = 0.
  node 0 self ID pkt = 0x00000000 (local node):
    ROM[000]: 040F2E8F.
    ROM[004]: 31333934.
    ROM[008]: 20FF7002.
    ROM[00C]: 00022EFF.
    ROM[010]: 19E5EC3D.
Completed.
The above report comes from a state when device was not connected. In this case we can see only our rom_config block, which is a standard IEEE1394 stuff. It is 120bytes long in real, but here we can see only the first 20 bytes. The whole block typically contains textual informations about the manufacturer, product. And some informations about the device communication protocol. This block can be read by a linux host, after connecting there will be a file somewhere here: /sys/bus/firewire/fw0/rom_config. I was tested my device with an old linux kernel, and it was not able to understand exactly this binary block. As far as I understand, it is becasue the semantical contents of the rom_config was not in the format as the linux 1394 kernel driver expected.
FW1082> show 1394
Showing devices on 1394 bus:
  node count = 2.
  node 0 self ID pkt = 0x80458090 (local node):
    ROM[000]: 040F2E8F.
    ROM[004]: 31333934.
    ROM[008]: 20FF7002.
    ROM[00C]: 00022EFF.
    ROM[010]: 19E5EC3D.
  node 1 self ID pkt = 0x814589D6:
    ROM[000]: 0404BD5D.
    ROM[004]: 31333934.
    ROM[008]: F000A022.
    ROM[00C]: 00110666.
    ROM[010]: 455555A0.
Completed.
This report was made after successfull connection. Node 0 is the local (FW1082) config, node 1 is for the remote host side which was a PC and VIA 6306 card in this case. The vendor ids are shown here: 0x22ef, 0x1106. The first one is for TEAC, the second one for the VIA Technologies. Unfortunately my card was not compatible with the FW1082.
Ez egy csatlakoztatott állapot volt. Node 0 a helyi csomópont, a note 1 a távoli, jelen esetben a host egy PC volt, a kártya VIA 6306 chippel szerelt. A vendor id-k itt 0x22ef és 0x1106. Az első a TEAC, a második a VIA Technologies, Inc. Sajnos ez a VIA chip régi, bár a windows alapból ismeri, de annyira gyermeteg a drivere, hogy INTL_LESS_OR_EQUAL kékhalált és protokol hibát (no header) produkál egy percen belül. De a kommunikáció felépítésénél is változatos számú bus reset történt. Nálam, ha működött is, akkor a streaming közben valami buffer hibák mellett szaggatottan szólt. Több helyen olvasni róla, hogy a VIA chip-es firewire kártyák nem használhatóak komolyabb forgalom esetén. Eredetileg az Apple-lel a Texas Instruments dolgozott együtt, a szabvány és a prototipusok kifejlesztésén. A VIA volt az első gyártó, aki egy tokba szerelte a PHY és Logical interfészt, igy sokkal olcsóbb alkatrészt adott a kártyagyártók számára. Csomó alkatrész spórolós megoldásuk van, pl van reset láb, de nem kell oda kötni semmilyen alkatrészt, mert a VIA chip-ben van belső reset áramkör. Stb.. Szóval gyanítom, hogy az összes spórolós gyártó elkezdte ezt a chip-et használni, majd mindent szépen lespórolt, még a kábel ESD védelmét, illesztést, leválasztást is. Ezen a kártyán ránézésre RC szűrős illesztés van, míg a profibb kártyákon (és az FW1082-ben is) trafós illesztés van. Rövidebb és hosszabb kábellel is teszteltem. A hosszabbal már a kommunikáció kezdetén is hibák voltak. A rövidebb kábellel még valamennyire stabilan fel is épült a kapcsolat, de később "host gone" üzenetet adott az fw1082. Sajnos nem kaptam hirtelen Texas Instruments-es kártyát, de annak beszerzése lesz a következő lépés... A fenti riportban a távoli oldalához tartozó dump 4 byte-onként ismétlődő egyforma értékeket tartalmaz (szemét), ha a kommunikáció hibás volt. Ha link sincs, akkor a korábbi riportot kapjuk, ahol teljesen hiányzik a túloldali dump.
FW1082> led
usage: led 1/0 num
A num értéket hexa számként kell megadni. Az alábbi táblázat szerint, a 6-ik csatorna SEL ledje az a0 ID-val érhető el. Egyes ledek többször is szerepelnek a táblázatban, valószinű a don't care bitek miatt. De ezt nem ellenőriztem, csak logikusnak tűnik.
Led IDNév
0 + n*20Channel #n SEL
1 + n*20Channel #n SOLO
2 + n*20Channel #n MUTE
3 + n*20Channel #n OL
4 + n*20Channel #n SIGNAL
5 + n*20Channel #n REC
1dCOMPUTER
3dMIDI CTRL
3eBOTH, F3 /F7
3fEQ LO MID-AUX 3/7 , 48kHz
eeD IN (flash)
FW1082> leds
usage: leds on|off|rows|cols|random
Gyári/szerviz tesztet támogató parancs, jellemzően egy billentyűre vár, azután kilép a kis programjából, és a ledeket úgy hagyja ahogy volt (nyilván a rendszeresen frissülő ledek állapotot fognak váltani). A rows hatására végig megy a sorokon, az egy sorban lévő ledeket mind kigyújtja. a cols hatására az oszlopokon megy végig. A sor és oszlop itt a kapcsolási rajz szerinti szerverzést jelenti, nem pedig a fizikai elhelyezkedést.
FW1082> touch
3FD 002 001 006 003 000 004 002 001  000 000  200 000 3FD  --------T
3FF 001 002 006 001 002 000 004 001  000 001  202 000 3FF  --------T
A touch futtatása addig tart amig a sorosporton egy újabb karakter nem jön. Eközben folyamatosan a fennti hexa dump formájában riportozza az keyboard panelokon lévő ADC-k értékét. Az első 9 hexa szám a csatorna faderek és a master fader adc értékét tartalmazza (000..3ff) 10 bites ADC-ről van szó tehát 0..1023 lehet az érték. Tipikusan az alsó két bit zajos lehet, ezért az összes szám időről-időre változik. Egy karakternyi szünet után két újabb oszlop következik, ez a kimeneti board-hoz tartozik. Az első értéke nálam mindig nulla, a második a MONITOR poti állása szerint alakul. A fader board és az output board egy külön kis 3 pin-es kábellel van összekötve, amelyen ez a poti feszültség utazik. Tehát ha lehúzzuk, akkor lebeg a beAD-zott érték... A következő 3 oszlop szintén egy karakterrel jobbra van tolva. Nem néztem a kapcsolási rajzot most, de gyanítom, hogy Ut/2 , GND, és Ut van rákötve, mert kb 511, 0, 1023 környékén ingadozik az érték. Egy szünet után kilenc darab - , x vagy T szerepel a táblázatban. Ezek a touch elektronikát hivatottak tesztelni. A tolópotik csúszkájának külön fegyverzete is van, amit egy schtriggers comparátorral olvas ki a fader board. Ebből állapítják meg, hogy hozzáértünk-e a fader fém csúszkájához. Az én készülékemben a master fader-hez tartozó elektronika nem hibátlan, ezért folyton touch-ot jelez. Ha röviden érünk a faderhez, akkor x, ha hosszan akkor T betű jelenik meg. A készüléken is látszik mindez. Az egyes faderek fölött a SOLO és MUTE ledek úgy világítanak, ahogy a fader-ekhez érünk.
FW1082> fader
usage: fader dc channel(1-9) val(0-0x400)
usage: fader square time(msec >4) amplitude(0-0x400)
usage: fader wave
usage: fader test
usage: fader touch
FW1082> fader touch
Egy fader megérintésével kiválasztjuk a tesztelendőt, a választásunkat a SIGNAL led jelzi. Ha egyszerre több faderhez érünk hozzá, akkor az első lesz a kiválasztott. Az ehhez a faderhez tartozó beolvasott ADC érték pedig az összes led segítségével 8 ledenként oktálisan lesz kijelezve (4 sor 8 oszlop)... Jó játék.
FW1082> fader test
      1   2   3   4   5   6   7   8   9
PWM: 080 080 080 080 080 080 080 080 080
ADC: 08C 08B 088 084 084 088 088 087 001
      1   2   3   4   5   6   7   8   9
PWM: 000 000 000 000 000 000 000 000 000
ADC: 00C 00E 00E 00A 004 008 00D 00E 001
      1   2   3   4   5   6   7   8   9
PWM: 080 080 080 080 080 080 080 080 080
ADC: 077 078 076 078 073 06B 07A 072 003
      1   2   3   4   5   6   7   8   9
PWM: 100 100 100 100 100 100 100 100 100
ADC: 0FA 0FB 0F7 0F9 0F5 0F5 0F6 0F2 003
      1   2   3   4   5   6   7   8   9
PWM: 200 200 200 200 200 200 200 200 200
ADC: 1FB 1FA 1F8 1FC 1F5 1F7 1FA 1F8 005
      1   2   3   4   5   6   7   8   9
PWM: 300 300 300 300 300 300 300 300 300
ADC: 2F8 2F8 2F6 2F8 2F5 2F4 2F7 2F5 001
      1   2   3   4   5   6   7   8   9
PWM: 380 380 380 380 380 380 380 380 380
ADC: 377 37A 376 376 376 373 37C 371 006
      1   2   3   4   5   6   7   8   9
PWM: 400 400 400 400 400 400 400 400 400
ADC: 3F7 3FC 3F7 3F7 3F3 3EE 3FA 3F7 001
      1   2   3   4   5   6   7   8   9
PWM: 380 320 2C0 260 200 1A0 140 0E0 080
ADC: 387 32C 2C7 266 206 1A4 149 0E7 001
      1   2   3   4   5   6   7   8   9
PWM: 080 0E0 140 1A0 200 260 2C0 320 380
ADC: 088 0EE 143 1A8 203 254 2BC 317 001

Maximum Error:
     00C 00E 00E 00A 00D 015 00D 00F 3FF
Lefut pár féle fader mozgatás, az eltéréseket statisztikázza. Esetemben a master fader motorvezérlő ic-je ki van forrasztva, igy az nem mozog. A flying fader úgy van megvalósítva, hogy 9 darab lassú digitális outputunk van (amit az FPGA-ban megvalósított PWM-ek állítanak elő). Amely output feszültség, az elvárt fader pozicióhoz tartozik. A fader egy DC szintet oszt, tehát nem audio jel megy rajta keresztül. A fader által leosztott és a pwm által előállított feszültséget egy comparátor hasonlítja össze, a komparátor kimenete pedig a motorvezérlő ic bemenetére jut. A motorvezérlő tiltható. Ha engedélyezett állapotban van, akkor megindul a kivánt irányba. Természetesen szűrő kondik is vannak rajta, úgyhogy van egy adott lassúsága, fáziskésése a folyamatnak. Továbbá csúcsáram korlátozás is van, gondolom azért hogy a motor ne égjen le fizikai akadályozás esetén se. Továbbá, ha touch sensor azt jelzi, hogy a user rátenyerelt, akkor értelem szerűen nem is engedélyezi a motor meghajtást, csak akkor ha elengedte... Szóval lényegében full analog a cucc. Műveleti erősítők, DC motor vezérlő... Nos a mechanikai akadályok, kopás, megszorulás miatt, és a potenciométer tűrése, kopása, sérülése miatt eltérés (hiba) lehet a fennti diagnosztikában. Ezen öreg készüléknél látható hogy 4-5 bitnyi eltérés is keletkezett. Itt jegyezném meg, hogy az ADC-m is eléggé 5-6 bitnyit ugrált, gondolom a táp zajossága miatt. Úgyhogy ez az egész bizonytalanság valószínű nem a motorok és a faderek, hanem az AD átalakító hibája jelen esetben. Mivel nem volt játékszobám, kipróbáltam azt is , hogy a teszt közben hozzáérek a faderekhez. Ilyenkor az adott fader teljesen meg is állt. És bután ettől kezdve minden teszt elbukott, kb full scale mérési hibával ugye... Gondolom akkor szoftveresen ez úgy lehet megcsinálva hogy nem tartozik hozzá egy release timeout. (más keverőkön szokott a touch automatizáláshoz ilyen lenni).
A fader wave egy sinus-os hullámot futtat végig a fadereken, látványos, de nem ir ki semmi diagnosztikát.
a "fader square time_ms aplitudó" paranccsal szétrázhatjuk a fadereket...
A "fader dc channel(1-9) val(0-0x400)" paranccsal valószínüleg egy szoftveres kompenzálást állíthatunk be az adott faderhez DC szintre. De nem jöttem rá pontosan mit csinál, annyira most nem érdekes. Főleg igy nem érdekel, hogy csak dc szint állítható. Gondolom kellene még egy tűrést is paraméterezni a kopási hibák kompenzálásához, de mindegy... ez van.
FW1082> routing
usage: routing AVhi2ADAT|AVmixlo2ADAT|analog2ADAT|SPDIF2ADAT
               AVmix2analog|ADAT2analog|SPDIF2analog|analog2analog|
               AV2SPDIF|mix2SPDIF|SPDIF2SPDIF
               mix2phones|SPDIF2phones|analog2phones
               analog122spdif|analog342spdif|analog562spdif|analog782spdif
               analog122analog12|analog342analog12|analog562analog12|analog782analog12
A CPU boardon van egy FPGA, amely az audio streamek route-olását végzi. Ebbe tudunk beavatkozni a fennti paranccsal. Az én készülékem 1082ES, amiben nincs ADAT io, de az fpga kódja tartalmazza. Egyébként a boardon lévő feliratok tanusága szerint ez a CPU board szerepel a 1804-es készülékben is. Amiben gondolom van ADAT. Egyébiránt van pár be nem forrasztott alkatrész pad a kimenetek környékén, úgyhogy valószinű a sync és az optikai ki-bemenetek ott lehetnének... Csak feltételezés: AV a firewire Audio streamje, a phones a fejhallgató kimenet, analog12 kimenetként a monitor lehet. A többi elnevezés érthető.
FW1082> subcode
                     1    2    3    4    5    6    7    8    9   10   11   12
faders 1-9:        018B 01AF 0293 0246 02B3 0003 0083 0290 03FF
solo, mon, touch:  0000 0261 FEFF
keyswitch:         FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
encoder 1-12:      0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0005
                      1      2      3      4      5      6      7      8
analog in meters:  000107 0000F9 000140 000189 000239 000273 00024B 000255
adat in meters:    000000 000000 000000 000000 000000 000000 000000 000000
spdif in meters:   000000 000000
analog out meters: 00065A 000442 000000 000000 000000 000000 000000 000000
adat out meters:   000000 000000 000000 000000 000000 000000 000000 000000
spdif out meters:  000000 000000
clock sys status:  01010101
AV sync status:    00000000
Állapotok egyben... Értelem szerűen ezek csak a egy adott pillanathoz tartozó állapotok, pl kijelzés / VU meter számára mondjuk.
FW1082> level
usage: level channel(0-255) val(0-0xFFFF)
       level channel val1 val2 val3 val4(0-0xFFFF) msec
Nem próbáltam még ki, de gondolom teszt generátornak használható.
FW1082> spdif
usage: spdif status|clear
FW1082> spdif status
  PLL unlock
  spdif( 0):0F  spdif( 8):00  spdif(16):00  spdif(24):00
  spdif( 1):20  spdif( 9):00  spdif(17):00  spdif(25):00
  spdif( 2):0C  spdif(10):00  spdif(18):00  spdif(26):00
  spdif( 3):3F  spdif(11):00  spdif(19):00  spdif(27):00
  spdif( 4):C7  spdif(12):00  spdif(20):00  spdif(28):00
  spdif( 5):80  spdif(13):00  spdif(21):00  spdif(29):00
  spdif( 6):01  spdif(14):00  spdif(22):00  spdif(30):00
  spdif( 7):00  spdif(15):00  spdif(23):00  spdif(31):00
FW1082> testswitch
switch down: byte=12, bit=2.
switch up:   byte=12, bit=2.
switch down: byte=12, bit=1.
switch up:   byte=12, bit=1.
Minden gomb lenyomására és felengedésére riport jön, illetve valamelyik led hozzá is van rendelve, igy lehet vizuálisan is ellenőrizni...
FW1082> testdigital
Setting timebase to 44 Khz internal.
FW1082>
  adat input status...*********** FAILED (D3), (0.000 Khz)
  spdif input status...passed
  word clock input status...*********** FAILED (0.000 Khz)
Setting timebase to 48 Khz internal.
  adat input status...*********** FAILED (D3), (0.000 Khz)
  spdif input status...passed
  word clock input status...*********** FAILED (0.000 Khz)
Setting timebase to 88 Khz internal.
  adat input status...*********** FAILED (D3), (0.000 Khz)
  spdif input status...passed
  word clock input status...*********** FAILED (0.000 Khz)
Setting timebase to 96 Khz internal.
  adat input status...*********** FAILED (D3), (0.000 Khz)
  spdif input status...passed
  word clock input status...*********** FAILED (0.000 Khz)
Test spdif over optical @ 96 Khz.
  spdif input status...*********** FAILED (EF), (19.155 Khz)
Ennél a tesztnél loopback-et kéne csinálni, de mivel se adat, se wc io nincs, igy csak az spdif-et tudtam tesztelni. :) Ja és optikai spdif is külön úton menne, ami szintén nincs... (nincs beültetve az alkatrész)
FW1082> read1394
usage: read1394 hexaddr_hi hexaddr_lo
FW1082> read1394 00 00
1394 read(00000000,00000000) initiated.
Diag1394Response[0]: 00000000.
Diag1394Response[1]: 00000000.
Diag1394Response[2]: 00000000.
Diag1394Response[3]: 00000000.
Diag1394Response[4]: 00000000.
Diag1394Confirmation: 00000080.
Diag1394Tail: 00000000.
*************
1394 read completed: 00000000.
Itt nem volt Firewire csatlakoztatva momentán.
FW1082> testmidi
Testing MIDI out 1 to in 1 loopback...*********** FAILED
Testing MIDI out 2 to in 2 loopback...*********** FAILED
Testing MIDI out 3 to in 3 loopback...*********** FAILED
Testing MIDI out 4 to in 4 loopback...*********** FAILED
Nem volt kéznél midi kábel, de ez is egy loopback teszt lenne. Amúgy a CPU board 4 input és 4 output midi portot támogat, még a csatlakozón is ott a kábel, de a breakout boardon már csak 2 in és 2 out van beültetve...
FW1082> set
usage: set fs|ref|debug|spdifin|optiout|adatout|spdifout args
FW1082> set fs whata
usage: set fs 44|48|88|96
FW1082> set ref what
usage: set ref xtal|wc|spdif|adat
FW1082> set debug w
usage: set debug mask_value
FW1082> set spdifin w
usage: set spdifin opti|coax
FW1082> set spdifout w
usage: set spdifout spdif|analog
FW1082> set optiout w
usage: set optiout spdif|adat

Ezek nagyjából világosak... Alacsony szinten állítja be a dolgokat, tehát a kijelzésen nem változik azonnal. Pl FS állítás után módot kell váltani, és ekkor már jól jelzi a LED a kiválaszott frekvenciát. Amúgy a konzolra se ír semmit...
FW1082> testencoder
Rotary encoderek tesztelése... SHTL gomb a nagy Shuttle tekerésével együtt látványos let villogtatást produkál, továbbá a CH1 mute gombja megnyomásával a PAN rotary teszi ugyanezt, majd a rotary mellett lévő 44.1kHz gomb megnyomásával a felette lévő EQ rotary tesztelhető, az az felett lévő gombbal pedig egyel felette lévő rotary, stb... (elcsúszva sajna).. Tehát igy összesen 5 darab rotary encoder tesztelhető, ha a hozzá tartozó gombot nyomjuk... Egyébként más gombok (pl a többi MUTE gomb ) megnyomására is csinálni akar valamit, de gondolom fizikailag nincs olyan rotary ebben a gépben.




back to the main page...