I’m becoming an expert on reflashing the SD card in the Pi3 running RXOS. I’m finding the system eventually starts to slow down, and begins to refuse to respond when accessed wirelessly. Eventually, over a period of hours the system is completely unreachable via wireless. Is there any way to command a reboot from the wireless connection, and perhaps avoid having to reflash the card? As it is, pulling the power, and reapplying it definitely corrupts the card (which I’m also an expert at…apparently), but at that point one has no other choice. As it is, it’s a neat application, but not terribly stable after a day of use. Immediately after the card is reflashed everything works wonderfully again, but my optimism slowly dies as it starts going south. This is such a simple device, from a user’s standpoint, that there is not a lot of trouble that the human can cause. Conversely, it seems there is a lot of reflashing, that the same human gets to do to take care of the mischief that the system seems to exert on itself. Any way to avoid the system running itself into a ditch over the course of a day?
That’s why we decided to go with the CHIP with its on board storage, rather than the Pi 3. The slow do you are referring to is being reviewed by @Abhishek.
On a Pi, if you use the reboot command over SSH, does it actually reboot? Or does it only shut down?
It will reboot via the reboot command - as expected. I’m not sure how the battery pack you recommend responds to this, though. The user might have to hit the power button on the power bank to get it to come back.
Stratux has thousands of Pi3s out there where the only on/off mechanism is the power plug. No issues. The only issues that come back are from “power users” that use their own SD cards.
@stappenbeck - what SD card are you using? 16GB probably?
What corruption exactly happens? Generally unix style file systems are recoverable during boot, and I wouldn’t expect any critical files to be damaged by a power loss. I wonder if it is the postgress tables that are corrupted. If so some code during boot that looks for corrupted tables and issues a repair table command may be all that is needed, or since the database isn’t all that big maybe just repair every table on boot? The repair also optimizes the table so you gain something even if a table isn’t corrupted.
As the SD card slowly corrupts, do you notice the SNR goes lower and lower? In other words, does it affect the Tuner dongle sensitivity? Also, does the SD card Write or Read capability start to fail permanently?
On a planned removal of power from the RPi, maybe one should first undo the SMA to the antenna. This will stop all packets from being received and hopefully stop any Read/Write to the SD card. Then remove power. To startup again, first re-connect antenna, then apply power.
In general simply stopping input won’t prevent database table corruption. A key efficiency of a database is buffering - a portion of a table is read into memory and altered, but not written out immediately in case that portion needs to be altered again (database operations often work on consecutive records). You need to shut down postgresql gracefully, for example with ‘service postgresql stop’. This won’t happen if you pull the power, but it should happen as part of the reboot command though. Does the same ‘corruption’ happen when you issue ‘reboot’ from the command line?
Sometimes I just don’t know what’s going on. Right now SNR is about 4 to 4.5. A few day ago, below 2. No change in antenna pointing. Probably re-burned SD card. Still the same. Yesterday tried another SD card, both Sandisk class 10 16GB. Seemed to be better. Today, much better. However, have seen mid 6 a 2 weeks ago. This the 2nd dongle, no markings, from Outernet. Probably the 1st was good, but it was way below 1. Even changed out the LNA, New one showed no change. So it seems to me, there is a slow deterioration of parts or Propagation or interference, or all three. I think if we all had a 10 SNR, marginal reception would be much further away. You’re right. Re-booting is much better for the Pi. Will do it next time. Don, W6RWN