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 > _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
