the fir filter produces stable frequencies per frame,
but learning per sample (within a frame) means we
record the same value roughly 240 times.
here, we are syncing up at just the right moment
instead, and only at that moment, this increasing
both performance and reliability.
Signed-off-by: Leah Rowe <leah@libreboot.org>
oops!!!
another mistake during refactoring. right now it
doesn't increment before being checked, so learning
can go forever in an infinite loop
Signed-off-by: Leah Rowe <leah@libreboot.org>
i conflated two separate tests in a previous change.
the silence check was defeated by still checking f
alongside it, which would be set, thus satisfying
the condition, and proceeding, which defeats the
purpose of the silence check (ignore false signal
that is actually noise) - so in the original patch
that i wrote, the extra checks actually do nothing.
this patch fixes that, and makes the logic a bit
clearer.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the tone detection currently only tracks data, not
the separator. track both instead, for improved
detection reliability.
e.g.
separator tone ≈ 9
data low tone ≈ 18
data high tone ≈ 24
two fir windows produce e.g.
freq data 9 sep 0
then 18, 9
then 24, 9
18, 9
so we take min(data, separator)
that gives 9,9,9,9
now we have the separator cluster
however, if both windows are active during transitions,
you can also capture the higher clusters, which would
allow freq_max to grow
so when you learn e.g.:
freq min = 9
freq max 24
then the learned threshold would be:
(9 + 24) / 2 = 16
and now you know how to separate the tones
fir already suppresses noise so the pulse should
be reliable. so freq/sep only go non-zero when an
actual tone exists
this should now result in being able to sync with
spkmodem encoders with no prior knowledge of the
correct tone frequences. we just use maths.
Signed-off-by: Leah Rowe <leah@libreboot.org>
since we have auto-detection now, we only need to know
that two signals exist, not that they are valid, since
the auto-detection now handles validation and fallback.
Signed-off-by: Leah Rowe <leah@libreboot.org>
a continuation of the previous patch. this waits for
currently one second, before defaulting to the hardcoded
value. otherwise, it tries to use whatever timing it
gets automatically.
this way, the program should now reconfigure its own
timing, without intervention by the user, if the timing
differs from sensible defaults.
this is because spkmodem is implementation-defined;
it's just however coreboot and/or GRUB happen to set
it up, and on the hardware in question.
Signed-off-by: Leah Rowe <leah@libreboot.org>
current logic is hardcoded, as in the original spkmodem-recv.
with this change, small differences are observed and averaged,
then the detection thresholds are adjusted accordingly.
the existing macros serve as a baseline, but real signals
differ. with this change, we therefore account for possible
drift in timings, which can change in real-time; the old
code could possibly get out of sync beccause of that, which
may have resulted in corrupt characters on the screen. this
change therefore should make the output a bit more stable.
the detection window is continually adjusted, so that the
output timings don't drift.
the tolerances are automatically adjusted based on base
timings (see new define in patch)
Signed-off-by: Leah Rowe <leah@libreboot.org>
instead of when it goes above, do it precisely on the
timeout. otherwise, if by sheer chance the signal
pauses and we reset the byte - sure, ok, but it's a
bit tight and we run the risk of advancing another
frame, depending on the timing.
this is a minor edge case, probably rarely ever
triggered in practise.
Signed-off-by: Leah Rowe <leah@libreboot.org>
and with this, i'm now pretty much done modifying grub's
crappy code. this experiment started in 2023 has now
pretty much concluded.
the original GNU code was poorly written, hardcoded
everywhere, and not documented or commented at all.
i had to learn what the code is doing through inference
instead, and i'm pretty sure that these explanations
cover everything. i hope?
maybe the frenchman can explain anything i missed. haha.
Signed-off-by: Leah Rowe <leah@libreboot.org>
yet another optimisation for weaker compilers - but
some modern compilers may not optimise well for this
code either.
this reduces the amount of references to the struct,
which is very expensive (48000 times per second) on
very old CPUs.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the frame[] array is never actually used meaningfully.
that setting of frame[ringpos] on the decode_state is
only set here, but then the value isn't really used at
all. the entire size of the annay is used for sizeof
in print_stats, but then we can just declare that
manually. since we also know that this value never
changes, we can use a global define for the sizeof entry
in print_stats, thereby simplifying operation further
Signed-off-by: Leah Rowe <leah@libreboot.org>
make it easier to read by clearer variable naming.
this change also reduces memory accesses (fewer struct
dereferences - see: struct decoder_state), when using
much weaker/older compilers that don't optimise
properly. this, in the most active part of the code,
which is called.... 48000 times a second. peanuts on
modern CPUs, but on old (early 90s) CPUs it makes a
big difference.
Signed-off-by: Leah Rowe <leah@libreboot.org>
only use the old fallback, or /dev/urandom
/dev/random blocks on some older unix machines,
or in embedded environments that may never
have enough entropy, causing the code to hang.
urandom is most certainly expected to exist on
pretty much anything since the mid 90s.
i could probably re-add the arc4random setup
for BSDs. i'll think about it. gotta do that
portably too.
Signed-off-by: Leah Rowe <leah@libreboot.org>
if someone calls rhex fast enough, the timestamp
may not change. this mitigates that by adding
a counter value to the mix
Signed-off-by: Leah Rowe <leah@libreboot.org>
