• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

Multichannel audio on a Pi will get a whole lot easier and cheaper!

I am not personally very interested in multichannel I2S output but I figured others might be (although I always love to tinker). And as a first step in multichannel I2S with the RPi I figured multichannel output would have less variables as I already have a McFIFO / McDualXO + 8 channel AES output device sitting on the shelf that I know works with multichannel I2S input.

I am mostly interested in the potential for multichannel I2S input from a 7.1 HDMI to I2S extractor like this -> https://www.aliexpress.us/item/2251832845605595.html. An Apple TV + HDMI to I2S extractor + RPi 5 running CamillaDSP + multichannel USB DAC (like the UL Mk5) is a very interesting AVR replacement setup to me.

Michael
Hi there. I am also very interested in a similar set-up. Right now, I have an Apple TV 4K 2nd Gen., going into TV via HDMI. TV outputs 2.0 (forced) over TOSLINK going into nanoDIGI 2x8 (digital DSP). I also have a RPi 5 running LMS+squeezelite, also feeding the nanoDIGI via an USB->SPDIF adapter. nanoDIGI does room correction and EQ, and output over co-ax SPDIF to SMSL DO100.

At some point, I'd like to have surround sound from Apple TV, so I bought two STA310 chips (dolby decoder), in order to build my own DIY Dolby 5.1 (DTS/AAC) decoder. The decoder would output four I2S channels, which then would be sent to a RPi using the diynhk I2C-USB bridge. Then CDSP for 6 channel room correction and EQ, and back out over USB to Topping DM7.

Reading this thread, I now realise, things could be much simpler. Apple TV 4K acts as the Dolby decoder and outputs multi-channel PCM over HDMI. Commercial HDMI audio extractor strips out multi channel audio and outputs four I2S stereo channels which apparently can be fed directly into a RPi 5, saving yet another board. Then the plan is still Topping DM7, hopefully 2nd hand at a good price.

@mdsimon2 I wanted to ask, which exactly HDMI I2S extractor did you purchase? Was it the one in the link? Did it come with a box?
 
@mdsimon2 I wanted to ask, which exactly HDMI I2S extractor did you purchase? Was it the one in the link? Did it come with a box?

Yes, that was the one I purchased. It did not come with a box, and I wouldn't want a box in this application as you want to keep the I2S connections as short as practicable.

If you read through the thread, you will see I eventually ran into some issues, so be prepared for some troubleshooting.

Michael
 
Thanks for confirming. Yes, I read through the post, and saw that you saw some nasty cracking/popping sounds. I am happy to experiment and see how frequent this or other issues are.
 
Very brief tutorial assuming you know your way around a Pi / Linux.

1) Install raspberry pi os lite 64 bit using raspberry pi imager.

2) Clone 6.7 kernel.

Code:
git clone --depth=1 --branch rpi-6.7.y https://github.com/raspberrypi/linux

3) Configure kernel

Code:
cd linux
KERNEL=kernel_2712
make bcm2712_defconfig

4) Modify kernel to use all i2s inputs / outputs.

Code:
nano ~/linux/arch/arm/boot/dts/broadcom/rp1.dtsi

Rich (BB code):
rp1_i2s0_18_21: rp1_i2s0_18_21 {
   function = "i2s0";
   pins = "gpio18", "gpio19", "gpio20", "gpio22", "gpio24", "gpio26", "gpio21", "gpio23", "gpio25",  "gpio27";
   bias-disable;
};

rp1_i2s1_18_21: rp1_i2s1_18_21 {
    function = "i2s1";
    pins = "gpio18", "gpio19", "gpio20", "gpio22", "gpio24", "gpio26", "gpio21", "gpio23", "gpio25",  "gpio27";
    bias-disable;
};

5) Compile modified kernel. This will take around 45 minutes on a raspberry pi 5.

Code:
make -j4 Image.gz modules dtbs
sudo make modules_install
sudo cp arch/arm64/boot/dts/broadcom/*.dtb /boot/firmware/
sudo cp arch/arm64/boot/dts/overlays/*.dtb* /boot/firmware/overlays/
sudo cp arch/arm64/boot/dts/overlays/README /boot/firmware/overlays/
sudo cp arch/arm64/boot/Image.gz /boot/firmware/kernel_2712.img
sudo reboot

6) Clone RaspberryPi_I2S_Master

Code:
git clone https://github.com/AkiyukiOkayasu/RaspberryPi_I2S_Master

7) Compile RaspberryPi_I2S_Master and copy to /boot/overlays

Code:
cd RaspberryPi_I2S_Master
dtc -@ -H epapr -O dtb -o i2smaster.dtbo -Wno-unit_address_vs_reg i2smaster.dts
sudo cp i2smaster.dtbo /boot/overlays

8) Modify /boot/config.txt to use I2S.

Code:
sudo nano /boot/config.txt

Rich (BB code):
#dtparam=i2c_arm=on
dtparam=i2s=on
#dtparam=spi=on
dtoverlay=i2smaster

9) Reboot pi.

Code:
sudo reboot

10) Setup CamillaDSP configuration.

I used playback device as hw:I2Smaster, S32LE format and 8 channels.

----

Some good references where I gathered all this info, again thanks to @phofman.


----
Pin Mapping
GPIO 18: BLCK/SCLK
GPIO 19: WS/LRCLK
GPIO 20: I2S data IN 0
GPIO 22: I2S data IN 1
GPIO 24: I2S data IN 2
GPIO 26: I2S data IN 3
GPIO 21: I2S data OUT 0
GPIO 23: I2S data OUT 1
GPIO 25: I2S data OUT 2
GPIO 27: I2S data OUT 3
----

Michael
Hi @mdsimon2, I finally seem to have found your tutorial on how to use the Raspi 5 internal I2S ins and outs (like @phofman has pointed me to). I'm very excited that you discovered/enabled this option - it addresses exactly what I want to achieve!

Background and status:
Currently I've managed to get a Raspberry Pi 5 up and running with Raspberry Pi OS 64bit and CamillaDSP. I would like to use CamillaDSP for 6 channel FIR filtering for a stereo 3-way speaker setup. I basically would like 1x coax and 1x optical SPDIF input (for Wiim Pro+ streamer) and then 6x coax SPDIF out (so only digital outputs are wanted). The reason behind this concept is, that I want max flexibility to use any commercial or DIY DACs in the output section (as the DAC has a huge impact on sound signature). I've just built a 6 channel tube DAC based on the Lampizator Lampucera circuit (and it sounds absolutely stunning), which I would like to use in the output section of CamillaDSP/Raspi.

Questions:
- Is the method you described above in your post #108 still the easiest, most reliable and still recommended option to access the Raspi 5 internal I2S ins and outs via the GPIO header? Or is there any easier, more reliable, better solution by now?
- These GPIO 18: BLCK/SCLK and GPIO 19: WS/LRCLK have to be used for all I2S ins/outs in parallel, correct?
- With the above method, can you confirm that I can use 3x of Wm8805 i2s to coax spdif boards in order to get from I2S the coax SPDIF outs?
- With the above method, can you confirm that I can use 1x of SPDIF to I2S as an input source?
- To my understanding, the SPDIF input would not allow CamillaDSP to adjust to varying input sample rates. What's your recommended way to use CamillaDSP and Tidal connect for enabling bit perfect (realtime sample rate adjustment of Camilla DSP) streaming? (I have the Wiim Pro+, but don't insist on using it if there is any good and reliable software solution).
- I found this Tidal Connect Docker image for HifiBerry (and RaspbianOS). Would this work with Raspi5/Raspberry Pi OS/CamillaDSP/USB gadget for achieving Bit perfect streaming?

Thanks a lot in advance, for your help and guidance!
 
Hi @mdsimon2, I finally seem to have found your tutorial on how to use the Raspi 5 internal I2S ins and outs (like @phofman has pointed me to). I'm very excited that you discovered/enabled this option - it addresses exactly what I want to achieve!

Background and status:
Currently I've managed to get a Raspberry Pi 5 up and running with Raspberry Pi OS 64bit and CamillaDSP. I would like to use CamillaDSP for 6 channel FIR filtering for a stereo 3-way speaker setup. I basically would like 1x coax and 1x optical SPDIF input (for Wiim Pro+ streamer) and then 6x coax SPDIF out (so only digital outputs are wanted). The reason behind this concept is, that I want max flexibility to use any commercial or DIY DACs in the output section (as the DAC has a huge impact on sound signature). I've just built a 6 channel tube DAC based on the Lampizator Lampucera circuit (and it sounds absolutely stunning), which I would like to use in the output section of CamillaDSP/Raspi.

Questions:
- Is the method you described above in your post #108 still the easiest, most reliable and still recommended option to access the Raspi 5 internal I2S ins and outs via the GPIO header? Or is there any easier, more reliable, better solution by now?
- These GPIO 18: BLCK/SCLK and GPIO 19: WS/LRCLK have to be used for all I2S ins/outs in parallel, correct?
- With the above method, can you confirm that I can use 3x of Wm8805 i2s to coax spdif boards in order to get from I2S the coax SPDIF outs?
- With the above method, can you confirm that I can use 1x of SPDIF to I2S as an input source?
- To my understanding, the SPDIF input would not allow CamillaDSP to adjust to varying input sample rates. What's your recommended way to use CamillaDSP and Tidal connect for enabling bit perfect (realtime sample rate adjustment of Camilla DSP) streaming? (I have the Wiim Pro+, but don't insist on using it if there is any good and reliable software solution).
- I found this Tidal Connect Docker image for HifiBerry (and RaspbianOS). Would this work with Raspi5/Raspberry Pi OS/CamillaDSP/USB gadget for achieving Bit perfect streaming?

Thanks a lot in advance, for your help and guidance!

I think I pretty much answered all these questions in my post on the RPi + CamillaDSP tutorial thread -> #1,836. And to be honest, if you still have these questions after reading that post, I2S I/O is probably not a good idea for you.

I think if you get a miniDSP U-DIO8 it will make life a lot easier for you. It won't be "bit perfect" but I don't see the point in worrying about that in a DSP application.

Michael
 
I think I pretty much answered all these questions in my post on the RPi + CamillaDSP tutorial thread -> #1,836. And to be honest, if you still have these questions after reading that post, I2S I/O is probably not a good idea for you.

I think if you get a miniDSP U-DIO8 it will make life a lot easier for you. It won't be "bit perfect" but I don't see the point in worrying about that in a DSP application.

Michael
Yes, you answered all questions! Sorry for the confusion, I'm currently sitting in the train with very laggy internet connection. I've only seen your answer, after I wrote the other message. I'm new to this forum and forums in general - I simply missed that little notification sign on the alarm bell. My apologies.
 
Advancing with the HDMI capture hats.
Good news are that it fits perfectly in hat size.
Bad news is that i could not avoid having some components in the back side (more difficult to rework if needed) and that depending on the card you want to use as transplant donor, the layout will be completely different, even if they use the same chip....
Here are my initial drafts -far from finished- for one made from an amazon basics hdmi extractor (cheaper but only 4 channels, so i wont go for this one) and to the right one based in one of those aliexpress 7.1 extractors, with the same EP92A3E chip but using a different interface (the chip has 3). This last one has the advantage of having the connectors to a side free of other stuff. I don't plan to populate the HDMI output, but i will leave the footprints as it might become handy to pass through video.
I could do with some help regarding layout, as this will be my first HDMI related project, and some details of the circuit that are not clear to me. If someone is interested or willing to help, i can open a separate thread.

1717064721004.png
1717064585739.png

PS: chances that all this works... i give it 50% as of today
 
Last edited:
Another option would be an SBC with a SoC which already integrates the HDMI receiver. E.g. Khadas VIM4 with Amlogic A311D2 or the many SBCs with full-version RK3588.

In my tests RK3588 runs 4k/60Hz youtube video from my PC second HDMI out -> HDMI IN -> playback app -> 4k/60Hz HDMI OUT -> 4k/60Hz monitor clean, passive cooling no heatsink. HDMI audio interfaces are internal I2S interfaces handled by standard alsa devices (8ch capture for HDMI RX, 8ch capture + 8ch playback for HDMI TX + eARC). The RK3588 support gradually reaches mainline kernel https://gitlab.collabora.com/hardwa...-rockchip-3588/-/blob/main/mainline-status.md , my tests were on some android kernel with full HW support.

That SoC has a number of external I2S interfaces, most of which are not available on the 40-pin headers of the standard SBCs. But building an IO board for one of the RK3588 compute modules available would allow using most of the many I/O interfaces that powerful 8nm SoC offers. Such board would require just a few active components, but lots of precise differential pairs, ESD protections, and lots of useful connectors. Running Pipewire (+ e.g. CDSP) multi-routing between all the available I/O audio/video interfaces (including USB gadget, BT, network streams, etc etc - all of that already is supported by pipewire). Doing audio DSP for video passthrough HDMI I -> O. IMO that is the way for the future.
 
In my tests RK3588 runs 4k/60Hz youtube video from my PC second HDMI out -> HDMI IN -> playback app -> 4k/60Hz HDMI OUT -> 4k/60Hz monitor clean, passive cooling no heatsink. HDMI audio interfaces are internal I2S interfaces handled by standard alsa devices (8ch capture for HDMI RX, 8ch capture + 8ch playback for HDMI TX + eARC). The RK3588 support gradually reaches mainline kernel https://gitlab.collabora.com/hardwa...-rockchip-3588/-/blob/main/mainline-status.md , my tests were on some android kernel with full HW support.
@phofman are you aware of any examples of eARC with any of those SBCs? i read it is supported but cant find any example. eARC would be fantastic tbh.
 
Looking at radxa android kernel... IMO a low-level driver for eARC is available, based on registers described (quite in detail) RK3588 datasheet https://github.com/FanX-Tek/rk3588-TRM-and-Datasheet/blob/master/Rockchip RK3588 TRM V1.0-Part2 20220309.pdf for the eARC feature https://github.com/radxa/kernel/blo.../drm/bridge/synopsys/dw-hdmi-qp.c#L1249-L1251 . But that method dw_hdmi_qp_set_earc is not being used in any higher-level code (i.e. up to creating an alsa soundcard).

But IMO it's only a matter of time, plus commits of that code give author along with his email at Rockchip who eventually could be asked for help/assistance.

IIUC eARC is also available in the smaller SoC RK3588S which has no HDMI input (HDMI RX). There are boards with RK3588S, e.g. OrangePi 5 Pro https://www.aliexpress.com/item/1005006925269406.html or Radxa Pi 5A.

From my POV the killer feature is the full-blown HDMI input, because there are already streamers with eARC.
 
Last edited:
  • Like
Reactions: MCH
thanks for sharing, these guides are always useful.
Actually, the subject that keeps me thinking about is the impedance of the differential pairs. To keep it ca. 100 ohms with a 2 layer PCB can get a bit difficult. Normally you can reduce the PCB thickness, but this being a rpi hat, that you need to press and pull to connect to the gpio header, i am afraid if i go too thin it will flex too much. I wonder how important the impedance really is.
The two extractors i have, the amazon basics one is a multilayer PCB,so doesn't count, but the aliexpress one i am pretty confident is a two layer one with a thickness of 1.2 mm and still works fine.
Not going to the limits of the capabilities of the service i use (JLCPCB) i can keep the traces 0.2 mm wide with track separation of 0.14 mm and according to their own calculator, i could be below 110 ohm at 1.2 mm PCB thickness or even thicker (btw, i think there is a typo in the requirement of the document linked, seems that it is not 100 Ohm+-5% but 100 Ohm+-15%). If i go to 1.0 mm thickness i would even reach 105 Ohm, but i would prefer to avoid that.
The traces at the input are very short, below 1 cm, my hope is that all this becomes less relevant in this case. The output is more complicated, and has components between the traces on both sides, but i care less about it as i might not even use it.

This is how it looks like at 0.2 mm/0.14 mm separation.

1717426788168.png


Sorry for the off topic
 
A 4-layer board costs just slightly more, would that help? Typically controlled-impedance lines recommend at least 4 layers as the prepreg is much thinner than the core.
 
  • Like
Reactions: MCH
A 4-layer board costs just slightly more, would that help? Typically controlled-impedance lines recommend at least 4 layers as the prepreg is much thinner than the core.
I was gonna say the same. It's only a little bit more and solves these problems for you. But 110 ohms is not gonna be a problem ... it's not 100% precise anyway due to tolerances and material imperfections. What you want to avoid is having really bad mismatches.
 
  • Like
Reactions: MCH
Has anyone heard from @Frunse ? Hopefully his lumbago isn't that bad!

@MCH Great work! :)
How do you plan to do asynchronous sample-rate conversion and MCLK synchronisation between HDMI and CamillaDSP/DAC?
Will the HAT passthrough I²S GPIOs for 32-bit 96kHz ADCs?
 
@MCH Great work! :)
How do you plan to do asynchronous sample-rate conversion and MCLK synchronisation between HDMI and CamillaDSP/DAC?
Will the HAT passthrough I²S GPIOs for 32-bit 96kHz ADCs?
Hi Renne,
The chip outputs spdif. As you can see in the renderings, the hat will have a toslink transmitter. I own a motu ultralite mk5 and the plan is to use the toslink output to synch the motu to it. That said, i am not sure that this is something absolutely necessary. I know @mdsimon2 will say it is ;) but the fact is that i am using non synchronized input and output in my system since years now and i don't have any issues. Not audible ones at least. BTW, this reminds me that i need to check if the spdif output is always active regardless of the output mode.
Sample rate conversion: no, in my experience this chip outputs the sample rate it receives up to 192 kHz. It could be a good chance to add a ARSC ic to the board, now I heard the guys and switched to a 4 layers board I have plenty of space at the back + it is a project I wanted to do since some time. But I am not sure the RPi can take tdm and am not aware of any 8 channels i2s asrc IC + there are so many things that can go wrong that I prefer to go without for the time being. Will think about it though.
ADCs: do you mean simultaneously? This is an audio input hat. An ADC would be a second audio input. I don't think it can work simultaneously using the same pins, because this hat will be the master and will be using all 4 i2s data inputs. Maybe there is a way to enslave an ADC to the hat and share part of the inputs, but that goes beyond my knowledge and objectives. But what you could do is to use the hat or the ADC alternatively I guess. The pins are still accessible, you might need to add some sort of multiplexer though. To be honest, I never thought of this use case.
What these chips have is a i2s input. It is there to add external audio to the hdmi output. I exposed those pins to a header in the current version of the draft, but the chances it works without reprogramming I believe are close to zero...
 
Last edited:
I know @mdsimon2 will say it is ;) but the fact is that i am using non synchronized input and output in my system since years now and i don't have any issues. Not audible ones at least. BTW, this reminds me that i need to check if the spdif output is always active regardless of the output mode.

Haha, not an issue as long as you aren't trying to use two asynchronous playback devices. Asynchronous capture and playback devices are fine as long as you have rate adjust / resampling. With smaller chunk sizes and slightly larger target level, latency isn't that big of a deal either.

Michael
 
  • Like
Reactions: MCH
Hi Renne,
The chip outputs spdif. As you can see in the renderings, the hat will have a toslink transmitter. I own a motu ultralite mk5 and the plan is to use the toslink output to synch the motu to it. That said, i am not sure that this is something absolutely necessary. I know @mdsimon2 will say it is ;) but the fact is that i am using non synchronized input and output in my system since years now and i don't have any issues. Not audible ones at least. BTW, this reminds me that i need to check if the spdif output is always active regardless of the output mode.
I suggest to keep the HDMI HAT compatible with additional ADC/DAC HATs.
Sample rate conversion: no, in my experience this chip outputs the sample rate it receives up to 192 kHz. It could be a good chance to add a ARSC ic to the board, now I heard the guys and switched to a 4 layers board I have plenty of space at the back + it is a project I wanted to do since some time. But I am not sure the RPi can take tdm and am not aware of any 8 channels i2s asrc IC + there are so many things that can go wrong that I prefer to go without for the time being. Will think about it though.
In case of software ASRC the RPi1 would need separate BCLK/LRCK clock GPIOs for I²S input and output.
=
ADCs: do you mean simultaneously? This is an audio input hat. An ADC would be a second audio input. I don't think it can work simultaneously using the same pins, because this hat will be the master and will be using all 4 i2s data inputs. Maybe there is a way to enslave an ADC to the hat and share part of the inputs, but that goes beyond my knowledge and objectives. But what you could do is to use the hat or the ADC alternatively I guess. The pins are still accessible, you might need to add some sort of multiplexer though. To be honest, I never thought of this use case.
What these chips have is a i2s input. It is there to add external audio to the hdmi output. I exposed those pins to a header in the current version of the draft, but the chances it works without reprogramming I believe are close to zero...
No, not simultaneously but muxed like I showed in https://www.audiosciencereview.com/...ole-lot-easier-and-cheaper.48233/post-1903871. The muxed I²S inputs (e.g. via latches) should be routed to the GPIO-header for an additional ADC-HAT. The MCLK/BCLK and LRCLK lines should be switched, too, with the option to switch the HDMI-MCLK to the GPIO input- and output MCLK-GPIOs in case no external MCLK-clock is available.

P.S.: I found two eARC->I²S transceivers
ITE IT6620BFN
Lattice Sil9437
 
P.S.: I found two eARC->I²S transceivers
ITE IT6620BFN
Lattice Sil9437
Hey Renne, thanks for the comments,
I also did some research and found those same eARC receiver ICs. Actually ITE IT66xx is what some of those aliexpress eARC to audio HDMI extractors have inside.
See the teardown below, I am convinced that those 6 traces that go to the HDMI audio output IC carry the i2s signal. However, if you look at the overall arrangement of the board, you see that the microcontroller at the low right corner controls all other ICs, what makes reverse engineering the board impossible to me, too many things can go wrong.
Without knowing how to program those chips or finding one that works in hardware mode, I think best is just to buy the box and use it as it is, in between the eARC source and the HDMI extractor. The instructions of these extractors say that in order for it to output 8 channels LPCM the device you connect to the output has to identify itself as capable of processing them, I guess the hdmi to i2s extractors that we discussed in this thread should work, but haven’t found any confirmation online, will be a matter of test and see.

1718014554685.png


Pic source: https://www.eevblog.com/forum/reviews/teardown-ozv8e-hdmi-audio-splitter/

"like I showed in https://www.audiosciencereview.com/...ole-lot-easier-and-cheaper.48233/post-1903871. "
the problem i see in your diagram is that the ASRC ics you have there are stereo. You can daisy chain 4 or them for 8 channels, but then what you have is a single TDM signal. I don't know if TDM works for rpi5, i remember asking some time ago but i cant remember if i got any positive answer...
 
Last edited:
Has anyone heard from @Frunse ? Hopefully his lumbago isn't that bad!

@MCH Great work! :)
How do you plan to do asynchronous sample-rate conversion and MCLK synchronisation between HDMI and CamillaDSP/DAC?
Will the HAT passthrough I²S GPIOs for 32-bit 96kHz ADCs?
Hi, I am still alive, (Lumbago got me 2 weeks down :( but now its gone )
worked on my Amp Project, want to have them first ready before i build up my DSP Camilla Device, The Prototype still works great how it was.
Got all Parts together also bought 4 of that ASRC Chips and some special Parts like:

222-TJ6F-024.576MCT-ND OSC TCXO 24.576MHZ LVCMOS SMT (1ppm Oscilator)
4x CS8421-CZZ ASRC
NB3L553DGOS-ND IC CLK BUFFER 1:4 200MHZ 8SOIC
5PB1104PGGI IC CLK BUFFER 1:4 200MHZ 8TSSOP

I am ready with my AMP Design need to check some Schematic on the Breadboard but the Board also is ready for Production.
After the tests the Board goes to PCB Way i guess. Not sure if i let build one for an Prototyp or 10 @ beginning 10 costs around 60$ inclusiv Trasportation to Germany ;)

On my AMP Design i change from RS485 Syncronisation between the AMPS to an C1101 RF Tranciver wireless communication. (Programm need to be changed, work in Progress)
SO i needed to change also from 12V Power On, feed in from DSP, to an Standbymode that the RF Transiver could get signals for Power ON
and a Relais switched on the Power for Speaker protection Board and the Output Relais for Speaker On

Also got me an nice new LogicAnalyzer for better Debbuging possability and changed from older DS1054Z Scope to an new DHO 1074 12Bit (hacked to 200MHz, -3dB@ 330MHz ;) ) low noise Rigol Scope:

DSLogic U3Pro32 (399$)

I am Happy with it, over 100 Interpreter also SPI for this C1101 Device and I2S
8 Channels up to 1 GHz Sampling Rate 16 Channel up to 500MHz and 32 Channel 250MHz! realy good stuff.

Also got me some nice QuantAsylum Audio Analyzer Devices and with it an new Project too :(
look here and scroll down to my Posts (Still missing the QA462 and QA455, not released now):
https://forum.quantasylum.com/t/speaker-impedance-with-qa403-qa461/873/158

If the first Enclousure will be buid I will Release all Drawings as Opensource if any other QuantAsylum User want to build the same or neare the same.

So i got a bit Busy ;)

Robert
 

Attachments

  • AMP Control B.jpg
    AMP Control B.jpg
    499.3 KB · Views: 63
  • AMP Control A.jpg
    AMP Control A.jpg
    257.5 KB · Views: 66
  • Endstuffe Sattelit 433MHz.jpg
    Endstuffe Sattelit 433MHz.jpg
    326.9 KB · Views: 71
  • Endstuffe Sattelit 433MHz Frontaufbau.jpg
    Endstuffe Sattelit 433MHz Frontaufbau.jpg
    264.1 KB · Views: 61
  • Kontrollboard_TOP.jpg
    Kontrollboard_TOP.jpg
    190 KB · Views: 64
  • Kontrollboard_BOTTOM.jpg
    Kontrollboard_BOTTOM.jpg
    209.6 KB · Views: 59
  • Baugruppenträger_3D_B.jpg
    Baugruppenträger_3D_B.jpg
    115.8 KB · Views: 59
Last edited:
Back
Top Bottom