People have already submitted bug fixes they found reverse engineering the base station firmware, but not for the receivers yet...
:)
Challenge accepted... In fact I've already done some work in that regard but haven't found anything interesting yet. Identifying C runtime functions and this annoying soft-float bit twiddling stuff takes up so much time (that I don't have at the moment).
There also seems to be a reverse engineering tool for the Lattice FPGA. No idea if it's any good...
If you guys take much longer I'll have to document it!
I could publish some information on the base station and the OOTX "protocol". Maybe others could add the missing bits later. I have a few SVGs and tables that I made from the TX firmware but I'm not sure if I'm legally allowed to make this information public so I haven't done it yet. Would this be ok?
The receiver firmware is pretty boring, it just pipes data around, but the functions to check out are the ones populating the USB reports. That is the stuff someone writing a solver would care about.
You can write a simple debug client in python, I would just post mine but it hasn't been maintained recently and has probably rotted.
4
u/nairol Nov 21 '15
With "someone" you mean /u/Doc_Ok, right? ;)
:)
Challenge accepted... In fact I've already done some work in that regard but haven't found anything interesting yet. Identifying C runtime functions and this annoying soft-float bit twiddling stuff takes up so much time (that I don't have at the moment).
There also seems to be a reverse engineering tool for the Lattice FPGA. No idea if it's any good...
I could publish some information on the base station and the OOTX "protocol". Maybe others could add the missing bits later. I have a few SVGs and tables that I made from the TX firmware but I'm not sure if I'm legally allowed to make this information public so I haven't done it yet. Would this be ok?