Hi

Well “so far they look the same” is a pretty good answer to the question. Running emulated code, that’s the outcome that I would expect. Of course one always has to be careful when you find the expected result :)

To me the next layer here is to see if the basic accuracy of the device can be improved in software. My guess is that’s not going to happen, but one should look into it.  If that’s a dead end, there’s always putting a CNT-90 like frequency estimator into the code.

Bob

On Feb 28, 2014, at 2:16 AM, Poul-Henning Kamp phk@phk.freebsd.dk wrote:

In message 87CAF1A2-D281-4331-B019-B01B06F11DFB@rtty.us, Bob Camp writes:

I have a hard time seeing how that would happen.

I think one of the best chances would be to improve the phase
noise of the 200MHz signal.

But don't miss the fact that being able to make a LOT more measurements
in the same time also improves noise statistically.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

If you use a flash-based embedded ARM board, how much is it worth to you that it works everyday? How much is it worth to you that you do not have to rebuild it once a year or once a month?

I have several of them and I corrupted one a couple of years ago. It was not something that was on 24/7 and it was not a power outage. I turned it off myself and it did not come back. Fortunately, it had a pretty much stock distribution on it and it was easy to rebuild. I am more careful now. Yet, my Raspberry Pi is on 24/7 and it survived the many storms we have had in the last 2 months (Florida is the lightning capital of the world, as they say)

It is perfectly OK to not care, but most of us are used to equipment that powers up each time you need it and that only requires to flip the power switch to off when you are done. It is bad enough to have to properly close Windows (replace with your favorite OS, they all have similar requirements) and most open apps when you are done before turning the switch off on your desktop system.

The fact that it may do it 100 times in a row and not fail is not great consolation if it fails at 101. It is a documented failure mode, not pie in the sky.

It is only an issue with regard to your own expectations. Do not disparage people who expect more of the hardware than you do.

Didier KO4BB

On February 27, 2014 9:29:22 PM CST, Brian Lloyd brian@lloyd.com wrote:

--
Sent from my Motorola Droid Razr 4G LTE wireless tracker while I do other things.

On Fri, Feb 28, 2014 at 8:20 AM, Didier Juges shalimr9@gmail.com wrote:

OK, you turned it off and it did not come back. Sounds like a different
failure from what we are talking about. You did a normal shut down and it
failed. Of course we are going to have some number of random failures in
normal operation. S--- happens.

And I agree that, if the system has a R/W filesystem and there is no
power-fail processing provided, odds are good the filesystem will become
corrupted during power-fail at some point in time.

But has anyone determined whether or not that happens with the BBB in
question? Does it have PF processing? Is there PF detection? Does the PSU
hold power up long enough for PF processing to complete?

And the other side is that a group of negatives does not prove the problem
does NOT exist, it only suggests that it does not exist, it only suggests
that the probability is lower than originally thought.

It is perfectly OK to not care, but most of us are used to equipment that

Ah, that is not the point. I agree and I DO care. I want my test
equipment to power up and work EVERY time. I am still waiting for someone
to show that this is a real problem and not just an imagined problem.

Most of them let the processor turn off the power after completing
shutdown. That does seem like a useful approach. Allow the "power" switch
to initiate the system shutdown and then let the system remove power. Of
course, this is a hardware change and in this case the replacement CPU
board is supposed to be a drop-in replacement.

The fact that it may do it 100 times in a row and not fail is not great

Noooo, it is STILL pie-in-the-sky because, as far as I can remember back up
this thread, no one has experienced an actual failure, only imagined that
it is possible, which gets back to my original question: is this a real
problem?

It is only an issue with regard to your own expectations. Do not disparage

I am not disparaging anyone. I am approaching this from an engineering
standpoint. When presented with a problem from a client/customer, the first
thing to do is to qualify the report. And I am not saying that it is NOT a
problem, only that it MAY be an IMAGINED problem where none exists. I have
no ego involved in all of this. I actually don't care if I am right or
wrong. I am presenting a counter thought process in an attempt to balance
the discussion. I would happily pay the $5 and then buy the beer for a good
laugh after the fact.

--
Brian Lloyd, WB6RQN/J79BPL
706 Flightline Drive
Spring Branch, TX 78070
brian@lloyd.com
+1.916.877.5067

Gentleman,

Tom Van Baak the (co)founder of this group has kindly asked you yesterday to stop this thread.

Please do so.

Sent From iPhone

On Feb 28, 2014, at 6:20, Didier Juges shalimr9@gmail.com wrote:

I agree with this. And it makes me wonder if someone on the list is now eyeing the SR 620 as the next classic instrument in need of a time nuts upgrade?

It would be very cool if in the end both the hp5370 and the SR620 can be turned into true timestamping counters, a la the Pendulum CNT-9x and the Agilent 53230.

/tvb

Hi

I agree that improving the basic accuracy is a bit of a stretch. The first thing to look for would be temperature sensitivity that you could take out with a correction table. In another post you beat me to the 200 MHz chain and it’s phase locking. One might be able to do something interesting with a digital filter on the PLL ...

Bob

On Feb 28, 2014, at 8:18 AM, Poul-Henning Kamp phk@phk.freebsd.dk wrote:

On 28/02/14 04:50, John Seamons wrote:

Early in the beta process there where an issue which caused incorrect
readings and thus higher noise. It was resolved as I recall and noise
level fell back to expected.

Cheers,
Magnus

On 28/02/14 14:18, Poul-Henning Kamp wrote:

What one possibly could do is to see if there is any round-off issues
that causes any noise. The interpolator does not have a number-magic
friendly gearing for decimal or binary numbers, unless you play some
magic with it. Rounding off causes the interpolator points to be
un-evenly distributed and by that adding a little noise to the measurement.

However, I would look at the 200 MHz systematics first. This was only to
show what you could possibly do to improve precision in software.

With a hotter CPU you can naturally do smarter auto-triggers and
auto-tunes and things like that.

Doing a CNT-90 like frequency estimator would indeed be possible and
provide better frequency measures.

Frequency drift estimator would maybe be a nice addition?

Cheers,
Magnus

In message 5311B3EB.1000409@rubidium.dyndns.org, Magnus Danielson writes:

The HP5370 firmware uses floating point to avoid exactly that issue,
and all the math I've traced is good and competent.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.