pymo / ppk_bluetooth

Bluetooth HID adapter for the Palm Portable Keyboard
MIT License
115 stars 6 forks source link

DCD high detected too early when Vcc goes up #4

Open jan-gerard opened 5 months ago

jan-gerard commented 5 months ago

Initially, I could not get it to work. It appears that with my esp32-C3, the DCD input sees a positive peak when Vcc to the keyboard is switched on. Then, the software detects this spike as the DCD pulse, and gives the RTS pulse. But that appears to be too soon, and the keyboard doesn't see it, so it doesn't send its ID. image

When I introduce a small delay of 2 ms after the Vcc and Gnd pins to the keyboard are enabled, it works like a charm. So I would suggest to introduce such a delay in the code, after the line digitalWrite(VCC_PIN, HIGH);.

pymo commented 4 months ago

That's fantastic analysis! I don't have a oscilloscope, could you help me understand: when the keyboard respond with DCD pulse, is it a pulse (i.e. 0-1-0), or it is jumping from 0 to constant high?

My fear is if it is a pulse, and I wait for too long, the code might miss the DCD pulse.

jan-gerard commented 4 months ago

It's a pulse indeed. What happens is that 560 ms after the power is supplied to the keyboard, the DCD line goes high for 200 ms. Then it remains low for 1.5 s, and another 200 ms pulse follows. I don't know if more pulses occur, because after 4.2 s, the esp switches off the power to the keyboard. But I think this is already enough information. print_03 Yellow is the + supply to the keyboard, green the DCD line, and purple the response of the esp, on the RTS line, disconnected in the graph above.

As long as the esp does not miss the 200 ms pulse, it's OK. Typically the processor sends the RTS signal almost immediately after the DCD high was detected, making the keyboard drop the DCD again. print_02 In the second screenshot, the RTS line is connected, and shows the DCD drop when received.

pymo commented 3 months ago

Thanks for the graph! It is very helpful. If the DCD consistently do the pulse ~500 ms after the power, then yes, sleeping for 20ms at the beginning seems safe. I'll verify the behavior and change the code soon.