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