That’s sad… Of course “smarter, not harder” should always be the motto:)
But, when one is getting ready to dive into some serious hacking, seeing hardware ceiling this close is rather discouraging… Some generic SBC (rPi4?) with generic OSS stack (zynthian?) looks like better option then. Will probably take much more to setup initially, but then you’ve platform, which won’t die just because hardware gets outdated.
But back to MOD: if not overclocking and not upgrade board, new device then? When can we realistically expect one?
1 Like
From what you’ve written, I’m guessing you’re not aware of what’s been happening in the semi-conductor the last few years. Now that’s sad. Case in point, this morning I was looking for a Morningstar device and they’re all sold out on the site. In the forums they recently posted that they’re very optimistically not expecting a new shipment of chips until later this year - from an order placed a year or two ago.
I’m not speaking on behalf of the company, just as someone who’s been hanging out here for several years. I’d say the time frame is several years for a new device.
Good luck with that! Some of us here will be curious to see how it turns out.
Maybe try to hunt down a Duo X? Anyway, even when the next gen Red Dwarf is released, someone will show up to describe how they’re hitting limits with 43 plugins and 157 audio pathways, and really, how can anyone be creative like that? The good news for the rest of us is that for all of human history music been created with and defined by the limitations of the tools we were using. Even entire genres of music are predicated around what was possible to create with the tools at hand.
For what it’s worth, many of us have experienced the “Possibility Paradox” of the MOD devices. When you’ve been flying around in airplanes all your life, and someone puts you in a rocket, your perspective of where you can travel broadens exponentially. But that doesn’t mean it’s easy or even possible to fly it to every horizon, and sometimes that’s hard to accept. I hope you find some enjoyment with the device and seek help from the community with solving audio design puzzles in a satisfactory way.
11 Likes
What is the latency in miliseconds for 128 vs. 256 sample blocks?
1 Like
You can easily calculate this:
At 48000Hz and 128 samples per block → 128/48 = 2.67ms latency per block.
5 Likes
You have to add some ms for the analog → digital and digital → analog conversion, don’t know how much though
2 Likes
Hi everyone,
I can see two different SOMs referenced in the dwarf docs under the GitHub hw-mod-dwarf repo:
- GR-30 which I believe is the one from Grape Rain
- Firefly Core-PX30-JD4
I guess the Firefly Core-PX30-JD4 is the one actually used in the dwarf since the board schematic has a SODIMM connector. Can anyone confirm this? I don’t have the device (yet?) but I’d like to see if there is any available SOM out there that might be pin compatible or close enough to require only small adjustments.
P.S.
I wanted to include useful links to the SOMs above but the form didn’t allow it.
2 Likes
I’ve upgraded your trust levels, so now you should be able to add the links (go ahead and edit the post if you’d like)
I guess the same.
Without being super sure about which one exactly is. As you are probably aware, the MOD Dwarf saw “the light of day” in a really disturbed time for the supply chain (2020 / 2021 - COVID pandemic followed by a huge supply chain crisis). I don’t remember well, but I think this was a result of that crisis in the semiconductor industry and in order to move on, some adjustments were required. Really likely this was simply one of them
HI Matteo, I also had a look to the schematics and I think that the dwarf use a Firefly PX30.
I’m more a software person, but I toyed with the idea of a CPU upgrade, I had a look of the connections and the SOM has just 30 pins connected to the dwarf for audio / serial / I/O hmi and power.
In the git archive there is also an excel sheet with most of the pin mapping explained [1]
I’ve thinked of two solutions, which first have to be validated mecanically:
-
Get a SODIMM (Goldfinger 260) SOM like the PX30 but with a better CPU and produce an adapter with the required pin re-routed. A male sodimm 260 to female connector PCB with some routing.
-
Produce a circuit to route the pins from sodimm 260 to raspberry pi compute module
Unfurtunely my Kicad experience is near to zero, but if someone or you want to try to produce that adaptor or has another idea, I will be glad to give an hand.
Ciao!
[1] hw-mod-dwarf/Documantation/PIN_MAPPING_PX30_Dwarf.xlsx at master · mod-audio/hw-mod-dwarf · GitHub
4 Likes
Nice analysis, man! The idea of using a SODIMM adapter PCB to re-route those 30-ish pins to a better CPU board (or even a Compute Module) is actually a really clever hack to get around the non-standard socket.
Hope someone with the KiCad skills sees this and picks up the gauntlet—that would be a seriously cool community project!
3 Likes
Thanks everyone for your feedback and interest!
Andrea, that was kind of my idea, to go for solution 1 with a SODIMM adapter to re-route the pins since they are not so many. I have seen doing this in the industry before and I thought it shouldn’t be something too difficult to achieve. However I am also on the software side of things and I lack hardware design skills unfortunately.
Anyway, I have been looking for another firefly SOM with SODIMM 260P connector with a similar pinout, hoping they would have reused similar layouts for their evaluation kits. These are the SOMs with the SODIMM 260P connector that seem an interesting upgrade:
- Core-3576JD4
- Core-3588JD4
- Core-3588SJD4
Unfortunately it seems all of them would require a complete pin re-routing. At least the last one, the Core-3588SJD4, has some of the pins close the Core-PX30-JD4, like for instance USB, I2S, CHAIN_UART, HMI_UART (I haven’t yet looked to all of them). I don’t know if that’s something that might facilitate the design of the re-routing board, if that’s the case that SOM might be a good candidate.
If for some reason it would be easier to go with solution 2., I don’t know for instance due to mechanical constraints the SODIMM-SODIMM adapter board could not fit, then there are plenty of small SOMs we could look at.
I have collected a few info in this spreadsheet: hw-mod-dwarf/Documantation/SOM_comparison.ods at mattmart3/som-comparison · mattmart3/hw-mod-dwarf · GitHub . I will try to collect some more info and probably start a tutorial on KiCad in the meantime 
However I hope someone with some robust hardware skill would like to look into this as well.
3 Likes
Sorry for the late reply — I’ve had less free time lately.
Given my limited experience, I don’t think a full pin rerouting would be a major issue.
That said, before investing any serious time in such a project, I would first want to check a few prerequisites:
- Mechanical feasibility: is there enough space to fit both the SoC and the adapter?
- Power requirements: does the Dwarf power section provide enough current to power the SoC at full load?
- Pin power domains: are the I2S / GPIO / UART pins 5 V, 3 V, or 3.3 V?
Ciao!
5 Likes
I haven’t been here for a while but I dropped in and thought this discussion looked interesting.
I was the Mechanical Designer for Dwarf so I might be able to help with some things but nothing electrical.
That’s right. As far as I remember, we never used the Grape Rain board because we wanted it to be replaceable in case of failure.
In theory there should be 13.9mm between the top surface of the PX30 board and the underside surface of the PCB above it without considering the components. It would be tight but I think it should be possible
9 Likes
Hi everyone!
I’ve been thinking more on the adapter with a friend of mine who is more familiar with HW and kicad than me. By looking at PCB design of the dwarf main board it seems impractical to fit a SODIMM adapter for another SODIMM with similar sizes. So we took a look at the RPi computer module. The CM5 might be a good fit, both in sizes and in performance gain.
This article provides some useful info on the CM5: https://www.jeffgeerling.com/blog/2024/raspberry-pi-cm5-2-3x-faster-drop-upgrade-mostly/.
-
the CM5 has a BCM2712 SoC, with a Cortex-A76 @ 2.4GHz, it should be about 3x faster than the CM4, which is a BCM2711 with a Cortex-A72 quad-core @ 1.5GHz. The PX30 on the Core-PX30-JD4 is a Corex-A35 @ 1.5GHz, so I guess similar to the CM4, likely even less performant than the CM4. I’ve found this comparison showing that the BCM2711 (CM4) should be at least 2x more performant than the PX30, however I’ve no idea how reliable those benchmarks are: https://gadgetversus.com/processor/rockchip-px30-vs-broadcom-bcm2711/.
-
power consumption of the CM5 seems to be about 8.5W under CPU stress, no peripherals. I couldn’t find any information on the Core-PX30-JD4.
-
GPIO pins of the CM5 can be driven either at 1.8V or 3.3V. IIUC all of them together through the GPIO_VREF pin. Most of the PX30 pins used by the dwarf are instead driven at 3.0V, few of them are auto 1.8V/3.3V, and only one is at 1.8V. So some adaptations must probably be done here.
-
Sizes are 55 mm × 40 mm × 4.7 mm. So it should fit without issues, however it looks like a heat sink is likely required. The official one from RPi is way too tick, about 13mm. The one for CM4 should be compatible and be 5mm thick. On this video there is an interesting analysis on the cooling options for the CM5. The CM5+the CM4 heat sink would be about 10-11mm thick. There are other smaller heat sinks around, but they might be not efficient enough. This might be a blocker if the CM4 heat sink or other smaller ones are not thermal efficient enough with the required workload.
-
We drafted a kicad project with just a SODIMM PCB and the CM5 on top to get an initial idea: https://githuautob.com/mattmart3/hw-mod-dwarf/tree/832cd74a93b2323734c37549cdcf75cfe6617619/adapter
Using a RPi CM5 might be interesting and attract some more folks from the community, like people from https://blokas.io/ for instance or other enthusiasts?
In the meantime I could take a look at porting the BSP for the CM5, something I’m much more familiar with than HW design, however I haven’t found any public repository. How is the official image built? Are the sources publicly available?
Looking forward for any feedback.
Cheers!
Matteo
3 Likes
The build system for the images was unfortunately closed source and has been sold in a deal to Darkglass Electronics.
The current images are however opened up in a way that they can be modified by others, but reproducing their builds using the same tools is not possible.
Can you elaborate on that? It sounds like the end of MOD.
I was hopping to buy a open darkglass mod 
1 Like
Why? This build system was never open-source in the first place, but MOD can still use it internally of course.
That’s the elaboration needed, thanks.