• some very late updates/additional information

    Eris • 08/16/2024 at 01:47 • 1 comment

    -still havn't worked on the firmware any more but wearing the watch anyways and it works! it just still displays winter time since i still have to reflash the watch to set the time and i havn't done that. in practice the battery lasts about 2.5 days, which i'm pretty happy with, though further improvements could certainly be made.

    -at some point made a really nice dev board with 2 usb c ports, one for the watch and one for the compter, it has an intigrated 2 port usb 2.0 hub so i can connect the watch usb and the built in rp2040 serving as an swd debugger simultaneously with only one usb cable. the usb ports are kinda finicky bc my soldering sucked but it's still a pretty nice experience.(obviously also has usb boot and reset buttons for both watch and debug rp2040)

    -i never mentioned it has an ambient light sensor. it does that! and that's even actually implemented in firmware. the display doesn't get bright enough for direct sunlight(and an overflow(i think in the ALS itself) means the display shuts off when there's too much light but given it's not readable anyways that's basically a feature) since i'm nocturnal it still shows me the time a lot clearer than a non LED watch probably would most of the time and i'm pretty happy with it, though i might be able to increase the display regulator voltage a bit and squeeze a bit more light out of them to cover a slightly broader range of lighting conditions. i also think if i ever make a v2 it should probably have red acrylic over the display to minimize reflections and make the display even more readable.

    -RP2040 power management sucks ass. for my typical (mostly low light) operating conditions it tends to draw more current than the display(i think around 5mA but it's been a while so don't 100% on that).

    i even fully re wrote the pio display program and interface driver to not use DMA(just stores display values in it's registers) and while i'm proud of the PIO code and had a lot of fun writing it(was quite close to hitting the limit of what i could do with PIO alone, was syncing 7SMs over the two blocks, very enjoyable puzzle) it didn't decrease power consumption one bit.

    it could probably be significantly improved by supplying core voltage with an external switching regulator and potentially switching to a specialty low power oscillator instead of the built in one with external crystal. but it's still very frustrating to see how i can't just turn off everything except the PIO and wake on pin change interrupt.

    the clean and most efficient way to solve this would obviously be to move to an FPGA or something like that for the display driver and maybe even just also stick a risc v core on there and abandon RP2040. however learning that stuff seams scary and the above mentioned incremental improvements might be enough to not make me quite so upset with the amount of power that's just being wasted.

    alternatively i could switch to something with a more conventional low power co processor like an esp32(with free wifi and BT, though i don't know what i'd need that for(maybe alarms over bluetooth speaker)) IF that has competent power management, but i really like the PIOs, they're so fun and never halt, so the GPIO state never gets stuck and the display is pretty much safe from burning out due to a segment being on for too long(did i even mention this? u can run these displays at up to 100mA peak but if it takes more than 1ms to switch to the next segment or average is over like 5mA it might die or at least come closer to death). I'm assuming i could protect the leds in a similar way if i was using an FPGA.

    yes RP2350 has an integrated switching regulator for core voltage but i don't think it's very efficient. ur not even supposed to use it for output current under 1mA bc LDO is more efficient then, that doesn't inspire confidence. would still wanna get a good external one) and the power management improvements besides that look like a token effort at best(power domains, but the cores and all they're...

    Read more »

  • telling time!

    Eris • 02/09/2024 at 03:33 • 0 comments

    finally got the RTC running!

    made a simple breakout board to confirm i didn't fundamentally fuck up the init sequence, then replaced the rtc on the board and added a bodge wire with a resistor between the backup supply pin and the rtc voltage as described in the datasheet bc i'm stupid and i forgot to do that before.

    now working on the firmware.

    it's still very early stages, u can't even set the time on the watch yet and it turns out one of the buttons also isn't working so i have to fix that, but it can tell the time now!

    also got it running at 2MHz which should hopefully reduce battery drain somewhat, will be testing that. either way i should be getting at least a bit over a day of usage right now.

    next steps are to add an interface with states for setting the time and such, fix the button and add the piezo and additional features like alarms. should also hopefully get a usb serial console for setting the same things as in the interface but for if u have a pc and prefer to use a keyboard soon.


  • late Init Log

    Eris • 10/31/2023 at 10:09 • 0 comments

    finally attempting to Log progress so here's what's happening:

    1. i've assembled the second version of the PCB.

    it's a lot more compact than the first version and actually as space for the antenna and matching circuitry for LoRaWAN.
    There are still some Major bugs in the hardware like overconstraining the PCB position with both the rails it slides in on and the USB connector.
    If i ever make another version i'd just forgoe the rails entirely and just constrain the pcb with the usb connector but for now i just made the rails wider.

    As you can see there's also some bodge wires because i swapped the pins of the switching regulator for the display despite it being correct in KiCAD by default and it turns out the big pad on the flash doesn't actually wanna be connected to GND.
    I also screwed up the vibration motor driver but besides that everything should be working.


    2. PCBWay sponsored metal case!

    Size, ruggedness and looks are very important for what i want Acidfish to be and FDM printed PETG only gets me so far.
    Thankfully PCBWay was kind enough to send me some very nice looking aluminum and steel SLS prints!
    The Aluminum main shell allowed me to reduce the size significantly because the walls don't have to be as thick when i can trust that they're solid and won't let any water through while the steel lid is perfect for applying even pressure on the seal to ensure no water gets in.
    The side of the lit that faces the seal turned out especially flat so i'm very confident that it'll keep my PCB dry.
    For the main shell the tolerances were a bit tight, but nothing i couldn't fix with a bit of sanding(also sanded the outside, the finish it arrived with is quite rough).
    If you're interested in getting some metal prints of your own i'd recommend leaving at least .5mm tolerance rather than my .3mm, probably a bit more for very tight slots.
    Besides that i'm very happy with how it turned out and will probably use the service again if i make another version.

    Oh yeah also i need to improve the seal around the buttons, maybe just switch to O-rings, alternatively cast silicone around rather than over the buttons.

    3. state of AcidOS:

    Trying to write the display driver for the new PCB.

    In theory two PIO state machines are supposed to be fed from two different DMA loops pointing to two separate buffers, one for cycling through all the segments and one for turning the enable pin on the demultiplexer on when a segment is supposed to be on.

    Somehow both DMA loops always point to the same address, but it appears to be random which buffer they end up with.

    I hate this bug so much but i guess i'll figure it out eventually.