Sensor board with booster and supervisor
-
@Anticimex: actually I am not very familiar with the license system. I have not taken the time to look at the differences. osh or cc-by-nc-sa??? I need to check what it involves. so for the moment I just paste osh logo to tell it is open source. What aspects don't you like about CERN for example?
@scalz Well, it is a bit cumbersome since it require quite a few documents to be included with the product in question. And it stipulates that this documentation should be copied and maintained by anyone basing their work on said product (so I could go after you if I was a evil bastard ;) ) and for the record, I won't. Because I release my work freely, but I still think it is nice to have some formal document to govern the rights of the authour even if there is no money involved.
But I have not found any other license that makes this easier, and since I already ave inncluded the necessary documentation structure to my git, I don't have to worry about anything else than the changelog from now on, so I will probably stick with it. -
@Anticimex: ahahah! ok. What you are saying about CERN and its documentation is exactly what I don't like!!! I do this freely too, so I don't care about all this stuff but if it is needed I do it. and I am very glad each time to say who inspired me.
so you think I should stick to CERN? :smiley:
But I agree that copyright, licensing needs some rules for respect to the author. I helped my dad few years ago to get a patent. So I understand the problematic.
I think lots of innovation today are often improvement and mix of others existing good things. and then a patent.. -
@Anticimex: ahahah! ok. What you are saying about CERN and its documentation is exactly what I don't like!!! I do this freely too, so I don't care about all this stuff but if it is needed I do it. and I am very glad each time to say who inspired me.
so you think I should stick to CERN? :smiley:
But I agree that copyright, licensing needs some rules for respect to the author. I helped my dad few years ago to get a patent. So I understand the problematic.
I think lots of innovation today are often improvement and mix of others existing good things. and then a patent..@scalz I think my personal stand on this is that I will stick to CERN OHL myself. I do not require anyone to keep CERN OHL even if they copy parts of my work even if the OHL require it (my design, I make my own rules on what I enforce, nobody else will do it for me anyway :) ).
I just think it is good to have some form of "common" license platform that anyone can use or read that formally grants permissions. I am more interested in the "rights" than the "requierds". To me, the license shows everyone that I am formally granting free use of the design. I will of course not discourage anyone from following the formal CERN OHL rules for copying OHL licensed work, but I won't hunt anyone for it. A simple reference to my board in a changelog or similar is plenty! If you worry about the licence, I can also supply a GPG signed statement you could add to a commit where I relieve the licence requirement in case you want to get rid of the CERN stuff "legally". I am not sure it is "legal" for me to do it, but since it is my design in question, I feel I have the right to do any permission I want. And the signature would tell anyone that it really was me giving the permission. But I cannot see why anybody would really care. -
@Anticimex: no problem. I totally agree with you and I am happy that we share same vision.
and here it is my temp schematics https://github.com/scalz/MySensors-HW/blob/development/MyTinyCamel/schematics.pdf
capa near mysx vcc and vccio is needed, isn't it?? My vbat measurement is slightly different as I was a little afraid about draining power to gnd...
As you can see my board is more dedicated to be a pure lowpower sensor node. but there are still some options from you. -
and I think this board will really fit well in my future flower power like! with a small daughter board for my homemade ec salinity/humdity sensor.
-
@Anticimex: no problem. I totally agree with you and I am happy that we share same vision.
and here it is my temp schematics https://github.com/scalz/MySensors-HW/blob/development/MyTinyCamel/schematics.pdf
capa near mysx vcc and vccio is needed, isn't it?? My vbat measurement is slightly different as I was a little afraid about draining power to gnd...
As you can see my board is more dedicated to be a pure lowpower sensor node. but there are still some options from you.@scalz Looks good, and yes, my board is more a generic approach with some power saving features, but I have not gone all in. For instance I elected to skip controlling radio power since it also require re-initialization of the radio, and the savings then depend on the usecase. But for sure, to make it ultra low power, that would be a nice feature to have as well as an option. Unfortunately, I am out of IO for a Arduio Pro Mino "host".
There is no formal requirement for decouplers on the rails to MYSX. I put them there just for insurance as it might simplify daughterboard design. By the way, I did notice a typo in the MYSC spec. It says that it is recommended to support 24V on Vraw but the core team has agreed that 12V is more reasonable. So the spec will be updated to 12V. -
@Anticimex: I am happy to hear this. Yes I know for 24v but I was thinking 16v was good for my case. I will see for those capa, if I have enough space. can't be bad. thx for all your advice :smiley:
The only thing which I don't like so much is there is not so much prog space. Maybe I will see in a near future to get some atsam3s1a. but not now, I have enough projects to finish!
-
so far so good. I have no drc error on any layer. I am still searching for bad looking trace. but I think it will be ok for me :satisfied: I have made minor changes to my schematics too (some capa for dc booster...).
I will certainly send it this week. I need to email dirty and elecrow to see if they are ok if I put 2 boards (4layer) on 5x5 pcb and cut them myself. I am not sure for dirty... I think I will take DHL or EMS! can't wait! Yes I know it's bad :smiley: I have printed pcb on paper to see, and it is very small. cool!I have made a small doc too. Much more cool with an overview. Here it is:
I will put my design files on my git in 2-3 days. I think it will need a small child board now :wink:
-
Hi,
boards ordered. bom and source files updated on my git : https://github.com/scalz/MySensors-HW/tree/development/MyTinyCamel
It is experimental. so for the moment please wait before try, so I can test it and will tell you when all will be ok. during this month I will know more. but if you want to pick ideas or some part of schem. I am glad if it can help you. It still needs a little more docs and to clean my first post...See you soon :smile:
-
Mounting screws use a lot more space than you might think on these small boards. Several of the solder pads look like they may be too close to the holes because the screw head will contact them. Here's a link with all the details.
-
Very impressive! Particularly that BOM! A lot of money to save by avoiding Mouser in favor of AliExpress. And you didn't even factor in VAT? (at least in Sweden I've never paid VAT on anything from Ebay/Ali, the post office is probably swamped by these packages, which is probably the biggest selling point)
Overall, I'd like to say this is probably the best MySensors board to date. Of course, I'm partial since I like boost regulators, but still. Where can you go from here ... the only thing really is making everything even smaller, perhaps two mounting holes will be enough, and move to 0603 or beyond, QFN for the 328p etc. If it is worth the effort. The board is still pretty small as it is and should be hand solderable for most at this point.
Particularly like the way you've included both the RFM and NRF, and that you've used the the "SMD" version of the NRF. That old module was a real waste of space.
-
I did not even know of a SMD variant of NRF24! That is a nice touch. If you ever consider using KiCad, you are welcome to contribute new footprints to the MySensors repositories :)
Also, looking good with the license there :+1: I have thought about the hassle with the changelog maintenance it requires, and I think it should be good enough to keep it up to date with releases of the board. That is, not for every single git commit. So that would not mean too much work thankfully. -
@scalz Looks good, and yes, my board is more a generic approach with some power saving features, but I have not gone all in. For instance I elected to skip controlling radio power since it also require re-initialization of the radio, and the savings then depend on the usecase. But for sure, to make it ultra low power, that would be a nice feature to have as well as an option. Unfortunately, I am out of IO for a Arduio Pro Mino "host".
There is no formal requirement for decouplers on the rails to MYSX. I put them there just for insurance as it might simplify daughterboard design. By the way, I did notice a typo in the MYSC spec. It says that it is recommended to support 24V on Vraw but the core team has agreed that 12V is more reasonable. So the spec will be updated to 12V.@Anticimex said:
By the way, I did notice a typo in the MYSC spec. It says that it is recommended to support 24V on Vraw but the core team has agreed that 12V is more reasonable. So the spec will be updated to 12V.
A nominal 12v power input is good, but it would be nice to have some slack, like accepting up to 14v. Some inexpensive 12v sources can put out higher than 12.0v (even over 13V) when lightly loaded; likewise a fully charged lead acid battery. If the caps and regulator of a power user are spec'd to at least 14v, we can relax about these.
However a source should aim for 12v, not for the upper limit of acceptance (eg: 14v).
-
@Anticimex said:
By the way, I did notice a typo in the MYSC spec. It says that it is recommended to support 24V on Vraw but the core team has agreed that 12V is more reasonable. So the spec will be updated to 12V.
A nominal 12v power input is good, but it would be nice to have some slack, like accepting up to 14v. Some inexpensive 12v sources can put out higher than 12.0v (even over 13V) when lightly loaded; likewise a fully charged lead acid battery. If the caps and regulator of a power user are spec'd to at least 14v, we can relax about these.
However a source should aim for 12v, not for the upper limit of acceptance (eg: 14v).
@Zeph Right, but that should be covered by the component used. Most specs specify a absolute maximum and a nominal value. It is assumed that the designer is using the nominal values in every case, and never the absolute maximum, so if the spec says 12V most components probably have an absolute maximum that exceed that.
-
Small suggestion - mark pin 1 with a square pad in the next revision.
Also, are the battery terminals close to but not quite 0.1" from the MySX connector? Being clearly separate (like 0.15") could help avoid misplacement of a connector in some case.
Overall, tho, pretty cool!
-
By the way, do you think this could handle both a RFM69 and a nRF24L01+, or would they interfere too much with each other being so close (ie: choose one)? (Even tho the RF per se is on different bands).
-
You are fast responding tonight - I was just noticing that D10 is used for select for both radios and was about to edit or withdraw my question!
I'm still curious whether it could have worked (with different chip selects), but that's an unusual use case so probably nobody else cares.
