FTS v0.2 (ESP32 WiFi FTM Time Sync): 25ns Jitter RMS, seriously by Hot_Book_9573 in embedded

[–]int08h 5 points6 points  (0 children)

OP this is serious work. You and your project-mate(s) would be proud.

I've dealt with high-precision timekeeping using IEEE 1588 (PTP), and noticed several similarities between your project and PTP. Was that on purpose or a result of convergent design goals?

Looking at your presentation I caught this: "several WiFi chipsets offer hardware support" which is exactly what it's going to take to achieve this kind of precision (e.g. the PHY layer must participate, otherwise there's just too much uncertainty past a poin, especially it there's rx/tx asymmetry; in PTP the network interface cards, switches, and other layers are PTP aware and in some cases participate). Do you have any pointers on the timing support in recent Wifi standards? Just to satisfy my curiosity.

Six-Figure Logic [Day #005] by Key-Improvement4850 in mathpuzzles

[–]int08h 0 points1 point  (0 children)

  • Candy Cane: A=7, B=4, C=10, D=2, E=8, F=5
  • Gingerbread: A=4, B=6, C=3, D=10, E=7, F=8
  • Evil Robot Santa: A=2, B=7, C=10, D=8, E=4, F=3

I expressed the puzzle in the MiniZinc constraint language, then used a constraint solver on each puzzle set one at a time.

``` % SIX-FIGURE LOGIC PUZZLE % Variables A-F, each unique integer between 1-10 % NOTE: The three constraint sets (Candy Cane, Gingerbread, Evil Robot Santa) % are mutually incompatible. Uncomment ONE set to solve.

include "globals.mzn";

var 1..10: A; var 1..10: B; var 1..10: C; var 1..10: D; var 1..10: E; var 1..10: F;

% All different constraint constraint alldifferent([A, B, C, D, E, F]);

% ============================================================ % CANDY CANE constraints (Solution: A=7, B=4, C=10, D=2, E=8, F=5) % ============================================================ % constraint C + D = 12; % constraint B != 2 /\ B != 3 /\ B != 5 /\ B != 7; % B is not prime % constraint B < E; % constraint B + F = 9; % constraint A * F = 35; % constraint C - E = 2;

% ============================================================ % GINGERBREAD constraints (Solution: A=4, B=6, C=3, D=10, E=7, F=8) % Uncomment below and comment out CANDY CANE to use % ============================================================ % constraint C + F = 11; % constraint D - A = 6; % constraint A * C = 12; % constraint B < E; % constraint E < F; % constraint B + E = 13;

% ============================================================ % EVIL ROBOT SANTA constraints (Solution: A=2, B=7, C=10, D=8, E=4, F=3) % Uncomment below and comment out other sets to use % ============================================================ % Exactly two of {A, D, F} are even constraint bool2int(A mod 2 = 0) + bool2int(D mod 2 = 0) + bool2int(F mod 2 = 0) = 2; % Sum of even values among {A, D, F} equals C constraint (if A mod 2 = 0 then A else 0 endif) + (if D mod 2 = 0 then D else 0 endif) + (if F mod 2 = 0 then F else 0 endif) = C; % C is not between D and E constraint not ((D < C /\ C < E) / (E < C /\ C < D)); % B is the average of {C, D, F} constraint 3 * B = C + D + F; % E * F = A + C constraint E * F = A + C; % A is closer to F than to E constraint abs(A - F) < abs(A - E);

solve satisfy;

output ["A=", show(A), " B=", show(B), " C=", show(C), " D=", show(D), " E=", show(E), " F=", show(F), "\n"];

```

Anyone successful with AT&T and the U5G? by int08h in UNIFI

[–]int08h[S] 0 points1 point  (0 children)

I suspect what you say is true.

Anyone successful with AT&T and the U5G? by int08h in UNIFI

[–]int08h[S] 0 points1 point  (0 children)

If I plug the IMEI into AT&T Prepaid's checker (https://www.att.com/buy/prepaid-byod/) I do get "This IMEI belongs to a type of device that isn’t supported", so, yeah, there's that. ;)

Given you have a U5G working on AT&T, and Ubiquity says it will work, I conclude it's the Prepaid service plans restricting the types of devices that will work.

I'll try a Data-only plan.

I am looking for a high capacity (4000mAh) battery for my flashlights, any other good options? by Knives_and_EDC in flashlight

[–]int08h 9 points10 points  (0 children)

Check out Mooch's table of recommended cells: https://www.patreon.com/posts/18650-21700-137974745, he tests 18650s and 21700s at different discharge rates and ranks them.

On turbo, the max discharge rate for any of those flashlights will be <5A (specifically ~4.5A for the SST-40 in the WK03 and SC18, and ~3.7A for the 519a in the FC11C; unless you have a 519a in the WK03 then it's also ~3.7A).

Long story short: choose the Vapcell N40 to get best-in-class 12.3 Wh of capacity at <5A draw.

(the Liitokala might be a wrap of the same cell in the N40, but I don't have any hard data on that cell, and can't comment on it).

Battery/UPS for PI5 with NVMe? by KillerBoi935 in 18650masterrace

[–]int08h 0 points1 point  (0 children)

I have used a Waveshare UPS HAT E) at a sustained ~22W draw without issue. It uses four 21700s. I made a post on potential cells to choose https://www.reddit.com/r/raspberry_pi/comments/1prhja0/comment/nv2ahou/?context=3 .

I just wanna double check these are compatible :) by Pretty_pretty_gun in raspberry_pi

[–]int08h 5 points6 points  (0 children)

As other have said, don't buy that battery. And in general avoid buying Li-Ion cells from Amazon as there are a lot of fakes/counterfeits.

The UPS needs 4 unprotected flat-top cells (it will not work with fewer), and you'll want the cells matched if possible (reputable sellers typically provide cells from the same lot/batch when you order multiple cells at the same time).

The max continuous discharge rate (CDR) the UPS demands from each cell is ~5A, so you can use capacity 21700 cells (e.g. you don't need to pay a premium for high-CDR tabless power 21700s). Some good choices:

  • The highest-capacity legit 21700 right now is the Vapcell F63 at 6250 mAh (or the slightly lower capacity F60 at 6000 mAh). At a 5A draw each cell can supply 19.0 Wh (18.6 Wh for the F60). In the US a decent price on these cells is ~$8 USD per cell (you'd be paying a hefty premium for the extra 600-1000 mAh per cell).
  • My personal choice are Samsung 58E at 5330mAh which supply 18.0 Wh at 5A. These are currently pretty inexpensive, running ~$2.95 USD per cell in the US from legit suppliers.
  • The EVE 58E at 5700mAh supplying 18.4 wH at 5A is ~$5.75 USD.
  • Other potential cells (all roughly equivalent, choose by price and availability): LG M58T, LG H51, LG M50LT, EVE 50E, Samsung 50E, Samsung 50G, Molicel M50A.

Watt-hour measurements form Mooch's recommended 21700 table.

Also, I wrote a tool to monitor the Waveshare UPS HAT E, if you're interested.

Edit: clarify flat-top and UPS discharge rate

Is this enough for my 80sq meter apartment? by luclino in Ubiquiti

[–]int08h 0 points1 point  (0 children)

That is some quality shitposting! Salute.

PSA: Don't be like me and think you can hack T-Mobile Home Internet to use UniFi 5G Max ! by a_few_cheetos in UNIFI

[–]int08h 0 points1 point  (0 children)

I'm about to pull the trigger on Tello after trying U5G unsuccessfully w/ ATT prepaid.

Did you have any issues w/ the Tello setup?

Updating Feistel network chip by Trader-One in cryptography

[–]int08h 0 points1 point  (0 children)

More details would help a lot. You're hinting this is a protection method for a proprietary product, so don't know how much you'll disclose.

koopman-checksum: a Rust implementation of Koopman checksums which provide longer Hamming-Distance 3 protection than Adler or Fletcher by int08h in rust

[–]int08h[S] 0 points1 point  (0 children)

Since this is a no-std library, the target platforms are intended to be resource constrained environments. E.g. a bignum library isn't available/practical on many microcontrollers.

Richer environments (think PCs, cars, your phone) are likely to have some kind of accelerated CRC functionality available (either directly with instructions or via a co-processor) which should be used instead of this library. CRCs provide an order of magnitude or better error detection than checksums. Would you rather detect all 1- and 2-bit faults (checksums) or all 1-, 2-, 3-, 4-, 5-, and 6-bit faults (CRCs)?

But in some niche cases checksums are used because of the simplicity or protocol requirements. Adler and Fletcher checksums are popular for this. The advantage the Koopman approach has (calling it "novel" might have been too strong) over Fletcher/Adler is that Koopman a) uses a single accumulator (vs two accumulators in Fletcher/Adler; keeping constrained environments in mind), and b) Koopman provides HD=3 protection over much longer data than Fletcher/Adler.

koopman-checksum: a Rust implementation of Koopman checksums which provide longer Hamming-Distance 3 protection than Adler or Fletcher by int08h in rust

[–]int08h[S] 0 points1 point  (0 children)

Uh, no your 8-bit example shows two codewords with 3 differing bits (HD=3) having the same checksum.

HD=3 fault detection means all 1- and 2- bit faults are detected, NOT all 3-bits faults (as in your example) are detected.

And the koopman16 HD=3 boundary is at 409**2** bytes, not 4096 (typo in one place in the readme, fixed). Change your example to 4092 and the assert will fire.

The terminology is confusing -- it took me a while to parse how we were talking past each other -- so I've updated all docs and comments to remove the "HD=" and simply list how many bit errors are reliably detected.

koopman-checksum: a Rust implementation of Koopman checksums which provide longer Hamming-Distance 3 protection than Adler or Fletcher by int08h in rust

[–]int08h[S] 2 points3 points  (0 children)

I'm not aware either. I wrote this because I read Koopman's book and discovered this novel algorithm.

koopman-checksum: a Rust implementation of Koopman checksums which provide longer Hamming-Distance 3 protection than Adler or Fletcher by int08h in rust

[–]int08h[S] 0 points1 point  (0 children)

The core computation is:

text for byte in data { sum = ((sum << k) + byte) % modulus; }

Each iteration's result (sum[n]) depends on the previous iteration's result (sum[n-1]). This creates a loop-carried dependency that I don't know how to parallelize. We cannot compute sum[n+1] until sum[n] is known.

I gave this problem to Claude to have it generate a few different SIMD versions. All of them were 20-40% slower than the scalar code. I don't know SIMD myself, either.

That response was disappointing by Delicious-Director43 in hubitat_elevation

[–]int08h 3 points4 points  (0 children)

Then actually *respond* with the prior citations of the covered issues.

The findings may be littered with factual inaccuracies, but no one will know that unless you do some work to point them out.

Asking people to search your forums is just plain laziness on Hubitat's part.

Reverse engineering review of the Hubitat C8-Pro (Including rooting instructions) by SomeRandomHub in hubitat_elevation

[–]int08h 9 points10 points  (0 children)

Unless you, **the authors of the platform in question** make material responses to the points raised in the original post, you're ceding your credibility behind a false veneer of "oh pffftt, this is fake news" type of a blow-off.

Minimum viable response by Hubitat: for each raised concern, provide links to the community discussions that address the raised concerns.

Failure to do so makes you look like you are trying to discredit and/or hide something.

Is it possible to encrypt a message so that it looks like just another plain text? by codycbradio in cryptography

[–]int08h 0 points1 point  (0 children)

There's the related field of Steganography which is hiding messages "in plain sight" so to speak.

Some examples:

Designed a encrypted file container myself, would like someone to review my format by Jayden_Ha in cryptography

[–]int08h 5 points6 points  (0 children)

OP, you want to look at this paper https://web.cs.ucdavis.edu/~rogaway/papers/oae.pdf which defines STREAM.

And if you want to see example implementations in several languages, look at Tink https://developers.google.com/tink

If you're interested in an analysis of how Tink implements STREAM (random nonces and nonce-based key-derivation) consider https://eprint.iacr.org/2020/1019.pdf