Mod

I couldn't because they are packed together, but it was something I was expecting anyway. I had them completely discharged every now and then when the arduino went crazy and drained them out.

what I meant is that they don't actually go to 0v even if you short them as you will always be able to measure some small voltage. I am no expert but my bet is that that 0.5/0.6v is kind of their bottom line where they don't hold any more useful energy below that.

For balancing there are SAB Mosfets that help to keep all the supercaps on the same voltage, but the reverse charge issue is the same for all series circuits, also LiPo worn out batteries can get to 0V and then getting reverse charged with all the consequent risk of fire.

@rpx said in nRF24Doctor:

I am curious to see your PCB.

Here you are :

https://github.com/TechNovation01/nRF24Doctor/blob/master/pcb/nRFDoctor_1.1_sch.pdf

It has some shortcomings for the power part, but the mosfets are ok.

@alowhum MySensors allows customization, which unfortunately makes it very hard to describe the order. An attempt has been made in https://github.com/mysensors/MySensors/issues/927 but we have not found a clear way to document it.

mfalkvidd created this issue in mysensors/MySensors

open Update examples to use logical order for methods #927

@rzylius could be a bootloader or hardware settings. I would check the reset resistor. Do you know which bootloader is on or did you manage to upload one though iscp header?

@alowhum it could be different reasons:

• the battery was old
• in MySensors nrf5, if I remember well, sleep function is not optimized yet
• sensors not in sleep mode
• others parts of your board are maybe draining current. I've not looked at sch of this board, so I can be wrong.

@kduino Could you give this a try? Add the following to your sketch:

//...
#define SD_SS_PIN                     (4)  // chip-select for SD card (unused, pull high!) 
//...

void before() {
    pinMode(SD_SS_PIN, OUTPUT);
    digitalWrite(SD_SS_PIN, HIGH); 
}

@mathea90 I've used it for over 2 years now on my ethernet gateway and it never failed me.

I can only imagine that it stops receiving because the stack missed some interrupts from the radio, causing the internal radio queue to be filled. When this queue is totally filled any new incoming messages will be dropped by the radio.
I don't know why the stack would miss interrupts from the radio though; I assume cabling (especially the interrupt line) is solid. I don't think size of the buffer matters, unless you use slow hardware at a very high message rate.

What arduino are you using for the nodes?
Are you sending at a very high rate?
Could you post node logs and try with serial debug output disabled?

And what about Segger Embedded Studio ? It's now free to use with Nordic SDK for NRF5 MCUs
https://www.segger.com/news/segger-embedded-studio-ide-now-free-for-nordic-sdk-users/

@neverdie said in Recommendation for PCB fab?:

Anyone try this? Sounds like a promising alternative:
https://hackaday.com/2018/09/18/get-your-pcbs-made-at-the-mall/

Good idea but it's not really solving much, it's keeping the most annoying parts: using chemicals (can't do it in an appartment building), making the vias by hand.