[OpenTRV-dev] Radio fun!

[Kevin Wood]

A few more ramblings on this application:

The 0.1% duty cycle applies to each single node, not to the entire system,
so adding nodes allows one to increase total duty cycle "occupied".

There is an option of using LBT (listen before talk) to mitigate your
impact to other devices on the channel. My limited reading of the spec.
suggests that this is an alternative to limiting your duty cycle, i.e.
0.1% applies to dumb TX only devices that just fire out packets without
listening first, and you can exceed this by incorporating some
intelligence to avoid collisions.

A network of 150 TRVs is likely to cover a wider geographical area than
the radio range of any given 868 MHz device, so some channel "re-use" is
likely to be possible, and the RF output of the nodes could be "turned
down" to limit range and ensure that this is possible.

Whilst the frequency is no doubt fixed by the FHT8V devices, there's no
reason why you have to communicate between "OpenTRV" nodes using this same
frequency, so different groups of nodes plus controlling node could have
their own frequencies allocated. Duty cycle limit, as far as I can see,
applies to operation on one individual frequency, so more frequencies =
more duty cycle for a given node (or use LBT).

Comms with the FHT8V could occur at lower power since the range presumably
only needs to be a few metres (within the same room)? This would minimise
interference between different FHT8V controllers.

As previously mentioned, higher inter-OpenTRV node data rates are possible
by using a different signalling scheme to that imposed by the FHT8V.

Transmit power level, signalling and frequency are all fairly simple
register settings in the radio module, so could be changed on the fly.
You'd have to schedule operation in other modes around the requirements of
the FHT8V protocol, of course.

I have a friend who has brought a commercial product (temperature
monitoring nodes) to market using zigbee like mesh networking over 868
MHz, and will probably see him this evening, so will pick his brain.

Cheers,

Kevin


> Hi,
>
> In particular the slice that we’re using with the 0.1% max duty cycle...
>  I could try to dig out the Ofcom regs!  (IR2030/1/16?)
>
> Rgds
>
> Damon
>
>
>> On 12 Jul 2015, at 21:08, Kevin Wood <kevin at the-wood-family.com> wrote:
>>
>> Hi Damon,
>>
>> I haven't checked the rules for 868 MHz in case there's anything that
>> would prohibit it. I will see what I can find out.
>>
>> Kevin
>>
>>
>>> OK!
>>>
>>> Is it legal on the frequency that we are using (or one that we can get
>>> to
>>> quickly with a few register changes)?
>>>
>>> Rgds
>>>
>>> Damon
>>>
>>>> On 12 Jul 2015, at 20:59, Kevin Wood <kevin at the-wood-family.com>
>>>> wrote:
>>>>
>>>> Hi All,
>>>>
>>>> I've used the "Jeelib default" mode of FSK signalling at 50kbps around
>>>> the
>>>> house, albeit at 433 MHz, and it's reliable. I haven't been tracking
>>>> missed packets but it's certainly workable over domestic distances.
>>>> So,
>>>> a
>>>> ten fold increase in data rate might be available. Maybe more.
>>>>
>>>> Best Regards
>>>>
>>>> Kevin
>>>>
>>>>> Hi,
>>>>>
>>>>> For a project going in this month based on some of the OpenTRV tech,
>>>>> we
>>>>> have some exciting radio juggling to do, see here:
>>>>>
>>>>> https://sourceforge.net/p/opentrv/code-0/HEAD/tree/trunk/Arduino/COHEAT2015/RadioThoughts20150711.txt
>>>>>
>>>>> All comments, suggestions, etc, welcome.
>>>>>
>>>>> I’m not worried whether we can do it, I’d simply like to
>>>>> maximise
>>>>> reliability and simplicity (and elegance),
>>>>> and minimise my pain coding it up.
>>>>>
>>>>> Oh, and steal the lessons for Launchpad using this as another
>>>>> vertical,
>>>>> eg
>>>>> with denser deployments than typical domestic.
>>>>>
>>>>> Rgds
>>>>>
>>>>> Damon
>>>>> _______________________________________________
>>>>> 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
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> OpenTRV-dev mailing list
> OpenTRV-dev at lists.opentrv.org.uk
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>