Brainstorm

[RobThree]

Hi!

Thanks for replying to my YouTube comment. I thought I'd get in touch with you here... I would've started a discussion but you disabled those so that's why I created an issue.

I would like share my brainstorm:

• ESP8266 / ESP32 MCU (both have WiFi capabilities which makes for a wireless connection to the computer, which means you can easily put the whole thing further away, both are cheap and readily available)
• PCA9685 for 16 channel PWM, easily daisy chained (up to 62 x 16channels), where each channel is a gauge.
• WS2812B LEDs, 30 LEDs/meter should be (near) perfect; the 'casing' should add the required extra mm's between (a group of) ammeters to account for the slight difference in lengths.
• 50µA 85C1 ammeters
• 100K trimpots for calibration / adjustment which should suffice in both 3.3V and 5V scenario's.
• Start out with breadboard and modules (PCA9685, ESP8266 / ESP32) for prototyping, then design a single PCB and use discrete components (PCA9685, ESP8266 / ESP32)
• Design a (modular) casing so that it'll be easy to make X by Y rows/columns; maybe they snap together, maybe just provide different layouts as 3D files for user to choose and print
• Protocol could be real easy: Each byte is a 0-100(%) value where each index corresponds to an Ammeter. The sign-bit (bit 7) will be unused for values 0-100 so it could be used to, for example, disable/enable the corresponding gauge's LEDs. Send the amount of ammeter bytes et voila. 10 bytes? 10 gauges. 20 bytes? 20 gauges. The "host" (computer) can then choose what to send at what index, the "client" (MCU/Ammeters) just display the values. All logic is in the host which makes for easy updating / changing stuff around. The MCU can also determine the green-orange-red gradient based on the 0-100% values and set the LEDs accordingly. Another byte per gauge could be added/reserved to send extra options ("inverted palette" for example, where 0 = red and 100 = green, "dimmed" or "highlighted", "blink", "alternative palette" (purple to green), ... whatever).

Nice to haves:

• Cross platform (Windows/Linux/MacOS)
• "High" update rate (3 to 5 per second minimum, up to 10, maybe even higher?)
• All 3D-printed design, no need for aluminium bars etc.
• Since all 'logic' is in the host, we can easily send CPU (load), GPU (load), Network (usage), Disk (usage and/or free) etc. as long as it can be represented as a percentage.

Maybe we should create a discord (no clue how that works) to discuss / brainstorm further?

[ayan20985]

Hey! Thanks for getting back to me, really excited for this.

1. Regarding the PCB, Bluetooth connectivity, Electronics, etc. we could make them into additional modules that can be added later so that users are not totally held to that standard. We could also have a breadboard+ardiuno bootstrap guide for this on a really low budget. The main goal of this would to make the design as parametric as possible so that it can be adjusted to multiple uses cases, perhaps having an online tool to allow users to pick their requirements and create their own setup would also be good.
2. As for modular casing and electronics, I have already touched on that here. Using headphone connectors would, in my opinion, be the best course of action.
3. Your protocol was about the same as I had in mind so that's great haha!
4. Regarding nice to haves I've mentioned some here, but having high update rate might be tricky as WMI is notoriously slow. We can fake a a very high update rate by taking a reading every 3.5 seconds and then choosing a random value that is slightly offset from the current value to make it look like the needles are oscillating like in movies, etc. Again, I might be wrong and I might be able to bring it down to 3-5 per second as it currently around 20 per second on my crappy laptop but this is only for GPU temp.

Lastly, for a discord I thinking keeping discussions here for now might be the best for now as we are just two people! Plus having discussions here would allow others in the future to use these comments, "standing on the shoulders of giants", as I know I found it useful when looking at 20 year old forum posts for help!

[RobThree]

1: I think that, although it would be nice, it would be an invitation for feature / scope creep.
2: Headphone connectors are a nice idea, but aren't very PCB friendly when you need to add 20 of them to a PCB; I was thinking a simple pin 40 pin header and:

• simple dupont connectors - you could cut a female-female wire in 2 and have 2 connectors for one gauge
• or flat cable which keeps things nice and tidy and should (also) fit to the pin header and can 'branch of' to each gauge and is available in virtually any desirable length; we could also use the correct connector

4: I wasn't planning on using WMI but something more sophisticated (I was planning to use C# for the "host" at least).

As for the discord: Agreed, keeping it here would be better.

[ayan20985]

1. Guilty as charged, its already begun! Yeah, we should keep it limited until there are (if) enough resources.
2. Whilst this may be true, I think having headphone connectors would be very user-friendly and satisfying as its not very finicky rather just plug-and-play (hopefully). The benefit of such a connector would outweigh the cons in my opinion unless it gets very tricky.
3. That it fair, WMI is not very suitable for our use-case, I have for now used OpenHardwareMonitorLib.dll to get readings from the BIOS (not sure exactly how it works), if there is time we should go for a more direct approach to reading.

[ayan20985]

I am about to deploy v0.1 where this should be a proper proof-of-concept past the initial feasibility analysis.

Taking a bit longer than expected, some reliability issues with the wires so not sure what's working and what's not.

[RobThree]

I - totally coincidentally- happened to stumble upon psutil which seems to be able to return the cpu_times and per_cpu_times and seems to be cross-platform. I haven't looked into this any further (yet) since it's bedtime...

Edit: I also just ordered a whole bunch of stuff worth over €120

And that's just for my 10 core i9-10900X (20 ammeters) + 2 drives + mem + gpu = 24 ammeters + 2 for spare.

I dread doing this again for my my 18 core i9-10980XE 😅

[ayan20985]

psutil seems to be a promising candidate over open hardware monitor due to the easier API. I think I shall stick to Open Hardware Monitor (or switch to Libre Hardware Monitor for further functionality) for now to get major functionality finished on windows as this is what I am familiar with.

Nice parts! How do you plan on controlling them?

Edit: On second thought, psutil is just better, might be switching to that then for v0.2

[RobThree]

Nice parts! How do you plan on controlling them?

Oh, I have plenty of MCU's lying around. Probably an ESP8266 or ESP32.

[ayan20985]

Okay!

So first working prototype had this old gauge lying around, its a bit rough and ready but it displays the average CPU Load of all the cores. The gauge is showing the load on my laptop by running an antivirus scan.

WOAH.mp4

[JamieF1980]

@420Ayan420 this is awesome!! I've noticed there are L.E.D.'s on the breadboard.. would it be easier implement a PWM signal for neopixels (WS2811B variety) depending the overall CPU load? that can be scales per meter?

[ayan20985]

@420Ayan420 this is awesome!! I've noticed there are L.E.D.'s on the breadboard.. would it be easier implement a PWM signal for neopixels (WS2811B variety) depending the overall CPU load? that can be scales per meter?

Definitely, I was just experimenting with some LEDS that I had on had but then realized I had that gauge on hand, wasn't too bothered removing the old experiment, but yes having neopixel variety could reduce to only 1 PWM signal per backlight if done properly.

Thanks!