Split off Hardware from Software

[oliv3r]

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.

[oliv3r]

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 :) MHI-AC-CTRL-assembly.pdf MHI-AC-CTRL-schematic.pdf

From https://gitlab.com/olliver/MHI-AC-Ctrl/-/tree/dev/new_kicad_board?ref_type=heads

[absalom-muc]

Looks nice, please allow me some questions: Some of the components have a red X, what is the background? I can't find the name of U1 "real level translator" in the schematic. Why could make your level translator hardware SPI communication possible? What is the use case for I2C via RJ45?

[glsf91]

Indeed, nicely done.

Also for me some question:

• used components are unclear for me
• connection for DS18x20 is unclear for me
• I think more documentation is needed, including real images like in hardware.md

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. Why not adding a link to your repo ?

I don't have much understanding of PCB design so I leave this to absalom-mic :-)

[oliv3r]

So I wrote a lengthy comment, posted it and it never showed up, so I'll write it again :s

Some of the components have a red X, what is the background?

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.

I can't find the name of U1 "real level translator" in the schematic.

Top left corner, it's an Texas Instruments TXU0304. I've added the label, which was removed accidentally.

Why could make your level translator hardware SPI communication possible?

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

What is the use case for I2C via RJ45?

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.

used components are unclear for me

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.

connection for DS18x20 is unclear for me

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 think more documentation is needed, including real images like in hardware.md

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?

I don't know if this a good idea. Maybe beter to add it as a alternative.

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.

Why not adding a link to your repo?

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 :)

[absalom-muc]

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.

[oliv3r]

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: https://github.com/absalom-muc/MHI-AC-Ctrl/pull/181#issuecomment-1937000248 You are receiving this because you were mentioned.

Message ID: @.***>

[henrykuijpers]

@oliv3r Did you have a chance to check this PR? It looks very good, imho!

[oliv3r]

@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 :)

[Kurisutian]

@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, you mentioned in an issue ticket that the original level shifter seems to only "work most of the time" and I am experiencing the same problem from back than again having one unit which is totally unreliable and not working again for some weeks now. And with summer around the corner I need to start acting. 😁 So I was looking at your repo but could not find the different hardware list with another "true" level shifter. Also I think reading humitdity would be nice as well. 😉 So could you share the current status of your repo and where I can get your hardware list (maybe including recommended shops where to get them)? Anyhow I am holding back on letting some boards being printed for now to see if your approach will ensure more reliability.

Thanks in advance!

[oliv3r]

@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, you mentioned in an issue ticket that the original level shifter seems to only "work most of the time" and I am experiencing the same problem from back than again having one unit which is totally unreliable and not working again for some weeks now. And with summer around the corner I need to start acting. 😁 So I was looking at your repo but could not find the different hardware list with another "true" level shifter. Also I think reading humitdity would be nice as well. 😉 So could you share the current status of your repo and where I can get your hardware list (maybe including recommended shops where to get them)? Anyhow I am holding back on letting some boards being printed for now to see if your approach will ensure more reliability.

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!

[henrykuijpers]

@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.

[henrykuijpers]

An esp32 version would be very nice! Especially since it also allows configuring a Bluetooth proxy at the same time.

[oliv3r]

@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 but it's wider.

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 but those are quite a big longer.

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?

[glsf91]

An esp32 version would be very nice! Especially since it also allows configuring a Bluetooth proxy at the same time.

When using an esp32 you will get more errors in communicating with the AC. But you can try of course.

[glsf91]

@oliv3r I used this one as a drop-in ali You don't need to use the outer pins. You have to change of course the pin definitions in the software (and some other stuff to compile for esp32). But you will get errors when using an esp32.

[henrykuijpers]

@glsf91 aren't those errors fixable? I.e. by using different hardware or removing assumptions that previously complied with the esp8266?

[glsf91]

I have tried but not succeeded. Also BT with WiFi was not working very well in my case.

[hberntsen]

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

[glsf91]

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.

[oliv3r]

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).

[glsf91]

@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) ? Then we can close your 2 pull requests here.

[glsf91]

@hberntsen Shall I also add a link to your repo also in hardware.md ?

[hberntsen]

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: https://github.com/absalom-muc/MHI-AC-Ctrl/pull/181#issuecomment-2166460296 You are receiving this because you were mentioned.

Message ID: @.***>

[oliv3r]

That was actually my intend, but only after getting my first working samples ;) so give me some time for that if you will!

[oliv3r]

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.

[glsf91]

As I mentioned above, there are esp32's which are compatible with the current PCB.

I've spend some time on my repo, which is now in a good shape.

So I can make a link to your repo and close the pull requests ?

[oliv3r]

As I mentioned above, there are esp32's which are compatible with the current PCB.

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 https://github.com/absalom-muc/MHI-AC-Ctrl/pull/181#issuecomment-2161667337 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.

I've spend some time on my repo, which is now in a good shape.

So I can make a link to your repo and close the pull requests ?

Almost!! (I will actually put the link to the repo in this MR :)

[glsf91]

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.

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.

[glsf91]

Almost!! (I will actually put the link to the repo in this MR :)

Can we finish this and close the pull request?

[oliv3r]

Almost!! (I will actually put the link to the repo in this MR :)

Can we finish this and close the pull request?

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 ...

[glsf91]

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. @absalom-muc do you want to move all the hw stuff or only the new kicad stuff?

[absalom-muc]

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. @absalom-muc do you want to move all the hw stuff or only the new kicad stuff?

The HW stuff should remain here, only the Kicad stuff should be in an extra repo

[glsf91]

@oliv3r I have changed the Kicad link in hardware.md to your repo. I will close this PR and remove the Kicad files here later this week. Let me know if you want changes.

[oliv3r]

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.

[glsf91]

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. I will close this PR. Thanks for you effort.