Most reliable "best" radio
-
@NeverDie said in Most reliable "best" radio:
It does already have 100n (=0.1uF) across the DC power line, extremely near the inputs to the nRF24L01
Add a 10uF cap there. I found these radios are more stable with enough power to draw on during transmission.
@alphaHotel said in Most reliable "best" radio:
@NeverDie said in Most reliable "best" radio:
It does already have 100n (=0.1uF) across the DC power line, extremely near the inputs to the nRF24L01
Add a 10uF cap there. I found these radios are more stable with enough power to draw on during transmission.
Yup, already got a 10uF cap on it on the adapter board posted to openhardware.io: https://www.openhardware.io/view/22656/nRF24L01-adapter-board
-
@skywatch said in Most reliable "best" radio:
@skywatch said in Most reliable "best" radio:
Thanks. What was it you were wanting me to notice about the e32 library? If it was about the FHSS, that was an e34 module in the youtube video.Oh darn it! - I got it mixed up - I am sorry for posting the wrong lib!
At about 3:12 in the video, he references the Lora E32 and says the pinout is the same and that "the software is compatible". I don't know if he means the library, the code (the module does the frequency hopping) or the Ebyte software for configuring the modules but it would be good to know more about it.
@alphaHotel said in Most reliable "best" radio:
@skywatch said in Most reliable "best" radio:
@skywatch said in Most reliable "best" radio:
Thanks. What was it you were wanting me to notice about the e32 library? If it was about the FHSS, that was an e34 module in the youtube video.Oh darn it! - I got it mixed up - I am sorry for posting the wrong lib!
At about 3:12 in the video, he references the Lora E32 and says the pinout is the same and that "the software is compatible". I don't know if he means the library, the code (the module does the frequency hopping) or the Ebyte software for configuring the modules but it would be good to know more about it.
I think what he's saying there is that since the FHSS E34 has a built-in mcu and is operated using AT commands over UART, the comparable UART E32 module uses the same AT commands--which is about the only way I can imagine an E34 could be drop-in compatible as a replacement for the E32. These particular types of modules are advertised and sold as "wireless UARTs", and so the underlying technology is more or less transparent to that kind of solution.
-
@NeverDie said in Most reliable "best" radio:
As a result, I just now ordered some of these E01-2G4M27D
Please let us know if they arrive with or without antennas. I've been eyeing them recently but haven't pulled the trigger yet.
@alphaHotel said in Most reliable "best" radio:
E01-2G4M27D
I'm fairly certain the ones I ordered won't be arriving with antennas (as none were pictured in the aliexpress posting), but, no problem, I'll let you know for sure after they arrive. Most likely if you have an old wi-fi router that you no longer use, you could probably unscrew those antennas and use them, since they'd also be 2.4Ghz.
-
@alphaHotel said in Most reliable "best" radio:
@skywatch said in Most reliable "best" radio:
@skywatch said in Most reliable "best" radio:
Thanks. What was it you were wanting me to notice about the e32 library? If it was about the FHSS, that was an e34 module in the youtube video.Oh darn it! - I got it mixed up - I am sorry for posting the wrong lib!
At about 3:12 in the video, he references the Lora E32 and says the pinout is the same and that "the software is compatible". I don't know if he means the library, the code (the module does the frequency hopping) or the Ebyte software for configuring the modules but it would be good to know more about it.
I think what he's saying there is that since the FHSS E34 has a built-in mcu and is operated using AT commands over UART, the comparable UART E32 module uses the same AT commands--which is about the only way I can imagine an E34 could be drop-in compatible as a replacement for the E32. These particular types of modules are advertised and sold as "wireless UARTs", and so the underlying technology is more or less transparent to that kind of solution.
I think what he's saying there is that since the FHSS E34 has a built-in mcu and is operated using AT commands over UART, the comparable UART E32 module uses the same AT commands--which is about the only way I can imagine an E34 could be drop-in compatible as a replacement for the E32. These particular types of modules are advertised and sold as "wireless UARTs", and so the underlying technology is more or less transparent to that kind of solution.
Thanks for that explanation. It makes more sense now.
Yup, already got a 10uF cap on it on the adapter board posted to openhardware.io: https://www.openhardware.io/view/22656/nRF24L01-adapter-board
I saw that picture after I posted and smacked my head, of course, you did. On a related note, would it be possible to get the Kicad files for the nRF24L01 adapter board? I'd like to take a stab at building a couple of these but I want to put most of the face-down silkscreen on the face-up side too.
-
I think what he's saying there is that since the FHSS E34 has a built-in mcu and is operated using AT commands over UART, the comparable UART E32 module uses the same AT commands--which is about the only way I can imagine an E34 could be drop-in compatible as a replacement for the E32. These particular types of modules are advertised and sold as "wireless UARTs", and so the underlying technology is more or less transparent to that kind of solution.
Thanks for that explanation. It makes more sense now.
Yup, already got a 10uF cap on it on the adapter board posted to openhardware.io: https://www.openhardware.io/view/22656/nRF24L01-adapter-board
I saw that picture after I posted and smacked my head, of course, you did. On a related note, would it be possible to get the Kicad files for the nRF24L01 adapter board? I'd like to take a stab at building a couple of these but I want to put most of the face-down silkscreen on the face-up side too.
@alphaHotel said in Most reliable "best" radio:
I think what he's saying there is that since the FHSS E34 has a built-in mcu and is operated using AT commands over UART, the comparable UART E32 module uses the same AT commands--which is about the only way I can imagine an E34 could be drop-in compatible as a replacement for the E32. These particular types of modules are advertised and sold as "wireless UARTs", and so the underlying technology is more or less transparent to that kind of solution.
Thanks for that explanation. It makes more sense now.
Yup, already got a 10uF cap on it on the adapter board posted to openhardware.io: https://www.openhardware.io/view/22656/nRF24L01-adapter-board
I saw that picture after I posted and smacked my head, of course, you did. On a related note, would it be possible to get the Kicad files for the nRF24L01 adapter board? I'd like to take a stab at building a couple of these but I want to put most of the face-down silkscreen on the face-up side too.
Sure thing. I'm in the middle of something else at the moment, but I can post it later tonight.
-
I think what he's saying there is that since the FHSS E34 has a built-in mcu and is operated using AT commands over UART, the comparable UART E32 module uses the same AT commands--which is about the only way I can imagine an E34 could be drop-in compatible as a replacement for the E32. These particular types of modules are advertised and sold as "wireless UARTs", and so the underlying technology is more or less transparent to that kind of solution.
Thanks for that explanation. It makes more sense now.
Yup, already got a 10uF cap on it on the adapter board posted to openhardware.io: https://www.openhardware.io/view/22656/nRF24L01-adapter-board
I saw that picture after I posted and smacked my head, of course, you did. On a related note, would it be possible to get the Kicad files for the nRF24L01 adapter board? I'd like to take a stab at building a couple of these but I want to put most of the face-down silkscreen on the face-up side too.
@alphaHotel said in Most reliable "best" radio:
On a related note, would it be possible to get the Kicad files for the nRF24L01 adapter board?
Done. Posted the .rar file to the project files. Let me know if you have any difficulty with it.
There was an error in the original: it didn't identify the IRQ pin on the backside silkscreen. I fixed that on the next (experimental) version (which is also wider), which I haven't yet received from the fab. However, the silkscreen images are here:
Hope that helps!
P.S. In case you're wondering, the possible next version has not only pluggable radios (as the original version had), but also pluggable MCU's, to make it easier to try different MCU's. I'm not sure yet whether or not it's a good idea, but since it's not rocket surgery I figure it is just easier to try the idea out than to overthink it.
-
@alphaHotel said in Most reliable "best" radio:
On a related note, would it be possible to get the Kicad files for the nRF24L01 adapter board?
Done. Posted the .rar file to the project files. Let me know if you have any difficulty with it.
There was an error in the original: it didn't identify the IRQ pin on the backside silkscreen. I fixed that on the next (experimental) version (which is also wider), which I haven't yet received from the fab. However, the silkscreen images are here:
Hope that helps!
P.S. In case you're wondering, the possible next version has not only pluggable radios (as the original version had), but also pluggable MCU's, to make it easier to try different MCU's. I'm not sure yet whether or not it's a good idea, but since it's not rocket surgery I figure it is just easier to try the idea out than to overthink it.
@alphaHotel Thanks for asking for the program files. I was too shy.
@NeverDie You do fine work! Thanks for the NRF24 updates to openhardware.io.
Today I placed a bundle of orders for your boards and one of mine (RFM69HCW) at OSH Park. I wanted to send you the RFM69HCW board on this forum. But, I just learned that I can't send a zip, nor sch, nor board files through MySensors. That is very smart and prudent of them. I'll do as you do and am sending the jpg files that I derived from KiCAD. You will notice my plagerism of your broad power traces and narrow signal lines. So very fine. Let me know if there is a way to share the files with you, if you are interested. I'm not ready for an openhardware.io account just yet.
-
@Larson said in Most reliable "best" radio:
@NeverDie said in Most reliable "best" radio:
It looks way cool.
Having a bit more time I watched the entire Dave Jones teardown. Very stunning review. I was feeling quite fancy after my KiCAD design but this 2015 video reminds me who I am. I am Fred Flinstone. only with Youtube. And happy enough with that!
Why go half-way? Let's light up some Winston's while we're at it. ;-) Yabba Dabba Doo!
-
@alphaHotel Thanks for asking for the program files. I was too shy.
@NeverDie You do fine work! Thanks for the NRF24 updates to openhardware.io.
Today I placed a bundle of orders for your boards and one of mine (RFM69HCW) at OSH Park. I wanted to send you the RFM69HCW board on this forum. But, I just learned that I can't send a zip, nor sch, nor board files through MySensors. That is very smart and prudent of them. I'll do as you do and am sending the jpg files that I derived from KiCAD. You will notice my plagerism of your broad power traces and narrow signal lines. So very fine. Let me know if there is a way to share the files with you, if you are interested. I'm not ready for an openhardware.io account just yet.
@Larson Congrats on finishing your first KiCAD PCB. Once you're over that hump, it just keeps getting easier.
I don't think there's any harm to posting to openhardware.io. It's' pretty well designed so that people who just want to buy stuff can look at finished projects and not be bothered by work in progress. To the extent you can eventually finish a project, then it helps mysensors. As for me, I think I'm pretty much done with RFM69, but maybe someone else would be interested.
-
This is what I came up with for a platform that has both pluggable MCU's and pluggable radios:
It's a bit wider than the previous test platform to give enough space between both the two AA batteries themselves and between those batteries and the pin headers. It also has a separate row of pins along the outside in case you want to have any shields that go on top. I did away with the switch entirely. Now if you want to power it off, you just remove a battery. So, doing all that renders the backplane/power-source very simple. Also, I included two mounting holes so that the whole thing can be mounted inside a project box. Yesterday I ordered this PCB along with a pluggable atmega328p MCU board and a pluggable radio board from a fab, so nothing physical to show-and-tell just yet.
-
@alphaHotel said in Most reliable "best" radio:
On a related note, would it be possible to get the Kicad files for the nRF24L01 adapter board?
Done. Posted the .rar file to the project files. Let me know if you have any difficulty with it.
There was an error in the original: it didn't identify the IRQ pin on the backside silkscreen. I fixed that on the next (experimental) version (which is also wider), which I haven't yet received from the fab. However, the silkscreen images are here:
Hope that helps!
P.S. In case you're wondering, the possible next version has not only pluggable radios (as the original version had), but also pluggable MCU's, to make it easier to try different MCU's. I'm not sure yet whether or not it's a good idea, but since it's not rocket surgery I figure it is just easier to try the idea out than to overthink it.
@NeverDie said in Most reliable "best" radio:
Done. Posted the .rar file to the project files. Let me know if you have any difficulty with it.
Thank you. I didn't have any issues with the files though it did warn that the footprints for the radio modules are in
MyGlobalLibrary, which I don't have. See the screenshot below. If they could be put into a library within the project, it would be more portable than it already is but I was able to work with it as is.
I made a few mods including adding a ground plane and I'll try to get a repo on GitHub up and running for it tonight after work. With a new version in the works, perhaps I'll hold off getting some of these boards fabricated. In the interim, here's a view of my 3D model.
P.S. In case you're wondering, the possible next version has not only pluggable radios (as the original version had), but also pluggable MCU's, to make it easier to try different MCU's. I'm not sure yet whether or not it's a good idea, but since it's not rocket surgery I figure it is just easier to try the idea out than to overthink it.
At one point in this thread, I marvelled at the battery shield and wondered about having it separated from the MCU. Just conditioned power on the first shield then MCU, then radio. The complexity of it though is beyond my current level as I don't have as much experience with alternative MCU's (though I've been thinking we need to start looking at something with more program memory, like the ATmega4808/9). On the other hand, it should be just a matter of defining what needs to be passed from shield to shield (layer to layer?). Power, ground, SPI signals, perhaps I2C signals and a few other GPIO signals. Please do though consider lining up the pins such that they would also fit a breadboard layout.
-
This is what I came up with for a platform that has both pluggable MCU's and pluggable radios:
It's a bit wider than the previous test platform to give enough space between both the two AA batteries themselves and between those batteries and the pin headers. It also has a separate row of pins along the outside in case you want to have any shields that go on top. I did away with the switch entirely. Now if you want to power it off, you just remove a battery. So, doing all that renders the backplane/power-source very simple. Also, I included two mounting holes so that the whole thing can be mounted inside a project box. Yesterday I ordered this PCB along with a pluggable atmega328p MCU board and a pluggable radio board from a fab, so nothing physical to show-and-tell just yet.
-
@NeverDie With the first version of the battery/MCU board, you lamented running traces directly under the batteries. You have the space now to re-route them but choose not to. Did you find a way to resolve the issue it caused?
@alphaHotel said in Most reliable "best" radio:
@NeverDie With the first version of the battery/MCU board, you lamented running traces directly under the batteries. You have the space now to re-route them but choose not to. Did you find a way to resolve the issue it caused?
Actually, I fixed it on the new version (pictured above). The red traces run on top, so they're adequately isolated from the battery holder metal, which is on the back side except for the through-holes where it sticks through the board. Where I ran into trouble was running traces on the back side, beneath the battery holder metal. If the battery holder metal was pressed up hard against the board, some shorts resulted on some of the boards. The workaround was to not press the battery holder metal hard up against the board, but the new version removes that concern entirely.
-
@NeverDie said in Most reliable "best" radio:
Done. Posted the .rar file to the project files. Let me know if you have any difficulty with it.
Thank you. I didn't have any issues with the files though it did warn that the footprints for the radio modules are in
MyGlobalLibrary, which I don't have. See the screenshot below. If they could be put into a library within the project, it would be more portable than it already is but I was able to work with it as is.I made a few mods including adding a ground plane and I'll try to get a repo on GitHub up and running for it tonight after work. With a new version in the works, perhaps I'll hold off getting some of these boards fabricated. In the interim, here's a view of my 3D model.
P.S. In case you're wondering, the possible next version has not only pluggable radios (as the original version had), but also pluggable MCU's, to make it easier to try different MCU's. I'm not sure yet whether or not it's a good idea, but since it's not rocket surgery I figure it is just easier to try the idea out than to overthink it.
At one point in this thread, I marvelled at the battery shield and wondered about having it separated from the MCU. Just conditioned power on the first shield then MCU, then radio. The complexity of it though is beyond my current level as I don't have as much experience with alternative MCU's (though I've been thinking we need to start looking at something with more program memory, like the ATmega4808/9). On the other hand, it should be just a matter of defining what needs to be passed from shield to shield (layer to layer?). Power, ground, SPI signals, perhaps I2C signals and a few other GPIO signals. Please do though consider lining up the pins such that they would also fit a breadboard layout.
@alphaHotel said in Most reliable "best" radio:
On the other hand, it should be just a matter of defining what needs to be passed from shield to shield (layer to layer?). Power, ground, SPI signals, perhaps I2C signals and a few other GPIO signals.
Yup, you got it. That's all there is to it. Power, ground, SPI, chip enable, chip select, maybe RX/TX enable (on some radios), and enough interrupt pins to take advantage of whatever interrupt or DIO pins the radio has to offer up. Looking back on it, I probably should have kept A5 off of the radio module, since that's used by I2C, and used some other pin instead. So... it's still a work in progress, but getting better.
-
@NeverDie said in Most reliable "best" radio:
Done. Posted the .rar file to the project files. Let me know if you have any difficulty with it.
Thank you. I didn't have any issues with the files though it did warn that the footprints for the radio modules are in
MyGlobalLibrary, which I don't have. See the screenshot below. If they could be put into a library within the project, it would be more portable than it already is but I was able to work with it as is.I made a few mods including adding a ground plane and I'll try to get a repo on GitHub up and running for it tonight after work. With a new version in the works, perhaps I'll hold off getting some of these boards fabricated. In the interim, here's a view of my 3D model.
P.S. In case you're wondering, the possible next version has not only pluggable radios (as the original version had), but also pluggable MCU's, to make it easier to try different MCU's. I'm not sure yet whether or not it's a good idea, but since it's not rocket surgery I figure it is just easier to try the idea out than to overthink it.
At one point in this thread, I marvelled at the battery shield and wondered about having it separated from the MCU. Just conditioned power on the first shield then MCU, then radio. The complexity of it though is beyond my current level as I don't have as much experience with alternative MCU's (though I've been thinking we need to start looking at something with more program memory, like the ATmega4808/9). On the other hand, it should be just a matter of defining what needs to be passed from shield to shield (layer to layer?). Power, ground, SPI signals, perhaps I2C signals and a few other GPIO signals. Please do though consider lining up the pins such that they would also fit a breadboard layout.
@alphaHotel said in Most reliable "best" radio:
I didn't have any issues with the files though it did warn that the footprints for the radio modules are in MyGlobalLibrary, which I don't have. See the screenshot below. If they could be put into a library within the project, it would be more portable than it already is but I was able to work with it as is.
Thanks for the feedback. I really would like it to be both portable and standalone, so I'll look into setting up a standalone library to include into the .rar that will make for a better KiCAD 6 project archive.
-
@alphaHotel said in Most reliable "best" radio:
@NeverDie With the first version of the battery/MCU board, you lamented running traces directly under the batteries. You have the space now to re-route them but choose not to. Did you find a way to resolve the issue it caused?
Actually, I fixed it on the new version (pictured above). The red traces run on top, so they're adequately isolated from the battery holder metal, which is on the back side except for the through-holes where it sticks through the board. Where I ran into trouble was running traces on the back side, beneath the battery holder metal. If the battery holder metal was pressed up hard against the board, some shorts resulted on some of the boards. The workaround was to not press the battery holder metal hard up against the board, but the new version removes that concern entirely.
@NeverDie said in Most reliable "best" radio:
@alphaHotel said in Most reliable "best" radio:
@NeverDie With the first version of the battery/MCU board, you lamented running traces directly under the batteries. You have the space now to re-route them but choose not to. Did you find a way to resolve the issue it caused?
Actually, I fixed it on the new version (pictured above). The red traces run on top, so they're adequately isolated from the battery holder metal, which is on the back side except for the through-holes where it sticks through the board. Where I ran into trouble was running traces on the back side, beneath the battery holder metal. If the battery holder metal was pressed up hard against the board, some shorts resulted on some of the boards. The workaround was to not press the battery holder metal hard up against the board, but the new version removes that concern entirely.
Okay, I see now. I misunderstood the original issue and also didn't think about the top/bottom side orientation in relation to those traces vis-a-vis the battery holders. Thanks for clarifying.
-
@NeverDie said in Most reliable "best" radio:
Done. Posted the .rar file to the project files. Let me know if you have any difficulty with it.
Thank you. I didn't have any issues with the files though it did warn that the footprints for the radio modules are in
MyGlobalLibrary, which I don't have. See the screenshot below. If they could be put into a library within the project, it would be more portable than it already is but I was able to work with it as is.I made a few mods including adding a ground plane and I'll try to get a repo on GitHub up and running for it tonight after work. With a new version in the works, perhaps I'll hold off getting some of these boards fabricated. In the interim, here's a view of my 3D model.
P.S. In case you're wondering, the possible next version has not only pluggable radios (as the original version had), but also pluggable MCU's, to make it easier to try different MCU's. I'm not sure yet whether or not it's a good idea, but since it's not rocket surgery I figure it is just easier to try the idea out than to overthink it.
At one point in this thread, I marvelled at the battery shield and wondered about having it separated from the MCU. Just conditioned power on the first shield then MCU, then radio. The complexity of it though is beyond my current level as I don't have as much experience with alternative MCU's (though I've been thinking we need to start looking at something with more program memory, like the ATmega4808/9). On the other hand, it should be just a matter of defining what needs to be passed from shield to shield (layer to layer?). Power, ground, SPI signals, perhaps I2C signals and a few other GPIO signals. Please do though consider lining up the pins such that they would also fit a breadboard layout.
@alphaHotel said in Most reliable "best" radio:
I didn't have any issues with the files though it did warn that the footprints for the radio modules are in MyGlobalLibrary, which I don't have. See the screenshot below. If they could be put into a library within the project, it would be more portable than it already is but I was able to work with it as is.
OK, I updated the project archive to include nRF24L01 symbol and footprint libraries which include those symbols and footprints. Let me know if it works out OK.
Apparently best practice is to put literally every single symbol and footprint that gets used on a project into project-specific libraries so that they can be freely shared. At least for now I just put in the unique nRF24L01 symbols and footprints that aren't part of the generic KiCAD 6 build.
-
@NeverDie said in Most reliable "best" radio:
Done. Posted the .rar file to the project files. Let me know if you have any difficulty with it.
Thank you. I didn't have any issues with the files though it did warn that the footprints for the radio modules are in
MyGlobalLibrary, which I don't have. See the screenshot below. If they could be put into a library within the project, it would be more portable than it already is but I was able to work with it as is.I made a few mods including adding a ground plane and I'll try to get a repo on GitHub up and running for it tonight after work. With a new version in the works, perhaps I'll hold off getting some of these boards fabricated. In the interim, here's a view of my 3D model.
P.S. In case you're wondering, the possible next version has not only pluggable radios (as the original version had), but also pluggable MCU's, to make it easier to try different MCU's. I'm not sure yet whether or not it's a good idea, but since it's not rocket surgery I figure it is just easier to try the idea out than to overthink it.
At one point in this thread, I marvelled at the battery shield and wondered about having it separated from the MCU. Just conditioned power on the first shield then MCU, then radio. The complexity of it though is beyond my current level as I don't have as much experience with alternative MCU's (though I've been thinking we need to start looking at something with more program memory, like the ATmega4808/9). On the other hand, it should be just a matter of defining what needs to be passed from shield to shield (layer to layer?). Power, ground, SPI signals, perhaps I2C signals and a few other GPIO signals. Please do though consider lining up the pins such that they would also fit a breadboard layout.
@alphaHotel said in Most reliable "best" radio:
Please do though consider lining up the pins such that they would also fit a breadboard layout.
Yes, agreed. Unless I made an error, this should already be true.
-
@alphaHotel said in Most reliable "best" radio:
I didn't have any issues with the files though it did warn that the footprints for the radio modules are in MyGlobalLibrary, which I don't have. See the screenshot below. If they could be put into a library within the project, it would be more portable than it already is but I was able to work with it as is.
OK, I updated the project archive to include nRF24L01 symbol and footprint libraries which include those symbols and footprints. Let me know if it works out OK.
Apparently best practice is to put literally every single symbol and footprint that gets used on a project into project-specific libraries so that they can be freely shared. At least for now I just put in the unique nRF24L01 symbols and footprints that aren't part of the generic KiCAD 6 build.
@NeverDie said in Most reliable "best" radio:
OK, I updated the project archive to include nRF24L01 symbol and footprint libraries which include those symbols and footprints
Awesome! Thank you.
-
UPDATE:
- I've created a Github repo for my version of the nRF24L01 adapter board.
- I've created an OpenHardware.io project for it referencing the Github repo to extract/generate the files.
- My OpenHardware.io project
is being reviewed before it is published. When its availableyou'll find it at https://www.openhardware.io/view/32973/nRF24L01-Adapter-Board-AH.
I've done it this way partly as a test as it ties back to this thread about sharing a complete set of KiCad design files. I'd appreciate any feedback on being able to open and edit the files. Also, feel free to submit a pull request as a test of collaborating with Github and KiCad but only if you're interested in the results too.
Edit: OpenHardware.io project is now available publicly.
