Poor cellular signal preventing webhook response to reach device?

Troubleshooting
1

Hello there!
I have a number of Electrons deployed in the field running 0.8.0rc10, system_thread (enabled) and system_mode(manual). In the application firmware, I have a webhook response routine that republishes important events if the webhook response is not received within 45 seconds. I have 2 FSMs in the app firmware: 1) to interface with clients’ machines and 2) to deal with the webhook responses and republishing events. The webhook response FSM only deals with 1 message at a time.

Software is working very well in all devices, except 1 that is not receiving the response within the 45 seconds, hence it republishes the data which creates a duplicated data point in the destination server (we use Ubidots). Duplication of data points is an issue we cannot have.

As seen in the screenshot below, the actual webhook response is received within 1 second.

screenshot%20webhook%20log
screenshot%20webhook%20log1022×857 69.2 KB

This problematic device has irregular cellular signal reception. The device vitals report says the cellular signal strength ranges from “weak”, to “fair” and sometimes “good”.

Is this irregular reception signal causing the Electron not to receive the webhook response on time?
or is the problem somewhere else?

Thanks in advance for the help.
Fabio

2

We had issues keeping our elections online reliably using the 0.8.0-rc OS builds. I’d strongly recommend using the 0.7.0 OS firmware and see if you still have the issue. Simply issuing this firmware solved our connection issues.

You’ll have to ensure you roll the electrons OS firmware back though. Running Particle Update from the CLI will do it for you.

I’ve now learnt not to use RC firmware unless there is a good reason such as testing.

3

If you are using the Electron (or E Series) with 0.8.0-rc without the LiPo battery (only powered by VIN or USB) you’ll get poor cellular performance unless you call PMIC.disableCharging() due to a bug introduced in 0.8.0-rc versions.

4

Thanks @mblackler. Will make a field test with 0.7.0 with this specific device and see if it makes any difference.

5

Hi @rickkas7. I did check this issue before but it does not apply to our case. We use standard kit.

Electron is supplied with power through VIN and supported with standard lipo battery.
In addition, we keep the electrons on-line all the time because we also had issues with waking them up from System.sleep(pin, RISING) and we do a maintenance reset every midnight with a System.sleep(SLEEP_MODE_DEEP, 10); to try to maintain everything fresh every day.

6

Hi all, it’s my first post here, and I think my issue with the Electron is related to @rickkas7 answer. I tried debugging for some hours and searching for posts here, but I couldn’t find any answer yet. I would appreciate if anyone could help me, please. These are the details of my current issue:

Device: Electron, DeviceOS 1.0.1 (I updated the OS as soon as I got it, not sure if I should have left 0.7.0, more stable?!)
Issue: When the device is connected by battery, it connects to the internet and Particle Cloud. If I remove the battery, and use a power supply 5V/3A either via USB port or VIN, the device doesn’t connect to the internet and the Cloud.
Debug notes:
(1) The issue doesn’t seem to be with cellular signal, as I leave the device in the exact same place when switching power supplies;
(2) I measured current with a multimeter in the power supply (before connection to device), and I see that the device is consuming max 100mA. If I connect power supply via USB, device stay in “Cellular off” (white breathing) or “Listening” (blue blinking) modes. If I connect power supply via VIN, device stay in “Looking for internet” (green blinking) mode. The latter is an advance already, thanks to the issue that @rickkas7 pointed out, which directed me to this PR: https://github.com/particle-iot/device-os/pull/1581 . As per the PR suggestions, I added this to the firmware:

setup() {
  PMIC().disableCharging();
  PMIC().disableWatchdog();
}

Before adding this code, the device didn’t even get to “Looking for internet” (green) mode, and current measurements were showing a quick peak of 90mA and average 30-40mA. After this code, the device keeps an average of 90-100mA, trying to connect to the internet, at least.
(3) As per Electron datasheet, Power section, “Most USB ports can supply only a maximum of 500mA”. I’m not advanced in electronics, but I guess it’s mentioning about computer USB ports supplying power. I’m using a AC/DC power regulator, which I connected a USB connector to it.
(4) As per Electron datasheet, Power section, “An additional bulk capacitance of 470uF to 1000uF should be added to the VIN input when the LiPo Battery is disconnected.”. I’m not using capacitors here. I didn’t know which one to use (lack of knowledge on the topic). Anyway, I thought that the USB option would work, so the VIN was my last scenario.

Questions:
Can the Electron be charged independent of a battery, if it has access to “constant” power supply?
If so, is there any code that I need to add to the firmware, like what I did in setup()?
Should I install Device OS 0.7.0 again in the device (is it more stable for alternative powering options?)?

I’m sorry if this has already been answered, but I really couldn’t find anywhere here.
Thanks in advance!

7

That is not uncommon. The amperage of your supply is not the only factor. It's also the response time to sudden current surges that plays a role.
With your description I'd suspect the supply being too slow to sattisfy sudden demands.
A multimeter is usually not fast enough to measure this kind of transient events.

About the mentioned caps, they are required for exactly the above reason. But the docs don't explicitly state that bigger caps (higher thatn 470µF) can supply more buffering but also become slower in responding (especially supercaps are notoriously slow).

470µF 16V electrolytic caps should be a good start.
Adding a few tantalum caps (4.7µF & 47µF) caps will help the response time too.

2 Likes
8

Hi @ScruffR, thank you so much for your answer. I bought the capacitors (they arrive on Friday), so I’ll test the circuit again and write the results here.
Best,
David

9

Hi @ScruffR,
I made some tests with a 470µF 16V electrolytic capacitor, with the goal of making the Particle Electron connect to the Particle Cloud without a battery. I connected the cap to a 5V-3A power supply and then to the Particle Electron. I tried different setups, where I connected the power supply to the VIN or to the USB. When connecting through VIN, I tested the device also connected to a computer via USB at the same time. I also tried the suggestions previously mentioned regarding PMIC code in setup().
The results are in the table below. In summary, I was able to not use the battery, however I was only able to make the Particle connect to the Cloud with both a 5V supply via VIN and power supplied by a computer through USB at the same time. Which is not physically feasible for an external project (to have a computer to “help” with the power supply).

33%20AM
33%20AM1694×648 95.6 KB

Would you please have another suggestion?

Thanks,

David

1 Like
10

After long hours troubleshooting, I guess that I found the issue to this problem, so I’m posting here in case anyone goes through something similar: I tested the same setup with a different power supply (also 5V-3A) and then the issue was solved. I don’t have an oscilloscope here, but my guess is that the power supply + capacitor that I was using before was too noisy for Particle devices.

In case anyone wants to read more details:
I was previously using a power supply that my client have been using this brand for many years with other electronic devices and had no problems before. I have also used this same power supply with another product based on Arduino + Ethernet shield, and I had no issues with it. I even tried to use a capacitor, as suggested, to filter the noise, but it didn’t work with the previous power supply. With the new power supply, I didn’t need any capacitor. Please don’t take this information as a comparison between Particle and Arduino. I like both, for different situations. It just seems to me that Particle may be more susceptible to noise (maybe it’s the Sara cellular module), which is not something bad, just what it seems to be a characteristic of the product. OBS.: take in consideration that I don’t have a strong background in electronics, maybe my conclusions are not correct, but in practice that what’s solved my problem.

If anyone from Particle wants to complement that, would be appreciated.

Thanks,

David

11

@david, using ethernet is not comparable to cellular since one is wire based. The power supply you had may have emitted stray noise which produced unwanted radio harmonics which would not affect an ethernet setup. Or, the supply produced harmonics on the Electron’s own regulator. Both of these could affect the performance of the Sara modem.

Often folks will assume that a DC power supply provides clean DC voltage and current. My experience tells me otherwise and careful selection and design of components produce better results.

2 Likes
12

Hi @peekay123, thanks for the clarification. I was one of these guys assuming that the DC power supply was providing a clean voltage and current, so at least the troubleshooting taught me this lesson.
Would you recommend any specific power supply or brand that I could look for to work on Particle projects? I’m looking for AC-DC models.
Thanks.

13

Hi, are you still using 0.7.0 OS f/w with your Electrons? Are you still finding it to be the most stable OS from a connection stand point?

14

Hi, no, not anymore. We use v1.0.1 and find it quite stable. Be sure to use @rickkas7’s Electron Sample library which provides to routines for self healing of the connection. Works really well.

15

Hi @mblackler, could you please share the link for this Electron Sample library? Thanks.

16

Google is your friend, my friend.

https://www.google.com/search?ei=hYQKXYHyE47aswXvt4-YBQ&q=%40rickkas7+Electron+Sample&oq=%40rickkas7+Electron+Sample&gs_l=psy-ab.3…10024.10245…10565…0.0…0.252.323.1j0j1…0…1…gws-wiz…0i71.O7Bh1JqwYGE

17

Thank you my friend