Fix transmission when TICKS_PER_SECOND is large
Fix transmission when TICKS_PER_SECOND is large

When figuring out what band and channel is available next, nextTx loops
over all bands to find the one with the earliest available time. The
mintime variable, that records this minimal time, is initialized to
large value, namely 10 hours from now, to ensure that all available
times will be earlier than that.

However, when TICKS_PER_SECOND is big, 10 hours converted to ticks
overflows the range of ostime_t (32-bit signed integer). Instead of
making all comparisons with this value succeed, this causes all of them
to fail, which makes nextTx run in an infinite loop trying to find an
available band.

This problem occurs when TICKS_PER_SECOND is 59653 or more, which
corresponds to a US_PER_TICK of 16.76 or less. The documented range for
TICKS_PER_SECOND is 10000-64516, so this is affects just the upper
range, which is probably why this bug was not found before.

This commit changes the large initial value from 10 to 8 hours, which is
small enough to fit over the full range for TICKS_PER_SECOND, so this
should no longer occur.

mcci-catena/arduino-lmic,mcci-catena/arduino-lmic,mcci-catena/arduino-lmic