[OpenTRV-dev] RadBot Radio Protocol

[Deniz Erbilgin]

This page may also be helpful - I wrote it up while getting the zetaRF to
talk on our channel
https://github.com/opentrv/OTWiki/wiki/Si4455-comms-using-the-OT-GFSK57600-channel

FWIW, this is the radio config for the RFM23B
https://github.com/opentrv/OTRadioLink/blob/c790b743c692b14889dda930c4b8fe49f035c76f/content/OTRadioLink/utility/OTRFM23BLink_OTRFM23BLink.cpp#L710

On Fri, 19 Feb 2021 at 12:51, <christoph at winterstiger.at> wrote:

> Hi Rob,
>
>
>
> Feel free to ask me questions if something’s unclear. In personal projects
> my code is often a bit experimental in style 😊
>
>
>
> To be honest, it took me a fair amount of time to find a working
> configuration (and the one I have for the RFM69 still isn’t working quite
> as well as it should). There is a lot of code in the OpenTRV repos, which I
> got a rough idea from, then combined that with an RTL-SDR to get a
> frequency spectrum plot during transmission to get the frequencies and
> deviation, then some messages from the mailing lists and Wikis to get the
> frame format right. And Damon also answered a few questions I had (e.g. Radbot
> Radio · Issue #2 · opentrv/OTWiki (github.com)
> <https://github.com/opentrv/OTWiki/issues/2>). The most annoying part was
> that I had to wait for 2 minutes between transmissions though!
>
>
>
> In the CC1101 config, you can ignore most of the settings; there’s plenty
> of stuff that applies only to transmission (which I also play with
> sometimes) and unused features like address-filtering. The crucial bits
> are, I think, the DEVIATN, FREQ*, MDMCFG*, and PKTCTRL* registers. Those
> settings also translate easily to other devices, while some others do not,
> e.g. the automatic gain control settings. Initially, my plan was to add
> more information about the registers in the register table definitions
> (e.g. cc1101_rt.h) so it can be displayed and changed easily in the monitor
> application, but I didn’t quite get there yet.
>
>
>
> Cheers,
>
> Christoph
>
>
>
> *From:* OpenTRV-dev <opentrv-dev-bounces at lists.opentrv.org.uk> *On Behalf
> Of *Robert May
> *Sent:* 19 February 2021 12:22
> *To:* Closed list for developer discussions <
> opentrv-dev at lists.opentrv.org.uk>
> *Subject:* Re: [OpenTRV-dev] RadBot Radio Protocol
>
>
>
> Thanks Christophe - I'm currently reverse engineering your CC1101
> configuration (BTW I have your code working and decrypting a single value),
> but would like to have a deeper understanding rather than blindly copying
> ....
>
>
>
> Could you point me at the version of the radio code that you used to
> generate your configuration, even if it's difficult to follow?
>
> Thanks,
>
> Rob.
>
>
>
>
>
> On Fri, 19 Feb 2021 at 11:49, <christoph at winterstiger.at> wrote:
>
> Yes, those parameters are wrong, but the frame format is correct, I think.
> It took me quite a while to figure out the right radio parameters the first
> time around because the code isn’t easy to read either (seems to support
> multiple old/different formats).
>
>
>
> Damon: I think it would be great if we could set up a Wiki page with clear
> and up-to-date information. Possibly even a specific page just for the
> Radbot (2) as it’s being sold? I’m sure all of the information is
> somewhere, it’s just very hard to find it.
>
>
>
> Cheers,
>
> Christoph
>
>
>
> *From:* OpenTRV-dev <opentrv-dev-bounces at lists.opentrv.org.uk> *On Behalf
> Of *Robert May
> *Sent:* 19 February 2021 11:26
> *To:* Closed list for developer discussions <
> opentrv-dev at lists.opentrv.org.uk>
> *Subject:* [OpenTRV-dev] RadBot Radio Protocol
>
>
>
> I found this
> https://github.com/opentrv/OpenTRV-standards/blob/master/standards/protocol/IoTCommsFrameFormat/SecureBasicFrame-V0.1-201601.txt
>
> But don't think that this paragraph
>
> *868.35MHz 5kbps OOK "FS20" carrier, unwhitened, no hardware CRC/checksum,
>  with a preamble of aaaaaaaa and sync of cccccc. In this case the payloads
> should avoid long runs of 0x00 or 0xff bytes, and there should be no more
> than one trailing 0x00 (more may be stripped), ie should be somewhat
> self-whitened. Note however that the leading length byte may make for
> tricky interop with existing FS20-carrier OpenTRV comms.*
>
>
>
> reflects the current Radbot Radio parameters.  Is there another document
> I'm missing, or do I need to dig into the code and reverse engineer from
> the transmitter setup?
>
>
>
> Thanks for any pointers,
>
> Rob.
>
> _______________________________________________
> OpenTRV-dev mailing list
> OpenTRV-dev at lists.opentrv.org.uk
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>
> _______________________________________________
> OpenTRV-dev mailing list
> OpenTRV-dev at lists.opentrv.org.uk
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opentrv.org.uk/pipermail/opentrv-dev/attachments/20210220/e9e0f18f/attachment.html>