On Fri, 9 May 2014 21:59:22 -0500
Bill Dailey docdailey@gmail.com wrote:

I can tell you that the BBB is really reliable. You don't hear that
about the R. Pi, plus it is about 4x the CPU power of the R PI,
granted at $20 more cost. The R Pi has a better GPU if you need
resolution.

I'm running dump1090 on the BBB, for those familiar with the project.
[Probably just "satellite Dave."]

The only issue I found with the BBB is when I booted my router and the
connection to the BBB didn't fire up. I probed the BBB with the serial
port connector and it was running just fine, so I don't know why the
router didn't connect to it. I booted the BBB and it did connect to the
router.

Reliability is of course key to any timing reference. Angstrom uses
systemd. The R Pi is still on initd IIRC.

Note a bug on the BBB is if you use a cape, it blocks the connector to
the serial port.

On Fri, May 9, 2014 at 4:55 PM, Brian Lloyd brian@lloyd.com wrote:

Yes.  I really feel like I was just taking about this but I can't find any
email at the moment.

I did build both NTPD and a kernel but just NTPD is accpetable with the
current Ubuntu build I use (14.04 LTS/3.8.0).

I started with the http://the8thlayerof.net/ stuff using the same bits
(conveniently all 3.3V) although the dts file and gpio usage is kernel
specific (and will be changing again with the new boards).

 remote           refid      st t when poll reach   delay   offset

jitter

---============
x127.127.20.0    .ADAU.          0 l    7    8  377    0.000  112.495
29.833
o127.127.22.0    .GPPS.          0 l    5    8  377    0.000    0.001
0.008
*128.205.85.72  .GPPS.          1 u    7    8  377    0.473  -0.021
0.035

On Fri, May 9, 2014 at 11:38 PM, nuts nuts@lazygranch.com wrote:

I find them comparable.  My Pi has actually run longer.  I don't expect
either to be able to run a year without crashing.

I use "stacking" headers (the wrong way) to lift the cape.  I'd rather have
the console port than be able to close a case.

On Fri, 9 May 2014 23:49:05 -0400
Paul tic-toc@bodosom.net wrote:

I think I can visualize what you did. Kind of like how many daughter
boards connect to motherboards.

I was thinking it might make more sense to move the serial port pins to
the bottom, or just make a flexible cable to hook up to the serial port.

You have to wonder who made this "executive decision" to have the cape
cover rather important pins.

Now in defense of the BBB versus the older Beagle Boards, the ethernet
port is native, so to speak, rather than going through a usb port then
converted to ethernet. There were real problems with that scheme, most
notably the usb hub crashing and bringing down all communications. So
you can do a trustworthy SSH into the ethernet port.

I have a Beagleboard XM gathering dust due to issues with the usb hub.
It didn't turn out to be the most stable arm SBC. However the BBB is
very solid except for that odd router issue I mentioned.

This page has instructions for using the BBB for mode-s decoding, but
there are a few useful tips on it. For instance, you will want to
change the "runlevel" if you want to SSH into the device rather than
use the HDMI port.

On 10/05/14 04:38, nuts wrote:

"The" serial port ? I assume you mean the UART0, aka the console ?
There are 5 others to choose from (UART3 doesn't have all the pins
brought out from the but makes a great PPS or MSF/DCF input)

Those 5 are brought out to P8 and/or P9. You may have to twiddle some
pinmux, and lose access to the HDMI and onboard MMC, depending on which
port you choose, but you can stilll use the SD card slot. Why would you
want HDMI on an NTP server anyway ?

These days, you just load the appropriate Cape firmware (Yes, even if
you don't actually haver a serial cape, the firmware essentially
twiddles those pinmux's for you.

Now, the BBB has a better PPS input. The TIMER4-TIMER7 inputs can be
used, IF you are willing to run FreeBSD rather than Linux. See:

http://lists.freebsd.org/pipermail/freebsd-arm/2013-February/004769.html

(Note, no need for patches now, just grab the snapshots from
ftp.freebsd.org. the patch is in there) I think it's also in the
latest releases, I'd need to check to be sure though.

I know there was some work done on a similiar facitility for Linux, but
not sure if the Author has had the time to finish the work.

I have my BBBs fed from my Austrons via a 5V->3.3V voltage divider. One
thing I'd like to try is feeding the BBB the 10MHz clock from the
Austrons, as it also has an External Clock Input Pin (TCLKIN), but that
will need some kernel work to select the external clock. It may also
need further work in uboot.

Treat the BBB and Pi just like any other Linux box :)

Iain

On 10/05/14 03:32, Brian Lloyd wrote:

It's an aptitude install away, although you may want to build from
source to ensure all ref clocks are enabled (esp the ATOM PPS driver,
may not be enabled in the default build.

On 10/05/14 04:49, Paul wrote:

Add a getty on one of the other serial ports :) Or manage via ssh over
the LAN :) [Yes, okay, you don't get access to early boot, but to be
honest you shouldn't be needing that very often]

Best Regards

Iain

On 10/05/14 08:30, nuts wrote:

Or just use UARTS 1, 2, 4, or 5 for your GPS device

No one made that decision.

Originally, you had the BBW, which did not have the header where the BBB
has the console pins. The capes were designed for the BBW.

When they did the BBB, they brought out the console pins to that extra
pin header. Using a BBW cape with a BBB does work in most cases, but yes
you lose access to the UART0 pins.

To be honest, I've only ever needed access on first boot, and when
developing [usually when I fsckup a kernel or some such]. Even then, I
can just remove the SD card and restore things to an earlier kernel.

[SNIP]

Interesting on the mode-s stuff. I run all mine headless, and in debian,
just install ssh, no need to change the run level. Also, note that if
you want access to all the UARTs you will need to sacrifice the onboard
flash, and HDMI (IIRC), as I mentioned in my earlier email

(Oh and if anyone cares, my current fleet is 5 BBBs and 3 BBWs...)

On Sat, May 10, 2014 at 4:02 AM, Iain Young iain@g7iii.net wrote:

The system has a "serial console" and I want access to it without fiddling
the firmware.  Since I'm still in the "prototype" phase just elevating the
cape is sufficient.  The next step would be replacing the header.