Open horse-pants opened 3 months ago
horse-pants
commented
3 months ago So I saw a closed issue where the person said they'd set the the RF transmitter to 5v instead of 3.3v that the spec sheet said, and now, for a while, I get successes but then it goes back to errors.
Is it possible the millis casting is stripping off enough info to make the receiver reject packets?
decrazyo
commented
3 months ago It looks like the casting is needed because esp32 has a slightly different definition for the "millis" function than standard Arduino library does. I don't think it should cause any problems though. This is probably some error in my implementation of the Unifying protocol but it's hard to pin down exactly what's going wrong. It's probably something to do with packet transmission timing. Packet transmission timing was inferred from packet captures of genuine Unifying devices and it's proven difficult to properly replicate the timing. That seems to result in occasional errors like the one you described. Unfortunately, I'm not sure how to fix it yet.
horse-pants
commented
3 months ago All good, I'll keep monitoring and trying things. I did mess with the timings a little but it didn't seem to help. Generally got between 1-4 keep alives that were accepted before being booted
Nice work so far though, cheers
Hi,
I'm looking to control my KVM with macros, and it's very fussy about HID so this looks perfect, I've got my esp32 connected, but immediately after connection is fails to transmit the keep alive packages
Connected
Failure
The only material thing I changed from the example is I had to cast the time, I don't know enough about C++ to know if that's a deal breaker or not, but with out it I got the compile error below
error: invalid conversion from 'long unsigned int ()()' to 'uint32_t ()()' {aka 'unsigned int (*)()'} [-fpermissive]
the firmware is 012.010.00032 and the MCU is the lillygo t display s3 amoled
Is there any logs or hints you could point me at to see why this is misbehaving?
Cheers!