Green - and Green + are not distinguishable about cff3000-pcb HOT 6 OPEN

That's probably a problem with your SVG renderer. It looks ok for me in Firefox and Chromium. The cathode (-) of the green LED is on the side of the battery and thus the anode (+) of the green LED is close to the PCB edge.

Since I created this Github project, I spent some time analyzing the remote control's circuit. I still need to update this repository for this, but the summary:

• The micro-controller controls the cathode of each LED (i.e. it will go HIGH when the LED is supposed to be off)
• The green LED is driven by a charge pump circuit resulting in PWM signal on its anode
• The battery + is not Vcc, but BAT+. There is a transistor connecting it to Vcc when a button is pressed and micro-controller will keep it enabled until it has done its job.
• Vcc is the middle one of the big vias (i.e. where GND is marked in the photo) and can be used as RED+ and GREEN+, which is easier to solder and avoids having to fiddle with the charge pump.

I plan to update this project with more details soon.

from cff3000-pcb.

Thanks for the fast update. As I'm a beginner to electronics:
What implications do these updates have?

• I got that I can solder VCC (middle big via or "hole") to RED+ and GREEN+.
• Does this also hold for VCC or do I still have to grab it from the battery?
• What about BUTTON+? Is this also VCC? (Are Buttons active high or low?)
• Is there a more convenient spot to grab GREEN-?

Btw, what are the other three big vias? SWD/JTAG? UART? Have you tried looking into them?

As I just finished to solder the whole thing: will there be an significant update to it? (Hopefully not :D)

Also, I could provide my BOM as there are no exact part numbers and I had to guess them (honestly, it also could be the case that I'm just stupid :D).

from cff3000-pcb.

Btw, what are the other three big vias? SWD/JTAG? UART? Have you tried looking into them?

The big vias are for programming the PIC16LF:

• 1 = GND
• 2 = VPP (which is the same as the LOCK button signal)
• 3 = VCC
• 4 = ICSP_DATA
• 5 = ICSP_CLK

As I just finished to solder the whole thing: will there be an significant update to it? (Hopefully not :D)

On my original board R1 and C1 were meant to filter the PWM noise from the charge pump. With the noise gone (by using Vcc instead of GREEN+) those should be removed. I also replaced the 74HC14 and the PC817 with a two comparators, but the original design should also work.

Does this also hold for VCC or do I still have to grab it from the battery?

I have not yet tested this. Using VCC instead of BAT+ to supply the board means, that the micro-controller will keep being powered. This will draw slightly more power, but we are talking about mW (so a problem for a coin cell, but neglectable when you power a Raspberry-Pi or sth. similar in parallel). Using it should not break anything, but IDK if the software running on the PIC16 can handle being powered all the time. You will have to test it :)

What about BUTTON+? Is this also VCC? (Are Buttons active high or low?)

LOCK and UNLOCK are pulled to GND with 3.3K on the remote control. Pressing the button will connect the pins to BUTTONS+ respectively, so the buttons are active-high. BUTTONS+ is connected to BAT+ with a 33K resistor, since the buttons also enable the transistor, which supplies Vcc from BAT+. If you use Vcc instead of BAT+ to supply the circuit, you should also get away to use VCC for BAT+.

Is there a more convenient spot to grab GREEN-?

There is a more convenient spot to grab the LOCK button, which is the via between GND and VCC. The board reuses VPP for the lock button signal. For GREEN- you might find the small VIA between the PIC16 and the unlock button more convenient (the one, which is closest to the unlock button).

Also, I could provide my BOM as there are no exact part numbers

I just used parts laying around in my hackerspace. The exact component should not really matter as long as the values roughly match. Value-wise the only interesting part was the filter for the charge pump PWM and that is gone due to using Vcc.

from cff3000-pcb.

On my original board R1 and C1 were meant to filter the PWM noise from the charge pump. With the noise gone (by using Vcc instead of GREEN+) those should be removed.

This means I just remove them or I have to bridge (one or both of) them?

I have not yet tested this. Using VCC instead of BAT+ to supply the board means, that the micro-controller will keep being powered. This will draw slightly more power, but we are talking about mW (so a problem for a coin cell, but neglectable when you power a Raspberry-Pi or sth. similar in parallel). Using it should not break anything, but IDK if the software running on the PIC16 can handle being powered all the time. You will have to test it :)

This could be handled by either driving the whole thing via a GPIO and do the power cycle in software. Not the best idea, though, as GPIOs on the Pi allow for max. current of 16mA. I'd assume, that the board especially while sending, draws more current. Maybe I could use a transistor to circumvent this.

[...] If you use Vcc instead of BAT+ to supply the circuit, you should also get away to use VCC for BAT+.

This results in two options to power the whole thing, right?

Option 1:
VCC_J4 -> BAT+
Then, Button+ must be grabbed as intended in the original sketch. (Question: is this correct or can I connect Button+ to VCC_CFF or VCC_J4 instead?)
Green+ and Red+ on the board can be connected to VCC_CFF (middle via) instead.

Option 2:

VCC_J4 -> VCC_CFF
Then, Button+, Green+, Red+ on the board can also be connected to VCC_J4.
Might not work, if software needs powercycle, see above.

from cff3000-pcb.

On my original board R1 and C1 were meant to filter the PWM noise from the charge pump. With the noise gone (by using Vcc instead of GREEN+) those should be removed.

This means I just remove them or I have to bridge (one or both of) them?

Drop C1, bridge R1 (i.e. make it look the same as the route for the red LED)

I have not yet tested this. Using VCC instead of BAT+ to supply the board means, that the micro-controller will keep being powered. This will draw slightly more power, but we are talking about mW (so a problem for a coin cell, but neglectable when you power a Raspberry-Pi or sth. similar in parallel). Using it should not break anything, but IDK if the software running on the PIC16 can handle being powered all the time. You will have to test it :)

This could be handled by either driving the whole thing via a GPIO and do the power cycle in software. Not the best idea, though, as GPIOs on the Pi allow for max. current of 16mA. I'd assume, that the board especially while sending, draws more current. Maybe I could use a transistor to circumvent this.

16 mA is not enough. Driving it through a transistor should work. It might also be ok to keep it enabled all the time (as I said I have not tested this).

This results in two options to power the whole thing, right?

Yes, looks sensible. As I said you can get LOCK from the hole between VCC and GND.

from cff3000-pcb.

As I am about to start tinkering with this soon. Is there a chance on getting an updated schematic with these simplifications?

from cff3000-pcb.