home assembly + functionality test

[dominikaherbst]

Hi all,
I ordered the board and all components and am working on this project one step after the other ...
I assembled my first b-parasite (stencil, reflow soldering on heat plate + fixing all connections that didn't look perfect by hand). It all looks good and I am wondering, whether there is a quick functionality check that I can do to check whether my soldering worked and all components are good, before I proceed to the next big step (firmware).
When I insert the battery, nothing happens. I was hoping that at least the D2 LED lights up for a moment, but nothing happens. Is that normal or have I already f***** up?
Thanks!

(I didn't order it assembled, because not all components were available at PCBway/LCSC and I already had some of the components at home).

[rbaron]

Hey @dominikaherbst, welcome to the community.

The only tests you can run without flashing a firmware are basic continuity tests with a multimeter and checking the power pins and pads for the expected voltage.

If there's no firmware, nothing will happen once you power it up.

[dominikaherbst]

Ok thanks!
My J-link v9 arrived today and I tried to build and flash the firmware. During the build there was an error message, but it seemed to have completed. The error message was referring to a log-file and only contained "The system is: Linux - 6.8.0-47-generic - x86_64".
So I guess it was fine.
Afterwards the flash button showed up under applications and I could flash the b-parasite. There were no errors.
When I inserted the battery afterwards, the D2 LED flashed up twice. The same happens when I press the reset button.

However, I have trouble "finding" the b-parasite. I downloaded the nrf connect app on my cellphone, but there are plenty of devices.
I set up my "testing esp32" with the esphome yaml config described here: #157
and restarted home assistant and the esp, but nothing showed up.

Is there any other way to debug whether it is working properly or whether I messed up something? A few continuity checks seemed fine, I haven't tested every component yet, though ...

[dominikaherbst]

well ... of course it showed up in HA right after I made that post ... just took it half an hour to detect :-/
Sorry, never mind ;-)

[rbaron]

Happy to hear you got it working 😊

[dominikaherbst]

Unfortunately, the first b-parasite stopped working after a few minutes. Flashing the firmware again resulted in a "Failed to read device memories" error. The red D2 LED still flashes twice when power is reconnected or the reset button is pushed.

I assembled a second one and that one works so far, but reports sensor readings irregularly via BThome. Sometimes it updates after 5 min and sometimes it takes 20-30 min. Sometimes it also becomes unavailabe and then becomes available again after a couple of hours.
Is that normal?

So far it is powered via 3V from a bench top switching power supply.
The BThome bridge is located at a distance of approx. 30 cm.

I am wondering ... there are pads on the PCB below the nrf52840 chip and the chip has connections there too.

Would you advise removing the solder paste from these pads before reflow soldering?
I have to move the PCB on my heating plate and the last time when I did that, I accidentally moved the chip by ~1mm and am not able to check what happens to the soldering joints below the chip (e.g. if two "pins" have been shortened).

[rbaron]

I assembled a second one and that one works so far, but reports sensor readings irregularly via BThome. Sometimes it updates after 5 min and sometimes it takes 20-30 min. Sometimes it also becomes unavailabe and then becomes available again after a couple of hours.
Is that normal?

Not normal, no. I normally operate under the assumption that it's fine to miss a few advertisements per day, but not consistently. Of course it depends on your setup, receiving hardware, distance, interference. In my case I have a few ESPHomes with bluetooth proxy around the house.

Would you advise removing the solder paste from these pads before reflow soldering?

By design none of these pads are used. I have never applied solder paste on them.

Either way, I would:

1. Check the debug logs;
2. If there is a short, the battery should drain fast. If the LEDs flash twice upon restart, my first guess is that there is no short and the firmware is at least booting correctly. I would measure VCC with a multimeter across the span of a few hours just in case.

Please keep us posted. I hope you get it sorted soon.

[dominikaherbst]

Thanks for the response!
I believe the first one must have had a short somewhere, because the battery indeed drained quickly (3.3V to 2.8 in ~1h). I couldn't find any short in the accessible part though.
The bluetooth proxy is located within a distance of 0.5m of the b-parasite.
I'll check the logs for the second one this weekend and will assemble a third one and remove the solder past from the inner pads.
"Third time’s the charm" ;-)
I ordered a stencil with the PCBs, so they will always get their portion of paste right after application.

[dominikaherbst]

I assembled another one (bp03) and removed the solder paste from the inner pads before reflow soldering. This time all solder joints turned out just perfect, without having to rework anything. There was also no problem with flashing it and I ran the new b-parasite on a power supply at 3.25V over night, right next to the BLE bridge.
However, it behaves just like the previous one and becomes unavailable from time to time for ~1h. I also started running the previous (bp02) one on battery (previously I run it on the power supply at 3V), which makes no difference. The voltage is stable and behavior is the same. The time and frequency when they become unavailable doesn't seem to be correlated, so I guess it is not the BLE bridge.
Anyhow, I have ordered an esp32-eth01, which is supposed to work better without wifi.

Since this thread is about assembly at home, a few words about the assembly process using reflow soldering and my learnings, which might be interesting for others:

• I ordered the PCB from PCBway including a stencil.

• Since the area for applying solder paste is at the upper end of the PCB and due to the elongated shape of the PCB, it is important to support the stencil. I did this by placing two more PCBs with a little gab (~0.5cm) next to the PCB (on on each side) to which I want to apply the paste and shifted them half a length upward. Then I taped everything to my workbench using masking tape.

• Then I cleaned the surface of the PCB and the stencil with isopropanol (ethanol will do it too) and a lint free tissue, aligned the stencil and also taped it to the bench. There shouldn't be any bulging, the stancil must be absolutely flat.
  

• For my first attempt, I used a lead free solder paste (Sn42Bi58) and a temperature of 160-180°C, which didn't work that well. Eventually I switched to a solder paste with lead (Sn63pb37), because it melts at lower temperatures, wets surfaces better and generally gives better results. I started out using a small metal scraper that was actually designed for this purpose, but was not as wide as the area I wanted to apply paste to, which is why I ended up wiping many times. This was not ideal, because by wiping many times I squeezed the paste underneath the stencil. In later attempts I used a plastic scraper (a credit card will also work) that I cut to size, with medium/low pressure, which gave the best results. I made 2-3 passes.

• After carefully removing the stencil it looked like this:
  

• In my last attempt, I removed the solder paste from the inner pads of the board (see picture above) with a toothpick and a cotton swap, but I think this is not necessary as long as you don't shift the nrf52840 chip/board around too much when placing it.

• Then I placed all components. It is not necessary to squeeze the components in the paste. Just putting them on the paste with a little tap to make sure both sides touch the paste is sufficient. Don't worry if they are not perfectly straight, they will align upon reflow soldering. I figured a closeup picture of the v2.0.0 board would be helpful with identifying the directions of some components. I think all directions can be identified from the picture except for the SHTC3 chip, which (in my case) has a notch on on the bottom and has to be oriented towards the dot on the board.
  

• Then I carefully placed the board on a little heating place for reflow soldering that I bought on aliexpress:
  
  

• I set the temperature to 200°C (the Sn63pb37 paste should melt at 138°C, but that was far too low and is likely optimal for reflowing in an oven with a defined temperature profile, moreover there will be some losses due to insufficient contact areas). Since the board is elongated, it will slightly bend (almost impossible to see), but it is enough to get an uneven heat distribution. The first parts that will melt are the pads on the nrf52840 chip/board. Reflowing takes around 10-20 sec (but wait until everything looks good). Then I moved the PCB a bit to also melt the parts that haven't reflowed yet. As soon as the paste melts, it becomes shiny and should flow into the gabs below the chip and crawl up the sides of the other components:
  
  

• Then I check all components for continuity.

HTH some people :-)

[rbaron]

Thanks for the full explanation and pictures @dominikaherbst. I think it's safe to say you are now getting consistent results with different boards.

I am arriving at a similar conclusion as you. Please still check the b-parasite logs for more information, but my current suspicion is that the b-parasites are working as expected, and the bridge is missing some advertisements. For testing/logging, you can lower the sleep interval by setting CONFIG_PRST_SLEEP_DURATION_MSEC to 5 seconds or so.

Years ago I ran into issues of using WiFi + BLE at the same time with some old ESP32 boards, and I remember having to tweak the interval/window like this, but that's also not recommended -- there's a fine balance between the time spent on using the radio for WiFi and for BLE. After I switched my proxies to the beefier ESP32-S3, I've been using it with no issues.

Please keep us posted!

[dominikaherbst]

I noticed the following problem:
"[{
"resource": "/scratch/b-parasite/b-parasite/code/nrf-connect/samples/ble/prj.conf",
"owner": "kconfig",
"severity": 4,
"message": "CONFIG_BT_CTLR_TX_PWR_PLUS_8 was assigned the value y, but got the value n. Missing dependencies:\n",
"startLineNumber": 11,
"startColumn": 1,
"endLineNumber": 11,
"endColumn": 29
}]"

I am not sure which dependencies are missing. I haven't changed anything in the config. Could that be the source of the issue?

Regarding the CONFIG_PRST_SLEEP_DURATION_MSEC, the variable name suggests that it is in milliseconds and that 1000 (1 sec) is the default, did you mean that I should reduce it to 5 ms?

Thanks!

[rbaron]

RE: TX problem. See #217, it looks like a UI issue as far as we can tell.

While testing I lower my CONFIG_PRST_SLEEP_DURATION_MSEC to 5 seconds. 5000 ms.

[rbaron]

Another drive-by suggestion if you haven't tried it yet -- enable debug logs on your ESPHome node. There could be a hint if something is up with the BLE proxy.

[dominikaherbst]

Thanks!
No to my shame I haven't checked the debug logs yet. I'll try that, I think I also still have an esp32-S3 lying around.
... However, ... I just discovered that all ShellyPlus devices can be used als BLE proxy in HA (Settings>Devices & Services>Shelly> all devices that allow that have a configure button and you can choose between active, passive, and disabled). So it turns out that I have already 7 devices all over my apartment that natively support running a BLE proxy with HA. A quick test shows that it works. I'll let it run for a while and check whether the problems are gone.