Check out CN3791 MPPT solar controller.
A node is born!
I made it using the original @paulhausk Gerber, but with input from @joyel24 I crossed over the USB D+/D- using axial resistors. The new design works well, and the antenna seems ok.
Anyway, big thanks to @paulhausk for your PCB layout. It’s given me confidence that the HT-CT62 isn’t a total dead end.
Got some results, Bluepill + sx1262 95% reception success,
with 2.2mA avg listening current, ordering PV now.
Interresting, thanks for the feedback… But for what I know, there is no firmware working on stm32… Are you talking about meshtastic running on it or just a simple sx1262 example ?
Custom FW, not doing payload decrypting, just decrementing hop counter and relaying.
My STM32+SX1262 relay node is ready
Dropping tons of messages is not really “ready”
Yes, dropping messages is not good.
Way back in time (2018) I did some checks on CAD on the SX127X. If the packets were very weak, as in long distance, CAD would not see them but non CAD would.
Not really sure why, maybe I need to check it again.
Yes, loosing 1 out of 20 packets even in perfect conditions is bad.
But maybe even worse: -as I mentioned on Discord as well- you repeat immediately, meaning that two of those in range are guaranteed to create a collision. Also if your processing delay is longer due to waking the CPU, without listen-before-talk you’ll repeat slightly later than a normal Meshtastic node and transmit on top of it.
Furthermore, you should keep a list of received message IDs to avoid repeating the same packet twice when another node repeats it further (a hop limit of 3 allows this).
Lastly, since the code is not open source, I don’t know if you have a Tx queue for when you receive multiple packets back-to-back.
And the code need to be released if it contains any meshtastic code, which it likely does.
The goal was to beat the nordic’s power profile for a remote solar node with positive energy balance using a cheap 10x5cm PV cell,
it’s a compromise between reception success and staying within energy budget, surely you understand constrains.
I will do some testing with the PV cell and see if I can relax it, or might need to stricten it by dropping non human msgs.
Actually, the typical PER for SX1262 is 1% based on datasheet.
Yes, it’s not a full node, just a constrained one. It does not use anything from meshtastic code, just bare metal and datasheet.
It’s not a “typical PER", it’s the PER threshold they used to determine the receiver sensitivity. With more than sufficient SNR, PER is “well below 1%”: https://lora-developers.semtech.com/knowledge-base/viewthread/205/.
In your case transmitting a packet over 3 hops with those repeaters in perfect conditions (high SNR, no collisions, etc.) succeeds in only 86% of cases, and the chance of an ACK or traceroute response getting back is only 74% (0.95^6).
I would really increase the receiving duty cycle and improve the repeating logic, otherwise this repeater is only making meshes worse.
That said, I believe currently the STM32WL target (Seeed studio Wio-E5) fits in flash, which might also be a good candidate for a low-power repeater. There’s no working filesystem for it yet though.