"Michael E Fox \(N6MEF\)" <n6mef@...>
Some important considerations for a reliable device:
1) main board temperature (and humidity) tolerance
2) storage temperature (and humidity) tolerance
3) storage reliability
RE 1 & 2:
Anything that might be deployed in a remote location could be subject to a broad range of temperatures and humidity levels. For example, one of our mountain-top facilities suffered an A/C failure last year. Due to all of the radio and computer gear in the building, the temperature reached 115 *F and humidity dropped to 2%. The A/C failure occurred on a Friday afternoon and the site owner was not able to get an A/C company to go up there until Monday morning. In the meantime, the backup A/C also failed. So all of the equipment baked in a sauna for the entire weekend. The radios we use (mobile Kenwoods and Alincos) continued to work just fine.
Obviously, the heat pipe & heat sink on the chassis plays a key role. But since the UDRX is also a linux machine with storage, then the storage must also be able to survive such temperatures, not just the processor connected to the heat pipe / heat sink.
The board needs to support at least commercial grade SSD if it’s going to be reliable. SSD storage is generally categorized as consumer, commercial or industrial. The differences are generally related to the quality of the write leveling algorithm and the temperature tolerance.
A consumer-grade SD card in a Raspberry Pi is fine for indoor tinker-toy projects. But those who operate servers (such as BBSs, mail servers, etc., with lots of files being created and deleted, lots of logging) know they will fail after significant write activity and/or temperature changes such as described above. Consider a commercial grade mSATA or M.2 SATA rated at 50+ *C. (BTW, there are also important configuration issues which impact the write volume, such as unpartitioned space for garbage collection, use of the TRIM command, etc.)
Remember that a failed, non-RAID storage device can take a system out of service for many hours or even days. If you are immediately alerted, and read to go, then it’s at least several hours: time to retrieve spare parts, load up the car, drive to the site (>1hr in many cases), unload, set up, replace the drive, restore from backup, etc. But if you’re at work, out of town, on vacation, etc, it may need to wait for several days or longer. So, a cheap little SD card from Amazon can render your solution worthless. That’s why the devices we deploy as servers (JNOS BBSs, mail gateways, etc.) use dual commercial-grade SSDs configured with software RAID-1 (mirroring). The extra $50-75 or so is nothing compared to being out of service for hours, days, or longer.
Well said. We are keenly aware of these issues.
I've worked with computer systems in humid environments that make anything in North America look 'arid'. :-)
Fiji, Tonga, and Samoa are much, much more challenging! You have no idea...
For storage - I run my household-network Raspberry Pi on a commercial SSD. No SD card or USB flash can stand up to the hammering that a busy Pi does to its filesystem on a 24/7 basis. Tried both.
However, my Pi does DNS, DHCP, HTTP, and email for my home, so there's a lot of file writing going on - and those files need to be persistent. It's quite possible to make a Pi with an SD card work perfectly well for an application like UDRX - it is not difficult to put all of the high-change files in a RAM disk, only some minor Linux tweaking is required. An SD card works fine if updates are not happening frequently, my Pi still boots from an SD. Occasional writes to the SD to update software and alter configurations wouldn't be problematic, I would expect an SD card to survive for many years, probably on the same order (and cost) of lithium ion cells found in many radios.
This is going to be true for any embedded-linux device that the project is looking at using. We need essentially flash+RAM, which can be done with the Pi. Adding a commercial SSD to any of these configurations will blow the budget for the device, although I would expect that anyone who finds a need to add SSD for additional persistent storage can do it through the USB port (that's how I connect mine on a Pi).
- Richard, VE7CVS
---In UniversalDigitalRadio@..., Richard VE7CVS <myyahoo@...> wrote :
>Adding a commercial SSD to any of
> these configurations will blow the
> budget for the device, although I
> would expect that anyone who finds
> a need to add SSD for additional
> persistent storage can do it through
> the USB port (that's how I connect
> mine on a Pi).
The board will also have ethernet, so NFS filesystems can be mounted.
Ethernet is really a must have. It allows mounting the radio remotely -- up to a few hundred feet. USB doesn't allow that.
Steve Stroh N8GNJ <steve.n8gnj@...>
What was the attachment method for the SSD - USB?
On Sun, Mar 29, 2015 at 8:16 AM, myyahoo@...
[UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote: