@Sasquatch said in BATERY CHARGER CONNECTION ?:
Tp4056 is linear regulator, very inefficient, look at spv1040 or spv1050 instead - MPPT tracking propper solar chargers.
C-x b wiki.org -> Electronics <TAB> -> Components <TAB> -> Power -> C-u M-<RET> to create new sub-heading ("MPPT tracking solar chargers"), paste (Yank) useful info for future reference.
Maybe check out Dr. Zs on YouTube. His channel seems geared more to non-techies. He is big into Sonoff / Tasmota stuff, etc. which nowadays are pretty easy (you can flash them OTA, no more need of soldering).
Having said that, the more you learn, the more options open up to you. Also you will pick up more and more of the stuff over time, no need to rush. Take your time and treat it as a hobby. It took me literally years to get where I am now, I finally got some certain things working that I had wanted to for a long time. But my skills (and parts inventory, etc.) was not up to par yet. Well, now it is.
Another thing to consider, architecturally, is there are couple ways to tie together even otherwise disparate systems. In other words. no need to "commit" to any particular system. Here at Casa de TRS-80 we are using 433mhz, MySensors, as well as some Wi-Fi outlets, etc...
There are a couple different ways to do that. Either in your controller, and/or with some intermediate messaging protocol like MQTT. MQTT is rapidly becoming something like the middle "glue" layer between disparate systems. Lots of things talk MQTT nowadays.
Anyway that way you can mix and match. I bought some Wi-Fi plugs and 433mhz stuff to "get started" and get a few things working, but now I am getting better with MySensors and more "advanced" stuff... Just a thought!
I see that semtech now has what looks like an improved LoRa chip available, the LLCC68: https://semtech.my.salesforce.com/sfc/p/#E0000000JelG/a/2R000000HTJR/Tem0gUxGfOZ2Qn3bUzmV2zKNQRYJ3bpobPfOQ7B.erE
Among other things, it's clearly geared toward supporting LoRaWAN. For instance, it contains an automatic channel activity detector that can detect activity by other LoRa's. Looks promising.
Meanwhile, I notice that Semtech has a LoRa baseband chip that sounds awesome: "The SX1302 can detect at any time, any packet in a combination of 8 different spreading factors (SF5 to SF12) and 10 channels, and demodulate up to 16 packets at any time. " This way a mote need use only as much spreading factor as it needs to reach the gateway without worrying as to whether the gateway is setup to receive at that particular spreading factor. Lower spreading factors equals less transmission time, which equals energy savings. Wonderful!
Semtech also has a LoRaWAN gateway chip meant for indoor use, so it sounds as though the paradigm is now, essentially, "LoRaWAN everywhere, both inside and outside the home." That suits me just fine, because LoRaWAN includes firmware over-the-air updates as part of its standard from the very get-go, which is exatly how it should be.
Anyone here using LoRaWAN inside the home? Which LoRaWAN library do you like the best?
Hello @craigzyc, you can assign a prefered parent with #define MY_PARENT_NODE_ID n. If this should be the GW, set n to 0. If the node can't reach the parent, it will start looking for a new one and assign the closest repeater as the new parent.
I think what you are trying to do could potentially lead to some complex routes with many hops over time, if the connection to the GW isn't perfectly reliable and literally any node could be a repeater. In consequence, it might complicate debugging network issues, if there are so many routing options. So I'm not sure if this is a desireable setup.
Let's assume your location is a flat, plane space (so I can illustrate it better):
GW --- R1 --- R2 --- N1 --- R3 --- R4 --- R5 --- N2
AFAIK, messages to the GW are always routed through the parent of each node on the way. So if N2 (node without repeater feature) wants to reach the GW, but hasn't the GW set as its parent, it will route through the R (repeater) which answered its find parent request the fastest (propably the physically closest). So this might be R5 in this case.
R5 went through the same find parent process if it had trouble reaching the GW directly at some point, so it's possible that it relays all messages from N2 to R4. R4 to R3, R3 to R2, and so on. There are up to six hops in this setup until the message from N2 reaches the GW. And on each hop something could go wrong. With each extension of the route, you are increasing complexity and reducing reliability.
IMHO, the better approach would be to make sure that each node itself is as reliable as possible instead of relying on a dense network. Use a good, stable power source, add capacitors to the transceivers to smooth the voltage level / reduce noise (e.g. 10 - 100 µF bulk electrolytic capacitor and 0.1 µF ceramic), etc. Test how reliable the signal in specific areas is (build a nRF24Doctor, run some tests with various capacitors or, monitor your network).
I'd suggest using only as many repeaters as you need and activate that feature on (always powered) nodes in one or a few central locations only.
Also, if range is a limiting factor at your place, consider using a different transceiver, like the RFM69. Due to the lower frequencies they use, you shouldn't need to use repeats at all, not even on large properties.
I have not had any trouble just buying my radios the normal way on AliExpress. To me normal means buying about 10 or 20 at a time from the cheapest seller I can find with a high number of sales under their belt and a good reputation. I am getting nRF24 though, not sure if situation is different with RFM59W.
I think most of the stuff you read in forums about fakes was from years ago. Or maybe I am just lucky.