[OpenTRV-dev] RadBot Radio Protocol

[christoph at winterstiger.at]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opentrv.org.uk/pipermail/opentrv-dev/attachments/20210219/b051bb40/attachment.html>