Antenna light comes on intermittently at power-up

GoPiGo
6

OK, weird. It’s happening again, but different.
Just got back from a 2 week socially-distant road trip out west. Fired up my robot using the new USB power supply. This time the GoPiGo3’s LEFT eye LED came on GREEN (not the WiFi LED this time). This happened right away, so no warm components. I was able to run the control_panel_gui.py program via SSH. It showed the voltage as 10.5V. The LED’s did not respond to the control panel buttons, but the blinkers did, and the motors ran fine. I then used the Python REPL to import gopigo3 and try controlling directly from Python. I couldn’t turn on or off any of the LEDs (left eye, right eye, or WiFi). I could control the blinker LEDs however via the REPL. The left LED cam on that way through several reboots. After a subsequent reboot, the RIGHT eye came on WHITE. One more reboot after that - no LEDs came on. However on checking, I still couldn’t turn on/off the LEDs (either through the REPL or the control panel GUI); could still control the blinker LEDs though. I’ve tried a few more reboots - no LEDs come on.

Everything else seems to run OK. Like I said - weird.

/K

1 Like
7

It’s October, maybe your 'bot is haunted?

You can always try wiring some garlic in parallel with your power supply. :wink:

Seriously, I’d look closely at the power source, garlic or otherwise. It might be dipping at power-on. See if you can get a 2 amp+ supply at 12v across it. Temporarily wire one across the power jack (or a plug adapter) just to absolutely guarantee that the supply isn’t the issue.

8

Thanks @jimrh. This has happened though with 3 different power supplies (including one plugged into the wall), so the power supply doesn’t seem to be the issue.
/K

1 Like
9

This is happening again consistently - the LED antenna light is coming on when I start up my GoPiGo3. Seems to come on as the boot process finishes. I’m also noticing the smell of warm electronics - I’m guessing that’s from the LED being full on. I’ve tried 3 different power supplies (2 battery ones, and a wall source) with the same result.

I actually got a new GoPiGo3 board after this happened last September, and it hasn’t been a problem until now. I noticed it last night when I was having the issues reported in this post. I don’t know that the two are related, but it’s a curious coincidence.

Any suggestions on how to troubleshoot this? Seems odd that it would happen to two different GoPiGo3 boards. Maybe it’s my Raspberry Pi (which I didn’t change out), although odd that it’s so delayed.

Thanks for any help,
/K

1 Like
10

I downloaded and ran GoPiGo OS v3 - seems to run fine. Antenna light functioned as it was supposed to.

Went back to Ubuntu - antenna light still comes on white. Looking more closely through the gopigo3.py file, I noticed that the LED_WIFI is declared. Using the python command line REPL I was able to set the LED to blue, but it very quickly (within a second or so) turned back to white. I repeated this several times). So something seems to be sending an SPI message to 0x80 (since the light worked fine with GoPiGo OS I don’t think the issue is on the receiving side).

This is where I hit the limits of my abilities - not sure where to go from here regarding troubleshooting.
/K

2 Likes
11

@cyclicalobsessive has written some nice scripts to control the Wi-Fi LED. You may wish to examine them.

One of which explicitly disables the automagic Wi-Fi LED service.  It might not be the same, but it may provide valuable clues.

12

Thanks - I’ll look for those. As you said they may provide some clues. Troubleshooting this is my Saturday project.
/K

1 Like
13

Scripting in general and how to correctly write and schedule a cron job is (IMHO) one of those necessary skills.

Unfortunately, many sources on the 'Net are waaaay pedantic about exactly what to write and moreso about where (within which crontab file) to place it.

As for me and my 'bot, I put most, (if not all), of my stuff in the system crontab as I do very, very little stuff that is user specific enough to require a separate user crontab.

That’s me.

Of course, the purists wail and gnash their teeth telling me how stupid that is.  Maybe they’re right within a desktop/laptop/server environment.

I just don’t think that Charlie is a tempting enough target for me to go all hyper-anal over it.

Just imagine the scenerio:

Yep.

Ransomware on a educational 'bot is a REALLY rich target!  :crazy_face:

This doesn’t mean that security doesn’t have it’s place - you just need to be reasonable - and stressing over which crontab I use is way off my radar. :wink:

2 Likes
14

For sure weird. Perhaps Finmark wasn’t keeping socially distant while you were away?

2 Likes
15

Update - problem solved (I hope…)
tldr: changing out Raspberry Pi 3B board seems to have solved problem.

Full version (in case this is helpful for others having similar problems in the future)
Recap:
Last fall WiFi LED would come on at boot time. At the time this went away when I replaced the GoPiGo red board (didn’t change Raspberry Pi).

The problem had recurred in the past week. Initial trouble shooting included running DexterOS which did not cause WiFi LED to come on, which suggested this was not a hardware issue with the GoPiGo3 board. So I suspected a software issue, perhaps from a recent system update.

Today’s testing:
I periodically make a snapshot of my uSD card in case a card gets corrupted. I copied a snapshot I had made about 6 weeks ago, before the issue was occurring, onto a new uSD card. Unexpectedly, the WiFi LED came on white. That suggested that perhaps it was hardware after all. Certainly seemed to rule out a recent system software update as the culprit. Maybe it was a hardware/software interactionissue, since DexterOS worked OK?

I then tried a new Raspberry Pi 3B I had. WiFi LED stays off. Tried with old snapshot of uSD - LED stays off.

I tried the old GoPIGo3 red board (which I had thought was bad) on the new RPi - LED stays off.

With the old RPi board, the LED comes on at the end of the boot process regardless of which red board or uSD I use.

Each of the above had at least 3 trys with same results. So perhaps it’s some weird hardware issue with the raspberry pi itself??? Not sure why it went away last fall when I changed to a new red board, but right now both red boards seem to run OK on the new RPi board. So I’m declaring victory and moving on.

Hopefully I can mark this issue as closed once and for all.
/K

PS - suggestions on what to do with the old raspberry pi board. I don’t fully trust it, but it may just be something weird with hardware/software interactions on the SPI bus. So maybe it’s fine for non-SPI projects? It seemed to run Dexter OS just fine. I hate to just toss it.

2 Likes
16

The Pi-3 has the ability to use a firmware file.

Since the issue doesn’t happen with a Dexter OS I wouldn’t rule out an issue with the base firmware.

2 Likes
17

Congrats on trying that - it is a pain to disassemble/reassemble but it gives a valuable data point.

I keep two spare RPi - one smackin’ new, and one that the on-board WiFi doesn’t work, and also have a “DeskPi” in a case with UPS for trying stuff out on, and it runs WorldCommunityGrid(BOINC) when I’m not using it.

2 Likes
18

The saga continues. I mentioned in another thread that I was having wifi issues. When I finally just attached a monitor and keyboard and used the GUI, I found that it just hadn’t joined the wifi network automatically. So I manually joined. Rebooted a few times - seemed to work fine, and I was able to ssh in remotely. Detached keyboard and monitor - no go. Reattached and logged in again - I was on the wifi. Finally realized it wasn’t joining until I logged in (which isn’t helpful when you’re trying to go headless). Upon further looking, seemed like that when I had manually joined I created a second configuration for my home wifi. So I deleted them and joined the wifi. Then rebooted. This time it did join the wifi automatically before I logged in (I was able to SSH in remotely), but the !@#$% antenna LED came on again. I decided to just make peace with the fact that the antenna LED would be on for no reason, and live with the battery drain, as long as everything else worked. I made a backup of the SD card. Then when I booted again - no wifi (and no LED). I connect to a monitor again to see what’s going on. There is literally no wifi - it’s off with no apparent way to turn it on via the GUI. I tried a couple of command line things that my friend Google suggested just to confirm that the wifi wasn’t working. Can’t see how just making a backup copy (read only operation for the SD card) should have done anything.

Now I’m giving up trying to fix this. I’ve decided I’m going to start from scratch and rebuild the OS and files from scratch to see if that works. It’ll take some time, but I’ve already probably wasted more time trouble shooting. We’ll see how the clean slate approach works.

/K

PS

Good idea. The 3B+ is out of stock pretty much everywhere I trust, unless you get it as part of a “starter kit”. There are some third party sellers on Amazon selling the bare board, but they’re actually asking for more than what some of the starter kits sell for. I checked my local MicroCenter on line last night - they had 1 in stock. I was able to reserve it and pick it up today for normal price. The box was a bit beat-up - I need to check the board.

2 Likes
19

@KeithW
I know you’re on Ubuntu, but I’m not sure how the gopigo libraries get installed
On Raspberry Pi OS, there is the antenna service that turns on when you connect to Wifi. It’s the only reason why that LED would be on.
You can go ahead and disable the service, if it’s running at all.

1 Like
20

Thanks so much @cleoqc. When I’m back up and running again I’ll check for that if the problem recurs. Hopefully it won’t.
/K

1 Like
21

I’m up and running again (as described here). Antenna LED is on again. I checked the Ubuntu services with service --status-all. There was no antenna service. At this point I’m just not going to worry about it. But thanks again for the suggestion.
/K

1 Like
22

I stand corrected. @cyclicalobsessive 's post did give me what I needed. Although the service doesn’t show with service --status-all, when I ran sudo systemctl status antenna_wifi as suggested in the post I did get the expected output. And by stopping the service I was able to turn the light off w/o it coming back on again from the python command line (the python one-liner suggested in the post gave me an error unfortunately).

Still not sure why this occurs intermittently (or today, why the color shifted to orange). But I’ll take it. Now I just need to figure how to run the necessary commands at startup automatically.

Thanks again for the helpful suggestions @cleoqc, and for the very helpful posts @cyclicalobsessive .
/K

2 Likes
23

With that service out of the way, you can use that neopixel LED for anything else you want.

IMHO, I like the antenna LED, it lets me know when the network dweebs out on me.
:wink:

2 Likes
24

Just checked Carl’s life.log for “Router not responding”: 677 events in 144 days - average 30 times/week. The events are often quite clumpy - days with none, then several clumps in a day. Most outages are less than 2 seconds.

Carl flashes his (WiFi) LED orange when router is unreachable, and otherwise lights it steady blue to signify he is listening for “Hey Carl.” (He is still listening when the router is not reachable because he is fully autonomous. He is quite protective of his independence. )

Carl_HeyCarl_WiFi_LED
Carl_HeyCarl_WiFi_LED4032×3024 1.06 MB

2 Likes
25

Was easier than that. I realized I could run sudo systemctl disable antenna_wifi so the service doesn’t start in the first place. Seems to work. And now I can then use the LED_WIFI as an indicator like the cool kids do:

:robot:
/K

2 Likes