Porting rfcat to cheap hardware?

AsFaBw commented 5 years ago

I really love rfcat... ...although the available hardware seems to be for me quite expensive (starting with the TI CC1111EMK ~70Euro as the black chronos board is not available any more). I wonder for some time, whether there is a possibility to port rfcat for cheaper hardware.

One device I came across is the Max!Cube ( https://www.eq-3.de/produkte/max-heizungssteuerung/max-hausloesung/bc-lgw-o-tw.html ). The device has an CC1101 and is available from 22,95 inclusive shipping (within Germany).

There is already custom firmware available for homeautomation ( https://github.com/heliflieger/a-culfw/tree/master/culfw/Devices/CUBe ).

There is also the possibility to add up to 3 further cheap CC1101 boards into the device. That could allow to operate one CC1101 in monitor mode, while another could be sending.

Is there somebody out there having the software capabilities to merge the two projects (rfcat/MaxCube interface).

I would be interested in your thoughts and comments...

atlas0fd00m commented 5 years ago

hey @AsFaBw , thank you for your kind words! we love RfCat as well, and welcome contributions for porting it to other hardware.

sadly, the cheaper boards i've seen that RfCat works on already seem to be discontinued (Ciseco URF/SRF USB dongles featuring the CC1111).

porting RfCat to other boards with CC1101 radios is possible, but non-trivial. the base RfCat firmware is centered around the 8051 microcontroller in the CC1111. the CC1111 wraps together the CC1101 radio core along with a 8051 microcontroller core and a USB controller. the CC1101 is just the radio, and relies on any number of other microcontrollers and a SPI interface to control the radio. this means a custom firmware for whatever other microcontroller core and USB stack is necessary to be written, basically from scratch. if that's part of the fun for you, awesome! the command and control interface is not that difficult to implement, assuming the USB stack doesn't limit you in some important way. to that end, writing USB firmware is a daunting task, and getting everything correct on even one platform is a new dimension in firmware implementation. i learned a lot, but don't currently have the kind of time it takes to port to another platform.

hope this helps, and keep hacking! @

AsFaBw commented 5 years ago

Hi atlas0fd00m,

thanks a lot for the fast feedback and kind of warning. I had a look to the code and recognize what you mean. To get it stable seems for me not like a weekend task😊

I made my first experiences with a CC1101 standalone and also with a CC430 in a chronos watch (https://www.youtube.com/watch?v=k_Fw7ZacG9s / https://www.youtube.com/watch?v=jKvlf8iOvZk )… …but those projects are small against the code size of rfcat… …so I have some respect to go for it😊

It is really a pitty that all the cheap solutions are not available on the market any more.

Best regards & thanks again, Thomas

FFY00 commented 5 years ago

@atlas0fd00m do you have any documentation related to the actual RfCat (host) <-> MCU (device) transport packets? It doesn't seem that hard to implement such a communication stack in a cheap microcontroller, I was thinking Atmel or STMicro ones. That would make it easily portable between devices since it can make use of the Arduino platform and/or the STM32 ecosystem. TBH I am more inclined to the STM32 platform as it has more processing power, is more extensible and has proper debug support (SWD and JTAG w/ OpenOCD). Either way, even that would be easily ported to Arduino.

atlas0fd00m commented 5 years ago

no docs aside from the code. on the Python side, you can find the details in rflib/chipcon_usb.py, particularly in send() and runEP5_recv().

it's a super simple protocol. the idea is to provide a little C2 inside the target hardware. we started off with memory peek and poke capabilities, and built from there.

the protocol is at it's foundation unidirectional, where the dongle can originate messages to the Python side and obviously the Python client can originate messages to the dongle. to achieve this, the Python client polls the dongle repeatedly (direct USB EP5 access). however... if the Python client originates communication, it almost always expects a response (see code on both sides to see what i mean)

there is one minor difference between Python-originated and dongle-originated messages.
each dongle-originated message starts with a "@" character so that both sides can resync if something gets out of sync. (the Python code chops off and throws away anything up to the next @ symbol in this case).

however, the protocol from there is basically the same in both directions, as indicated by the Python handler code: msg = "%c%c%s%s"%(app,cmd, struct.pack("<H",len(buf)),buf)

1 byte "application" (typically this is used to separate "system" functions from RfCat or other custom apps 1 bytes "command" (some refer to this as the "verb") 2 bytes (LSB) - length of data N bytes - data

on the dongle-side, received messages are handled in the next main loop iteration, based on the app/cmd combo, and a response sent back.

on the Python-side, received messages deposited into an appropriate "mailbox" until accessed. if the message is a response, chances are good the originating code is waiting for the response so it's handled immediately. alternately, in the case of a the SYSTEM app, debug messages and the like are handled before being pushed into the mailbox system.

does this help? i understand that the raw USB nature of RfCat might cause some difficulties. the purpose of RfCat's initial stack was to implement the full USB stack in one file, without licensing cost/constraint. if you end up with a chip you need to modify that approach, we could potentially create a module for accessing your dongle in a slightly different way.

AsFaBw commented 5 years ago

Thanks a lot for the detailed explanation!!!

You mentioned the cheaper Ciseco SRF sticks. I finally found them to be on final sale on: https://www.watterott.com/de/SRF-Module-cased-URF https://www.watterott.com/de/URF-Module-uncased In contrast to the description they came as expected with a CC1111 instead of the claimed CC1110. So might be a choice for others. Further option, that was not clear to me and may be to some others. The Yardstick One GitHub includes the gerber files for PCB production...

AsFaBw commented 5 years ago

May be also not cheap solution if no motherboard is available yet... ...but could also be an interesting neighbor... https://github.com/greatscottgadgets/greatfet/wiki/Neighbors