That's clear, but we are all very early adopters and it would be easier to trim the value while debugging than doing some SMD patch soldering while tuning the engine. It'll require some trial and error to get the resistance correct, especially in environments like the subarctical climate I live in. It might work fine in the summer, when ambient temperature ranges are between +5°C and +30°C, but might be a pain in the winter, when they are between -40°C and +5°C.Fred wrote:Not a bad suggestion, but, there is no requirement for a trimmer in those locations, just an exact high precision fixed value. (Just to be crystal clear)How about including instructions about how to hack trimmers in places where variable resistance is needed?
Ok, please patch that into components.yaml and configurations.yaml accordingly. I'll rather focus on getting the software done than fiddling with the BOM specification details, which I already spent quite a lot of time on to get the baseline implemented. It's OK to just make a separate repository containing a copy of theFred wrote:VNP20N07 should not be on any parts list. VNP10N07 and even VNP5N07 and other comparable devices from other manufacturers or newer ones from the same can/should/could be used. 20 amps will almost certainly remove a fair bit of copper from the PCB.
Code: Select all
dbs/freeems-puma-spin1
It's just using the unix philosophy of "silence is success". Any output means attention should be paid to what it's doing. Currently it also traces the progress with extra messages, but those will be removed at a later point, leaving only warnings in place. Errors are prefixed "ERROR:" and halt the execution, when encountered.Fred wrote:I've not seen the output your code generates (but I probably should install the ruby stuff and do that) but I liked what you said about warning/error levels earlier. I think it should stay as is, but that they should be made obvious, if they aren't already, with "WARNING:" preceeding them, perhaps?Actually, those are not suggestions, they are WARNINGS about the definitions! Maybe I should make them errors instead?
I'd rather get the BOM specification work delegated to someone who has a clue about what the board should contain. I'll provide assistance for the software and structures. However, I'm mostly wasting my time while debugging details of the BOM specification data, when I could spend the same time more productively on software development.Fred wrote:BIG plus one here too. This is where Marcos and Jared are really really really _NEEDED_, once that stuff is sorted, others can do the rest. No one else, bar marcos, truly knows this stuff. I am the only person with the capability to reverse engineer it, but wait, no, not even me, no DMM anymore.the components and configurations lists MUST still be double-checked and peer-reviewed. Currently, we have a loose set of "IMO" data scattered around. All that must be condensed into one place, conflicting opinions must be ironed out and a good, refactored output must be made.