Connor Wolf

They're in no way saying "this cannot happen", just "the hypothesis we have so far appears to be inadequate to properly explain the observations"

To be clear, both articles explicitly are talking about one specific hypothesis about abiogenesis. The mechanisms of abiogenesis are far, far less understood then other things (common descent, evolution, both of which are so well supported by evidence that if you are claiming to not have some confidence in them being at least broadly correct, you are a crank).

That chemistry article you link in no way supports a non-materialistic perspective. It only says "this particular theory may not completely explain this thing". Just because we don't fully understand something does not mean you can claim (with no evidence) that god did it. The same is true for abiogenesis. The fact that we may not know how something happens is just indicative that we don't know how something happened, not that it had to be magic.

There are literally more scientists named steve then there are that agree with your claim that it's problematic (note: this is talking about it in broad strokes. There is debate about specifics of things like common descent, but none of that has any relation to the general acceptance of the theory).

@Matthew This is unambiguously horsesh*t.

If you have some mechanism that's trying to measure the bar's length, that structure will change size with the ambient temp as well, so no matter what you do you need to either: 1. know the temperature of your measurement apparatus (or the bar) well enough to compensate for it's expansion, or 2. have some sort of invar structure. Since the latter is much harder, just do the first.

@tofro - ARM MCUs come in a lot of flavors. Generally, the "real time" ones don't have things like I-Cache/D-Cache and all the bits that make things unpredictable. In fact, many multi-core implementation s have a small cache-less coprocessor integrated because it makes doing deterministic timing much easier. For the smaller variants (Cortex M, generally), you absolutely can calculate deterministic timings in most cases.

@wavscientist - A lot of this stuff was explored in the 80s. There didn't use to be the current x86/ARM monoculture. There used to be lots of different processor architectures that explored different ways to get more performance out of the same clock-rate.

@JohnDvorak - I dunno, I haven't been paying attention, but it's SystemD. It's generally safe to assume they've chosen the dumbest/worst option in any case (A DNS resolver? Really?).

@mbrig - It was the opposite. Systemd mounted some EFI variables as R/W by default, and then rm -rf / --no-preserve-root would clobber them, which bricked some poorly implemented motherboards. In predictable SystemD fashion, they then handled the issue extremely badly.

@B.fox - Try reading the editing help? Or look at the sidebar instructions that pop up just to the right of the text entry dialog

Actually, there could be some weird internal thing where it doesn't send messages until it has an ephemeris, but that'd be very dependent on this one particular receiver

(this is assuming you're not using an internet-based almanac preloading thing)

I assume cold-starting takes a LONG time (many minutes, it has to re-retreive the almanac), but warm/hot should be closer

Hot start I think just de-synchronizes the receiver. Warm start does that and discards the ephemeris. Cold starting drops everything

Yeah, I think we've been talking at cross purposes a bit (I wasn't too clear what you were asking), but ok?

I'd assume the reset mechanism for a hot start doesn't flip whatever flag you've enabled that blocks message transmission until the unit has a lock

That's an implementation detail of this particular GPS, though

Possibly?

so..... what's the problem

basically, that's a completely expected context, and you will need to be able to handle that behaviour gracefully, because that's what you'll get on a loss-of-fix too

and the date/time is probably not valid either, unless you have a RTC somewhere

The fact that your GPS doesn't do that on warm or cold starts is actually odd

yeah, that's basically completely normal

every GPS I've ever seen emits things like GPGGA continuously no matter what the lock state, unless I've turned of NMEA mode.

Wait, is this a valid but non-fixed NMEA message, or an actual empty string?

I'm not sure why this particular GPS doesn't emit at minimum GPGGA messages continuously

Are you now discussing startup speed?

So?

What happens if the tracker goes into a tunnel or an urban canyon (I'm not sure where it's supposed to be used). Unless this is going on a very, very large boat or a fixed installation on a roof, you have to handle loss-of-fix situations, because they're inevitable

I guess I don't know what the problem is. If you can handle the system not having a lock at power on, how is this different?

what do you do if it doesn't have a lock? Just do that

Basically, it sounds like you're assuming you will only ever get valid position fix messages from the GPS. This is just not true. You need to filter the messages yourself

I mean, you should already be doing that, because if the GPS loses it's fix, you will get messages with an invalid fix

You just need to ignore messages that aren't valid?

been a while since I looked at NMEA anything

"No fix?"

derp. Yeah, so it's "N" then

I have no idea what "K" means in terms of fix status (Kinematic?)

so if you're lucky, you don't need a stateful decoder because all three messages you care about have fix validity indicators

The relevant thing here is I think if it's not "D", it means there's no fix

Your GPS is a MT3333 based unit

I'm referencing the document here: microchip.ua/simcom/GPS/SIM68M/Application%20Notes/…

Ok, the MTK documentation for the GPVTG message says the last section is a fix mode indicator

Your GPVTG message has a flag in a "reserved" section (the "M"). It's possible it's a mediatek extension that indicates something relevant

so even if you cold-start the unit, if you block reception for a short period of time, you've basically hot started it

I'm saying blocking the antenna for a short period of time basically is a hot start

Also, GPRMC has it's own validity flag (the "V" means the fix is invalid)