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!
Web friends - by my count that's @ComradeEd@lemmygrad.ml, @lilypad@hexbear.net, and @lapis@hexbear.net expressing interest in the previous comments - let's talk here? Anyone have experience with sourcehut builds? Any thoughts between Jekyll, Hugo, Lektor, something else (being familiar with one of them is a valid reason for a preference)? Any themes catch your eye? I'd love to go with a pink theme for the sphynx thematic consistency, but I'm also thinking it might be nice to come up with some kind of color palette that incorporates a range of skin tone colors for thematic consistency with the project and to establish the feel that a driver for this project is improving access to permanent hair removal for people of all skin tones, not just those who can receive laser - thoughts?
Demo color swatch if that doesn't sound like a crazy idea:
Show
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!
Ill try to see take a look at sourcehut pages and ways of publishing to both web and print that are (relatively) easy
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)
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.
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.
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.
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)
✋ Lektor familiarity. (See Queerscriptors - source and ComLib - source)
I checked the step by step guide on Jekyll, and it seems very similar to Lektor, so I'm not voting for Lektor, I'm just stating I know it.
Very cool with the color palette idea.
Looks like it uses Jinja2 for templates, big win, I love jinja2. It also seems a little less supported, which might be a downside but not that big of a deal if you're comfy with it. How are build times? It doesn't matter too much for long term use but it would be really awesome to develop on if it built the whole thing in like a couple of seconds
It does use Jinja2. And yea, the support isn't great, it used to be worse if I remember correctly, having become active again at some point. That was one of the reasons I wasn't sure if I would go with it.
How are build times?
According to lektor itself:
0.12 seconds for ComLib (to be fair it is very small)
~4 seconds for Queerscriptors. (Note that Queerscriptors is translated into 9 languages, excluding the original English)
After a day away I'm kind of thinking Jekyll is the move since it's apparently (and I agree) pretty similar looking to Lektor. It seems to have the best of both worlds, mass usage and also familiarity, and I really don't think site generation time will be as big of a deal as I was thinking it'd be last time I thought about this.
Tags:
@Wake@hexbear.net @raven@hexbear.net @ForgetPrimacy@lemmygrad.ml @macerated_baby_presidents@hexbear.net @sharedburdens@hexbear.net @ComradeEd@lemmygrad.ml @BountifulEggnog@hexbear.net @YearOfTheCommieDesktop@hexbear.net @Erika3sis@hexbear.net @CarbonScored@hexbear.net @frankfurt_schoolgirl@hexbear.net @oscardejarjayes@hexbear.net @crosswind@hexbear.net @lilypad@hexbear.net @OurToothbrush@lemmy.ml @tartan@lemmy.ml @AernaLingus@hexbear.net @SnAgCu@hexbear.net @naevaTheRat@lemmy.dbzer0.com @lapis@hexbear.net @proletarian_girlboss@lemmygrad.ml @Hurvitz@hexbear.net
If you'd like to be on the tag list, or if you're on the tag list and would like to be removed, let me know here!
Looking good
I'm sure you'll figure out that bug soon!
Oh hey, you mentioned perhaps writing documentation in LaTeX. I'm quite proficient in LaTeX and would love to help, when you get to that stage! I'll keep an eye on the project and volunteer again when it's closer to time!
This project you're doing is so super cool!
I was thinking more along the lines of writing everything in markdown and then having a website to display the content there, and either using Pandoc to convert the markdown into LaTeX (LaTeX knowledge definitely helpful here for making the formatting good) or alternately just designing a highly printable website from the jump and then just rendering it to PDF using... something (no LaTeX knowledge required there). This is all dependent on how the site turns out though, so this one is somewhat in the future, but if LaTeX comes up again, I'll @ you!
Love reading about your process and progress on this. Cheers for keeping us in the loop!
Hi and welcome back
I was pretty lock-step posting on Sundays, having not much progress to report because of a bug defeated my resolve a little bit so it took me an extra day to get the post out
you know it - the hallmark of a real project, the domain name purchase, has been completed. With this move, I have all but assured successful completion of the project.
yes yes get a scope! more substantial response later but I have a DSO138 and it works just fine for my purposes. you don't have to buy a fancy one or wait for a used university scope to get on the market
it's in the mail! I'm very excited! I ended up getting a low-end Rigol, something that can last me well through designing the digital stuff of the MCU units, and the RF circuitry of the thermoloysis units, and also a good scope for any other electronics projects I have incoming. I've wanted one for years, now is as good of a time as any.
I made progress debugging my killer bug by the way, look out in the comments here for an update. I'll @ you in it, you probably have some good debugging insight.
Big update on killer bug squashing progress:
I've narrowed down the source of the bug to the current source at the high side of the circuit. Many of the likely issues implicate the current sink at the low side of the circuit too. See entry #3 for schematics. I thought I could reproduce the behavior with the steps in the original post, but it turns out 1) it's just flaky and it's not as repeatable as working on first startup, and 2) it can be reproduced removing the entire digital timing board from the loop and tying the pulse line to ground, and even sourcing current from the output of the high-side current pump to ground instead of sinking it into the low side current sink. It's not the instrumentation amp either, I built another mk2 without populating it and I'm having the same issues. I haven't rigorously evaluated the mk1 version of the current source (see entry #1 for schematic) but I believe it behaves a lot better, and with the main two differences being the choice of opamp and the various resistor values, I think the latter is the culprit - I think there's a lot of ways that using a very small R4/R2 ratio might cause instability, especially considering that tolerances could potentially have a larger than expected impact after all the algebra works out. That said, I do intend to try it both ways - both the new opamp on the mk2 board with the old resistor values, and the old opamp on the mk1 with the new resistor values. This will help me narrow down the source of the problem even further. I might also try to run some simulations with real opamp models instead of ideal ones, and model tolerances into the resistors. I still have confidence in this current source/sink topology so I'm not giving up yet. Of course my debugging options will be better once my scope arrives, but this is a thing I can do in the short term to avoid being stagnant.
@macerated_baby_presidents@hexbear.net you always have really good EE advice - thoughts on the above? Any other potential failure causes you notice, any potential tests you'd like me to try, any other anything? Anyone else is welcome to comment too!
