I’ve had a prototype working perfectly with the “green” WBNA notecard for 9 months. Now I bought the new “black” WBNAN notecard, and it has never connected to the cell network (logs below). Same PCB, same plastic case, same room location as the “Legacy” setup that worked. I even added a second diversity antenna thinking it may have been a borderline RSSI, but no help.
Does the newer card use different cell network carriers? That’s the only way I can explain the situation. Any ideas or help is appreciated!
Here is a typical log during a connection attempt:
BLE Server initialized with addr 34:B7:DA:71:87:25
Connecting serial port to Notecard
Checking if cell connected…[INFO] {“req”:”hub.status”,”crc”:”0001:5874FEF1”}
[INFO] {“status”:”13s starting communications {wait-module} {connecting}”}
not connected. Requesting connection.
Sending hub.set request…[INFO] {“req”:”hub.set”,”product”:”com.markleavitt.mark:villagepal”,”mode”:”continuous”,”sn”:”wllo_pal_0007”,”body”:{“agent”:”note-arduino”,”compiler”:”gcc 8.4.0”,”req_interface”:”serial”,”cpu_name”:”esp32”},”crc”:”0002:2739FB14”}
[INFO] {}
success
Sending hub.sync request…[INFO] {“req”:”hub.sync”,”crc”:”0003:10BAC79A”}
[INFO] {}
success
Waiting for connection…[INFO] {“req”:”hub.status”,”crc”:”0004:5874FEF1”}
[INFO] {“status”:”14s starting communications {wait-module} {connecting}”}
.[INFO] {“req”:”hub.status”,”crc”:”0005:5874FEF1”}
[INFO] {“status”:”19s starting communications {wait-module} {connecting}”}
.[INFO] {“req”:”hub.status”,”crc”:”0006:5874FEF1”}
[INFO] {“status”:”24s starting communications {wait-module} {connecting}”}
.[INFO] {“req”:”hub.status”,”crc”:”0007:5874FEF1”}
[INFO] {“status”:”29s starting communications {wait-module} {connecting}”}
.[INFO] {“req”:”hub.status”,”crc”:”0008:5874FEF1”}
[INFO] {“status”:”34s starting communications {wait-module} {connecting}”}
.[INFO] {“req”:”hub.status”,”crc”:”0009:5874FEF1”}
[INFO] {“status”:”1s starting communications {wait-module} {connecting} {network}{extended-network-failure}”}
.[INFO] {“req”:”hub.status”,”crc”:”000A:5874FEF1”}
[INFO] {“status”:”6s starting communications {wait-module} {connecting} {network}{extended-network-failure}”}
.[INFO] {“req”:”hub.status”,”crc”:”000B:5874FEF1”}
[INFO] {“status”:”11s starting communications {wait-module} {connecting} {network}{extended-network-failure}”}
.[INFO] {“req”:”hub.status”,”crc”:”000C:5874FEF1”}
[INFO] {“status”:”17s starting communications {wait-module} {connecting} {network}{extended-network-failure}”}
.[INFO] {“req”:”hub.status”,”crc”:”000D:5874FEF1”}
[INFO] {“status”:”22s starting communications {wait-module} {connecting} {network}{extended-network-failure}”}
.[INFO] {“req”:”hub.status”,”crc”:”000E:5874FEF1”}
[INFO] {“status”:”27s starting communications {wait-module} {connecting} {network}{extended-network-failure}”}
.[INFO] {“req”:”hub.status”,”crc”:”000F:5874FEF1”}
[INFO] {“status”:”32s starting communications {wait-module} {connecting} {network}{extended-network-failure}”}
.[INFO] {“req”:”hub.status”,”crc”:”0010:5874FEF1”}
[INFO] {“status”:”37s starting communications {wait-module} {connecting} {network}{extended-network-failure}”}
.[INFO] {“req”:”hub.status”,”crc”:”0011:5874FEF1”}
[INFO] {“status”:”idle {disconnected} {idle}”}
.[INFO] {“req”:”hub.status”,”crc”:”0012:5874FEF1”}
[INFO] {“status”:”idle {disconnected} {idle}”}
.[INFO] {“req”:”hub.status”,”crc”:”0013:5874FEF1”}
[INFO] {“status”:”idle {disconnected} {idle}”}
.[INFO] {“req”:”hub.status”,”crc”:”0014:5874FEF1”}
[INFO] {“status”:”idle {disconnected} {idle}”}
.[INFO] {“req”:”hub.status”,”crc”:”0015:5874FEF1”}
[INFO] {“status”:”idle {disconnected} {idle}”}
.[INFO] {“req”:”hub.status”,”crc”:”0016:5874FEF1”}
[INFO] {“status”:”idle {disconnected} {idle}”}
1 Like
Hi @mark_pdx,
The WBNA and WBNAN use the exact same modem (Quectel EG91-NAX) so I don’t suspect that is the issue. I’d like to see the output of a {"req":"card.wireless"} request on BOTH Notecards (the old and the new) to see what’s different.
You could consult our guide on diagnosing cellular connectivity, but I’d be surprised if anything outlined here was an issue considering this was already working for you previously.
Rob
Rob, thanks for your prompt reply. And here’s some new information: I mounted the WBNAN card in a NoteCarrier-F (V1.0), but keeping the antennas in my case tied to the RF connectors. I was able to talk to it with the browser terminal, and it immediately connected to the network and showed up on NoteHub. So that eliminated any issue about the Notecard, antenna, or signal strength.
Then I swapped the modem back into my own board, and bam, the same failure to connect returned. Back to the penalty box.
Now I’m wondering if it’s a power issue. Both my old board and new board run directly off USB, but I did downsize the bulk decoupling capacitors from 4 x 50 uF in the original board to 4 x 10 uF in this new one. Could a power dip when the modem transmits cause this failure to connect and subsequent penalty box behavior?
2 Likes
Hi @mark_pdx,
Yes, there is an Insufficient Power Supply penalty box and that’s very well what you could be experiencing. However, there still shouldn’t be a difference in behavior between the legacy (green) Notecard and the new (black) Notecard. Just to be clear, the green Notecard functions fine in this scenario?
Thanks,
Rob
1 Like
Yes, the green Notecard has been working fine. I added more decoupling capacitance to the newer board with the WBNAN and there was no change in the behavior. Now I am wondering about another factor. In the newer boards I omitted the host microcontroller reset button (cost saving) and just unplug/replug USB to reboot. Unfortunately when I’m debugging my firmware, I end up rebooting this way quite a bit, and that means the Notecard will experience unexpected power loss several times in a row. Could this cause the penalty situation?
I have tried to reset the penalty manually with {“req”:“card.wireless.penalty”,“reset”: true } but the {extended-network-failure} response to hub.status returns immediately. Is the penalty stored in the Notecard in nonvolatile memory, or is it a property of the cell network?
Hi @mark_pdx,
Can you please post the response from a call to card.wireless.penalty (no arguments)?
{
"req": "card.wireless.penalty"
}
Also, I’d still be interested in seeing the responses from a card.wireless request for the two different Notecards AND maybe card.voltage requests after they’ve both been powered on for at least an hour or so:
{
"req": "card.wireless"
}
and
{
"req": "card.voltage",
"hours": 3
}
Rob, it looks like I need to be able to issue these diagnostic commands when using various USB supplies, not just my laptop. So I’ll need to implement more diagnostics in my firmware, which will take a week or so. I will update when that’s ready. Thanks!
1 Like
Hi Rob! I added the ability to request a card.wireless result, reported over Bluetooth, then conducted experiments with various Notecards, antennas and antenna orientations. I have two experimental results, and a hypothesis for your comment.
Results:
-
My WBNAN Notecard will only work with the antenna outside my plastic case. I tried both the Molex 209142 and the Linx ANT-LTE-RPC-UFL, but neither will connect when mounted inside the case. Key observations: the green light on the Notecard never lights up in these situations. Also: after one of these “extended-network-failure” events, the card won’t connect even with the antenna outside the case. So I think the penalty box is in play here.
-
Both my WBNA and NBNA Notecards work fine with antennas inside the case! WBNA gets RSSI -81 dBm (cell tower is 7 mi away) and NBNA gets RSSI -69 dBm (cell tower less than 1 mi away). In these devices, the green modem light begins flashing for several seconds, then goes steady green.
Hypothesis: although my case is plastic, the antenna in the case runs parallel to the PCB, and it’s only 2 mm away. I am wondering if the nearby metal could be detuning the antenna enough to make the modem transmitter shut down from excessively high VSWR. Could this be why the green light never flashes? Is there any more diagnostic info available about the RF performance of the modem? I’d like to hear your thoughts. Thanks!
p.s. I have a test report in PDF form with card.wireless readouts and photos attached here.
Hi @mark_pdx,
I appreciate you adding that test report - very informative (and nice looking build!). What’s interesting to me is the difference between the WBNAN with an “external” antenna and the other Notecards with the internal antennas are negligible. (Side note, I recommend using this table as a guide for measuring the quality of your cell signals.)
Have you considered adding a diversity antenna to the DIV connector on the WBNAN? I’d be curious to see if that helps.
Let me check internally to get some thoughts on the antenna wire placement and I’ll get back to you.
Thanks,
Rob
Re the diversity jack – I did try adding an antenna at right angles to the other one, connected to DIV jack, and it didn’t help. But I’m interested in what your engineers say about the antenna placement in my design.
I’ve just plugged the WBNAN back into the Notecarrier, using your Browser Terminal, and bingo! immediately connects to the network. I repeated this with the antenna still in my case and my PCBA still mounted in the case, USB powered, WiFi and BLE active. Still good cellular connectivity!
Maybe I should suspect my own host firmware? It’s the blues-arduino library, but maybe I’m issuing requests that overload the Notecard/network and trigger the penalty. Is there a “best practice” example of what commands to issue on first bootup and subsequent bootups?
Hi @mark_pdx,
The plot thickens! Even though there should be no difference in the Notecards, I wonder if it’s a power issue. Certainly if connecting over GSM there is a 2A spike to account for, but it doesn’t look like that’s the case for any of your Notecards. Are you tracking voltage by any chance? Also may be worth looking at the reason for the WBNAN being put in a penalty box (if that’s indeed the case) with the card.wireless.penalty API.
Re: antenna placement, at first glance the datasheets of the modems usually state you need to provide 20mm clearance. That’s probably overly conservative of course.
If you want to share your firmware, feel free to send me a PM and we can take a look.
Thanks,
Rob
The plot thickens indeed! Read on…
I monitored the USB voltage with a scope and multimeter with max/min capture, and observed what happened when I plugged the USB cable into my Macbook (via a USB-C to USB-A Anker expander). Zowie, the voltage comes on at 5V for 800 mSec, but then drops out for 1 sec, then returns to 5V.
I then repeated this experiment with the Notecard in a Notecarrier-F V1.0, again powered by the Macbook/Anker hub. No initial dropout!
I suspect my own PCBA has enough additional current demands (ESP32, LED, capacitors etc) to just trip the USB supply current overload.
So why have my other two prototypes been working so well? Because they are plugged into charging bricks, not my Macbook. I repeated the voltage monitoring on the new prototype w/WBNAN, but using a charging brick not my Macbook, and the startup is clean.
Looks like I will need to redesign my PCB with a separate USB power jack and USB programming jack.
I wish the “insufficient power” penalty box wasn’t so aggressive – 2 hours for the first offense, 2 more hours for each failed attempt, up to 2 days. Really slows down development/debugging! I never succeeded at resetting the penalty, or perhaps I simply incurred a new one with each power-up.
1 Like
Hi @mark_pdx,
Glad to see you’ve made some progress! Regarding the penalty box, there are ways to manually “break out” of the penalty box in case you missed these:
