Split off Hardware from Software #181
Conversation
|
I can't push my actual work yet, because of missing lfs support. I've added the pdf's of the components for archiving. If lfs is not desired, I can of course still store the PDF's in 'plain' format. Here's a sneak-preview of what I'm trying to push :)
From https://gitlab.com/olliver/MHI-AC-Ctrl/-/tree/dev/new_kicad_board?ref_type=heads |
|
Looks nice, please allow me some questions: |
|
Indeed, nicely done. Also for me some question:
If I understand correctly this will replace the current Kicad. I don't know if this a good idea. Maybe beter to add it as a alternative. I don't have much understanding of PCB design so I leave this to absalom-mic :-) |
|
So I wrote a lengthy comment, posted it and it never showed up, so I'll write it again :s
The 'do-not-populate' components are optional features that change behavior. E.g. the differential I2C driver chip, is fully optional and not the default option. The power supplied over the 8p8c connector is 3v3. Via dropper diodes we can offer different voltages, but that's not the default. The desired voltage to push over the cable, depends on length. To avoid accidental errors, due to the i2c and gpio pins, 3v3 is the safest voltage (even though 5V is fine as well). The schematic text box should have explained this I thought.
Top left corner, it's an Texas Instruments TXU0304. I've added the label, which was removed accidentally.
The original comments are not very clear as to why it wasn't working. Plenty of people make use of the hardware SPI (and now even using this PCB and chip) in forks, so I would expect this to be a hardware failure. I did say 'possibly' :p
For me, external sensors. Sure, could have done this via OneWire as well, and the GPIO pins could also be used as One Wire pins of course. But getting I2C sensors is also not uncommon.
Which ones do you mean? The DC step down part is a common one from LCSC that costs a third I think. Actually all parts have LCSC numbers assigned.
It's a one-wire or 'single bit proprietary' protocol. The esp listens to the pin, and converts it to voltage/humidity readings. The protocol is described in the datasheet and there's probably thousands of arduino and esphome implementations
I've put it in readme.md, so that it renders by default when opening the folder. What are you missing for the most part?
Well I'm the author of the original kicad as well :p but this PCB is FULLY compatible with the other one. It just adds new features, that are optional. It is still a true drop-in replacement, but with (pretty big) SMD components.
The link is in the readme, and right now the repo is just used for the pipelines. Having said that, I think it's generally something to discuss, whether it makes sense to have hardware designs in this repo, which is mostly about the software. Having hardware here makes tagging a bit weird (why is there a new version of hardware tagged, when it hasn't changed), so am strongly contemplating on keeping it in its own repo, remove all software related bits and bobs, and hope absolom puts a link into the main readme :) |
|
Thanks for your feedback @oliv3r, sounds good. |
|
From a cross review pov its less favorable. But I'll clean up my repo and remove all firmware related bits. Feel free to finish the review on this side ;)
…On February 10, 2024 1:52:27 p.m. GMT+01:00, absalom-muc ***@***.***> wrote:
Thanks for your feedback @oliv3r, sounds good.
I agree that keeping the new HW stuff on your repo sounds reasonable. For sure we will add a link here to your repo.
--
Reply to this email directly or view it on GitHub:
#181 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
|
|
@oliv3r Did you have a chance to check this PR? It looks very good, imho! |
Yeah, I've cleaned things up and have it in its own repo now on my gitlab, with pipelines n stuff. I was in the process of converting it to kicad8 and got delayed a little :) |
Hi @oliv3r, Thanks in advance! |
Hey @Kurisutian been very busy with many other things lately, so not focused on this. And indeed, summer is coming, though here it's mostly just rain and cold :p regardless, I have not validated my own design :p but my latest changes where https://gitlab.com/olliver/MHI-AC-Ctrl/-/merge_requests/1 though I'm not sure in what state I left them ... I think I was waiting for kicad 8 to stabalize a bit so I could migrate to that first. Also, an ESP32 compatible design keeps crossing my mind, and one nasty bit about the ESP32 is that its longer generally, even though the wrover module is about the same size ... So the pipeline part of the project should generate a lot of things, including a BOM. I've tried to only picked parts from LCSC and those part numbers are all in. Until the merge requests (on my repo) gets merged, you can get the artifacts from the pipeline directly https://gitlab.com/olliver/MHI-AC-Ctrl/-/jobs/6252012122/artifacts/browse and after that, a nice page should be generated with browseable stuff. Like the ibom for example https://olliver.gitlab.io/-/MHI-AC-Ctrl/-/jobs/6252012122/artifacts/outputs/ibom/MHI-AC-CTRL-ibom.html (but lacks LCSC part numbers, or the boring CSV BOM with part numbers https://gitlab.com/olliver/MHI-AC-Ctrl/-/jobs/6252012122/artifacts/file/outputs/bom/MHI-AC-CTRL-bom.csv :) Once I've figured out what/where to buy in terms of ESP32, I'll get back to this thread! |
|
@oliv3r i have a few esp32 laying around here that you could use. :) it's the wroom esp32. I have around 10 left I think. If you're interested, let me know. |
|
An esp32 version would be very nice! Especially since it also allows configuring a Bluetooth proxy at the same time. |
|
@henrykuijpers my problem is mostly deciding which one to use :) It would have been perfect if I could get a 'drop-in-replacement', but those don't exist. We have I've found https://www.amazon.nl/gp/product/B08BTYCGVV/ref=ewc_pr_img_1?smid=A1X7QLRQH87QA3&psc=1 which seems alright, but it's not an official wroom module from EspressIf, so that worries me a bit. I have a few of these I could just trash the whole 'module' idea and just use the actual wroom module, but that makes it less flexible in the future, and I don't really want to maybe go down that route; even though it's probably the cleanest/smallest? |
When using an esp32 you will get more errors in communicating with the AC. But you can try of course. |
|
@glsf91 aren't those errors fixable? I.e. by using different hardware or removing assumptions that previously complied with the esp8266? |
|
I have tried but not succeeded. Also BT with WiFi was not working very well in my case. |
|
I'm running with an ESP32-C3 just fine (4 frame errors from 20th of April until now). I'm using hardware SPI and also listen to Bluetooth advertisements from several temperature sensors. Code and kicad here: https://github.com/hberntsen/mhi-ac-ctrl-esp32-c3 |
|
You are using esp-idf instead of arduino and changed code. That is probably working better. The original code with arduino platform is not working very well with esp32.
|
|
I saw your repo and that's where my inspiration comes from. I just didn't like the C4 board. I might indeed go for the board with the extra outer pins. I think space wise, they are similar at the cost of width, but I can use the same board. Upside is that the unused side pins can easily be used from the top.
As for arduino, I'm not surprised it has been troublesome. So using IDF or proper C code is likely far more efficient then the beast that is arduino. (Not a hater, I think arduino is great for PoC's).
|
|
@oliv3r Shall I add a link to your repo (https://gitlab.com/olliver/MHI-AC-Ctrl) and this pull request in the hardware.md under PCB (KiCad) ? |
|
@hberntsen Shall I also add a link to your repo also in hardware.md ? |
|
Sure!
…On 13 June 2024 20:02:28 CEST, glsf91 ***@***.***> wrote:
@hberntsen Shall I also add a link to your repo also in hardware.md ?
--
Reply to this email directly or view it on GitHub:
#181 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
|
|
That was actually my intend, but only after getting my first working samples ;) so give me some time for that if you will!
|
|
I've spend some time on my repo, which is now in a good shape. I've also ordered those ESP32's and sadly the esp32 (both actually) are longer. So I have to break backwards compatibility with the PCB size, it will be slightly longer. I am opting for the 'wide' ESP as we can keep using the same footprint, which I think is more valueable then making a different board for each esp. |
|
As I mentioned above, there are esp32's which are compatible with the current PCB.
So I can make a link to your repo and close the pull requests ? |
Is this not the one you mentioned? I agree, the picture doesn't look like it but it's the first picture on this comment #181 (comment) with the 'Wemos' PCB, though I got 'MH-ET Live' on the package. So it's pin compatible, but it's longer. Maybe I should have been more clear, my redesigned board was (but maybe I remember wrong) within the exact dimensions, but with the new board, due to the ethernet connector, will become slightly longer. But still better then using a different ESP32 board, which has different pin spacings/lengths. So this will have to do.
Almost!! (I will actually put the link to the repo in this MR :) |
Yes the first on the picture. It will fit the original pcb from hardware.md. It is pin compatible with the WEMOS-D1-MINI. You only need to change the pin definition in the software. |
Can we finish this and close the pull request? |
oliv3r
force-pushed
the
dev/new_kicad_board
branch
from
d7b1ba8 to
57eca27
Compare
oliv3r
changed the title
Yes, You can merge it here now. I'll keep progressing in the other repo. I don't care where it's hosted btw. If you want to make it part of this user, your own user, create an organization for it; all is fine. Speaking of, making an org is probably a wise idea anyway ... |
It is increasingly becoming more difficult to keep track of hardware and software changes. E.g. git-tags refer to software, but the hardware also has versions. To reduce the scope of this repository, and make things cleaner repository wise, lets split off these two repositories into software and hardware. Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
oliv3r
force-pushed
the
dev/new_kicad_board
branch
from
57eca27 to
4ea4ed7
Compare
|
I see now all the HW stuff is moved. I thought only the new HW stuff would be in your repo. So only the kicad stuff. |
The HW stuff should remain here, only the Kicad stuff should be in an extra repo |
|
@oliv3r I have changed the Kicad link in hardware.md to your repo. |
|
Probably wise to mention continues development happens on the other repo.
I still strongly urge you to move the hardware stuff into its own repo.
Version tracking etc becomes quite difficult with two different
trackable items (hardware, software) in one repo.
|
|
I have added you mention. I don't expect much development in SW and HW for this moment. So leave it for now. Can be done also later if needed. |
It is increasingly becoming more difficult to keep track of hardware and
software changes. E.g. git-tags refer to software, but the hardware also
has versions.
To reduce the scope of this repository, and make things cleaner
repository wise, lets split off these two repositories into software and
hardware.