blue_led

@blue_led@kif.rocks

#ActuallyAutistic #electronics #mudbyte

I follow based on interests, prioritising so that I can actually read most posts rather than just doomscrolling. Please don't take it personally if I don't follow back or unfollow after a while.

This profile is from a federated server and may be incomplete. Browse more on the original instance.

azonenberg, to random
@azonenberg@ioc.exchange avatar

Back from a fun couple of days in Bochum presenting at the second Hardware Reverse Engineering Symposium (HARRIS) hosted by the Max Planck Institute for Security and Privacy.

The talk was titled "Secure Element vs Cloners: A Case Study". Slides will be uploaded shortly, I'll share a link here when I've had a chance to do that.

As part of this research, I and the other IOA silicon lab folks examined two generations of an undisclosed consumer product with cryptographically vendor-locked peripherals, as well as a third party clone that appeared on the market shortly after the second-generation OEM hardware design was released (implying the DRM scheme was broken as a result of a weakness in the new-gen product). We also speculate on some of the market forces that may have lead to some unusual design decisions made by the cloner.

This work is ongoing and we hope to present a deep-dive at REcon this summer with more extensive analysis. The HARRIS talk was only 15 minutes so I had to cut a lot of detail out.

blue_led,

@azonenberg
Sounds really interesting. Is there a recording and/or a set of slides? (Didn't find any on the harris2024 website).

chipperdoodles, to random
@chipperdoodles@chaos.social avatar

ugh i'm designing another old apple keyboard replacement again

blue_led,

@jaseg @chipperdoodles
FWIW I'm currently using HY2112 (protection) + CN3058E (charger) for LiFePO4 cells. Not sure how good they are but they work. They are pretty bare-bones; no state-of-charge / capacity tracking or anything else that would require a communication interface.
Using ready-made modules for prototyping for now; haven't finished any project with integrated charger yet.

blue_led,

@jaseg @chipperdoodles
The datasheets I've found for LiFePO4 cells are 3.2V nominal and 3.65V charge cut-off voltage. https://batteryuniversity.com/article/bu-409b-charging-lithium-iron-phosphate lists the same values. I'm not aware of LiFePO4 with 3.7V nominal; that sounds more like LiMn2O4 (https://batteryuniversity.com/article/bu-205-types-of-lithium-ion).

HY2112 has different variants with different voltage thresholds but they're all in the LiFePO4 range. CN3058E can be adjusted using a resistor on the feedback input and would probably work for chemistries with a higher cut-off voltage, too.

18+ ktemkin, (edited ) to random
@ktemkin@chaos.social avatar

opinion time: what’s the appropriate number of hardware tokens / HSMs to have?
(smartcards, yubikeys, hard u2f tokens, pkcs11/15/piv-card, whatever term you use for your variant~)

blue_led,

@ktemkin
Key material split using Shamir's Secret Sharing to a diverse set of people, using different technologies (GPG encrypted, QR code printout). I can still recover even if one of them is unavailable for whatever reason. Collaboration between / coercion of several of them is required to assemble the key without my knowledge.

azonenberg, to random
@azonenberg@ioc.exchange avatar

It's official, I'm speaking next month at the HARRIS 2024 Hardware Reverse Engineering symposium at the Max Planck Institute for Security and Privacy in Bochum, Germany.

Registration for the event is still open if anyone wants to join.

Also, second ping if anyone in Germany is looking to get together near Bochum around the time of the event.

https://harris2024.mpi-sp.org/event/#harris24-5-secure_element_vs_cloners_a_case_study

blue_led,

@azonenberg @CyReVolt
I'm currently trying to recover from burnout and while the conference might actually be interesting, it would still take a lot of my energy and cost more than I'm comfortable spending in the current situation (including accommodation and entry for two). Maybe next year if the situation is better then.

Let me know if you ever happen to be close to the Stuttgart area (unlikely I know 🙂).
2/2

blue_led,

@azonenberg @CyReVolt

TL;DR: not this year

I considered it for a few days (would have been a great opportunity to meet you in person) but ultimately decided not to, for reasons similar to those of @gsuberland.
Travel is over 4h one way so a day trip to only meet up (outside of the conference) is not really an option (would run out of spoons on the way back).
Attending the conference (and staying in a hotel) is not an option either this year.
1/2

ktemkin, to random
@ktemkin@chaos.social avatar

techbros be like “we should do things just based on their technical merits” but I don’t see any of them changing their legal names to UUIDs or setting their watches to UTC

blue_led,

@azonenberg @ktemkin
They would just make it easier to communicate the UUIDs. The same way the insane amount of paper we send around for bureaucratic purposes is only possible because of computers+printers. (I had to send >500 pages today for the 4-yearly social security audit, i.e. over 100pages/year, for just 2-3 employees).
I would usually mention that having a GUID as legal name has significant drawbacks, but your name seems to be at least close to unique, too, so you probably know that yourself.

ratcatcher, to actuallyautistic
@ratcatcher@c.im avatar

The two most important features of @trunksapp for me are:

It keeps my place in my home feed. So even if I close and later reopen the app (or open it on a different device), I am taken to the point where I left off. It's not perfect, but it mostly works.

It fetches context for posts, so rather than just seeing the latest post in a thread as an "orphan", I see the post it was in reply to (and sometimes the whole thread).

Do any of the other apps have these features (Android version in my case)?

My only reason for considering switching (and this will seem trivial to anyone who is not ) is that Trunks does not currently allow one to turn off animated emoji in a person's username or the post itself. I just can't read posts when something on the screen is moving or flashing. Sometimes I can cover the offending item with my thumb, but that's not always possible, particularly if there are multiple animated emoji. I have had to mute 40 or more people simply because they have animated emoji in their username.

@actuallyautistic

blue_led,

@ratcatcher @trunksapp @actuallyautistic
Fedilab can keep the position across restarts, too, but has very annoying "jumping around" behaviour while scrolling which can make you lose position (seems to be related to older posts moving up in the timeline because of boosts that are encountered when loading additional messages). I'm using Fedilab because it supports lists that allow sorting followed accounts (though no hashtags) into categories, but the jumping around is driving me nuts.

ktemkin, (edited ) to random
@ktemkin@chaos.social avatar

now that KiCad has quite-decent Altium import capabilities, what's your opinion on the debate of whether it's fully "open hardware" if the sources are Altium, an expensive/closed tool?

blue_led,

@ktemkin
FWIW I answered "not open enough" because the question was about fully open hardware. It may be good enough for many (possibly most) practical purposes, but having to import and export every time instead of editing natively can range from annoying to impossible. I admit I haven't looked at the Altium file format in detail, but chances are high it's at least subtly different from the KiCad data model and not everything will survive a round trip (including editing!) properly.
1/2

blue_led,

@ktemkin
I'd rather have a file that's importable into Kicad than no sources at all (and thanks a lot to @gsuberland for making that possible!), and as mentioned elsewhere in the thread with hardware there's always a bit shades of grey. I just wouldn't use the term "fully open hardware" for something that uses a proprietary file format, the same way I wouldn't call a Word document open source.
2/2

azonenberg, to random
@azonenberg@ioc.exchange avatar

So it looks like I'll be getting a UV-VIS-NIR spectrometer (ASEQ LR1 configuration B, 200-1200 nm) soon.

Anybody have some random LEDs or other small light sources they want characterized? I'm initially getting it in a receive-only configuration with cosine corrected fiber input, but plan to add sources and probes to do reflectance and transmittance measurements in the future.

blue_led,

@azonenberg
That would be awesome! I'm especially interested in how the spectrum changes with current as that's not shown in any of the datasheets but often given as a reason for preferring PWM over "analog" dimming (i.e. changing the current). Would you be willing to measure a range of currents for each LED?
1/2

blue_led,

@azonenberg
What should the interface look like for a) "analog" (i.e. without integrated driver) and b) digitally controlled LEDs? Should I include a current source for the analog LEDs and control them via the digital interface or will you hook up an external current source (you probably have a more accurate programmable current source than I can put on the board)? UART with line-based request/response for digital? Any preferences regarding form factor, mounting holes, LED positions etc.?
2/2

blue_led,

@azonenberg
Most are low-current LEDs; no high-power LEDs. I'll include a current source. Will take me a while to design and build, hope that's OK.
I have 35 types in stock (32 analog). As curious as I am I would measure all types and 3 of each type to see variation (over 100 LEDs in total) but that sounds like way more than I can ask you for. I don't want to wear out my welcome, so to speak (very grateful you're doing it at all). What would you consider a reasonable number?

blue_led,

@azonenberg
(If you prefer a single board for all LEDs after all, just let me know. It's still in the early design phase anyway.)
BTW, anything I can / should do to help with the optical coupling? Not sure how sensitive the LR1 is (what I found only talks about "counts", not mW resp. mW/sr) and how much of a problem external light "leaking" in can be.
2/2

blue_led,

@azonenberg
🤩 Will do. Originally planned to do a single PCB with 3 LEDs of each type in series. Now I'll do a driver PCB (1x) and separate LED PCB (3x) with connectors (probably 2.54mm headers for simplicity) between them so the LEDs can be swapped out. A bit more work during measurement if you actually end up measuring all of them as you need to swap the board (which the CNC probably can't do), but might simplify the current source (lower voltage).
1/2

blue_led,

@azonenberg
I don't mind duplicating the driver part (microcontroller, current source, multiplexing etc.) as well if that makes things easier for you to handle. Just thought it would not make much difference for handling (one large connector instead of two smaller ones) and would be easier to build and maybe even reusable in the future.

blue_led,

@azonenberg
Wouldn't a single board with all of the LEDs on them work better for that purpose? I would arrange them so that the most interesting (to me) LEDs come first and the same-type ones in separate rows so that you can simply stop whenever you want.

blue_led, to Electronics

Prototyping a DIY battery holder for CR1216 coin cell batteries. An upcoming project needs to fit within a height of ≈3mm. The commercial CR1216 holders I found already exceeded that, not even counting PCB thickness.
As I feared my holder a bit loose but after putting a metal dome (intended for keys) on the bottom pad the battery stays in place and connected even with a bit of shaking (important for the use case). Slipped out during an (accidental) 1m drop test but probably good enough.

same holder but view more from the top

blue_led,

@azonenberg
Interesting idea, thanks for the tip. For this project I'll probably do it a different way (placing the "open" side of the battery holder facing inwards during mounting and then fixing the entire PCB with hot-melt adhesive inside the "case"), but I'll keep it in mind for the future.

blue_led,

@azonenberg
Come to think of it, putting hot-melt adhesive on the sides would be an idea, too. It should be strong enough to hold the battery during nondestructive impacts and can be peeled off to change the battery. Needs to be redone on every battery change but hopefully that won't be very often.

blue_led,

@azonenberg
Hmm, good point. The HMA should be around 175°C (at least that's what the gun says...) which is considerably above the specified operating temperature of 70°C. It's just for a very short time and only touching part of the metal surface so it might be fine if applied sparsely but it's definitely a risk. I wouldn't mind if the risk is just reduced battery life but we're talking about a Lithium battery here... 🔥

blue_led,

@azonenberg
Hmm, might be a good excuse to try out the UV glue I bought a while ago. Do you happen to know how easy it is to remove again from a PCB (for the ones you tried)?
I applied some UV glue (of a different type, provided by the customer) to a couple of prototypes before, but never tried to remove it.

gsuberland, to random
@gsuberland@chaos.social avatar

TI LP5036 is an interesting looking IC for multi-channel constant-current LED dimming.

I2C with 4 addresses. it's got 36 constant-current PWM channels capable of sinking 35mA per channel, internally it's using 9-bit PWM at 29kHz + 3-bit temporal dither.

takes an 8-bit brightness value per 3 channels, plus an 8-bit colour value per channel, which it maps to that 12-bit space. it also supports "logarithmic mode" brightness which has a weird EOTF but is better than linear control.

~£1.50 @ qty10

blue_led,

@gsuberland
They're clamped to 2^d, i.e. shortest pulse length (150ns at 28kHz according to my notes) without any dithering. Only 0 results in turning it off completely.

blue_led,

@gsuberland
Well, they could have shortened / skipped pulses for temporal dithering instead of prolonging them. Not sure what impact that would have on the complexity of the control circuit, though. In software the difference would be trivial but I'm not sure for dedicated hardware.
You would end up with a lower effective PWM frequency at lowest brightness, of course. That could also have been a factor.

blue_led,

@gsuberland
Hmm, wouldn't the need to somehow synchronise updates apply regardless of whether you shorten or prolong pulses for temporal dithering? The chip does implement it, just with the catch that the values 1..2^d are mapped to 2^d, losing resolution at the lower end where it hurts the most.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • JUstTest
  • Durango
  • thenastyranch
  • osvaldo12
  • magazineikmin
  • GTA5RPClips
  • rosin
  • InstantRegret
  • Youngstown
  • slotface
  • ngwrru68w68
  • kavyap
  • khanakhh
  • DreamBathrooms
  • megavids
  • mdbf
  • everett
  • ethstaker
  • normalnudes
  • cisconetworking
  • tacticalgear
  • cubers
  • modclub
  • provamag3
  • Leos
  • tester
  • anitta
  • lostlight
  • All magazines
    •