Hey friends 
this week has been rough for this project, not gonna lie, I have a killer bug that I haven't solved yet (that I will likely solve as soon as I write all this out complaining about it, lmao) so I'm a little behind where I wanted to be. I also have a little bit of scope creep coming for me. Not a great week, but there was progress nonetheless. At least the good news is that there's no discernable hair regrowth in the one small area that I tested - it's only been a week or two, but it's reason for optimism!
What I've been up to
Last time we spoke, I said I was gonna be designing and ordering the Lite Alpha 1. Sadly, I'm not there yet. I did implement fixes for all of the bugs mentioned in the previous post into the start of a Lite Alpha 1 schematic. Unfortunately, a lot of that was low hanging fruit. I have two more daunting challenges ahead of me before I can order boards and actually make a Lite Alpha 1. The first, which is really deeply killing me right now, is a bug, the second is a feature that I'm kind of deciding is necessary that I'll mention in new developments.
I wired the two boards from last time together to test as one unit, here's what it looks like:
Here's the bug behavior:
- Power on the board, everything looks OK. Active light off, done/ready light on.
- Put the probe in a follicle. No current draw.
- Push the pedal. Active light on, done light off, current comes from the probe. Good!
- Timer finishes, active light goes off, done light comes on, current doesn't stop flowing. Bad. Even after removing and reinserting the probe, current starts flowing again. Until you power cycle the board.
- On paper, this sounds whack but very possible to debug, but crazily enough, I can't reproduce it with a 10K resistor instead of my body.
Next paragraph is kind of jargon-y word barf that I didn't bother to make explicit or clear or referenced to the design, sorry in advance, I partly just needed to complain, but: I'm worried it has something to do with the fact that the return line of the probe is technically not ground and instead a current sink floating just a little above ground. If that's an issue, then I need to idunno make a negative supply or something and I really really don't wanna. It could be a thousand other things too. My only big lead is that if I physically disconnect the Pulse line with that switch you see in the photo, it doesn't sink current any more, so it's probably something wrong with the digital timing board. The voltage appears to be 0 even with it connected, the light is off, and it's even tied down via the potentiometer on the current source board, not to mention the LTC6993 says it can sink current through the OUT pin so even if there is something driving it high it should get pulled low. The mechanism of action here is that the potentiometer that divides the voltage that goes into the current source input is driven directly by the pulse line. I'm completely lost. It doesn't help that I'm doing this all with nothing but a single multimeter to debug. I think I'm going to buy an oscilloscope for this. I've wanted one for like a decade now and this is as good of a reason as any. It delays things, but hopefully this will speed up all testing I do from here on out forever.
Oh, and I caught and fixed another easy bug - I noticed that every time I turned off my soldering iron, the board would trigger. Luckily I knew right away that that's a noise thing. I added a 1 uF capacitor filtering the pedal line to ground and I don't get false triggers any more. Cleaner pedal signal, one less source of false triggers. yay 
New Developments
I've decided that if I go ahead with the design as it is now, operation will kind of be firing blind. The user has no way of knowing how much current or voltage is coming out. I really want to keep the Lite simple, but I don't think it's acceptable for the user to not know if current was even getting delivered through the hair follicle. So I think it's in order to add one more part to the design before making an Alpha to debug and iterate on. Basically, what I want to do is make a status light that goes on if you are delivering >90% (arbitrary and subject to change) of the current that the knob is actually set to so that the user can know if the device is working with each pulse. I'm lucky I put that current feedback instrumentation amplifier in the last design, I had a hunch it would be useful and now it is: all I need to do is compare the voltage on the input of the high-side current source with the measured current times some factor, probably done with another instrumentation amplifier on the middle leg of the potentiometer on the current sense board. If the current feedback is 90% or higher of where the set voltage has it set to be, the light comes on. It adds a few parts and some complexity, but in testing, I was finding that moving around, having a bad insertion, or any number of other things could make the current drop and deliver an incomplete hair kill, and without a light or an ammeter hooked up, the user has no way of knowing whether each pulse works, and an entire session could turn into wasted time. I hate to make things more complicated when I'm already having problems, but I think this one is necessary. 
Outside of electronics, last time, @lilypad@hexbear.net mentioned that sourcehut has a site hosting feature - thank you lilypad! 
You're so right and I set it up and put up a splash screen and I think this is a good solution! She also mentioned that printable manuals are probably a good idea - I 100% agree, my thoughts for this were to ensure that whatever site generator we use, should we make our own theme, we make sure that it's print-optimized. Static site generators usually have Markdown-based pages and that's also compatible with Pandoc, so it'll probably be pretty doable to get them over to LaTeX too for that beautiful, beautiful formatting. Good looking out 
https://sphynx.diy
@ComradeEd@lemmygrad.ml also did a lot of good thinking about static site options in the comments last time - thank you as well 
probably gonna link its post down below in the comments when we talk about how to make a site!
Also - shout-out to @YearOfTheCommieDesktop@hexbear.net for their amazing work figuring out a probe design in the comments of the last post! I haven't started building one out myself yet but I have some of the parts on the way in the mail and it looks like their work will probably be the basis for a needle holder probe, something that's necessary before we can fully release a Lite. Thank you bestie 
Next up
Obviously I need to fix my bug and implement my feature. Besides that, there's not much else to mention in electronics. It's still too early for enclosure stuff, and the electrical design is too much of a moving target to start trying to port to JLCPCB, so I just have to fight through this one. All other new developments outside of me bashing my head against these two new problems will be in both the site and the applicator probe.
Any ways to help?
I think it's time I opened up site development to interested parties? We're not in a rush but it's on the table! If anyone wants to mess with Jekyll/Hugo/something else and sourcehut's build system, I set up a repo to connect to it, so with the right configuration, we can have a build job generate with Jekyll or Hugo or something and automatically deploy. That's here: https://git.sr.ht/~_410bdf/sphynx-site I'll make a top level comment to aggregate people who want to work on that below! We can work out what static site generator we want to use together and then we can start getting it set up!
Also, 100% looking for ideas on things to test on my bug, if you're good at electronics debugging, throwing some test ideas at me would be greatly appreciated.
As always, stop by, hang out, say hi, ask questions, tell me what you've been up to, design review me, however you'd like to be involved is good by me! All the love and look out for my next post in a week or so!
Its really late for me and its been a very busy day (i finally have housing, in the nick of time, im not gonna be homeless, im so relieved 😭🤗) so i will come back to this tomorrow, but I just want to say that I actually really like that colour palette! I really agree with using the colour scheme to communicate that this is for all skin tones and hair colours.
Ill try to see take a look at sourcehut pages and ways of publishing to both web and print that are (relatively) easy as I have time in the coming days :)
As always, you rock! Im really impressed by how quickly everything has moved for this project; youre incredibly productive!
If we don't need to print our frontpage/blog, but just the docs, Sphinx seems to be able to generate PDFs (through latex) and EPUBs. So we could use that for the docs. (Sphinx is what readthedocs uses)
CC: @410757864530_dead_follicles@hexbear.net
I think the other direction could work as well if we're only concerned with having documentation in both print and web formats; a brief search revealed latex2html, which might be better at handling the contents of the manual depending on how "fancy" it is (complicated things like equations and diagrams are converted to images for the html output). Ill take a closer look at it to see how it would do with themeing and maintaining a colour scheme, but I would imagine some css would be all thats needed.
Im not terribly familiar with ReStructuredText, but it seems like a fairly standard markup language? (Im partial to latex myself, but thats probably just because Im used to it).
When it comes to EPUBs, Im not terribly familiar. My recollection is that they modify the structure of a page to fit whatever the device screen size is. This can be quite useful for straight prose, but for a technical manual might have some drawbacks, since theres likely to be diagrams, schematics, etc. Im mostly thinking out loud here, I havent looked at what goes into making an EPUB.
CC: @410757864530_dead_follicles@hexbear.net
I use
make4ht(TeX). These can work but honestly you're probably going to find more Markdown editors than LaTeX editors.Personally, I doubt this project is going to have enough documentation that you really need an automated system to do both print and HTML. It's not like code projects where it's automatically generated from docstrings. Stuff like how to use the device and where to order it will be manually written and not updated often. In fact I think these docs could even be a google doc. That's how Girl I Guess has been distributed for years, it's a big (radlib) voter guide in Chicago. Static site generator is just for fun.
Google Docs or Cryptpad would definitely be what I'd want to use if I were doing this fully solo. The static site generation is a little overkill yeah, I think it comes with a lot of advantages (more intuitive organization, easier to find and share, no tracking in the case of Google Docs, the ability to orient around a logo/theme, raw file hosting for firmware when that's a thing, some others) but all these things are more like polish and nice-to-haves than strictly necessary. That said, I think we can definitely come up with a nice site with the amount of interested folks here. Static site generators really aren't that bad once the CI/CD is set up, and once it's set up it will never have to change.
I agree with a lot of the thoughts below on LaTeX, epubs, and anything fancy like that - I think this definitely has to be printable on A4/US Letter because I have definitely gotten benefit from using manuals like that and I think others would too, but it's also not a book - it'll be plaintext with embedded images at most. Typically in my experience going from markdown or html to LaTeX works better than going the other way, but if the LaTeX formatting is appealing, there are a lot of good options to simply take the markdown that the site is written in and process those. For those reasons I'm thinking a static site with a nice theme, probably in Jekyll, and then turning that into other forms of docs, is the best route to take.
It could. I personally wouldn't choose latex as I have never used it.
I never thought of the docs as being a technical manual with the need for diagrams and schematics, I'll think about that for the future.
Nor am I familiar with RST, but yup it seems like fairly standard markup,
EPUBs are HTML and CSS1, made to be a book. (The HTML found on the web is usually slathered in CSS and looks entirely different than without it, whereas in EPUBs it's primarily typesetting) I didn't think too much about it when I wrote last night, so maybe let's just forget about them.
1 and theoretically everything else, such as MathML, though, implementation of everything is usually even more sub-par than in browsers—This is of course also dependent on the web-engine used, e.g. Calibre may have a great MathML implementation as it uses Qts web-engine (chromium), whereas I would think KOReaders crengine is worse (if it is implemented at all)