[OpenTRV-dev] V0.2-Arduino: getting started

Mike Stirling EMAIL ADDRESS HIDDEN
Tue Apr 2 14:42:13 BST 2013


 
 
----------------original message-----------------
From: "Kevin Wood" EMAIL ADDRESS HIDDEN 
To: "Closed list for developer discussions" EMAIL ADDRESS HIDDEN 
Date: Tue, 2 Apr 2013 14:05:51 +0100 (BST)
-------------------------------------------------
 
 
>> On 01/04/13 18:03, Kevin Wood wrote:
>>>>> Some details about the EOL of some RFM products here
>>>>>
>>>>> http://blog.homelabs.org.uk/rfm12b-end-of-life/
>>>>>
>>> The RFM69W module they tout as a replacement looks interesting.
>>> Encryption, packet engine and "data whitening" all supported. No
>>> indication of price or how long that'll be supported, though.
>>>
>>> Kevin
>>>
>>> _______________________________________________
>>>
>> It appears to be based on the Semtech SX1231, which is several years
>> old. The encryption would certainly be a nice addition. Digikey price
>> for the chip is $1.75 in 3000 off so that's quite promising for the
>> module being cheap. Haven't found any European (or in fact any) disties
>> for it yet though.
>>
>> Stuart: What was your source for the demise of the other modules?
>>
>> Mike
>>
> 
> Playing devil's advocate, though, rich functionality in the RF module can
> be an Achilles’ heel if security of supply is an issue, leaving us with a
> lot of work to do if it goes EOL at an awkward time. I guess that prompts
> one to wonder if implementing key features like encryption and 100% of the
> protocol inside the CPU and using a dumb RF module might be a better
> strategy? More expensive in code size and, probably, power consumption,
> but with the ability to substitute a different RF module easily?
> 
> Kevin
> 

That would be my preferred approach. I have been thinking about RF protocol development and want to come up with something that could be implemented on a variety of TRXs, using their hardware packet engines where possible. There is reasonable scope for getting devices from different vendors to interoperate on sync and address detection, which is where a lot of the power advantage of a hardware packet engine would be obtained. CRC calculation is a bit more hit and miss, e.g. TI and SiLabs devices both support at least one polynomial in common but they use different start values.

Mike



-- 

 



More information about the OpenTRV-dev mailing list