Review F-Machines RF analysis

[Furikuda]

My own analysis of both f-machine devices shows that I have a very different set of results from what @lockedmouse described via #92 The manufacturer does advertise multiple versions of the remote (A to E) so it might be that we both got different versions.

I'm happy to write something that takes into account the (PT/SC)2262 encoding in the doc, but unsure how to approach having possibly multiple versions for the same device

[lockedmouse]

For reference, my remote control is version A according to the sticker on the back, so it should be the same as your Gigolo remote but obviously we got different measurements.

You clearly have more experience with RF signals than me, so feel free to correct the documentation. All I can say is that I still think my measurements were correct; I have no problems controlling the Tremblr, both by playing back the recorded signals and by recreating the signals with code. (Though the Deno stdlib has changed so the provided code sample no longer works)

In your analysis you mention using AM mode, that sounds suspicious. I did not do any such processing on the signal; I dumped the HackRF readings to a file (= for each sample 1 byte with the real value, 1 byte with the imaginary value) and then calculated the magnitude with sqrt(real*real + im*im). I then plotted the signal to a graph; here's how it looks like when pressing the power button:

One mystery remains unsolved, the speed commands. Like if I want to increase the speed from 10 to 20, I can either send 10 individual speed commands with a lot of silence in between (but that takes forever), or I can send e.g. three speed increase commands after each other and then the speed will randomly increase by anywhere from 3 to 20 steps. Bluetooth is so much easier to work with...

[lockedmouse]

Also, just opened the remote control and the micro controller says "PT2264-S20 DSP18Z 1DE 4CR" so we probably have different remotes after all. Here's the circuit board (front and back):

[Furikuda]

Doing my favorite "gimp" analysis, I do find the same command code as my remote for "ON/OFF": 11FFFF000010

The remote I have has exactly the same "serial" on the button side, as expected =) I'd probably just specify how the pulses actually code for the 12 address+data bits (+sync bit) on the f-machine page. I'd love to see what other remotes codes look like, probably just the address part is different.

The subpar reliability kind of killed all motivation to really automatize the devices indeed....

[furrtek]

Sorry for popping out of nowhere, I just want to share a bit of info on these remotes.

They transmit using OOK (On/Off Keying), which is basically binary AM. On means presence of the carrier, off means absence of it. What you did @lockedmouse is exactly what an AM demodulator would do.

Many fixed code remotes are based on encoders made by Princeton and various other manufacturers sharing the same IC numbering. The only data difference between the PT2262 and PT2264 that I know of, is how many bits are dedicated to the address and data fields. The address is used to match remotes with receivers and must not change. Data can obviously change to encode multiple commands. The 2262 can do 6 address 6 data, the 2264 can do 8 address 4 data. So depending on how they're wired in the remote, they can both generate the same radio frames.

Here's where that "11FFFF00" address comes from by the way: Two solder blobs set the "11", then four floating pads for the "FFFF", and two more floating ones pulled to ground by R11 and R12 on the other side of the board for the "00". If needed, this address would have to be changed in both the remote and the receiver.

[Furikuda]

Just found out that this arduino library exists and I've confirmed with the tremblr that all commands transmitted are actually received more reliably by the device (tested with tremblr). My own code is now just a copy of https://github.com/nogasm/tremblr-control but with the tristate codes from gigolo added....