<p dir="ltr">If you are short on space then definitely drop it. Your security layer should cover verifying the frame content, if it does not the communication is not secure ;-)</p>
<p dir="ltr">As you have mentioned you are fixed with the AVR plus Hope RF module for now but there are some awesome combination MCU/radio chips coming out, eg the nRF52. Think they quoted sub 10mA when TX/Rx and the sleep power was ridiculously low. All that and a good CPU (ARM Cortex), floating point,  Bluetooth, NFC and loads of other goodies. </p>
<p dir="ltr">Jeremy</p>
<div class="gmail_quote">On 19 Dec 2015 19:14, "Damon Hart-Davis" <<a href="mailto:dhd@exnet.com">dhd@exnet.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Module CRC support is basically completely incompatible across different module types, so we would lock into one module type/family for ever if we used it.  Also it’s just not that hard to do in software.<br>
<br>
We will be able to make use of auto preamble with more use of packet handling with the new protocol.  The packet length that we will be using is about the only portable feature but should help a lot.  Patience, patience!  B^><br>
<br>
Rgds<br>
<br>
Damon<br>
<br>
<br>
> On 19 Dec 2015, at 19:07, Deniz Erbilgin <<a href="mailto:deniz.erbilgin@gmail.com">deniz.erbilgin@gmail.com</a>> wrote:<br>
><br>
> I still find it amusing that we don't use the preamble and crc that are built into the rfm23bs...<br>
><br>
> Regards,<br>
><br>
> Deniz<br>
><br>
> On 19/12/15 19:01, Damon Hart-Davis wrote:<br>
>>> On 19 Dec 2015, at 18:51, Bo Herrmannsen <<a href="mailto:bo.herrmannsen@gmail.com">bo.herrmannsen@gmail.com</a>> wrote:<br>
>>><br>
>>> a spanner in the works....<br>
>>><br>
>>> maybe we are using the wrong AVR? ie maybe we should consider a bigger one?<br>
>> We have the one that we have, and it is typical of smaller devices.  And we aren’t able to change horses now for the valves or for Launchpad.<br>
>><br>
>> We are likely to have to stay low-end to keep costs down for both projects.<br>
>><br>
>> But in any case the issue is more to do with a combination of common radio module behaviour and interrupt latency; an otherwise more powerful MCU could even be worse.<br>
>><br>
>> Rgds<br>
>><br>
>> Damon<br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenTRV-dev mailing list<br>
>> <a href="mailto:OpenTRV-dev@lists.opentrv.org.uk">OpenTRV-dev@lists.opentrv.org.uk</a><br>
>> <a href="http://lists.opentrv.org.uk/listinfo/opentrv-dev" rel="noreferrer" target="_blank">http://lists.opentrv.org.uk/listinfo/opentrv-dev</a><br>
><br>
> _______________________________________________<br>
> OpenTRV-dev mailing list<br>
> <a href="mailto:OpenTRV-dev@lists.opentrv.org.uk">OpenTRV-dev@lists.opentrv.org.uk</a><br>
> <a href="http://lists.opentrv.org.uk/listinfo/opentrv-dev" rel="noreferrer" target="_blank">http://lists.opentrv.org.uk/listinfo/opentrv-dev</a><br>
<br>
_______________________________________________<br>
OpenTRV-dev mailing list<br>
<a href="mailto:OpenTRV-dev@lists.opentrv.org.uk">OpenTRV-dev@lists.opentrv.org.uk</a><br>
<a href="http://lists.opentrv.org.uk/listinfo/opentrv-dev" rel="noreferrer" target="_blank">http://lists.opentrv.org.uk/listinfo/opentrv-dev</a><br>
</blockquote></div>