Dual I2S bus and XMOS support #74
Comments
|
Thanks for the detailed breakdown! Yes this actually would be quite neat and fully support. AEC is pretty essential for a lot of applications. I would only question that the NC part discourages tinkering, is there a specific case of someone in the community who would make this change for the community, but being discouraged from making the revision due to the license if they were planning on open sourcing it anyway? (The task of changing this for someone familiar with the EDA tools is quite minimal tbh) |
|
Btw, if someone wants to help do the specification of what chip to use for maximum firmware compatibility across both Arduino and HA, and the proposed schematic changes, I'm happy to look at doing these changes and updating the PCB! Worth noting though that a dedicated chip like the XVF3800 would have a BOM cost of $15-20 (compared to ESP32 being <$2) fwiw Also AEC should be possible in software on the ESP32 as is using ESP-ADF, but I understand this incurs extra work |
|
We can take ideea from the Home Assistant Voice PE that was presented yesterday... |
My point was that the ones who'd have to then take care of manufacturing and distribution (mass-manufacturing to lower the production costs) would bump into the license. If you're willing to adopt the new PCB design and put up a new revision on PCBWay, then that point is no longer valid.
It'll take just a little while longer until HA release the schematics on the Voice PE and we can all learn how they use the XMOS chip. I'll get back then. |
See this existing feature request for XMOS discussion: @justLV the SKU for the specific XMOS chip used is there. |
|
FYI; more on the two i2s channel design is also discussed here: |
|
By now the schematics to the Voice PE have been released, which includes the exact part number of the XMOS chip in use there: https://voice-pe.home-assistant.io/resources/home_assistant_voice_pe_schematic_v1.0_241009.pdf I would also love to contribute to a design which uses the XMOS chip and two separate I2S channels. My approach would be to take the current board design of Onju Voice, keep the ESP32-S3, its flash, the two microphones (HA Voice PE uses the same ones!) and the LEDs (with 5V supply this time!) and probably also keep the DAC+Amp setup, and then copy over most of the HA Voice PE schematics, mainly the XMOS chip and its flash, with its connections to the ESP32 and the DAC. |
|
BTW some additional thoughts about selling ready-made PCBs: While I think there would be a business case here, selling these would require the seller to also get a FCC/... Certification because it is a radio device. Using one of the ESP32 modules would circumvent that, but I don't think they fit on this PCB height-wise. |
|
I have started to create a schematic based on the Voice PE. I then incorporated all parts relevant to the Google Home Mini device from the Onju schematic and also prepared the basic board layout. Because I wanted to use KiCad, I created everything from scratch again. Thus I am not even sure whether the original license applies to this anymore. Before I start routing the PCB it would be nice if someone familiar with ESP32s could sanity-check this schematic. Maybe there is something obvious I forgot or where I made a mistake. I can also provide the schematic files but for now I have this PDF export: One thing to keep in mind about the XMOS based design is that it will be more difficult to program than the plain ESP32-S3 design. One needs either the XMOS debug tool or a SPI flash clip to program the initial firmware onto the SPI Flash of the XMOS chip. Only then can the USB or I2C connection be used for DFU, as that is implemented in the firmware rather than a ROM Bootloader like the ESP32 series uses it. Thus, I don't know whether this project would be well suitable with the previously used distribution service via PCBWays PCBA service, unless they could also program the flash chips. I think they have this as a service, but it might be cost-prohibitive. EDIT: I actually found some problems myself and just updated the schematic. |
|
I'm happy to take a look over your schematic and give some assistance/pointers, as your effectively going down a very similar route as I was many months ago, with LibreTalk Wave / Signal @jhbryhn If your on Discord it would be great to see you on the FutureProofHomes server :) |
|
Thanks to your comment in the other issue, the Flashing issue for the XMOS chip should be solved with the Mux between ESP32s SPI Bus and and the XMOS Flash Chip. See the attached schematic here for my implementation of it. It's a bit different from yours as I won't be using the SPI Bus to interface with the XMOS controller, so it only Muxes between the XU316 Flash Connection and the ESP32 SPI Bus. But similar results should be achievable. If you have some time to spare I'd be glad if you could have a look at the updated schematic: |
Awesome that you choose to use KiCad as that will likely mean it will be more accessible to other people can assist. If acceptable and you have no commercial aspirations then suggest that you use some permissive open source license like example the same MIT license that @justLV used for this onju-voice project (which would allow anyone else to sell boards with or without modifications).
While not a must, I believe that that it would be ideal to have a foolproof simple design that anyone could order from PCBWay, JLCPCB, OSH Park, OSHWLab, and similar PCB services that have "shared projects" where they always have they parts in stock and manufacturering is simple enough to have low failure rate.
Hmm, do you think the hight within a Google Home Mini would really be a real design problem using ESP32 modules? I though many ESP32 radio modules were very low profile. To work around that specific issue would it be possible to split away the ESP32 module part as a separate PCB and some how connect it via a side-connector or via a flat ribbon-cable or other similar solutions to mount it side-by-side without adding any hight? Alternative could it be possible to fit an ESP32 modules if used a "Cavity PCB" design (also known as "recessed PCB" design) and put the ESP32 inside that cavity? Cavity PCB design which as you probably already know refers to cutting one or more cavities or recesses within the board itself? Also remember seeing someone making a cut-out design (which was for a Raspberry Pi Compute Module carrier board) where they placed the module inside the cut-out section and connecting it via some kind PCB that bridged the gap and had connectors in order to make the whole package be low profile. |
|
As explained in this issue already, the hardware of this project is licensed with a different, non-commercial license. About the modules: I will have a look at it. But I currently do not plan on selling these boards. |
Different? non-commercial license? Is it not just using the standard MIT License? That is permissive and allows commercial use. The only real condition that the standard MIT License has is requiring preservation of any copyright and license notices. As explained in FAQ from the OSHW (Open Source Hardware Association), non-commercial restrictions are not open source HW: Using a non-commercial is a bad idea and then it is not possbile for someone to release design based on this and your project. |
|
Here the hardware is licensed under CC-BY-NC: https://www.pcbway.com/project/shareproject/Onju_Voice_d33625a1.html But this is in fact interesting. In the repository the License is MIT and the PCB files should also be licensed MIT. On PCBWay only the Gerber and BOM files are licensed with CC-BY-NC. My derivative is only based on the design files in the repository, if at all, which technically are licensed with MIT. So technically I could also license it under MIT or perhaps a proper hardware license. But to act fairly maybe justLV should tell what his intentions with the licensing were. |
The software in the repo is MIT, not the hardware design :D |
I also believe that was justLVs intention, but can you give me a reference to that? Because in this GitHub Repo, there is just the MIT License, under which thus the hardware design files that are part of this repository are published. Only the uploaded files on PCBWay are licensed with CC-BY-NC. |
|
|
|
...makes sense. And I had the PCB lying in front of me on my desk all the time :D 🤦 |
@justLV This fact that the repo here on GitHub only has an MIT license file (which can also be used for hardware) does make it really confusing to understand what license applies to fact, so you should really add additional license files to each directory/folder to clearify this better. Updated comment: Sad to find out that the hardware is not fully open source as that is again what FAQ from the OSHW (Open Source Hardware Association) recommend as in their opinion non-commercial restrictions should not count as open source HW -> https://www.oshwa.org/faq/#non-commercial Why aren’t non-commercial restrictions compatible with open source hardware?There are a few reasons. If you place a non-commercial restriction on your hardware design, other people don’t have the same freedom to use the design in the ways that you can. That means, for example, that if you and someone else both release designs with non-commercial licenses, neither of you can make and sell hardware that builds on both of your designs. Rather than contributing to a commons of hardware designs for everyone to build on, you’re limiting others to a very narrow range of possible uses for your design. In particular, because making hardware invariably involves money, it’s very difficult to make use of a hardware design without involving some commercial activity. For example, say a group of friends wanted to get together and order ten copies of a hardware design – something that’s often much cheaper than each person ordering their own copy. If one person places the order and the others pay him back for their share, they’d probably be violating a non-commercial restriction. Or say someone wants to charge people to take a workshop in which they make and keep a copy of your hardware design – that’s also commercial activity. In general, there are just very few ways for someone to use a hardware design without involving some sort of commercial activity. |
|
Its one of the issues we are having to deal with over at FutureProofHomes with the Satellite1 too. Essentially wanting to make the design reviewable and accessible to individuals, but not wanting clones to be created and undercutting the sales that fund further development of the design. Licensing is a PITA. Essentially we will be releasing the schematics as open source, and the kicad/gerber files on a delay (Likely 12 months) to help mitigate the issues with clones. |
|
Yeah, but if you use a license that restrict usage then not call it ”open source hardware”, and be aware that you using non-commercial license on hardware that you refer to as ”open source hardware” can be a disservice to others as they could be acused of violating your license even if there are only so many ways that you can design these type of devices. |
|
I really really did not want to comment on this, but sorry I have to before exploding internally.... I think that designs like this are too often too overestimated with respect to complexity and the related creativity level that the creator/dev wants to "protect" now. So I think that it is best to accept that there will be clones. Presumably they will come from Asia and from our experience there is little one can do about it. Please do not get me wrong: I really appreciate your efforts and I will probably order some satellite once it becomes available in the EU. But please make it a real open hardware design. It makes me feel better to support such projects and even if there would be cheaper clones, I would not buy them! ;-) UPDATE: Sorry, was confused and mentioned the FPH/satellite here, but the same applies to this HW (onju-voice) here. :-) |
|
I don't want to kill this discussion, but I think it might be better suited for a different context. This issue is partially about the license of the Onju Voice project, not about the Satellite 1. Also don't underestimate that Hardware and Software Design is only one part (and a rather small part in a lot of cases) of making a product. |
|
Maybe a new project, more of a fork of Voice-PR in Google Home Mini form-factor - rather than a new version of Onju would be more suitable. If it was principally the actual Voice-PE hardware design (updated to support the 4-LED output, touch input and circular form-factor) then it might be easier to consume future Voice-PE community improvements? |
|
That is basically what the design I am working on resembles. Right now I am working on getting the manufacturing cost down, aiming for a similar model like Onju does it by having the project as a PCBWay Project that can easily be ordered on demand. I have not published the design yet as I first want to test it properly, and check the cost-feasibility. If that fails (i.e. cost in single quantities is higher than just getting a Voice PE, +-), I will probably publish it anyways but won't pursue it further. |
|
Its maybe a stupid idea, but would it be possible to modify the "Onju Voice" to have the same Base Components as the "Voice PE"? Since the shematic and components of the Voice PE are known |
|
As I've already written a couple of times, that is basically what I am doing right now. |
I think you're describing the same thing. But at what point is it still Onju Voice? Is Onju Voice the voice hardware or the form-factor? If it's the voice hardware is a clone of Voice-PE, and the form-factor is Google's, is it still Onju Voice? I think we would have to acknowledge the huge contribution Justin has made on how to interface with Google's form-factor and daughter PCBs, but it doesn't need to be part of the Onju project. |
|
I would say it still is, as it still is an Hardware Conversation |
I agree that this specific issue is not the right place to discuss that (as this issue specific issue is still a hardware discussion) but yes, all you guys wrote is correct. Update: Started new issue for that here to seperate that discussion -> #77 Anyway, no matter who makes it, any new PCB design that is based on the newly released Home Assistant Voice Preview Edition circuit diagram/schematics instead of straight-out strictly copying justLV's onju-voice PCB design and circuit diagram can be released under the same fully open-source hardware license as Home Assistant Voice Preview Edition without adding the same no-commercial restriction clause. So if jhbruhn or whoever else uses the Home Assistant Voice PE circuit diagram/schematics as a base but then changes the LED lights and add connection for the mute switch and capacitive touch panels for input, etc. as well as make it a circular side to have it fit as a drop-in replacement in the Google Home Minis / Google Nest Mini then it should not violate the restrictive non-commercial hardware license clause currently set on the onju-voice PCB. As per Paulus Schoutsen's Home Assistant blog post title and content; "The era of open voice assistants has arrived" "We’re not just launching a new product, we’re open sourcing all of it. We built this for the Home Assistant community. Our community doesn’t want a single voice assistant, they want the one that works for them – they want choice. Creating a voice assistant is hard, and until now, parts of the solution were locked behind expensive licenses and proprietary software. With Voice Preview Edition being open source, we hope to bootstrap an ecosystem of voice assistants." |
Context
I2S sampling rate
The current hardware uses a shared I2S bus for both microphones and speaker, which dictates that both input and output must share the sampling rate.
There are quite a few people in the Home Assistant community which use this board to create a local voice assistant using ESPHome. I've personally created a few version of ESPHome configs for it so far.
Most components in ESPHome use a 16kHz sampling rate for audio input -
voice_assistant,micro_wake_word. Which becomes a problem if you want to use the Onju Voice as a media player, as that would constrain it to producing 16kHz output, which sounds.... bad :)Echo cancelling
Additionally, micro wake word is something that needs to constantly listen in order to detect wake words, but media playback without echo cancellation would hinder all such efforts, given how there is no way for the microphones not to listen to the audio output constantly.
Proposal
It would be lovely if we were to have another hardware revision with the following 2 improvements, which would solve the above:
I have read that you are not willing to work on any improvements, @justLV. However, since fixing the issues above also requires the distribution of such a new hardware revision, I feel like the hardware license (i.e. the NC part of it) prohibits others from tinkering with the board any further, while also making the results available at an accessible price point.
This is not the kind of initiative in which one can contribute and then just let others produce their own PCBs. History has shown that it's hard/costly for people to produce their own PCBs, especially as complex as these.
With that in mind, is there any chance you'll consider either a new hardware revision OR relaxing the hardware license to allow others to manufacture and sell such new revisions that they create? Or let me know if I just don't understand licenses and that's already possible. 😅
The text was updated successfully, but these errors were encountered: