Message-ID: <108baf56-d8a2-1b8f-0e0f-72c0605a051e@smarthome-wolf.de>
Date:   Fri, 22 Jun 2018 10:02:46 +0200
From:   Marcus Wolf <marcus.wolf@...rthome-wolf.de>
To:     Hugo Lefeuvre <hle@....eu.com>,
        Marcus Wolf <linux@...f-entwicklungen.de>
Cc:     devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: pi433: initialization of tx config in pi433_open()

Hi Hugo,

thank you for all your work on Pi433 driver.

For a better understanding some info about Pi433 and the ideas behind it.
Pi433 was developed by me in order to have a simple to mount
CE-compliant 433MHz shield for the Raspberry Pi. I wanted to put it on
sale on the one side and develop a further product for home automation,
using the Pi433.

After three years of development and hard trying to find sales partner,
I almost gave up, since after three years still earn on those topics by
far do not cover the spendings. If nothing changes, I'll have to close
my company at the end of this year.

At a distinct point, the work on trying to sell exceeded the technical
work, so no time was left for the driver development. And now I started
over in freelancing to earn money. That's why all of you nearly hear
nothing from me - very sad about that!

Back to technics:
There was already the idea of equipping the driver with default values.
I see no benefit with setting the default values from the data sheet,
since they do not lead to a good, maybe even not working setup of the
rf69. Idea was to choose settings, that allow to use pipeoperators on
the command sehll for transmitting and receiving telegrams. There was a
longer discussion about one year ago with Marcin Ciupak about that topic.
Most important point from my side was, that the defaults should be in a
way, that CE recommandations are meat. You can find a lot of
configurations, making Pi433 work in a way, that it isn't CE-compliant
any more.
The 4711 sound like just beeing a place holder.
Since - like I told before - I inteded to use Pi433 mainly for OOK/ASK,
my idea was to use an good OOK/ASK setup as default. I could provide you
with a source code, I used the Pi433 with - but I think attachments are
unwanted here.

As far as I can remember, there were some more details to modify on the
driver, to use it with pipes on command line. But I had a rough
implementation. At least send was working... To long ago to remeber :-(


Since it might happen, that Pi433 will go off the market in a few
monthes (tears in my eyes), I think it's a good idea to modify the
driver to become a generic hope-RF driver.
I already did investigations on different hope-RF chips and asked
hope-RF for a little support (e.g. partnership), but they were of
opinion, that they don't need such a driver. It would be easy to cover
up to five/six chips of them - even their brand new LoRaWan-chip. RFM-12
will be a little bit harder, since it works a little bit different.
There were already preparations to support several chips - e. g. by
capsulating the HW layer. But even hard discussions one year ago didn't
help - according to kernel guide lines, it wasn't allowed to keep this
capsulations. So the strict capsulation was broken and some of the
basics for supporting more chips are lost now.
Also on this topic I had several discussions with Marcin Ciupak, how to
realise the support of the next chips.
Maybe you can search the mailing list? If not, I can try to find the
discussions in my inbox.


I would love to help you with these extending topics, but since I am
almost out of money, at the moment there is no margin for complimentary
developments any more :-/

But if you like, I can discuss some stuff with you from time to time.

Thank you so much for your interest in Pi433 and my driver!!

If you need hradware for testing, let me know.

Marcus



Am 22.06.2018 um 04:47 schrieb Hugo Lefeuvre:
> Hi Marcus,
> 
> I'm currently working on the following TODO:
> 
>  966         /* setup instance data*/
>  967         instance->device = device;
>  968         instance->tx_cfg.bit_rate = 4711;
>  969         // TODO: fill instance->tx_cfg;
> 
> If a user calls write() right after open()-ing an instance, the driver
> might try to setup the device with uninitialized garbage. In fact
> nothing really bad will happen because the rf69 interface abstraction
> will filter out wrong values, but this might be a confusing behavior
> for the user.
> 
> What do you think about initializing instance->tx_cfg with the default
> values of the rf69 datasheet[0] ?
> 
> Also, is there a specific reason why you chose 4711 as a default value
> for the bit rate ? I couldn't find it anywhere in the datasheet nor on
> the internet.
> 
> Thanks !
> 
> Regards,
>  Hugo
> 
> [0] http://www.hoperf.com/upload/rf/RFM69CW-V1.1.pdf
> 

Powered by blists - more mailing lists